Kipmi0 zjada do 99,8% procesora na centos 6.4

15

Mamy CentOS 6.4 i kipmi0pokazuje jako 99,8% procesora i 0,0% pamięci, a średnia wartość obciążenia wynosi 1,00. Co powinniśmy zrobić, aby to naprawić?

biz14
źródło
powinieneś zacząć od przeczytania tego www-01.ibm.com/support/…
squareborg
2
@ Przeczytałem go wcześniej, więc mówi tylko zignoruj, czy powinienem to zignorować, ale moje inne maszyny nie mają tego problemu?
biz14
Czy inne systemy są identyczne z tym systemem? Musisz ustalić, że są. Musi być coś zasadniczo odmiennego między nimi. Firmware? Te same wersje RPM?
slm
@Tak są dwie takie same maszyny z tymi samymi centos 6.4, czego powinienem teraz szukać?
biz14
Porównaj wyniki z lshwi dmidecodebędą moimi następnymi obszarami do zbadania.
slm

Odpowiedzi:

5

Debugowanie problemu

Czy inne systemy są identyczne z tym systemem? Musisz ustalić, że są. Musi być coś zasadniczo odmiennego między nimi. Firmware? Te same wersje RPM?

Można użyć narzędzi, takich jak lshw, dmidecodei patrząc w dmesgdzienniku wskazówek co do tego, co jest inaczej, a co przyczyną.

Dostałbym dobrą linię bazową zainstalowanych RPMów, uruchamiając to polecenie na jednym z systemów, w których nie występuje ten problem, i na tym, który jest, i porównuję listy pakietów, aby upewnić się, że wszystkie są w tej samej wersji.

 # machine #1
 $ rpm -aq | sort -rn > machine1_rpms.txt

 # machine #2
 $ rpm -aq | sort -rn > machine2_rpms.txt     

Następnie pobierz pliki na ten sam komputer i wykonaj sdiff z 2 plików:

 sdiff machine1_rpms.txt machine2_rpms.txt

Potencjalna przyczyna # 1

Witryna IBM nosi tę notkę techniczną: Kipmi0 May wykazuje zwiększone wykorzystanie procesora w systemie Linux w związku z tym problemem. Zgodnie z tym problemem można zasadniczo zignorować problem.

opis problemu

Proces kipmi0 może wykazywać zwiększone wykorzystanie procesora w systemie Linux. Wykorzystanie może wzrosnąć do 100%, gdy urządzenie IPMI (inteligentny interfejs zarządzania platformą), takie jak BMC (kontroler zarządzania płytą główną) lub IMM (zintegrowany kontroler zarządzania), jest zajęte lub nie odpowiada.

Naprawić

Nie wymaga naprawy. Należy zignorować zwiększone wykorzystanie procesora, ponieważ nie ma to wpływu na rzeczywistą wydajność systemu.

Obejść

  1. Jeśli używasz urządzenia IPMI, zresetuj BMC lub uruchom ponownie system.
  2. Jeśli nie używasz urządzenia IPMI, zatrzymaj usługę IPMI, wydając następujące polecenie:

    usługa ipmi stop

Potencjalne rozwiązanie # 2

Znalazłem ten post na czyimś blogu pod tytułem: problem z kipmi0 . Ten problem brzmiał identycznie jak twój. Problem został przypisany do problemu z 2 modułami jądra, które były ładowane jako część lm_sensorspakietu.

Były to 2 moduły jądra:

  • ipmi_si
  • ipmi_msghandler

Obejść

Możesz je ręcznie usunąć za pomocą następujących poleceń:

rmmod ipmi_msghandler
rmmod ipmi_si

Aby ta poprawka stała się trwała, musisz wyłączyć ładowanie tych konkretnych modułów jądra w jednym z lm_sensorsplików konfiguracyjnych, komentując je w następujący sposób:

# /etc/sysconfig/lm_sensors
# MODULE_0=ipmi-si
# MODULE_1=ipmisensors
# MODULE_2=coretemp

Uruchom ponownie lm_sensorspo wprowadzeniu tych zmian:

/etc/init.d/lm_sensors
slm
źródło
Byłem zarówno na stronie internetowej, jak i w moim systemie Nie znalazłem tego pliku / etc / sysconfig / lm_sensors. Coś zabawnego, gdy robię sortowanie pierwszego pliku, to Asc, ale drugi plik to desc? Po drugie, jak wyprowadzić różnicę do pliku. Tak, widzę też sporo różnic.
biz14
tak, teraz zrobiłem drugi raz, gdy jest posortowane odpowiednio malejąco. Nie rozumiem, jak używać grep „|”. Co jeszcze powinienem zrobić, aby rozwiązać ten problem?
biz14
Wszystko, co powiedziałem, to zrobić: sdiff machine1_rpms.txt machine2_rpms.txt | grep "|"wyciągnę wszystkie różnice między dwoma plikami .txt. Istnieją inne sposoby, aby to zrobić, ale to jeden sposób.
slm
Uruchomiłem to polecenie i oto dane wyjściowe sdiff 12_rpms.txt 11_rpms.txt | grep "|" perl-DBI-1.609-4.el6.x86_64 | perl-Digest-SHA-5.47-131.el6_4.x86_64. 12_rpms jest maszyną problemową, a druga nie ma problemu. Ale kiedy ręcznie wyglądam, 12_rpms ma 247 linii, a 11_rpms ma 263, ale sdiff jest tylko jeden? Więc jaki powinien być mój następny krok w oparciu o tę różnicę?
biz14
Opublikuj te pliki również na pastebin.com .
slm
24

Zgodnie z dokumentem IPMI :

ten wątek może zużywać dużo procesora w zależności od wydajności interfejsu. Może to zmarnować dużo procesora i powodować różne problemy z wykrywaniem bezczynności procesora i zużyciem dodatkowej mocy. Aby tego uniknąć, kipmid_max_busy_us ustala maksymalny czas (w mikrosekundach), w którym kipmid będzie się kręcił przed snem po tyknięciu. Ta wartość określa równowagę między wydajnością a marnotrawstwem procesora i musi być dostosowana do twoich potrzeb. Być może kiedyś zostanie dodane automatyczne dostrajanie, ale to nie jest prosta rzecz, a nawet automatyczne dostrajanie wymagałoby dostosowania do pożądanej wydajności użytkownika.

Możemy więc wykonać to polecenie, aby ustawić parametr kipmid_max_busy_us:

echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us

W naszym systemie, po ustawieniu tego parametru, procesor kipmi0 spadł do 15%.

Możesz tego spróbować.

Aby zmiany były trwałe, możesz skonfigurować opcje dla modułu jądra ipmi_si.
Utwórz plik /etc/modprobe.d/, tj. /etc/modprobe.d/ipmi.confI dodaj następującą treść: Teraz za każdym razem, gdy moduł jądra ipmi_si jest ładowany do jądra, parametr powinien być ustawiony automatycznie i poprawnie.
# Prevent kipmi0 from consuming 100% CPU
options ipmi_si kipmid_max_busy_us=100

d0ngw
źródło
Chociaż może to być poprawna odpowiedź, za najlepszą praktykę na stronach SE uważa się szczegółowe uzasadnienie w ramach odpowiedzi, a także cytowanie wszelkich linków zewnętrznych. W ten sposób, jeśli link zewnętrzny przestanie działać, logika i rozumowanie będą nadal widoczne tutaj.
Drav Sloan,
Czy istnieje standardowy sposób na wprowadzenie tego w życie na stałe?
tgharold
W CentOS / RHEL to polecenie można zmienić na stałe, dodając je do /etc/rc.d/rc.local. Plik rc.local działa po wszystkich innych skryptach inicjujących.
tgharold
1

kipmi0 można całkowicie wyłączyć na CentOS 6, dodając ipmi_si.force_kipmid=0jako parametr jądra

Przetestuj na ekranie rozruchowym GRUB-a, zaznaczając jądro, które chcesz uruchomić, naciśnij „a”, aby zmodyfikować parametry i dołączyć ipmi_si.force_kipmid=0

Ustaw na stałe, dołączając ipmi_si.force_kipmid=0do odpowiednich linii jądra w/boot/grub/grub.conf

UWAGA: W dystrybucjach, które mają ipmi_si jako oddzielny moduł jądra, bardziej odpowiednie jest użycie pliku modprobe.d conf. W CentOS ipmi_si jest wbudowane w obraz jądra, więc konfiguracje modprobe nie działają.

Dev
źródło
1

CentOS 6 ma sterownik ipmi skompilowany w jądrze. Jeśli nie potrzebujesz obsługi ipmi, wyłącz ją po prostu grub.conf

ipmi_si.tryacpi=0 ipmi_si.trydmi=0 ipmi_si.trydefaults=0
użytkownik72911
źródło
1

Znalazłem następujące rozwiązania tego problemu:

ipmitool bmc info

Wydaje się, że to budzi IPMI, a następnie przestaje używać 100% rdzenia.

Znalazłem również następujące pomocne:

echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us

W przeszłości byłem w stanie na niektórych serwerach rozwiązać 100% wykorzystania procesora poprzez:

ipmitool lan print

i

ipmitool bmc reset cold

ale z mojego najnowszego doświadczenia wynika, że powyższe opcje spowodowałyby, ipmitoolże nie odpowiadam i siedzę tam, powodując, że Ctrl+ Cto.

Mam nadzieję, że to komuś pomaga.

TheLinuxBug
źródło
Czy jest jakiś problem echo 1 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us?
Qian Chen,
0

Znalazłem ten działający CentOS 7 i próbuję dowiedzieć się, co się z nim dzieje.

Dla mnie było to „ipmicfg” Supermicro uruchamiane ze skryptu, który napisałem, czy coś takiego. Właśnie go zabiłem i użycie kipmi0 zniknęło.

Locane
źródło