PS Aux висит на высокой скорости процессора / ввода-вывода с Java-процессами

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

ps aux 

или попробуйте сделать что-нибудь в / proc / pid # как

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

Strace of 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

без удачи

РЕДАКТИРОВАТЬ

Системные характеристики

• 32-ядерный процессор Intel (R) Xeon (R) E5-2650 0 @ 2,00 ГГц
• 128 гигабайт оперативной памяти
• 12 4Tb 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  ]

В общем, я видел, как это произошло из-за того, что я зашел в тупик. Это подтверждается вашими straceвыводами. Попытка чтения файла / proc / xxxx / cmdline зависает во время выполнения ps auxкоманды.

Моментальные скачки ввода / вывода истощают ресурсы системы. Нагрузка 90-160 является крайне плохой новостью, если она связана с подсистемой хранения.

Что касается массива хранения, можете ли вы сказать нам, есть ли аппаратный RAID-контроллер на месте? Основное приложение на сервере смещено на запись? Диски, которые вы упоминаете (12 x 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,

Проблема ясна, а не проблема, связанная с диском. И это ясно из повешенного страуса:

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

/ proc - это интерфейс между ядром и пользовательским пространством. Это не касается диска вообще. Если что-то зависает при чтении аргументов команды, то это обычно проблема, связанная с ядром, и вряд ли проблема с хранилищем. Смотрите комментарий @kasperd.

Загрузка - только побочный эффект проблемы, и большое число не говорит полную историю. У вас может быть сервер с очень высокой нагрузкой, на котором приложение работает без сбоев.

Вы можете получить больше информации о том, что происходит с cat /proc/$PID/stack. Где $PIDнаходится идентификатор процесса, где чтение останавливается.

В вашем случае я бы начал с обновления ядра.

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

Исправлением было обновление ядра серии 3.10.x, которое CentOS предоставляет в своем репозитории centosplus здесь

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

Это покончило со всеми зависаниями дерева процессов. Как я уже сказал, система не испытывала какой-либо сумасшедшей нагрузки, когда запуск новых процессов не был быстрым. Так что большинство будет проблемой ядра 2.6 где-нибудь.

Это еще одно исправление.

Похоже, мы запускаем следующий рейд-контроллер

Adaptec 71605

Я делал обновления микропрограммы на всех затронутых машинах до последней версии, и это, кажется, устраняет проблему.

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