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

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

Блог MAATRIX · 2026-07-07

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

Содержание

  1. Сначала найдите узкое место
  2. Вертикальное масштабирование
  3. Быстрая помощь памяти: swap
  4. Горизонтальное масштабирование
  5. Оптимизация перед апгрейдом
  6. Частые ошибки

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

['Апгрейд наугад — деньги на ветер. Ограничивать может CPU, память, диск или сеть, и лечатся они по-разному. Быстрая диагностика:', '
# общая картина в реальном времени\napt install -y htop && htop\n\n# нагрузка на CPU/IO/steal одним взглядом\nvmstat 2 5\n\n# память: сколько реально свободно и есть ли своп\nfree -h\n\n# диск: не забита ли очередь ввода-вывода (%util к 100 = упор в диск)\napt install -y sysstat && iostat -x 2 5
', '
  • load average выше числа ядер + высокий %us → не хватает CPU;
  • swap растёт, free около нуля → не хватает RAM;
  • %util диска у 100, высокий iowait → упор в диск;
  • высокий %st (steal) → проблема не у вас, а в переподписке ноды.
']

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать масштабируемый VPS

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

['Вертикальное (scale up) — добавить мощности одному серверу: больше vCPU, RAM, диска. Самый простой путь: у большинства провайдеров смена тарифа делается из панели за минуты, часто с одной перезагрузкой.', 'После апгрейда убедитесь, что система увидела ресурсы:', "
# ядра\nnproc && lscpu | grep '^CPU(s)'\n\n# память\nfree -h\n\n# диск: расширить файловую систему после увеличения диска\ndf -h\n# для ext4 на растянутом разделе:\nresize2fs /dev/vda1  # имя раздела уточните через lsblk
", 'На AMD EPYC + NVMe у MAATRIX вертикальный апгрейд особенно эффективен: добавленные ядра действительно быстрые, а NVMe не даёт диску стать новым узким местом после роста нагрузки.']

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

['Если RAM не хватает эпизодически, своп спасёт от OOM-killer до апгрейда. Это не замена памяти, но страховка.', "
# создать файл подкачки 2 ГБ\nfallocate -l 2G /swapfile\nchmod 600 /swapfile\nmkswap /swapfile\nswapon /swapfile\necho '/swapfile none swap sw 0 0' >> /etc/fstab\n\n# снизить агрессивность свопа (реже свопить)\nsysctl vm.swappiness=10
", 'Важно: постоянный активный своп — сигнал, что памяти реально мало и пора на тариф побольше. Своп на диске в разы медленнее RAM.']

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

['Вертикальный рост когда-то упрётся в потолок ноды. Тогда переходят к горизонтальному (scale out) — распределяют нагрузку по нескольким VPS: отдельный сервер под БД, пул веб-серверов за балансировщиком.', '
# простейший балансировщик на nginx\nupstream app {\n    server 10.0.0.11:8080;\n    server 10.0.0.12:8080;\n}\nserver {\n    listen 80;\n    location / { proxy_pass http://app; }\n}
', 'Горизонтальное масштабирование сложнее (нужны общая БД, сессии, синхронизация), зато снимает потолок одного сервера и повышает отказоустойчивость. Начинать стоит с выноса базы данных на отдельный VPS — она обычно упирается первой.']

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

['Часто «нехватку ресурсов» лечат не деньгами, а настройкой. Прежде чем менять тариф, проверьте очевидное — нередко это даёт кратный выигрыш бесплатно.', '
  • Кэш. Redis/Memcached снимают с БД и CPU повторяющиеся запросы.
  • Индексы БД. Один пропущенный индекс способен грузить CPU на порядок сильнее нужного.
  • Воркеры. Слишком много php-fpm/gunicorn воркеров съедают RAM и уводят сервер в своп.
  • Статика. Отдавайте её через nginx или CDN, не через приложение.
', '
# сколько памяти реально ест каждый процесс — ищем прожорливых\nps aux --sort=-%mem | head -n 10\n\n# топ по CPU\nps aux --sort=-%cpu | head -n 10\n\n# медленные запросы PostgreSQL (включить лог)\n# в postgresql.conf: log_min_duration_statement = 500
', 'Если после оптимизации ресурсы всё равно стабильно заняты в обычные часы — вот тогда апгрейд оправдан и деньги пойдут в дело, а не на компенсацию неэффективного кода.']

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

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

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.

Арендовать масштабируемый VPS

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

Как понять, что пора масштабироваться, а не оптимизировать код?

Сначала оптимизация: кэш, индексы БД, лимиты воркеров. Если ресурсы стабильно заняты на 80%+ при уже оптимизированном приложении в обычные (не пиковые) часы — пора наращивать ресурсы.

Теряются ли данные при смене тарифа?

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

Вертикальное или горизонтальное — что выбрать?

Начинайте с вертикального: проще и дешевле. К горизонтальному переходите, когда упёрлись в потолок ноды или нужна отказоустойчивость. Первым шагом выносите БД на отдельный сервер.

Читайте также