ps aux висить на високому процесорі / IO з процесами java


13

У мене виникають деякі проблеми з процесом java та nrpe. У нас є деякі процеси, які іноді використовують 1000% процесор у 32-ядерній системі. Система досить чуйна, поки ви не зробите це

ps aux 

або спробуйте зробити що-небудь у / proc / pid # like

[root@flume07.domain.com /proc/18679]# ls
hangs..

Напруга 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,

процес java працює і завершиться чудово, але проблема полягає в тому, що він змушує наш моніторинг зійти з розуму, мислячі процеси знижуються, оскільки це очікування очікує завершення PS aux.

Я намагався робити щось подібне

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

без везіння

EDIT

Технічні характеристики

  • 32-ядерний процесор Intel (R) Xeon (R) E5-2650 0 при 2,00 ГГц
  • 128гг барана
  • 12 накопичувачів 7200 ТБ
  • CentOS 6.5
  • Я не впевнений, що модель, але постачальник SuperMicro

Навантаження, коли це відбувається, становить приблизно 90-160ш за 1 хвилину.

Дивна частина полягає в тому, що я можу зайти в будь-який інший / proc / pid #, і це працює чудово. Система реагує, коли я ввімкнути ssh. Як і коли ми отримуємо сповіщення про високе навантаження, я можу зробити ssh прямо в порядку.

Ще одна редакція

Я використовую термін для планувальника

[root@dn07.domain.com ~]# 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

Маунт виглядає так

[root@dn07.manage.com ~]# 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)

Гаразд, я спробував встановити налаштований і встановити його для пропускної здатності.

[root@dn07.domain.com ~]# 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  ]

Чи можете ви надати інформацію про серверне середовище? Розповсюдження та версія ОС, апаратні платформи були б доречними.
ewwhite

Ваша система завантаження в момент, коли це відбувається, також важливо.
ewwhite

Я вніс декілька змін із специфікаціями та навантаженням
Майк

Як виглядає вихід mount?
ewwhite

Дуже добре. Подумайте про використання tuned-adm profile enterprise-storageкоманди для обробки нобар'єра та кінцевого вимикача. Що показує dmesg|tailвихід? Ви бачите тайм-аути вводу / виводу?
ewwhite

Відповіді:


8

Взагалі, я бачив, як це відбувається через прострочене читання. Це підтверджується вашим straceрезультатом. Спроба зчитувати / proc / xxxx / cmdline файл висить під час запуску ps auxкоманди.

Моментальні сплески вводу / виводу голодують ресурсами системи. Завантаження 90-160 надзвичайно погана новина, якщо це пов'язано з підсистемою зберігання даних.

Чи можете ви сказати, що для масиву пам’яті є апаратний RAID-контролер? Чи упереджене основне додаток на сервері запису? Згадані вами диски (12 х 4 ТБ) - це низькошвидкісні диски SAS або SATA з низькою швидкістю. Якщо перед масивом накопичувачів немає форми кешування записів, записи можуть підштовхувати шлях завантаження системи. Якщо це чисті накопичувачі SATA на задній площині Supermicro, не варто знижувати можливість виникнення інших проблем з диском ( тайм-аути, несправний диск, задній план тощо ). Чи трапляється це на всіх вузлах Hadoop?

Простий тест - спробувати запустити, iotopпоки це відбувається. Крім того, оскільки це EL6.5, чи активовано будь-яке tuned-admналаштування ? Чи включені бар'єри для запису?

Якщо ви не змінили ліфт сервера вводу-виводу, це ioniceможе вплинути. Якщо ви змінили його на що-небудь, крім CFQ , ( цей сервер, мабуть, має бути в дедлайні ), ioniceце не матиме ніякої різниці.

Редагувати:

Ще одна дивна річ, яку я бачив у виробничих умовах. Це процеси Java, і я вважаю, що вони багатопотокові. Як ви робите PID? Яке sysctlзначення для kernel.pid_max ? У мене були ситуації, коли я раніше вичерпав PID, і в результаті було велике навантаження.

Також ви згадуєте версію ядра 2.6.32-358.23.2.el6.x86_64 . Це вже понад рік і частина випуску CentOS 6.4, але решта вашого сервера - 6.5. Ви оновили ядро ​​чорного списку в yum.conf? Напевно, ви повинні знаходитись у ядрі 2.6.32-431.xx або новішій для цієї системи. Можливо, виникла величезна сторінка зі старим вашим ядром . Якщо ви не можете змінити ядро, спробуйте відключити їх за допомогою:

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


є рейдова карта, але її щойно використовується для обробки 12 дисків на сервері. Його частина кластера Hadoop, тому вона багато пише, але також ці блокування виникають, коли пряжа тягне багато даних для зменшення роботи карти.
Майк

Я закликаю мене до центру обробки даних, щоб дізнатися, чи знають вони, для чого налаштований контролер рейду для кешу запису. Що стосується карти її a, 3a0613065fa Adaptec \ 71605 \ SATA/SAS RAID я перевірив, що вони теж SATA-накопичувачі Western Digital WD RE WD4000FYYZ
Майк

1
@mike Якщо ви не можете змінити ядро, спробуйте: echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabledна ураженій машині. Я припускаю, що це досить відтворюється, що ви можете спостерігати до / після цього налаштування.
ewwhite

4
виглядає, що налаштування та відключення величезної сторінки допомогли усунути проблему!
Майк

1
@Mike Відмінно. Оновлення ядра також може забезпечити полегшення. Але якщо ви застрягли з запущеним ядром, я радий, що це виправлення працює.
ewwhite

3

Проблема зрозуміла, а не проблема, пов'язана з диском. І це зрозуміло з повішеної стрази:

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

/ proc - це інтерфейс між ядром та простором користувачів. Він зовсім не торкається диска. Якщо щось підвішене, читаючи аргументи команди, зазвичай це проблема, пов'язана з ядром, і навряд чи проблема зберігання. Дивіться коментар @kasperd.

Навантаження є лише побічним ефектом проблеми, і велика кількість не розповідає про повну історію. У вас може бути сервер з дуже високим навантаженням, на якому програма веде себе без будь-яких збоїв.

Ви можете отримати більше інформації про те, що відбувається cat /proc/$PID/stack. Де $PIDідентифікатор процесу, де читається зупинка.

У вашому випадку я б почав з оновлення ядра.


2
Ви помиляєтесь. Що повертається при читанні, /proc/%d/cmdline- це частина адресного простору процесу, в якій ядро ​​зберігало командний рядок під час execveвиклику. Як і будь-яка інша частина користувальницького простору, він може бути замінений. Тому для доступу до нього, можливо, доведеться чекати, коли сторінку знову поміняють.
kasperd

Це дуже хороший аргумент. Дякую, що піднявся. Однак я думаю, що шанси на початок страйсу, коли ваш своп не відповідає, низькі, але не неможливі. Я оновлю свою відповідь.
Mircea Vutcovici

2

Тож навіть з усіма налаштуваннями та оновленням до останнього ядра 2.6, яке надає CentOS, ми все ще бачили зависання. Не так, як раніше, але все одно їх бачу.

Виправленням було оновлення до ядра серії 3.10.x, яке CentOS надає у своєму центрі splus тут

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

Це усунуло всі звисаючі процеси. Як я вже казав, система не перебуває під шаленим навантаженням, коли запуск нових процесів не був швидким. Тож більшість десь буде проблемою з ядром 2.6.


0

Це ще одне виправлення.

Схоже, у нас працює наступний контролер рейду

Adaptec 71605

Я робив оновлення вбудованого програмного забезпечення для всіх постраждалих машин до останньої версії, і, здається, усувається проблема.

Нам довелося перейти до експерименту з ядром 3.10 через інші випадкові проблеми, встановлені 3.10 на CentOS 6, але оновлення програмного забезпечення, здається, вирішило проблему.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.