Как масштабировать ресурсы VPS без боли

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

Сначала найдите узкое место

Апгрейд наугад — деньги на ветер. Ограничивать может CPU, память, диск или сеть, и лечатся они по-разному. Быстрая диагностика:

# общая картина в реальном времени
apt install -y htop && htop

# нагрузка на CPU/IO/steal одним взглядом
vmstat 2 5

# память: сколько реально свободно и есть ли своп
free -h

# диск: не забита ли очередь ввода-вывода (%util к 100 = упор в диск)
apt install -y sysstat && iostat -x 2 5

• load average выше числа ядер + высокий %us → не хватает CPU;
• swap растёт, free около нуля → не хватает RAM;
• %util диска у 100, высокий iowait → упор в диск;
• высокий %st (steal) → проблема не у вас, а в переподписке ноды.

Вертикальное масштабирование

Вертикальное (scale up) — добавить мощности одному серверу: больше vCPU, RAM, диска. Самый простой путь: у большинства провайдеров смена тарифа делается из панели за минуты, часто с одной перезагрузкой.

После апгрейда убедитесь, что система увидела ресурсы:

# ядра
nproc && lscpu | grep '^CPU(s)'

# память
free -h

# диск: расширить файловую систему после увеличения диска
df -h
# для ext4 на растянутом разделе:
resize2fs /dev/vda1  # имя раздела уточните через lsblk

На AMD EPYC + NVMe у MAATRIX вертикальный апгрейд особенно эффективен: добавленные ядра действительно быстрые, а NVMe не даёт диску стать новым узким местом после роста нагрузки.

Быстрая помощь памяти: swap

Если RAM не хватает эпизодически, своп спасёт от OOM-killer до апгрейда. Это не замена памяти, но страховка.

# создать файл подкачки 2 ГБ
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# снизить агрессивность свопа (реже свопить)
sysctl vm.swappiness=10

Горизонтальное масштабирование

Вертикальный рост когда-то упрётся в потолок ноды. Тогда переходят к горизонтальному (scale out) — распределяют нагрузку по нескольким VPS: отдельный сервер под БД, пул веб-серверов за балансировщиком.

# простейший балансировщик на nginx
upstream app {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
}
server {
    listen 80;
    location / { proxy_pass http://app; }
}

Горизонтальное масштабирование сложнее (нужны общая БД, сессии, синхронизация), зато снимает потолок одного сервера и повышает отказоустойчивость. Начинать стоит с выноса базы данных на отдельный VPS — она обычно упирается первой.

Оптимизация перед апгрейдом

Часто «нехватку ресурсов» лечат не деньгами, а настройкой. Прежде чем менять тариф, проверьте очевидное — нередко это даёт кратный выигрыш бесплатно.

• Кэш. Redis/Memcached снимают с БД и CPU повторяющиеся запросы.
• Индексы БД. Один пропущенный индекс способен грузить CPU на порядок сильнее нужного.
• Воркеры. Слишком много php-fpm/gunicorn воркеров съедают RAM и уводят сервер в своп.
• Статика. Отдавайте её через nginx или CDN, не через приложение.

# сколько памяти реально ест каждый процесс — ищем прожорливых
ps aux --sort=-%mem | head -n 10

# топ по CPU
ps aux --sort=-%cpu | head -n 10

# медленные запросы PostgreSQL (включить лог)
# в postgresql.conf: log_min_duration_statement = 500

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

Частые ошибки

• Апгрейд CPU, когда упор в диск. Всегда сверяйтесь с iostat и vmstat, а не с ощущениями.
• Жизнь на постоянном свопе. Это костыль, а не решение — добавьте RAM.
• Игнор steal. Если тормозит из-за переподписки ноды, апгрейд не поможет — меняйте провайдера.
• Забыли расширить ФС. Увеличили диск в панели, но не сделали resize2fs — место не появится.
• Сразу лезть в горизонталь. Для большинства проектов вертикального роста хватает надолго — не усложняйте раньше времени.

Частые вопросы