Выделенный сервер Hetzner — как выяснить причину переодического зависания веб-сервера?

Question

[Дмитрий]

Имеется выделенный сервер у Hetzner (EX4S), на сервере установленного множество различных сайтов (в основном на WordPress), раньше сервер работал нормально (мог зависнуть раз в месяц, и отправкой запроса в тех.поддержку производилась ручная перезагрузка, так как ctrl+alt+del и hardware reset не помогали). В данный момент сервер зависает примерно каждый день, примерно в одно и тоже время (ночью), и помогает тоже только ручная перезагрузка через тех.поддержку. Есть подозрение что конкуренты производят определенную атаку на сервер чтобы его повесить (мини DDOS или что-то подобное, возможно используя какую-то уязвимость). После перезагрузки сервер не зависает снова (даже если я успел сделать перезагрузку в течении 10 минут после зависания) и работает отлично еще сутки или больше. То есть атака/проблема одноразовая, но переодическая.

Я бы мог подумать что это из-за высокого одновременного траффика, но сервер выдерживал и большую нагрузку до этого без проблем (к тому же загрузка CPU/RAM не особо велика после перезагрузки).

Вопрос - какие логи и где можно посмотреть, чтобы понять что явилось причиной зависания? Тех.поддержка ответить не может, говорит что сервер полностью не отвечал и ничего посмотреть было нельзя.

Данные о сервере:
Стоит панель Parallels Plesk Panel v11.5.30_build115130819.13
Debian 6.0.7
GenuineIntel, Intel(R)Core(TM) i7-3770 CPU @ 3.40GHz
32 ГБ ОЗУ
Apache
PHP Version 5.3.3-7+squeeze17
suhosin

Лог файлы:
https://dl.dropboxusercontent.com/u/5349131/server... (800кб)

Answer 1

[Пума Тайланд]

смотреть все системные логи
при зависании попросить лару и посмотреть что на экране
ну и наймите уже админа )))

Answer 2

[Влад Животнев]

/var/log/messages показывайте (ну и /var/log/messages.1; zcat /var/log/messages.2.gz)
Ещё есть смысл глянуть в /proc/mdstat , если рейды синкаются.

Comments

[Дмитрий]

Добавил логи, спасибо.

[Влад Животнев]

DedalX: wiki.hetzner.de/index.php/Installation_des_r8168-T... - вот это почитайте (впрочем, может и не оно).

А падает он судя по всему от веселья с raid. Попробуйте выключить все сервисы и дать raid-ам досинкаться до конца без нагрузки (сразу после ребута посмотрите в /proc/mdstat - там md3 начнет синкаться, скорее всего).
Если поможет - то меняйте по очереди оба диска, какой-то из них черепашка.

[Дмитрий]

Ещеб я знал как сделать то что вы сказали, я не на столько специалист по серверам и их настройке.
В каком смысле менять диски? В физическом? Сервер то не мой, хетцнера, если с дисками физическая проблема мне надо как-то им объяснить почему я так подумал чтоб они это чинили и доказать что я прав, как это сделать?

Answer 3

[ShamblerR]

/var/log/kern.log
/var/log/syslog

для начала в студию

Comments

[Дмитрий]

Добавил логи, спасибо.

Answer 4

[Дмитрий]

Добавил запрошенные лог файлы (800кб):
https://dl.dropboxusercontent.com/u/5349131/server...

Помогите пожалуйста разобраться.

Comments

[ShamblerR]

Ох чет у вас тут странное.
1 че это за рейд такой странный зачем вам 4 массива по 2 диска ?
не проще было бы собрать 1 массив с 8 дисков и побить его на два раздела
и скорость была бы выше, и надежность.

Теперь по логам
в первую очередь смотрите все что у вас в kern
в идеале там должна быть только загрузка системы и все!
все что там появляется это kernel panic фактически вещь нифига не клевая.
у вас тут все исписано рейд массивом
типа
Apr 1 01:16:39 dedalx kernel: [ 7.529738] mdadm: sending ioctl 1261 to a partition!
Apr 1 01:16:39 dedalx kernel: [ 7.529796] mdadm: sending ioctl 1261 to a partition!
Apr 1 01:16:39 dedalx kernel: [ 7.529937] mdadm: sending ioctl 1261 to a partition!
Apr 1 01:16:39 dedalx kernel: [ 7.529986] mdadm: sending ioctl 1261 to a partition!
Apr 1 01:16:39 dedalx kernel: [ 7.530118] mdadm: sending ioctl 1261 to a partition!
Apr 1 01:16:39 dedalx kernel: [ 7.530165] mdadm: sending ioctl 1261 to a partition!
Apr 1 01:16:39 dedalx kernel: [ 7.530271] mdadm: sending ioctl 1261 to a partition!
Apr 1 01:16:39 dedalx kernel: [ 7.530330] mdadm: sending ioctl 1261 to a partition!
Apr 1 01:16:39 dedalx kernel: [ 7.530436] mdadm: sending ioctl 1261 to a partition!
Apr 1 01:16:39 dedalx kernel: [ 7.530494] mdadm: sending ioctl 1261 to a partition!

9.244299] EXT4-fs (md2): ext4_orphan_cleanup: deleting unreferenced inode 54788112
Apr 1 01:07:53 dedalx kernel: [ 9.244316] EXT4-fs (md2): ext4_orphan_cleanup: deleting unreferenced inode 54788111
Apr 1 01:07:53 dedalx kernel: [ 9.244320] EXT4-fs (md2): ext4_orphan_cleanup: deleting unreferenced inode 54788110
Apr 1 01:07:53 dedalx kernel: [ 9.244323] EXT4-fs (md2): ext4_orphan_cleanup: deleting unreferenced inode 54788109
Apr 1 01:07:53 dedalx kernel: [ 9.244327] EXT4-fs (md2): ext4_orphan_cleanup: deleting unreferenced inode 54788107
Apr 1 01:07:53 dedalx kernel: [ 9.244330] EXT4-fs (md2): ext4_orphan_cleanup: deleting unreferenced inode 54788105
Apr 1 01:07:53 dedalx kernel: [ 9.244334] EXT4-fs (md2): ext4_orphan_cleanup: deleting unreferenced inode 54788104
Apr 1 01:07:53 dedalx kernel: [ 9.244338] EXT4-fs (md2): ext4_orphan_cleanup: deleting unreferenced inode 54788103
Apr 1 01:07:53 dedalx kernel: [ 9.244341] EXT4-fs (md2): ext4_orphan_cleanup: deleting unreferenced inode 54788102
Apr 1 01:07:53 dedalx kernel: [ 9.244345] EXT4-fs (md2): ext4_orphan_cleanup: deleting unreferenced inode 54788101
Apr 1 01:07:53 dedalx kernel: [ 9.244348] EXT4-fs (md2): ext4_orphan_cleanup: deleting unreferenced inode 5478
и тд

Поскольку ошибки разные и в рахных массивах да часто
r 1 01:07:53 dedalx kernel: [ 10.431835] processor LNXCPU:03: registered as cooling_device8
Apr 1 01:07:53 dedalx kernel: [ 10.432461] processor LNXCPU:04: registered as cooling_device9
Apr 1 01:07:53 dedalx kernel: [ 10.433074] processor LNXCPU:05: registered as cooling_device10
Apr 1 01:07:53 dedalx kernel: [ 10.433649] processor LNXCPU:06: registered as cooling_device11
Apr 1 01:07:53 dedalx kernel: [ 10.434309] processor LNXCPU:07: registered as cooling_device12

в общем я бы порекомендовал вначале погрешить на память.
Протестить ее.
А потом уже на все остальное
В любом случае система ваша чувствует себя не очень то хорошо.
Это мягко сказать.

[Дмитрий]

ShamblerR: А как это все протестировать?

[Дмитрий]

ShamblerR: Hetzner мне ответили что это не "железная" проблема, потому что на моем сервере нет аппаратного рейда (как я понимаю он программный). Судя по гуглу данные ошибки могут быть связаны с багом некоторых версий ядра линукса.

[Дмитрий]

ShamblerR: Похожую проблему вижу тут: itinrussian.ru/%D0%BE%D0%B4%D0%B8%D0%BD-%D0%B8%D0%...

В принципе обновить ядро по этой статье-то я смогу, но меня пугает надпись "после обновления ядра настраиваем RAID как обычно", так как я без понятия как это делать и не хочу запороть сервер с кучей сайтов и файлов, какие нельзя потерять. Обязательно ли обновлять настройки рейда после обновления ядра (и что еще придется делать заново?) или достаточно его обновить, ребутнуться и на сервере все будет само работать как раньше? (Plesk Panel, веб сервер, все сайты и т.д.)

[ShamblerR]

DedalX: ямного слышал о такой проблеме как вы указали в статье, но не разу не видил у hetzner ее , это не она.
Да и проблема у вас не только в рейде вы посмотрите у вас весь керт завален сообщениями.
Анализируйте ошибки онлайн, сопоставьте на каком месте встает сервер и что дают последние записи
У меня были проблемы вплоть до умирания cgi процессов а оказалась оперативка.
Так что в любом слчае тестить железо у хетзнера дело полезное ведь юзают они бу вообе не закрывая глаза. есть случаи заказа железа с наработкой 20к часов
Так что железо нужно тестить.
Попробуйте так же проанализировать последовательность краха
Например
1. полезли керны, с какхи началось
2. сколько после этого сайты еще доступны
3. есть ли периодичность ?
4. отваливаются все демоны сразу или часть, если часть то последовательность.
например
если отвалилась бд то работает ли еще статика, если статика еще работает работает ли чистый php файл.
и тд
больше инфы

Answer 5

[Алексей]

Вы уверены что он точно завис? Заказывали LARA?
У нас была похожая проблема, и она была из-за кривой настройки сети хецнеровцами, примерно раз в сутки на серваке падала сеть и вставала только после мануального рестарта.
Саппорты от подобных проблем отмазываются, мол "а вы пробовали в реске пожить неделю? подождать пока упадет?".
Помог хороший пинок и немного мата. Они очистили ARP и вот уже неделю без проблем.

Answer 6

[ramjke]

Посмотрите, что у Вас висит в кроне
cron -e
Вы говорите, что зависание в одно и то же время - возможно, процесс резервного копирования или ротация логов подвешивает Ваш сервер. Просмотрите в панели управления, на какое время назначено резервное копирование.

DOS? Вам его помогут определить логи запросов /var/log/nginx/access.log или /var/log/apache/access.log - в зависимости от используемого Вами веб-сервера. Если на один IP приходится более десятка запросов в секунду - это точно дос.

Сервер полностью не отвечал? Предьявите /var/log/kern.log и /var/log/syslog, там описаны причины.