Почему упал сайт?

Главная
Блог
Почему упал сайт?

9 Ноября 2018

Нет, сайт падает не потому, что он устал. На то есть другие, более явные причины и сейчас мы рассмотрим три наиболее вероятных из них. Будем считать, что сайт «крутится» на виртуальном сервере, а если на физическом, то с «железом» все в порядке и нет никаких аппаратных неисправностей.

Закончилось дисковое пространство/свободные иноды

Самая банальная причина падения сайта. Во время работы сетевые сервисы вроде Apache, MySQL генерируют приличные объемы данных — логи, временные файлы, не говоря уже о загружаемых пользователями данных.

Сервису просто некуда дальше писать данные и он «крашится». Также причиной падения того же Apache может быть чрезвычайно большой размер журнала.

Мы рекомендуем следующее:

Чтобы регулярно не проверять дисковое пространство, установить сервис мониторинга для автоматизации данного процесса. Можно настроить тот же Zabbix или написать сценарий на bash для мониторинга дискового пространства.
Настроить logrotate для ротации и сжатия файлов журналов основных сервисов. Как правило, после установки logrotate все необходимые настройки уже будут в конфигурационных файлах, админу останется только убедиться в том, что logrotate запускается автоматически. Дополнительная инфа может быть найдена в man logrotate.

Проверка дискового пространства

Куда подевалось дисковое пространство?

Временные файлы — загляните в /tmp. Как правило, оттуда можно удалить сразу все.
Файлы сессий — каталог зависит от настроек движка.
База данных — для сокращения ее размера базу данных можно оптимизировать. Также можно выполнить специфические для движка запросы. Например, для WordPress следующий запрос удаляет комментарии со спамом, что может существенно сократить размер базы данных:

DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments)

Мэйл-боксы — стандартные почтовые ящики мало кто проверяет, а они могут быть заспамлены. Обычно они хранятся в /var/mail. Несколько гигабайтов спама — вполне реально.
Журналы — просмотрите в /var/log. Лучше всего настроить logrotate для ротации и сжатия журналов, но если некоторые журналы слишком большие и из-за них сервис не запускается, их можно удалить.
Резервные копии — возможно, вы не воспользовались услугой резервного копирования, а настроили создание бэкапов с помощью системного ПО. В этом случае проверьте каталог с бэкапами и удалите старые резервные копии.

А теперь внимание! Иногда заканчивается не свободное место, а свободное количество инодов (i-node). Результат такой же — система не может создать файл и сайт «падает» из-за подвисания сетевого сервиса. Куда подевались иноды? Некоторые движки, например, Magento, генерируют слишком много файлов сессий (обычно хранятся в /var/session, но все зависит от настроек движка). Такие файлы очень маленькие, места практически не занимают, зато крадут драгоценные иноды. Одна из тактик — регулярно чистить каталог сессий. В cron добавляется вот такой сценарий:

cd /var/session
for i in sess_*; do rm -fv $i; done

Недостаток этого способа в следующем:

При удалении сессий стирается вся инфа о пользователе, например, его корзина и данные о регистрации. Заходит пользователь в ваш магазин, выбирает товары и помещает в корзину. Тут запускается сценарий очистки и мало того, что корзина стерта, так ему еще и предлагают заново войти.
На одном из сайтов популярность была такова, что сессии очень быстро съедали все доступные иноды. Приходилось запускать их чистку чуть ли не раз в час, иначе сайт нормально не работал. Сами понимаете, раз в час всех пользователей, в том числе и менеджеров будет «выбрасывать» с сайта — дело не очень хорошее.

Альтернативное и более правильное решение заключается в создании еще одного диска (или раздела) с файловой системой reiserfs. Она не блещет производительностью, зато позволяет в одном блоке хранить несколько файлов — пока размер блока физически не заполнится. Reiserfs полностью решила проблему с инодами. Теперь сервер спокойно держит миллионы файлов инодов и чистить /var/session приходится довольно редко — на данном сервере автоматическая чистка вообще выключена и производится вручную администратором раз в месяц при регулярном обслуживании сервера.

Если облака для вас
не просто теория

Широкий спектр услуг
по выделенным северам
и мультиклауд-решениям

Конфигурация VPS и бесплатный тест уже через 2 минуты

Сконфигурировать VPS

Организация вашей IT-инфраструктуры на основе мультиклауд-решения

Запросить КП

Нехватка прочих ресурсов

Кроме дискового пространства, не нужно забывать о памяти и ресурсах процессора. Здесь поможет команда htop, которая показывает не только запущенные процессы, но и потребляемые ресурсы.

Команда htop

Одна из причин падения сайта — нехватка ресурсов, особенно, если речь идет о монстрообразных движках вроде Magento. Они чувствительны не только к оперативке, но и к количеству ядер.

Добавить необходимые ресурсы в панели управления Xelent — дело считанных минут. Просто добавьте нужные вам ресурсы и нажмите кнопку Перезагрузить и изменить.

Изменение параметров сервера

Неправильная конфигурация сервера

Мало выделить ресурсы, важно еще их правильно использовать. Если программное обеспечение использует ресурсы неэффективно, сайт может «падать». Типичный пример — «крушение» Apache из-за нехватки максимального количества процессов, которые может запустить Apache. В логах сообщение выглядит примерно так:

[Thu Mar 08 12:59:59.443036 2018] [mpm_prefork:error] [pid 37252] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

Здесь все казалось бы просто. Нужно открыть конфиг /etc/apache/apache2.conf и повысить значение MaxRequestWorkers. Но не спешите этого делать. Сначала выполните htop и посмотрите размер процесса Apache. Например, пусть процесс Apache занимает 100 Мб. Если вы установите 150 одновременных процессов, то понадобится 150 * 100 почти 15 Гб памяти и это нужно учитывать. Не забывайте, что для системы и других процессов (того же MySQL) также нужна память. Поэтому не переусердствуйте с этим параметром и не забывайте добавлять необходимые ресурсы в панели управления сервером.

Если же установить MaxRequestWorkers больше, чем может поместиться в памяти, в логах появится неоднозначная запись:

[Fri Mar 09 15:29:04.747616 2018] [core:notice] [pid 37252] AH00051: child pid 32103 exit signal Segmentation fault (11), possible coredump in /var/coredumps

Экспериментальным путем было выяснено, что причина в нехватке оперативной памяти.
Сервис MySQL особенно с его движком InnoDB тоже требователен к правильной настройке. База данных может легко подвиснуть при сохранении изменений вот с такой ошибкой:

SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction

Если MySQL еще жив, можно попробовать от админа БД ввести запрос:

SET GLOBAL innodb_lock_wait_timeout = 120;

Этот же оператор поможет, если перезапуск MySQL временно невозможен. Для постоянной установки значения конфигурации нужно открыть конфиг /etc/my.cnf и установить новое значение:

[mysqld]
innodb_lock_wait_timeout=120

После этого нужно перезапустить MySQL и попробовать поработать при новом значении.
Ошибки в работе могут быть вызваны и неправильной установкой параметра innodb_buffer_pool_size. В этом случае в логе может быть такое сообщение:

Memory size allocated for the temporary table is more than 20% of innodb_buffer_pool_size.

Такое сообщение будет сгенерировано, если размер памяти, выделяемый для временной таблицы на 20% больше, чем значение innodb_buffer_pool_size. Нужно просто увеличить значение этого параметра.

В большинстве случаев журналы помогут в расследовании падения сервера — в них даже приводятся четкие указания относительно того, какие параметры нужно изменить для нормальной работы сайта. Если подытожить, то причины падения сайта сводятся к нехватке ресурсов и неправильной конфигурации программного обеспечения.