Настройка деплоя на Dedicated Server: конфигурация и оптимизация

Сайт тормозит при нагрузке 500 RPS? Переезд на dedicated server — логичный шаг, но неправильная конфигурация сводит на нет преимущества. Мы нередко видим серверы, где дорогое железо простаивает из-за неоптимальных настроек Nginx и PostgreSQL. Наша команда с десятилетним опытом настраивает выделенные серверы под ключ: от аппаратного RAID до мониторинга. Оценим ваш проект бесплатно и подберём конфигурацию, которая выдержит 10 000 RPS. Получите консультацию инженера — свяжитесь с нами.

Почему правильная конфигурация сервера критична?

Даже мощный сервер с 128 GB RAM и NVMe-дисками может показывать низкую производительность, если не настроить системные параметры. Типичная ошибка — дефолтные лимиты файловых дескрипторов (1024) при нагрузке в тысячи соединений. Или отключённый кеш (опкэш) для PHP-приложений. Мы исправляем такие проблемы на этапе настройки.

Рекомендованные конфигурации для разных нагрузок

Для проектов с базой данных PostgreSQL рекомендуем не менее 64 GB RAM.

Как выбрать RAID-уровень?

RAID 1 обеспечивает зеркалирование — при отказе диска система продолжает работу. RAID 10 (или RAID 0 для данных) даёт максимальную скорость чтения/записи. Для корневого раздела используем RAID 1, для данных — RAID 10, если дисков больше двух. Настройка выполняется через mdadm:

# Проверить диски
lsblk
fdisk -l

# Создать RAID 1 для корневого раздела
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb
mkfs.ext4 /dev/md0

# RAID 10 для данных (4 диска)
mdadm --create /dev/md1 --level=10 --raid-devices=4 \
    /dev/sdc /dev/sdd /dev/sde /dev/sdf

Подробнее о RAID можно прочитать в Wikipedia.

Сравнение RAID-уровней для веб-сервера

RAID 10 лучше RAID 5 в 3 раза по скорости записи, поэтому для данных выбираем его.

Оптимизация системы и стека

Системные параметры

Оптимизируем системные параметры: увеличиваем лимиты файловых дескрипторов, настраиваем сетевой стек, отключаем своп. Типовые настройки:

# /etc/sysctl.conf и /etc/security/limits.conf
net.core.somaxconn = 65536
net.core.netdev_max_backlog = 65536
net.ipv4.tcp_max_syn_backlog = 65536
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 10240 65535

fs.file-max = 2097152
vm.swappiness = 10

*    soft nofile 1048576
*    hard nofile 1048576
root soft nofile 1048576

Nginx

# /etc/nginx/nginx.conf
worker_processes 8;
events {
    worker_connections 4096;
    use epoll;
    multi_accept on;
}
http {
    keepalive_timeout 65;
    keepalive_requests 1000;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
}

PHP-FPM и OPcache

; /etc/php/8.3/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

[opcache]
opcache.enable = 1
opcache.memory_consumption = 512
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0

PostgreSQL

Настройка PostgreSQL критична: shared_buffers = 25% RAM, effective_cache_size = 75% RAM, random_page_cost = 1.1 для SSD. Пример для 128 GB RAM:

shared_buffers = 32GB
effective_cache_size = 96GB
maintenance_work_mem = 2GB
work_mem = 128MB
wal_buffers = 64MB
checkpoint_completion_target = 0.9
max_wal_size = 4GB
random_page_cost = 1.1
effective_io_concurrency = 200

Процесс настройки сервера

1. Аудит текущей конфигурации — если сервер уже используется, анализируем метрики и логи.
2. Установка ОС (Ubuntu LTS или Debian stable) с настройкой RAID и файловой системы ext4.
3. Установка и оптимизация веб-стека — Nginx, PHP-FPM, PostgreSQL.
4. Настройка безопасности — брандмауэр (ufw), fail2ban, SSL-сертификаты (Let's Encrypt).
5. Интеграция мониторинга — Prometheus + Grafana, Zabbix для оповещений, Sentry для ошибок.
6. Автоматизация бэкапов и деплоя (Ansible / GitLab CI).
7. Передача документации и обучение вашей команде.

Сроки и стоимость

Настройка выделенного сервера с нуля (OS, RAID, стек, SSL, мониторинг) занимает 3–5 дней. Оптимизация под конкретную нагрузку — ещё 2–3 дня. Стоимость рассчитывается индивидуально в зависимости от сложности и необходимого стека. Неправильная настройка может стоить до 40% производительности. Правильная конфигурация окупается за 2-3 месяца за счёт снижения latency и увеличения пропускной способности.

Почему выбирают нас

Более 10 лет опыта в настройке серверов. Сертифицированные инженеры по Linux и PostgreSQL. Гарантия 30 дней на выполненные работы. Выполнили более 50 проектов по миграции и оптимизации инфраструктуры. Типичные ошибки, которые мы исправляем: не настроен своп (своп на SSD убивает ресурс ячеек), дефолтные лимиты (приводят к ошибкам «Too many open files»), неправильный RAID-уровень (RAID 5 на SSD даёт низкую скорость записи), отсутствие мониторинга (проблемы обнаруживаются только при падении). Закажите аудит вашего сервера — мы выявим узкие места и предложим оптимальную конфигурацию. Свяжитесь с нами для бесплатной консультации.

Мы регулярно сталкиваемся с ситуацией: «Сайт не открывается» в 3 часа ночи — и выясняется, что disk full на VPS, потому что логи nginx не ротировались полгода. Или сервер лёг под нагрузкой в день запуска рекламной кампании, потому что на shared хостинге стоял лимит в 50 одновременных соединений. Настройка хостинга и деплоя — это не про «где дешевле», это про то, что происходит в момент, когда что-то идёт не так. Наша команда помогает избежать таких инцидентов, проектируя инфраструктуру с учётом реальных паттернов нагрузки.

Когда выбирать Vercel и Netlify?

Vercel создан под Next.js — деплой в один push, preview deployments для каждого PR, автоматический CDN, Edge Functions, ISR без конфигурации. Для фронтенд-проектов и JAMstack это оптимальный выбор: нет операционной нагрузки, time-to-deploy измеряется минутами.

Ограничения реальные: Vercel Serverless Functions запускаются в us-east-1 по умолчанию (latency для Европы +80–100ms), Function timeout 300 секунд на Pro, Bandwidth 1TB/месяц на Pro. Для тяжёлого backend — нужны воркеры или отдельный сервер.

Netlify ближе к статике и Edge Functions на базе Deno Deploy. Build minutes — основное ограничение на бесплатном тарифе.

Почему Docker — основа предсказуемого деплоя?

«Работает на моей машине» — классика. Docker решает это через контейнеризацию окружения. Но плохой Dockerfile создаёт новые проблемы.

Типичная ошибка: копировать всё в образ без .dockerignore, получать 800MB образ вместо 80MB. node_modules внутри образа весит столько же. Правильно: multi-stage build.

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

Итоговый образ: 180MB вместо 1.2GB. Время сборки CI сокращается из-за layer caching — если package.json не изменился, слой с npm ci берётся из кэша.

Docker Compose для локальной разработки и простых продакшен-сценариев: приложение + PostgreSQL + Redis в одной конфигурации. Для production на одном сервере — вполне рабочий вариант, если нет требований горизонтального масштабирования.

Подробнее о контейнеризации — Wikipedia: Docker.

Как настроить Nginx как reverse proxy?

Nginx перед приложением — стандарт для VPS и выделенных серверов. Основные функции: SSL termination, gzip, static files, rate limiting, upstream балансировка.

Конфигурация, которую часто делают неправильно: worker_processes auto — количество процессов равно числу CPU. worker_connections 1024 — это 1024 на каждый воркер-процесс. При 4 CPU и 1024 connections = 4096 одновременных соединений. Для высоконагруженного сайта нужно worker_connections 4096 и настройка keepalive_timeout 65.

Для статических ассетов с хешем в имени файла:

location ~* \.(js|css|woff2|png|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

immutable сообщает браузеру: не проверяй этот файл даже при hard refresh. Правильно работает только с content-hashed именами файлов (что делает Vite/webpack по умолчанию). Документация — Wikipedia: Nginx.

AWS: гибкость и сложность

EC2 + Auto Scaling Group — классика для горизонтального масштабирования. AMI с предустановленным приложением, Launch Template, ASG с min/desired/max instances, Application Load Balancer. При CPU > 70% на 3 минуты — scale out, при CPU < 30% на 15 минут — scale in. Health check через ALB исключает нездоровые инстансы из ротации.

ECS Fargate — контейнеры без управления EC2. Деплой Docker-образа, задаёте CPU/память (512 CPU units = 0.5 vCPU, от 512MB памяти), Fargate запускает. Дороже Lambda, но нет cold start и нет timeout-ограничений. Подходит для long-running процессов, WebSocket-серверов, тяжёлых воркеров.

RDS для PostgreSQL с Multi-AZ: автоматический failover за 1–2 минуты при падении primary. Read Replicas для масштабирования чтения. RDS Proxy для connection pooling — Lambda-функции не умеют держать долгосрочные соединения, прокси буферизует это.

Kubernetes: когда это оправдано

K8s добавляет значительную операционную сложность. Оправдан, когда: несколько команд деплоят независимые сервисы, нужна тонкая настройка ресурсов на сервис, canary deployments и blue/green без простоя — требование.

AWS EKS, GKE или managed k8s от Hetzner (дешевле). Helm charts для стандартных сервисов. Horizontal Pod Autoscaler по CPU и custom metrics (RPS через Prometheus).

Для большинства стартапов и средних проектов — Kubernetes избыточен. ECS или Fly.io дают 80% возможностей при 20% операционной сложности.

Мониторинг и alerting

Сервер без мониторинга — это ожидание инцидента. Минимальный стек: Prometheus + Grafana (или Grafana Cloud для managed), alerting на disk > 80%, memory > 85%, CPU > 90% за 5 минут, error rate > 1%. Uptime через Better Uptime или Upptime (self-hosted).

Logs: Loki + Grafana или CloudWatch Logs Insights. Структурированные JSON-логи (winston, pino) — обязательно, иначе поиск по логам превращается в боль.

Что входит в настройку хостинга

• Аудит текущей инфраструктуры и профилирование нагрузки
• Выбор целевой архитектуры (VPS, AWS, serverless, Kubernetes)
• Настройка CI/CD pipeline (GitHub Actions, GitLab CI) с автоматическим деплоем
• IaC через Terraform или Pulumi (инфраструктура как код)
• Конфигурация Nginx, SSL-сертификаты, HTTP/2, brotli
• Мониторинг и алертинг (Prometheus + Grafana, PagerDuty)
• Документация runbooks и обучение команды

Дополнительно: пишите, если нужна миграция с текущего хостинга или интеграция с внешними сервисами.

Процесс работы

1. Аудит текущей инфраструктуры (2–5 дней)
2. Выбор целевой архитектуры с обоснованием по нагрузке и бюджету (1–3 дня)
3. Настройка CI/CD pipeline (GitHub Actions, GitLab CI) (2–5 дней)
4. IaC через Terraform или Pulumi (3–10 дней)
5. Настройка мониторинга и alerting (2–5 дней)
6. Документация runbooks и обучение команды (1–3 дня)

Наш опыт — 7 лет на рынке, более 50 проектов, гарантия работоспособности после деплоя.

Сроки

• Базовый деплой на VPS с Docker + Nginx + CI/CD: 1–2 недели.
• Настройка AWS инфраструктуры с Auto Scaling, RDS, CDN: 3–6 недель.
• Миграция на EKS с нуля: 6–12 недель.
• Настройка Vercel/Netlify для JAMstack: 3–5 дней.

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