ps aux wisi na wysokim cpu / IO z procesami java

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  ]

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.

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.

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.

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.