Как решить прерывистые зависания сервера? Запись на диск (и чтение с него) полностью останавливается
У нас есть сервер LAMP около 6 месяцев. CentOS 7.0
Он работал без остановки в течение первых 3 месяцев, после чего зависал.
Затем он работает в течение следующих 2 месяцев (также без остановки без перезапуска), затем снова зависает.
Затем он работает в течение 14 дней, затем он зависает.
Затем он работает в течение 14 дней, затем он зависает.
После каждого зависания приходилось перезагружать сервер. Мы не добавили / не обновили системное программное обеспечение.
Симптомы зависания одинаковы во всех этих случаях:
Запись на диск (и чтение с него) прекращается полностью.
Веб-сервер и база данных MySQL перестают работать. Мы не можем войти через физическую консоль или удаленно через ssh.
Однако, когда произошло такое зависание, у меня были открытые сеансы удаленной оболочки ssh с запущенными командами linux "top" и "mytop", и они работали (обновлялись) до перезапуска сервера.
Таким образом, это доказывает, что сервер не был полностью заморожен. Часть программного обеспечения все еще работала.
Сервер не может корректно перезапустить.
Я ничего не нашел в журналах. Все журналы остановились одновременно.
В последних записях на физической консоли (KVM) при зависаниях упоминались ошибки контроллера Adaptec RAID. Пожалуйста, смотрите ниже:
00001
[1143965.194144) 0000000000000246 000000014423ecb4 1111880869b6b740 ffff880000c 00040
00040
[1143965.194786] Call Trace:
[1143965.195044] [<Ifffffffa007f46b>] aac_fib_send+0x3db/8x510 [aacraid]
[1143965.195307] [<ffffffffa00794d8>] aac_get_adapter_info+0xc8/8xb70 [aacraid] [1143965.195573] [<ffffffffa007e990>] _aac_reset_adapter+0x430/0x620 [aacraid]
[1143965.195573] [<ffffffffa007e990>] _aac_reset_adapter+0x430/0x620 [aacraid]
[1143965.195838] [<ffffffffa0071a79>] aac_reset_adapter+0xa9/0x290 [aacraid]
[1143965.196101] [<ffffffffa0076214>] aac_eh_reset+Oxla4/0xle0 [aacraid]
[1143965.196368] [<ffffffff813d6d83>] scsi_try_host_reset+0x43/0x100
[1143965.196628] [<ffffffff813d812,17>] scsi_eh_ready_devs+0x887/0xc20
[1143965.196889] [<ffffffff813da43c>] scsi_error_handler+0x52c/8x820
[1143965.197151] [<ffffffff813d9110>] ? scsi_eh_get_sense+0x2a0/0x2a0
[1143965.197415] [<1111111181085aff>] kthread+0xcf/8xe0
[1143965.197675] [<1111111181085a30>] ? kthread_create_on_node+0x140/0x140
[1143965.197939] [<111111118151316c>] ret_from_fork+Ox7c/OxbO
[1143965.198200] [<1111111181085a30>] ? kthread_create_on_node+0x140/0x140
[1143965.198461] Code: 48 c? 87 b8 00 00 00 00 30 08 a0 5d c3 Al 11 84 00 00 00 00 00 Of 11 44 00 00 55 48 8b 87 90 01 00 00 48 89 e5 8b 80 be 00 00 00 <a8> 04 75 14 f6 c4 01 75 14 25 80 00 00 00 83 f8 01 19 c0 83 e0
00 00 Of 11 44 00 00 55 48 8b 87 90 01 00 00 48 89 e5 8b 80 be 00 00 00 <a8> 04 75 14 f6 c4 01 75 14 25 80 00 00 00 83 f8 01 19 c0 83 e0
75 14 f6 c4 01 75 14 25 80 00 00 00 83 f8 01 19 c0 83 e0
[1143974.082729] aacraid: aac_fib_send: first asynchronous command timed out.
[1143974.082729] Usually a result of a PCI interrupt routing problem;
[1143974.082729] update mother board BIOS or consider utilizing one of
[1143974.082729] the SAFE mode kernel options (acpi, apic etc)
Мы заменили плату контроллера RAID, но это не решило проблему, у нас снова был зависший сервер с теми же симптомами.
Теперь у меня все время работает удаленная оболочка ssh с "dmesg -wH", в надежде перехватить больше журнала dmesg, когда снова произойдет зависание.
Сервер имеет карту Adaptec RAID с двумя SATA SSD 960 ГБ в RAID 1 и двумя жесткими дисками SATA 500 ГБ в RAID 1.
SMART атрибуты в порядке для всех дисков.
Любой совет?
Изменить № 1 13.09.2015:
На всех перегородках много свободного места.
Бревна вращаются правильно.
Изменить № 2 13.09.2015:
RAID-контроллер: Adaptec ASR71605
BIOS: 7,5-0 (32069)
Прошивка: 7.5-0 (32069)
Водитель: 1,2-0 (30300)
Загрузочная флешка: 7,5-0 (32069)
1 ответ
Решение состояло в том, чтобы использовать собственный драйвер Adaptec (его можно загрузить с их сайта), а не драйвер с открытым исходным кодом, поставляемый с CentOS. Сервер работал около 11 месяцев с драйвером Adaptec (затем сервер зависал по неизвестной причине), что является значительным улучшением по сравнению с 14-дневным временем безотказной работы с драйвером с открытым исходным кодом.