ps aux wisi na wysokim cpu / IO z procesami java

13

Mam pewne problemy z procesem Java i sprawdzaniem nrpe. Mamy kilka procesów, które czasami wykorzystują 1000% procesora w systemie 32-rdzeniowym. System reaguje dość szybko, dopóki nie zrobisz tego

ps aux 

lub spróbuj zrobić cokolwiek w / proc / pid # like

[[email protected] /proc/18679]# ls
hangs..

Ciąg ps aux

stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
stat("/dev/pts1", 0x7fffb8526f00)       = -1 ENOENT (No such file or directory)
stat("/dev/pts", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
readlink("/proc/15693/fd/2", "/dev/pts/1", 127) = 10
stat("/dev/pts/1", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
write(1, "root     15693 15692  0 06:25 pt"..., 55root     15693 15692  0 06:25 pts/1    00:00:00 ps -Af
) = 55
stat("/proc/18679", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/18679/stat", O_RDONLY)      = 5
read(5, "18679 (java) S 1 18662 3738 3481"..., 1023) = 264
close(5)                                = 0
open("/proc/18679/status", O_RDONLY)    = 5
read(5, "Name:\tjava\nState:\tS (sleeping)\nT"..., 1023) = 889
close(5)                                = 0
open("/proc/18679/cmdline", O_RDONLY)   = 5
read(5,

proces java działa i zakończy się dobrze, ale problem polega na tym, że nasze monitorowanie szaleje, myśląc, że procesy są zakończone, ponieważ upływa limit czasu oczekiwania na zakończenie ps aux.

Próbowałem zrobić coś takiego

 nice -19 ionice -c1 /usr/lib64/nagios/plugins/check_procs -w 1:1 -c 1:1 -a 'diamond' -u root -t 30

bez powodzenia

EDYTOWAĆ

Specyfikacja systemu

  • 32-rdzeniowy procesor Intel (R) Xeon (R) E5-2650 0 @ 2,00 GHz
  • 128 gramów pamięci ram
  • 12 napędów 4Tb 7200
  • CentOS 6.5
  • Nie jestem pewien, ale model to SuperMicro

Obciążenie, gdy tak się dzieje, wynosi około 90-160ish przez 1 minutę.

Dziwne jest to, że mogę przejść do dowolnego innego / proc / pid # i działa dobrze. System reaguje, gdy włączam ssh. Na przykład, gdy jesteśmy powiadamiani o dużym obciążeniu, mogę ssh w porządku.

Kolejna edycja

Użyłem terminu dla harmonogramu

[[email protected] ~]# for i in {a..m}; do cat /sys/block/sd${i}/queue/scheduler; done
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq

Wygląda jak góra

[[email protected] ~]# mount
/dev/sda3 on / type ext4 (rw,noatime,barrier=0)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext2 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/sdb1 on /disk1 type xfs (rw,nobarrier)
/dev/sdc1 on /disk2 type xfs (rw,nobarrier)
/dev/sdd1 on /disk3 type xfs (rw,nobarrier)
/dev/sde1 on /disk4 type xfs (rw,nobarrier)
/dev/sdf1 on /disk5 type xfs (rw,nobarrier)
/dev/sdg1 on /disk6 type xfs (rw,nobarrier)
/dev/sdh1 on /disk7 type xfs (rw,nobarrier)
/dev/sdi1 on /disk8 type xfs (rw,nobarrier)
/dev/sdj1 on /disk9 type xfs (rw,nobarrier)
/dev/sdk1 on /disk10 type xfs (rw,nobarrier)
/dev/sdl1 on /disk11 type xfs (rw,nobarrier)
/dev/sdm1 on /disk12 type xfs (rw,nobarrier)

Ok, próbowałem zainstalować dostrojony i ustawić wydajność przepustowości.

[[email protected] ~]# tuned-adm profile throughput-performance
Switching to profile 'throughput-performance'
Applying deadline elevator: sda sdb sdc sdd sde sdf sdg sdh[  OK  ] sdk sdl sdm
Applying ktune sysctl settings:
/etc/ktune.d/tunedadm.conf:                                [  OK  ]
Calling '/etc/ktune.d/tunedadm.sh start':                  [  OK  ]
Applying sysctl settings from /etc/sysctl.d/99-chef-attributes.conf
Applying sysctl settings from /etc/sysctl.conf
Starting tuned:                                            [  OK  ]
Mikrofon
źródło
Czy możesz podać informacje o środowisku serwera? Istotna byłaby dystrybucja i wersja systemu operacyjnego, platforma sprzętowa.
ewwhite
Ważne jest również obciążenie systemu w punkcie, w którym to się dzieje.
ewwhite
Wprowadziłem kilka zmian ze specyfikacjami i jakie jest obciążenie
Mike
Jak wygląda wyjście mount?
ewwhite
Bardzo dobre. Rozważ użycie tuned-adm profile enterprise-storagepolecenia do obsługi nobariera i przełącznika terminu. Co dmesg|tailpokazuje wynik? Czy widzisz limity czasu we / wy?
ewwhite

Odpowiedzi:

8

Ogólnie rzecz biorąc, widziałem, jak to się dzieje z powodu opóźnionego odczytu. Potwierdza to Twój stracewynik. Próba odczytu pliku / proc / xxxx / cmdline zawiesza się podczas uruchamiania ps auxpolecenia.

Chwilowe wzrosty liczby wejść / wyjść wyczerpują zasoby systemu. Obciążenie 90-160 to wyjątkowo zła wiadomość, jeśli dotyczy podsystemu pamięci.

Jeśli chodzi o macierz pamięci, czy możesz nam powiedzieć, czy istnieje sprzętowy kontroler RAID? Czy podstawowa aplikacja na serwerze jest tendencyjna do zapisu? Dyski, o których wspominasz (12 x 4 TB), to dyski SAS lub SATA nearline o niższej prędkości. Jeśli przed macierzą dysków nie ma żadnej formy buforowania zapisu , zapisy mogą znacznie zwiększyć obciążenie systemu. Jeśli są to czyste dyski SATA na płycie montażowej Supermicro, nie pomijaj możliwości wystąpienia innych problemów z dyskami ( przekroczenia limitu czasu, awarii dysku, płyty montażowej itp. ) Czy dzieje się tak na wszystkich węzłach Hadoop?

Łatwym testem jest próba uruchomienia iotoppodczas tego procesu. Ponadto, ponieważ jest to EL6.5, czy masz włączone jakieś tuned-admustawienia ? Czy włączone są bariery zapisu?

Jeśli nie zmieniłeś windy we / wy serwera, ionicemoże to mieć wpływ. Jeśli zmieniłeś to na coś innego niż CFQ , ( ten serwer prawdopodobnie powinien być w terminie ), ionicenie zrobi to żadnej różnicy.

Edytować:

Jeszcze jedna dziwna rzecz, którą widziałem w środowiskach produkcyjnych. Są to procesy Java i założę się, że są mocno wielowątkowe. Jak sobie radzisz z PID? Jaka jest sysctlwartość kernel.pid_max ? Miałem sytuacje, w których wcześniej wyczerpałem PID i miałem wynikające z tego duże obciążenie.

Wspominasz także o wersji jądra 2.6.32-358.23.2.el6.x86_64 . Ma ponad rok i jest częścią wydania CentOS 6.4, ale reszta twojego serwera to 6.5. Czy umieściłeś na czarnej liście aktualizacje jądra w yum.conf? Prawdopodobnie powinieneś być w jądrze 2.6.32-431.xx lub nowszym dla tego systemu. Może występować problem z ukrywaniem strony ze starszym jądrem . Jeśli nie możesz zmienić jądra, spróbuj je wyłączyć za pomocą:

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled.

ewwhite
źródło
jest karta rajdowa, ale jest używana tylko do obsługi 12 dysków na serwerze. Jest to część klastra Hadoop, więc robi dużo pisania, ale także te blokady pojawiają się, gdy przędza pobiera dużo danych do mapy, zmniejszając zadanie.
Mike
Dostaję do centrum danych, aby do mnie zadzwoniło, aby dowiedzieć się, czy wiedzą, do czego kontroler RAID jest ustawiony na pamięć podręczną zapisu. Jeśli chodzi o kartę, to 3a0613065fa Adaptec \ 71605 \ SATA/SAS RAID zweryfikowałem, że są to również dyski SATA Western Digital WD RE WD4000FYYZ
Mike,
1
@mike Jeśli nie możesz zmienić jądra, spróbuj: echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabledna zaatakowanym komputerze. Zakładam, że jest to wystarczająco powtarzalne, że można obserwować przed / po tym ustawieniu.
ewwhite
4
Wygląda na to, że dostrojony i wyłączanie strony głównej pomogło rozwiązać problem!
Mike
1
@Mike Excellent. Aktualizacja jądra może również przynieść ulgę. Ale jeśli utkniesz z działającym jądrem, cieszę się, że ta poprawka działa.
ewwhite
3

Problem nie jest związany z dyskiem. Wynika to z powieszenia:

open("/proc/18679/cmdline", O_RDONLY)   = 5
read(5,

/ proc to interfejs między jądrem a przestrzenią użytkownika. W ogóle nie dotyka dysku. Jeśli coś jest powieszone podczas odczytywania argumentów polecenia, zwykle jest to problem związany z jądrem i mało prawdopodobne, że jest to problem z pamięcią masową. Zobacz komentarz @kasperd.

Obciążenie jest tylko efektem ubocznym problemu, a duża liczba nie mówi pełnej historii. Możesz mieć serwer o bardzo dużym obciążeniu, na którym aplikacja zachowuje się bez żadnych problemów.

Możesz uzyskać więcej informacji o tym, co się dzieje cat /proc/$PID/stack. Gdzie $PIDjest identyfikator procesu, w którym odczyt się zatrzymuje.

W twoim przypadku zacznę od aktualizacji jądra.

Mircea Vutcovici
źródło
2
Mylisz się. Odczyt jest zwracany przez /proc/%d/cmdlineczęść przestrzeni adresowej procesu, w której jądro zapisywało wiersz poleceń podczas execvewywołania. Jak każda inna część przestrzeni użytkownika, może zostać zamieniona. W związku z tym uzyskanie dostępu może rzeczywiście wymagać oczekiwania na zamianę strony.
kasperd
To bardzo dobry argument. Dziękuję za powstanie. Myślę jednak, że szanse na rozpoczęcie strace, gdy twoja zamiana nie odpowiada, są niskie, ale nie niemożliwe. Zaktualizuję swoją odpowiedź.
Mircea Vutcovici,
2

Więc nawet przy wszystkich poprawkach i aktualizacji do najnowszego jądra 2.6, którą zapewnia CentOS, nadal widzieliśmy zawieszanie się. Nie tak bardzo jak wcześniej, ale wciąż je widzę.

Naprawiono aktualizację do jądra serii 3.10.x, które CentOS zapewnia tutaj w repozytorium centosplus

http://mirror.centos.org/centos/6/xen4/x86_64/Packages/

To zlikwidowało wszystkie zawieszenia drzewa procesów. Tak jak powiedziałem, system nie był pod żadnym szalonym obciążeniem, gdzie uruchamianie nowych procesów nie było szybkie. Więc większość z nich to problem z jądrem 2.6.

Mikrofon
źródło
0

To kolejna poprawka.

Wygląda na to, że uruchamiamy następujący kontroler RAID

Adaptec 71605

Robię aktualizacje oprogramowania układowego wszystkich komputerów, których dotyczy problem, do najnowszej wersji i wydaje się, że to rozwiązuje problem.

Musieliśmy obniżyć wersję z eksperymentu z jądrem 3.10 z powodu innych losowych problemów z instalacją 3.10 na CentOS 6, ale aktualizacja oprogramowania układowego wydaje się rozwiązać ten problem.

Mikrofon
źródło