Падает с завидной регулярность VPS сервер на Debian 6. Аптайм редко больше 2х суток. В логах ничего(или я не там ищу?). На сервере LAMP и сайт с довольно высокой посещаемостью (3-4к в сутки)
После падения удается подключиться VNC консолью и там следующее:
Хостер говорит - покупайте услуги админа, помочь ничем не можем.
LinuxForum.Fans
Регулярное падение сервера
Автор: senya_m
15 сообщений
4175 просмотров
По этому куску вряд-ли кто-то что-то сможет сказать...
Почитайте вот эту статейку:
http://ifreebsd.org/linux/%D0%BA%D0%B0%D0%BA-%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B8%D1%82%D1%8C-%D0%BF%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D0%BF%D0%B0%D0%B4%D0%B0%D0%B5%D1%82-linux-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80-li/
А логи вообще на чем заканчиваются? Что последнее происходило перед падением?
По этому куску вряд-ли кто-то что-то сможет сказать...
А логи вообще на чем заканчиваются? Что последнее происходило перед падением?
Спасибо за ответ! Статью прочитал, но решение которое приводится там, вряд ли применимо для впс. А по диагностике слишком мало информации.
/var/log/messages
text
Dec 29 07:01:01 vps-4241 rotated[22800]: Rotation finished. 0 log files was processed. 0 seconds left
Dec 29 08:01:01 vps-4241 rotated[23262]: Checking links to log files
Dec 29 08:01:01 vps-4241 rotated[23262]: Checking links finished
Dec 29 08:01:01 vps-4241 rotated[23262]: Rotation finished. 0 log files was processed. 0 seconds left
Dec 29 09:01:01 vps-4241 rotated[23865]: Checking links to log files
Dec 29 09:01:01 vps-4241 rotated[23865]: Checking links finished
Dec 29 09:01:01 vps-4241 rotated[23865]: Rotation finished. 0 log files was processed. 0 seconds left
Dec 29 09:36:14 vps-4241 kernel: imklog 4.6.4, log source = /proc/kmsg started.
В 9-30 было сообщение о отсутствии ответа сервера по http(опрос раз в 10 минут), в 9-36 это уже началась перезагрузка.
В логах апача, mysql тоже ничего. kern.log, daemon.log тоже ничего в это время
Можно ли из этого сделать вывод что проблема с оборудованием хостера?
А вывод dmesg?
Можно ли из этого сделать вывод что проблема с оборудованием хостера?
да
Внимательнее проанализировав логи было обнаружено что за минуту до падения всегда в syslog появляются следующие строки
text
Jan 3 03:45:01 vps-4241 /USR/SBIN/CRON[31885]: (root) CMD (/usr/local/ispmgr/sbin/cron.sh sbin/eximquota.check.sh)
Jan 3 03:45:01 vps-4241 /USR/SBIN/CRON[31886]: (root) CMD (/usr/local/ispmgr/sbin/cron.sh sbin/ihttpd.check.sh)
Jan 3 03:50:01 vps-4241 /USR/SBIN/CRON[31907]: (root) CMD (/usr/local/ispmgr/sbin/cron.sh sbin/ihttpd.check.sh)
Jan 3 03:50:01 vps-4241 /USR/SBIN/CRON[31908]: (root) CMD (/usr/local/ispmgr/sbin/cron.sh sbin/eximquota.check.sh)
Jan 3 03:50:01 vps-4241 /USR/SBIN/CRON[31909]: (www-data) CMD ([ -x /usr/share/awstats/tools/update.sh ] && /usr/share/awstats/tools/update.sh)
Jan 3 03:50:01 vps-4241 /USR/SBIN/CRON[31903]: (CRON) error (grandchild #31909 failed with exit status 2)
Jan 3 03:53:02 vps-4241 kernel: imklog 4.6.4, log source = /proc/kmsg started.Как я понимаю, завершается конкретное задание с ошибкой, это же не может быть причиной зависания сервера?
судя по выводу, может
судя по выводу, может
это как вы так определили? там ошибка крона то что не может быть выполнено задание и не более того.
[quote="Rabat"]судя по выводу, может
это как вы так определили? там ошибка крона то что не может быть выполнено задание и не более того.[/quote]
Вот и я думаю, что не может.
Появились другие мысли. Пока изучал тему, попалось несколько случаев, когда зависание сервера происходило по вине апача, который жрал всю доступную память на слабых vps. Сопоставил события с посещаемостью сайта, получается что сервер подвисает в дни с наибольшей посещаемостью. free -m показывает наличие свободной в пределах 80Мб, что подозрительно при 2Гб ОЗУ. Жрал все mysql, конфиг поправил, теперь свободной памяти около 800МБ.
Разве ОС не следит за наличием и доступностью памяти? Логично что прожорливые процессы должны убиваться менеджером процессов, а зависаний происходить не должно, разве что в случаях с утечкой памяти. Как по мне вариант с нехваткой памяти не особо правдоподобен, тем более что еще доступен своп.
[quote="Rabat"]судя по выводу, может
это как вы так определили? там ошибка крона то что не может быть выполнено задание и не более того.[/quote]
Внимательнее проанализировав логи было обнаружено что за минуту до падения всегда в syslog появляются следующие строки
Jan 3 03:45:01 vps-4241 /USR/SBIN/CRON[31885]: (root) CMD (/usr/local/ispmgr/sbin/cron.sh sbin/eximquota.check.sh)
Jan 3 03:45:01 vps-4241 /USR/SBIN/CRON[31886]: (root) CMD (/usr/local/ispmgr/sbin/cron.sh sbin/ihttpd.check.sh)
Jan 3 03:50:01 vps-4241 /USR/SBIN/CRON[31907]: (root) CMD (/usr/local/ispmgr/sbin/cron.sh sbin/ihttpd.check.sh)
Jan 3 03:50:01 vps-4241 /USR/SBIN/CRON[31908]: (root) CMD (/usr/local/ispmgr/sbin/cron.sh sbin/eximquota.check.sh)
Jan 3 03:50:01 vps-4241 /USR/SBIN/CRON[31909]: (www-data) CMD ([ -x /usr/share/awstats/tools/update.sh ] && /usr/share/awstats/tools/update.sh)
Jan 3 03:50:01 vps-4241 /USR/SBIN/CRON[31903]: (CRON) error (grandchild #31909 failed with exit status 2)
Jan 3 03:53:02 vps-4241 kernel: imklog 4.6.4, log source = /proc/kmsg started.
Как я понимаю, завершается конкретное задание с ошибкой, это же не может быть причиной зависания сервера?
если всегда за минуту до падения и следующая строка после рестарта - наводит на мысли
Теперь все еще интереснее, корневой раздел внезапно становиться read-only. То-есть сам по себе, с регулярностью раз в 2-4 дня.
Примерно раз в 2-4 дня корневой раздел внезапно становиться read-only. Никаких действий на сервере не производится.
Помогает перезагрузка и fsck. Во время проверки fsck находит и исправляет несколько десятков поврежденных файлов.
В логах ничего в на это время.
Проблема не может быть связана с вашим оборудованием?
Support
Более детально проверили ситуацию, с сервером, где расположен Ваш VPS-сервер никаких проблем нет. К тому же, описанные Вами проблемы касаются только работы конкретно Вашего сервера. В этом случае попробуйте до перезагрузки сервера проверить свободное место и сделать fsck, а не после перезагрузки.
На данный момент свободного места более чем достаточно, используется всего 40%. Проверю при read-only.
fsck на смонтированном разделе? Уже имел неосторожность запустить, это убило весь раздел.
Support
С нашей стороны проблем нет, с оборудованием также все в порядке. С проблемой подобного рода обращаются впервые.
>Во время проверки fsck находит и исправляет несколько десятков поврежденных файлов
Утилита fsck все-таки находит поврежденные файлы, следовательно Вам нужно выяснить этот момент, что это за файлы и по какой причине возникает проблема подобного рода.
Гугление на эту тему дает только варианты проблем с железом.
На сервере только nginx+apache+mysql. Точно такая же конфигурация прекрасно работает на других впс у других хостеров.
Теперь все еще интереснее, корневой раздел внезапно становиться read-only.
меняй хостера, иначе будешь каждый раз ловить RO, проблема видимо с ВМ, подобное уже было - выход был таков, создал новую ВМ и перенес весь контент + конфиги, после этого полет нормальный.
если всегда за минуту до падения и следующая строка после рестарта - наводит на мысли
надо вообще глянуть что эти хитрожопые скрипты делают. :)
по первой картинки: проблема с ram/cpu/hdd , возможно просто ресурсов не хватает.
меняй хостера, иначе будешь каждый раз ловить RO, проблема видимо с ВМ, подобное уже было - выход был таков, создал новую ВМ и перенес весь контент + конфиги, после этого полет нормальный.
Видимо так и сделаю. Хостинг то дешевый, и служба поддержки соответствующая. Поражает нежелание разобраться с проблемой, тем более что проблема очень намекает на железо...
В качестве эксперимента:
1) попробуйте последовательно позапускать задачи из крона, о которых есть отметка в журнале перед падением. Удалось вызвать падение?
2) посмотрите задания крона на предмет задач, не успевших отметиться в логе, возможно, что причина там.
3) посмотрите автозапускаемое на предмет mount -o remount,ro. Хотя тут, скорее всего, просто следствие: сбой -> перезагрузка -> наличие ошибок в ФС -> ФС оставлена в РО.
3) посмотрите автозапускаемое на предмет mount -o remount,ro. Хотя тут, скорее всего, просто следствие: сбой -> перезагрузка -> наличие ошибок в ФС -> ФС оставлена в РО.
Перезагрузка не происходит, был в этот момент подключен по ssh.
Единственное что подозрительно, появляется процесс:
bin/sh/ usr/bin/mysqld_safe и грузит ЦП процентов на 40.
Хотя возможно mysql просто пытается получить доступ к диску и не может.
Войдите или зарегистрируйтесь, чтобы ответить.
