Сервер перегружен, что делать: гайд, чтобы исправить высокую нагрузку

Пожалуй, это знакомо каждому из нас – вы хотите найти что-то в интернете или сделать заказ в маркетплейсе, а нужный сайт не открывается.

Досадно, согласны?

Одна из возможных причин подобной ситуации – сервер перегружен запросами и не справляется с ними, из-за чего работа замедляется или вовсе останавливается. И если для пользователей это обычно сигнал к переходу на другой сайт, то для администратора или владельца проекта – может превратиться в сущий кошмар.

Ведь когда из-за нехватки ресурсов сервис начинает медленно отвечать, выдавать ошибки или полностью перестает работать, всё это может ухудшить пользовательский опыт, привести к затратам на экстренное восстановление, штрафам за нарушение SLA и т. д

Наша статья будет полезна каждому, кто заинтересован в снижении простоя своего сервиса и стабильной работе серверов.

Как понять, что сервер перегружен, и какие действия предпринять

Вот самые частые признаки того, что сервер, возможно, перегружен:

Высокое потребление ресурсов

Если CPU под 90–100%, а память (RAM) почти полностью заполнена.

По нашему опыту, ключевой метрикой, от которой нужно отталкиваться, является Load Average (то есть средняя нагрузка) – отслеживать следует такие пороги:

• load1 <= 0.7 * CPU_COUNT – зеленая зона
• load1 0.7–1.0 * CPU_COUNT – желтая зона
• load1 > CPU_COUNT – красная зона, значит, начинаются задержки 
• load5 > CPU_COUNT – в этом случае на сервере наблюдается системная перегрузка

Узнать о запущенных процессах и использовании CPU можно, введя в Linux-консоли команду top, а метрики, связанные с потреблением ресурсов, легко отслеживать через дашборды в системах мониторинга (Grafana, Prometheus и др.).

Долгий отклик серверных приложений

Если критические процессы (веб-сервер, база данных) самопроизвольно завершаются, SSH-подключение выполняется медленно или не устанавливается вовсе, а пользователи жалуются на “зависания” и ошибки 5xx (общий ответ сервера о том, что что-то пошло не так и он может быть перегружен).

Проблемы с сетью

Увеличение количества сетевых ошибок и повторных запросов, отказ балансировщиков нагрузки и высокая пакетная потеря при ping-тестах (>5–10% потерь пакетов).

Логи сигнализируют о проблемах

Сообщения о нехватке памяти и таймаутах соединений с БД, ошибки вида “too many open files”, “connection timed out”, “out of memory” и предупреждения в логах ядра (/var/log/kern.log, dmesg) о памяти или процессах.

Аномальное поведение системы

Например, если температура оборудования повышенная (>65–70°C для CPU и >40–45°C для жестких дисков) и заметен резкий рост количества запросов или активных пользователей.

Чтобы не допустить всех этих случаев, обычно мы рекомендуем пользователям всегда оставлять запас по требуемым ресурсам: например, хотя бы 1 Гб дополнительно для оперативной памяти и до 5 Гб – для диска. Кроме того, важно отслеживать количество обращений к сайту, поскольку если поток запросов резко возрастает, лучше вовремя это увидеть.

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

Избавляем сервер от лишних процессов

Если на сервере возникает большое количество процессов (к примеру, из-за cron-заданий) и он долго загружается, мы советуем использовать утилиту flock, которая может помочь избежать спама сервера заданиями.

Эта утилита ставит файловую блокировку на указанный файл, и пока блокировка удерживается одним процессом, другие – ждут или завершаются, что удобно для cron-скриптов и параллельных задач.

Вот общая команда для запуска flock: flock [опции] <файл-блокировки> <команда> (например, flock -n /tmp/lock.lock /path/to/script.sh).

Оптимизируем скрипты и выявляем проблемные участки кода

Повышенная нагрузка на процессор часто возникает из-за не оптимизированных PHP-скриптов.

В этом случае можно настроить PHP slow log – журнал, в который PHP записывает выполнение скриптов, превысивших заданный порог времени. Таким образом можно выявлять медленные и проблемные участки кода. Кроме того, отследить долгие участки в коде могут помочь отдельные профилировщики для диагностики – например, Perf, Valgrind, DTrace и др.

Освобождаем место на диске

Порой сервер перегружен из-за исчерпания дискового пространства. И в данной ситуации для анализа места на диске мы рекомендуем использовать ncdu – эта удобная утилита с простым текстовым интерфейсом позволяет быстро находить файлы и папки, занимающие больше всего места на диске.

Также в этом случае может быть полезно Redis – высокопроизводительное распределенное хранилище данных, которое работает как сверхбыстрая база данных типа “ключ–значение”: хранит все данные в оперативной памяти, поддерживает репликацию и различные структуры данных (строки, списки, хеши). Redis доступно нашим пользователям виртуального хостинга в качестве приватного сервиса (у нас есть подробная инструкция по настройке) и может быть установлено на VPS (установить Redis для Linux можно с помощью документации).

Теперь – о том, как проактивно отслеживать состояние сервера, чтобы не перегрузить его.

Как не допустить перегрузку сервера

Чтобы понимать, почему сервер перегружен, а также узнавать обо всём раньше пользователей, можно использовать специальные инструменты.

Например, в этом могут помочь такие системы, как:

Grafana

Свободная программная система, с помощью которой можно визуализировать данные практически из любых источников – например, Grafana поддерживает MySQL, PostgreSQL, Zabbix, Clickhouse, Prometheus, Graphite, InfluxDB, Elasticsearch и т. д. Благодаря широкому набору настроек и возможностей для кастомизации графиков и дашбордов Grafana можно легко настроить под свои нужды и задачи.

Например, используя систему Grafana вместе с Prometheus (инструмент для мониторинга и сбора метрик), можно не просто увидеть, что сервер тормозит или есть перегрузка массовыми запросами, а понять, почему так происходит и как давно.

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

Graylog

Открытая платформа, которая собирает и анализирует журналы VPS-серверов и приложений, помогая выявлять причины повышенной нагрузки и отслеживать аномалии. В отличие от Prometheus, который работает с числовыми метриками, Graylog специализируется на текстовых логах, превращая их в структурированные данные для расследования инцидентов.

Пример сводки с графиками ошибок:

Источник

При этом Graylog не просто выдает информацию, а помогает понять, почему сервер не загружается: например, это может быть такой вид атаки на перегрузку сервера, как DDoS, направленная на эндпоинт – то есть перегрузку конкретной точки входа.

Zabbix

Мощная гибкая система мониторинга с наглядными отчетами и диаграммами, которая позволяет в реальном времени отслеживать загрузку процессора, использование памяти, сетевой трафик, доступность сервисов, срок действия SSL-сертификата и многое другое.

Zabbix поддерживает множество протоколов и методов мониторинга (SNMP, IPMI, JMX, SSH, Telnet, ICMP, HTTP и т. д.), а также сотни готовых шаблонов для оборудования различных производителей, поэтому подходит как для небольших проектов, так и для высоконагруженных сервисов. Как и в случае с Grafana, VPS с Zabbix для мониторинга сервера можно развернуть у нас буквально в пару кликов.

Перегрузка серверов – частая проблема, поскольку в современную цифровую эпоху сайты регулярно сталкиваются с обработкой больших объемов трафика.

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