Сайт на VPS тормозит: как найти причину за 15 минут

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

Разберём порядок диагностики, который за пятнадцать минут сужает круг до одного виновника.

Сначала: где именно медленно

Прежде чем лезть на сервер, поймите, что тормозит. Откройте сайт, нажмите F12, вкладка Network, обновите страницу.

Смотрите на первую строку — сам HTML-документ, колонка Waiting (TTFB):

• до 200 мс — сервер отвечает быстро, проблема во фронтенде: тяжёлые картинки, много скриптов
• 500 мс и больше — тормозит сервер, идём дальше по этому гайду

Если TTFB маленький, а страница всё равно грузится долго — оптимизируйте картинки и скрипты, сервер тут ни при чём.

Шаг 1. Общая картина

Подключитесь по SSH и поставьте инструмент, который показывает всё сразу:

root@vps:~#apt install -y htoproot@vps:~#htop

Смотрите на три вещи:

Load average внизу. Три числа — нагрузка за 1, 5 и 15 минут. Сравнивайте с количеством ядер: на двухъядерном сервере значение до 2 нормально, выше 4 — перегрузка. Узнать число ядер: nproc.

Столбик памяти. Если полоса Mem забита почти полностью, а Swp растёт — памяти не хватает, и система начала выгружать данные на диск. Это самая частая причина резких тормозов.

Список процессов. Отсортирован по нагрузке на процессор. Виновник обычно сразу видно наверху.

Выйти — q.

Шаг 2. Проверяем диск

Диск — самый недооценённый источник тормозов. Сайт может «висеть» при почти пустом процессоре, если диск занят.

root@vps:~#apt install -y sysstatroot@vps:~#iostat -x 2 3

Смотрите столбец %util для вашего диска. Значение около 100% означает, что диск загружен полностью и стал узким местом.

Заодно проверьте, не кончилось ли место:

root@vps:~#df -h

Шаг 3. Память

root@vps:~#free -h

Ключевая строка — available. Именно она показывает, сколько памяти реально доступно, а не free. Если available близко к нулю — сервер задыхается.

Кто больше всех потребляет:

root@vps:~#ps -eo pid,rss,comm --sort=-rss | head -10

Значения в килобайтах. Делите на 1024, чтобы получить мегабайты.

Проверьте, не убивала ли система процессы из-за нехватки памяти:

root@vps:~#dmesg -T | grep -i "out of memory" | tail -5

Если такие строки есть — памяти точно не хватает. Это объясняет ситуацию «сайт периодически отваливается сам по себе».

Шаг 4. База данных

На сайтах с базой она виновата чаще всего. Медленные запросы возникают, когда данных стало больше, а индексов нет.

Для MySQL и MariaDB посмотрите, что выполняется прямо сейчас:

root@vps:~#mysqladmin -u root -p processlist

Долго висящие запросы в состоянии Sending data — верный признак отсутствия индекса.

Включите журнал медленных запросов:

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

Через день посмотрите, что накопилось — обычно виноваты два-три запроса.

Для PostgreSQL:

root@vps:~#sudo -u postgres psql -c "SELECT pid, now()-query_start AS длительность, query FROM pg_stat_activity WHERE state='active' ORDER BY 2 DESC LIMIT 5;"

Шаг 5. Логи веб-сервера

Иногда причина не в ресурсах, а в наплыве запросов.

Кто чаще всех стучится за сегодня:

root@vps:~#awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Если один адрес сделал тысячи запросов — это либо сканер, либо парсер. Заблокировать:

root@vps:~#ufw deny from 1.2.3.4

Какие страницы запрашивают чаще всего:

root@vps:~#awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Типовые причины и что делать

Не хватает памяти. Самое частое. Либо расширить тариф, либо уменьшить аппетиты: сократить число процессов PHP-FPM, ограничить память базе данных.

Диск загружен на 100%. Обычно это база без индексов или отсутствие кэширования — каждый запрос читает с диска. Проверьте, стоит ли кэш.

Один процесс съел процессор. Найдите его в htop. Часто это фоновая задача, скрипт в бесконечном цикле или неудачный плагин.

Наплыв ботов. Половина трафика небольших сайтов — сканеры и парсеры. Помогает ограничение частоты запросов в nginx:

limit_req_zone $binary_remote_addr zone=lim:10m rate=10r/s;

server {
    location / {
        limit_req zone=lim burst=20 nodelay;
    }
}

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

location ~* \.(jpg|jpeg|png|webp|css|js|woff2)$ {
    expires 30d;
    access_log off;
}

Когда пора менять тариф

Расширять сервер стоит, если после устранения явных проблем:

• load average стабильно выше числа ядер
• available память держится ниже 15% от общей
• %util диска постоянно около 100%

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

Чтобы не повторялось

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

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