Что можно сделать на KVM с 1 ядром и 1 ГБ? Полное руководство по выжиманию производительности

Каждый Чёрный пятница на форумах появляются KVM VPS «1 ядро, 1 ГБ, годовая оплата дешевле чашки кофе». Кто-то покупает и забывает, а кто-то на том же железе крутит блог, обратный прокси, WireGuard, RSS и cron-задачи. Разница чаще не в железе, а в умении работать с бюджетным VPS: заменить стандартный «полный набор» лёгкими компонентами и настроить ядро так, чтобы каждый мегабайт памяти и каждое переключение контекста были на учёте.

Здесь не будет совета «купите машину побольше». Один вопрос: где предел для сайта и сервисов на 1 ядре и 1 ГБ и как к нему приблизиться?

Смотрим правде в глаза: что тянет 1 ядро / 1 ГБ

В KVM одно ядро обычно означает отсутствие выделенного физического ядра — пиковая вычислительная мощность ограничена. 1 ГБ памяти нужно делить между ОС, кэшем, приложением и соединениями. Это не «ничего не запустится», а одна задача — и хорошо; остальное либо объединяют, либо выносят наружу.

Бюджет памяти: каждый мегабайт на своём месте

На минимальной установке Debian 12 с одним SSH система занимает около 150–200 МБ. «Реальный бюджет» для приложений — порядка 400 МБ, без учёта page cache и всплесков соединений.

• Система + systemd + sshd: ~150–180 МБ; отключение лишних unit экономит ещё 30–50 МБ.
• Web-прокси (Caddy / nginx): ~15–40 МБ; для статики nginx ещё легче.
• Среда приложения: бинарник Go — обычно 10–30 МБ; пустой процесс Node.js — уже 50 МБ+, на дешёвом VPS с осторожностью.
• База данных: SQLite почти без постоянного потребления; MySQL 8 с настройками по умолчанию легко съедает 400 МБ.
• Swap / zram: разумно заложить 512 МБ–1 ГБ виртуальной памяти как буфер, но не считать её «настоящей» RAM.

⚠️ Практика: в free -h смотрите колонку available, а не только free. Linux использует свободную память под кэш; для приложений важен именно available.

Сайт на 1 ядре / 1 ГБ: лёгкие альтернативы

Классический LAMP/LNMP на бюджетном VPS — убийца памяти. Ниже — связка, которая в бою держала личные сайты с тысячами просмотров в день:

Если нужен динамический контент, сначала один бинарник на Go (PocketBase, miniBlog и т.п.) или Python FastAPI + SQLite, с числом worker'ов, зафиксированным на 1.

Готовый Caddyfile для статического сайта

example.com {
    root * /var/www/site
    file_server
    encode gzip zstd
    header Cache-Control "public, max-age=3600"
}

Потребление памяти всего сайта обычно < 30 МБ, HTTPS обновляется автоматически — certbot не нужен. Сборка — локально или в CI, VPS только «раздаёт файлы» — самый стабильный путь для сайта на 1 ГБ.

Оптимизация KVM: ядро и системный уровень

Сеть и I/O KVM сильно зависят от хоста, но на стороне гостя тоже есть заметный запас настройки. Параметры ниже проверены на многих Debian / Ubuntu VPS:

1. Включить BBR

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_fastopen = 3

На трансокеанских линиях BBR часто лучше заполняет канал, чем cubic по умолчанию, и субъективно снижает задержку.

2. zram вместо классического Swap на диске

Дисковый Swap на VPS даёт высокую задержку I/O и может «заморозить» машину. zram сжимает RAM и имитирует Swap — удобнее для небольших всплесков:

apt install zram-tools
# в /etc/default/zramswap:
# ALGO=lz4
# PERCENT=50

3. Снизить swappiness, защитить «горячие» данные

vm.swappiness = 10
vm.vfs_cache_pressure = 50

4. Соединения и дескрипторы файлов

net.core.somaxconn = 1024
net.ipv4.tcp_max_syn_backlog = 2048
fs.file-max = 65535

5. Урезать сервисы systemd

Отключите ненужное: bluetooth, avahi-daemon, ModemManager, агент мониторинга панели (если мониторинг уже снаружи).

Семь надёжных сценариев для бюджетного VPS

Если воспринимать 1 ядро / 1 ГБ как выделенный edge-узел, а не мини-ЦОД, он стабильно тянет:

1. Личный блог / техдокументация: Hugo + Caddy, сборка локально, деплой через rsync.
2. Входной обратный прокси: спереди Cloudflare, сзади — внутренняя сеть или объектное хранилище.
3. WireGuard jump host: 3–5 устройств в сети, нагрузка на CPU минимальна.
4. Webhook / боты: Telegram, Slack и др., один процесс на Go или Python.
5. DNS или AdGuard Home: ограничьте размер логов запросов, настройте ротацию.
6. Лёгкий мониторинг: Uptime Kuma или curl-скрипт с отчётом во внешнюю панель.
7. Приватное зеркало Git: git daemon или Gitea в минимальном режиме, репозитории в пределах гигабайтов.

Для AI-инференса, сборки крупных проектов или пайплайна security scan бюджетного VPS мало — лучше отдельная dev-машина. Если оцениваете цепочку code security review, см. как использовать /security-review в GitHub Copilot App и тяжёлую работу переносите на локальный Mac или облако.

Красные линии: чего на дешёвом VPS делать нельзя

• Elasticsearch / ClickHouse: официальный минимум памяти далеко за 1 ГБ, OOM при старте.
• MySQL 8 с настройками по умолчанию: если только не ужать innodb_buffer_pool_size до 64M и смириться с очень медленными запросами.
• Панель + LNMP «в один клик»: панель + Nginx + MySQL + PHP легко переваливают за 800 МБ постоянно.
• Kubernetes (k3s, один узел): control plane не рассчитан на такой VPS.
• Docker «всё сразу»: dockerd + compose с кучей сервисов — сильная фрагментация памяти.
• Использовать VPS как NAS с круглосуточной раздачей BT: двойной удар по диску и памяти, плюс лимиты провайдера.

Мониторинг и диагностика: за 5 минут до OOM

На бюджетном VPS нет запаса — мониторинг должен быть лёгким, точным и с алертами:

• node_exporter: метрик много, но ~20 МБ — для машин с небольшим запасом.
• glances: удобен в терминале, glances -w — простая web-панель.
• Свой скрипт: cron каждые 5 минут проверяет MemAvailable, ниже 80 МБ — curl в Telegram.
• Ротация логов: logrotate обязателен; забитый access.log встречается чаще OOM.

При нагрузочном тесте смотрите: load average (на 1 ядре не держите > 1.5 долго), MemAvailable (желательно > 100 МБ), iowait (скачет при swap-thrashing).

Когда пора «выпускаться» на более мощную машину?

Любой из признаков ниже — сигнал, что бюджетный VPS исчерпан:

• OOM чаще раза в неделю после всех оптимизаций из этой статьи.
• Нужны одновременно Web + БД + фоновые задачи, и ничего нельзя вынести наружу.
• Стабильно > 10k UV в день, а origin после CDN всё равно на 100% CPU.
• Задачи сместились от «хостинга страниц» к «сборке, тестам, AI» — время смотреть на облачный Mac или VPS побольше.

Для выбора моделей и прокси-архитектуры, где важна вычислительная мощность, см. стоит ли ждать Gemini 4: выбор в 2026 — инференс и оценку лучше гонять в среде с запасом ресурсов.