У меня проблемы с java-процессом и проверками nrpe. У нас есть процессы, которые иногда используют 1000% ЦП в 32-ядерной системе. Система довольно отзывчива, пока вы не выполните
ps aux
или попробуйте сделать что-нибудь в / proc / pid #, например
[root@flume07.domain.com /proc/18679]# ls
hangs..
Strace 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
без везения
РЕДАКТИРОВАТЬ
Системные характеристики
Нагрузка, когда это происходит, составляет около 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, и я предполагаю, что они сильно многопоточные. Как у вас дела с ФИД? Что за 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.x.x или новее для этой системы. Может быть проблема с огромными страницами со старым ядром, которое у вас есть. Если вы не можете изменить ядро, попробуйте отключить их:
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, но обновление прошивки, похоже, решило проблему.