Почти каждый день мой сервер дает сбой из-за высокой нагрузки на сервер, и даже перезапуск apache или mysql не может решить проблему. Мне нужно перезагрузить сервер, чтобы решить эту проблему, иначе он снова выйдет из строя из-за высокой нагрузки.
Система журналов записывает что-то вроде этого при сбое:
Aug 11 18:33:53 server kernel: INFO: task httpd:20008 blocked for more than 120 seconds.
Aug 11 18:33:53 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 11 18:33:53 server kernel: httpd D ffffffff801538ac 0 20008 5816 20066 19809 (NOTLB)
Aug 11 18:33:53 server kernel: ffff81025a299dc8 0000000000000082 ffff81033b4c0740 ffffffff80009a14
Aug 11 18:33:53 server kernel: ffff8101063f8d80 0000000000000009 ffff8100b758f7e0 ffff8101c57187e0
Aug 11 18:33:53 server kernel: 00009436d4100b6c 000000000001d50f ffff8100b758f9c8 000000083b531588
Aug 11 18:33:53 server kernel: Call Trace:
Aug 11 18:33:53 server kernel: [<ffffffff80009a14>] __link_path_walk+0x173/0xfb9
Aug 11 18:33:53 server kernel: [<ffffffff8002cc16>] mntput_no_expire+0x19/0x89
Aug 11 18:33:53 server kernel: [<ffffffff80063c4f>] __mutex_lock_slowpath+0x60/0x9b
Aug 11 18:33:53 server kernel: [<ffffffff80023908>] __path_lookup_intent_open+0x56/0x97
Aug 11 18:33:53 server kernel: [<ffffffff80063c99>] .text.lock.mutex+0xf/0x14
Aug 11 18:33:53 server kernel: [<ffffffff8001b21f>] open_namei+0xea/0x712
Aug 11 18:33:54 server kernel: [<ffffffff8002768a>] do_filp_open+0x1c/0x38
Aug 11 18:33:54 server kernel: Firewall: *UDP_IN Blocked* IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:30:48:9e:6e:99:08:00 SRC=208.43.135.158 DST=255.255.255.255 LEN=151 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=38354 DPT=6112 LEN=131
Aug 11 18:33:54 server kernel: [<ffffffff8001a061>] do_sys_open+0x44/0xbe
Aug 11 18:33:54 server kernel: [<ffffffff8005d28d>] tracesys+0xd5/0xe0
Я много гуглил, пытаясь найти решение. Но похоже, что решение просто обновить ядро или драйвер диска, думает, что я не знаю, как это сделать.
В этом URL http://bugs.centos.org/view.php?id=4515 Многие люди сообщают о подобных проблемах, за исключением того факта, что они не связаны с httpd, как моя.
По словам одного из членов, одним из решений было бы добавить "лифт = нет" в /etc/grub.conf, как в этом примере:
title CentOS (2.6.18-238.12.1.el5xen)
root (hd0,0)
kernel /vmlinuz-2.6.18-238.12.1.el5xen ro root=/dev/VolGroup00/LogVol00 elevator=noop
initrd /initrd-2.6.18-238.12.1.el5xen.img
Действительно ли это решило бы проблему? Мой диск работает в режиме RAID. Может ли это вызвать проблемы на моем сервере?
Есть ли другое решение?
Это из-за блокировки мьютекса.
Внимательно проверьте напечатанную трассировку стопки: она перевернута. Вы найдете эту строку
mutex_lock_slowpath
Кажется, есть нехватка ресурсов.
Предлагаемый Sysstat в большинстве случаев является хорошим инструментом профилирования. Если вам нужно перейти к корню проблемы, вам потребуется дамп памяти vmcore или ядра. Есть два файла / proc, которые называются
/proc/sys/kernel/hung_task_timeout_secs
/proc/sys/kernel/hung_task_panic
Значение первого файла - 120. Поэтому вы видите сообщения о том, что задача заблокирована на 120 секунд. Тривиальный тест - увеличить его и посмотреть, что произойдет. Сделайте 240 или 360.
Следующий файл по умолчанию имеет значение 0. Это должно быть 1, если вы хотите собрать vmcore.
Очевидно, вам нужно настроить kdump и исправить цель дампа. Целевой объект дампа должен быть больше, чем размер физической памяти. Но даже если вы собираете vmcore, вам потребуются некоторые знания C, сборки и общей отладки, чтобы разобраться в нем. Профессиональная поддержка или системный администратор могут помочь лучше.
Но имо, смена лифта здесь ни на что не повлияет.
Запустите инструмент сбора статистики производительности (я предпочитаю sysstat, но вы можете предпочесть что-то другое) и проанализируйте, что он говорит вам о том, где находится узкое место.