Для ощущения надёжности и безопасности VPS часто берут с запасом. Но со временем процессор начинает простаивать, память заполняется кэшем, диск пишет логи и бэкапы вместо рабочей нагрузки, а тариф остаётся прежним. На фоне грустных новостей об НДС и кризисе есть хорошая — некоторые расходы на инфраструктуру можно сократить. О том, как это сделать, мы расскажем под катом.
Оцените реальную нагрузку
Начать стоит с аудита нагрузок. В Linux это можно сделать через htop, а в Windows Server — с помощью диспетчера задач и счётчиков Performance Monitor. Чаще всего после оценки распределения ресурсов оказывается, что процессор большую часть времени простаивает, а заметная часть памяти занята кэшем.
Интереснее, когда выясняется, что и дисковая активность связана в основном с логами и резервным копированием, а не с рабочей нагрузкой. Если это не разовый простой, а обычный режим работы, значит, конфигурация выбрана с большим запасом.
Но не спешите сразу «резать» тариф, оцените историю через недельные или месячные графики загрузки CPU, RAM и диска. Инструменты в этом случае не принципиальны — главное, чтобы были видны средние значения и пики. Если они короткие, то можно сразу перейти к последнему разделу статьи.
Экономьте дисковое пространство и IOPS
Дисковые операции (IOPS) — это самый дорогой ресурс на виртуальном хостинге, даже на SSD. Здесь оптимизацию стоит начать с ревизии, а именно посмотреть, что занимает диск и почему. В Linux для этого хватает стандартных утилит:
df -h показывает общую картину по файловым системам и даёт понять, где заканчивается место;
du позволяет посмотреть, какие каталоги реально занимают диск, а ncdu делает то же самое, но в интерактивном виде.
В Windows Server эту задачу решают встроенные средства анализа или сторонние утилиты. Обычно в топе списка оказываются каталоги с логами, бэкапами и временными файлами. Если ротация настроена формально или не настроена вовсе, они могут съедать десятки гигабайт и при этом постоянно писать на диск. То же самое относится к резервным копиям. Старые бэкапы часто продолжают храниться «на всякий случай», хотя давно потеряли практическую ценность. Регулярная очистка таких данных освобождает место и снижает нагрузку на диск.
Также полезно разделять все данные по «горячести». Рабочие базы данных, активные файлы и кэш логично держать на быстром SSD или NVMe. Архивы, старые резервные копии и редко используемые данные лучше вынести на отдельный диск или в объектное хранилище.
Отдельно стоит продумать снижение лишних операций записи. В Linux при каждом обращении обновляется атрибут atime, в результате даже обычная отдача статики через веб-сервер превращает чтение в запись. Для того, чтобы снизить IOPS, отключите логирование каждого запроса в Nginx/Apache.
В Windows Server есть механизм CompactOS, который сжимает системные файлы и позволяет освободить около 2–3 ГБ пространства диска. В некоторых случаях он даже помогает ускорить загрузку, так как процессору проще распаковать данные, чем читать их с диска.
Если на сервере активно используются резервные копии, есть смысл обратить внимание на инструменты, которые «умеют» инкрементное копирование, сжатие и дедупликацию. Если нужна подборка таких решений, пишите в комментарии.
Облегчайте систему и убирайте лишнее
Существенную часть нагрузки может создавать система. Оптимизировать её стоит с базового вопроса — действительно ли нужна такая тяжёлая ОС.
В случае с Linux оптимизация обычно означает выбор минимального дистрибутива. Например, Debian потребляет заметно меньше памяти и диска, чем универсальные образы с набором сервисов «на все случаи жизни».
В Windows Server ситуация похожая, только эффект заметнее — полноценная версия с GUI может занимать 15–20 ГБ на диске. Если постоянный графический интерфейс не нужен, лучше сразу выбрать core-редакцию. Если же GUI всё-таки необходим, можно вручную пройтись по службам и отключить всё, что на VPS точно не используется. Среди наших кандидатов:
Служба | Имя | Почему отключаем |
Distributed Link Tracking Client | TrkWks | Отслеживает связи NTFS в локальной сети. На изолированном веб-сервере бесполезна. |
Geolocation Service | lfsvc | Сервер стоит в дата-центре, он не перемещается. |
Downloaded Maps Manager | MapsBroker | Карты на сервере не нужны. |
Touch Keyboard | TabletInputService | У VPS нет сенсорного экрана. |
Windows Audio | Audiosrv | Если не передаёте звук по RDP, отключайте. |
Xbox Live Services | Xbl... | Весь пакет служб Xbox должен быть уничтожен. |
Отде��ьная тема — антивирус. За последние годы Microsoft Defender стал вполне приличным продуктом, но его архитектура предполагает постоянное сканирование операций чтения и записи. На VPS с одним vCPU процесс MsMpEng.exe может легко «съедать» процессорное время при распаковке архивов или сборке проектов. Полностью отключать защиту небезопасно, особенно если сервер доступен извне, но снизить её агрессивность разумно. Настройка исключений для папок с базами данных, логами и бэкапами даст ощутимый эффект.
Ещё один приём для тех, у кого в инфраструктуре больше одной машины, — контейнеризация. Docker или LXC позволяют запускать несколько сервисов на одном сервере без накладных расходов полноценной виртуальной машины. Контейнеры делят ядро, не дублируют ОС и запускаются быстрее. В результате один VPS может спокойно обслуживать десяток изолированных сервисов там, где раньше потребовалось бы несколько отдельных.
Но помните, что сам Docker тоже потребляет ресурсы. На совсем крошечных тарифах (512 МБ – 1 ГБ) накладные расходы могут «съесть» всю выгоду.
Настройте работу с памятью и свопом
При работе с памятью на Linux можно встретить совет о полном отключении swap (vm.swappiness=0). Это плохая идея. Если запретить ядру выгружать анонимные страницы в swap, оно начнёт выбрасывать файловый кэш. В итоге при нехватке памяти система будет постоянно перечитывать данные с диска, что только усугубит ситуацию.
Оптимальный вариант — оставить swappiness на разумном уровне (в районе 60) и исп��льзовать ZRAM — сжатый блок памяти, который используется как своп, но физически остаётся в RAM. В этом случае данные не пишутся на диск, а сжимаются и хранятся в оперативной памяти.
Алгоритмы вроде lz4 или zstd легко сжимают типичные данные приложений в 3–4 раза, поэтому своп объёмом 1 ГБ может занимать всего 300–400 МБ реальной памяти.
В Windows Server логика похожая, хотя реализована иначе. Здесь важно следить за тем, чтобы системе хватало физической памяти под рабочие процессы, а подкачка страниц не становилась основным источником данных. Для небольших Windows VPS это ещё одна причина аккуратно подходить к количеству служб и фоновым процессам.
Проверьте драйверы и используйте паравиртуализацию
Когда виртуальная машина не знает, что она виртуальная, она ожидает увидеть обычное «железо» — IDE-контроллер диска, сетевую карту Intel или Realtek, стандартные таймеры и прерывания. Гипервизор в этом случае вынужден всё это эмулировать, и каждый запрос к диску или сети превращается в цепочку лишних операций, переключений контекста и ожиданий. За это вы платите процессорным временем и задержками.
Решается это использованием паравиртуализации, в первую очередь драйверов VirtIO. Они позволяют гостевой системе напрямую взаимодействовать с гипервизором через упрощённые очереди в общей памяти, без эмуляции старого железа. Разница в производительности здесь хорошо заметна даже на глаз, особенно на дисковых операциях и сети.
В Linux с этим обычно всё просто. Поддержка VirtIO встроена в ядро уже много лет. Достаточно убедиться, что нужные модули загружены. В Windows Server ситуация чуть сложнее — в некоторых версиях драйверы VirtIO не включены по умолчанию, особенно если сервер ставился из собственного ISO или мигрировался с другой платформы.
Проверить это можно в диспетчере устройств. Если вместо Red Hat VirtIO SCSI controller используется Standard SATA AHCI Controller или, что ещё хуже, IDE, вы теряете заметную часть производительности диска.
То же самое относится и к сети. Red Hat VirtIO Ethernet Adapter работает значительно эффективнее, чем эмуляция старых сетевых карт, которая может съедать до трети одного ядра CPU только на обработке прерываний. Отдельно стоит проверить наличие VirtIO Balloon Driver — он позволяет гипервизору более гибко управлять памятью.
Если драйверов нет, их установка требует аккуратности. У нас в UltraVDS образы уже подготовлены, но при миграции бывает, что система загружается с эмулируемого контроллера. В этом случае к выключенной виртуальной машине добавляется небольшой дополнительный диск с типом VirtIO.
Оптимизируйте кэширование и приложения
Иногда выясняется, что основные потребители ресурсов — это приложения. В этом случае нужно работать с ними.
Кэширование статического и динамического контента
Статика почти всегда кэшируется безболезненно. Изображения, стили, скрипты нет смысла каждый раз «отдавать» заново. Это можно делать через CDN или напрямую на уровне Nginx с включённым gzip или Brotli. Такой кэш снижает сетевую нагрузку и уменьшает количество операций, которые сервер выполняет на каждый запрос.
С динамическим контентом всё сложнее, но и здесь есть рабочие варианты. FastCGI Cache, Varnish, Redis или Memcached позволяют отдавать готовые ответы из памяти, не нагружая приложение и базу данных.
Базы данных и их аппетиты
Базы данных заслуживают отдельного внимания. MySQL и PostgreSQL по умолчанию настроены универсально и не ориентированы на экономию ресурсов. Если оставить конфигурацию как есть, они с радостью займут всю доступную память и будут активно работать с диском.
В этом случае полезно ограничивать буферы. Для InnoDB достаточно выделить 60–70% доступной для MySQL RAM, а не всей памяти сервера. Это снижает давление на систему и уменьшает количество операций ввода-вывода.
Кроме того, если объём памяти меньше 2 ГБ, стоит отключить performance_schema, который может потреблять сотни мегабайт на сбор статистики, не принося реальной пользы.
PHP-FPM и фоновые процессы
Для PHP-проектов важно обратить внимание на режим работы PHP-FPM. Ondemand позволяет запускать процессы только при наличии запросов и завершать их в периоды простоя. Значения вроде pm.max_children лучше подбирать осторожно, ведь избыточное количество процессов под нагрузкой легко приводит к OOM, особенно при резких всплесках трафика.
Windows-приложения и IIS
В Windows-окружении логика та же самая. Сервисы, работающие поверх IIS или .NET, выигрывают от кэширования и аккуратного обращения с памятью. Чем меньше фоновых задач и лишних операций выполняет приложение, тем стабильнее ведёт себя сервер. З��есь часто оказывается, что проблема не в нехватке ресурсов, а в том, что сервисы просто работают «по умолчанию» и никогда не настраивались под конкретную нагрузку.
Удалённый доступ и административные сессии
Удалённый доступ редко воспринимают как источник лишних расходов. Кажется, что RDP или SSH — это просто способ попасть на сервер и что на фоне рабочих сервисов их вклад в нагрузку ничтожен. На практике всё иначе.
В Windows Server каждая RDP-сессия — это не просто терминал, а полноценная графическая сессия. Сервер рендерит интерфейс, кодирует изображение и отправляет его по сети. Если VPS без GPU, а так бывает почти всегда, вся эта работа ложится на CPU.
По умолчанию RDP может использовать H.264 и режим AVC444. Картинка получается красивой, но софтварное кодирование видео на одном виртуальном ядре быстро превращается в проблему. В этом случае есть смысл упростить графику через групповые политики.
Ещё один момент, о котором часто забывают, — транспорт. Если порт 3389 открыт только по TCP, RDP становится чувствительным к потерям пакетов и задержкам. В результате сервер тратит ресурсы на повторную передачу данных, а пользователь видит лаги.
В Linux-среде проблемы менее заметны, но и здесь бывают нюансы. Постоянно открытые SSH-сессии с активными tmux или screen, фоновые tail логов, забытые консоли с запущенными утилитами — всё это медленно, но верно съедает ресурсы.
В целом сервер не должен «обслуживать администратора» больше, чем это действительно нужно. Чем меньше времени вы проводите в графической сессии и чем проще её настройки, тем меньше ресурсов уходит впустую.
Снизьте сетевую нагрузку и исходящий трафик
Сеть обычно воспринимают как что-то вторичное. Пока сайт открывается и пакеты ходят, кажется, что всё в порядке. Но именно сетевые операции часто становятся причиной переплаты.
Первое, что стоит сделать, — понять, что именно сервер отдаёт наружу. В Linux для этого подойдут iftop, nload, vnstat. В Windows Server похожую картину дают счётчики сети в Performance Monitor или даже встроенная статистика в диспетчере задач. Очень часто выясняется, что:
большая часть трафика — это статика;
файлы отдаются без сжатия;
один и тот же контент постоянно уходит с сервера повторно.
Если сервер раздаёт изображения, скрипты или обновления, он делает это каждый раз заново, тратя и сеть, и CPU.
Сжатие — дешёвый способ экономии. Gzip и Brotli позволяют уменьшить объём передаваемых данных, особенно для HTML, JSON, CSS и JavaScript. Важно не включать сжатие «всё подряд», а ограничиться тем, что реально выигрывает от компрессии.
Один из самых эффективных способов снизить сетевую и процессорную нагрузку — перестать раздавать статику с самого сервера. CDN или даже простой внешний кеширующий прокси снимают с VPS огромный пласт работы.
Мелочь, о которой редко задумываются. Если соединения постоянно открываются и закрываются, сервер тратит ресурсы на установку TCP-сессий и TLS-рукопожатия. Корректно настроенный keep-alive позволяет обслуживать больше запросов на том же железе. Это снижает и сетевую болтанку, и нагрузку на CPU, особенно при большом числе коротких запросов.
Подберите конфигурацию VPS под реальную нагрузку
После того как вы выполните все действия выше и понаблюдаете за показателями, станет понятно, как сервер на самом деле живёт под нагрузкой. На этом этапе логично перейти к планированию ресурсов.
Если у провайдера почасовая или поминутная тарификация, самый простой способ сократить расходы — вовремя останавливать серверы, которые не нужны круглосуточно. Начинать лучше с тестовых стендов, демо-серверов, старых сайтов и вспомогательных сервисов. Они часто работают без реальной нагрузки, но продолжают потреблять ресурсы ночью и в выходные.
В случае с ежемесячной или годовой подпиской (как у нас в UltraVDS), серверы выключать смысла нет, но можно пересмотреть конфигурацию. Если система стабильно использует лишь часть ресурсов, можно поменять объём RAM и число vCPU без переустановки ОС, через панель или API.
Практика показывает, что запас в 20–30% от пиковых значений позволяет спокойно переживать деплой, всплески нагрузки и прочие сюрпризы. Такой плавающий ресайзинг почти всегда даёт стабильный результат, и в итоге каждая сэкономленная копейка складывается в существенную сумму.
А на чём вы экономите? Делитесь в комментариях своим опытом оптимизации VPS.
