Если ваши серверы работают медленно или ресурсы используются неэффективно, вы можете исправить это за несколько часов. Эта статья содержит проверенные настройки ядра, файловых систем и сети, которые напрямую влияют на производительность. Вы получите конкретные команды для диагностики узких мест и готовые конфигурации для веб-сервисов, контейнерных кластеров и баз данных, актуальные для дистрибутивов и оборудования 2026 года.
Диагностика узких мест производительности: что мешает вашему серверу в 2026
Оптимизация начинается с точной диагностики. Бессмысленно менять параметры, не понимая, где находится проблема. Используйте эти инструменты для мгновенного анализа состояния системы.
Ключевые метрики и инструменты для мгновенной диагностики
Запустите эти команды в терминале для базового анализа. Они покажут нагрузку на CPU, дисковый I/O и сеть.
vmstat -w 1
Эта команда выводит статистику по процессам, памяти и CPU каждую секунду. Смотрите на столбцы r (процессы, ожидающие выполнения) и us/sy (пользовательское/системное время CPU). Если r постоянно превышает количество ядер, система перегружена.
iostat -xz 1
Показывает статистику по дискам. Ключевые метрики: %util (утилизация диска) и await (среднее время ожидания I/O операции). %util выше 80% часто указывает на проблемы с дисковым подсистемой. Для NVMe дисков также полезен iostat -d 1 для просмотра отдельных очередей.
sar -n DEV 1
Собирает сетевую статистику. Мониторите rxkB/s и txkB/s для пропускной способности, а также drop и err для ошибок и потерянных пакетов.
| Метрика | Нормальное значение | Критическое значение | Инструмент |
|---|---|---|---|
| Загрузка CPU (по ядрам) | менее 70% | более 90% длительно | top, vmstat |
| Утилизация диска (%util) | менее 60% | более 80% | iostat |
| Среднее время I/O (await) | менее 10 ms для SSD | более 50 ms | iostat |
| Потерянные сетевые пакеты (drop) | 0 | любое постоянное значение | sar -n DEV |
Для комплексного анализа состояния системы перед глубокой оптимизацией используйте практическое руководство по мониторингу метрик CPU, памяти, диска и сети. Это поможет быстро локализовать проблемный компонент.
Специфика диагностики под современные нагрузки: контейнеры и высокопроизводительные диски
Стандартные метрики могут не отражать проблемы в плотных контейнерных кластерах или на NVMe. Для контейнеров ключевым является давление памяти (memory pressure) в cgroup v2.
cat /sys/fs/cgroup/memory.pressure
Высокие значения в строке some указывают на то, что некоторые процессы испытывают недостаток памяти. Для анализа состязаний (contention) за ресурсы ядра, особенно при множестве процессов, обращающихся к одному NVMe, используйте perf.
perf record -e 'sched:*' -a -g -o perf.data sleep 10
perf report -i perf.data
Это покажет, какие функции ядра тратят больше времени, часто указывая на проблемы с планировщиком или блокировками. Для микросервисных архитектур также полезен bpftrace для отслеживания системных вызовов с высокой частотой.
Готовые конфигурации ядра и сети для основных сценариев DevOps
После диагностики применяйте эти проверенные настройки. Они разделены по типам серверов для немедленного использования. Создайте файл /etc/sysctl.d/99-optimizations.conf и добавьте параметры ниже. После изменения выполните sysctl -p /etc/sysctl.d/99-optimizations.conf.
Оптимизация сетевого стека для веб-сервисов и микросервисов
Для высокого RPS и снижения latency добавьте эти параметры.
# Ускорение установки TCP соединений
net.ipv4.tcp_fastopen = 3
# Увеличение очереди принятых соединений
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
# Уменьшение времени ожидания для закрытия соединений
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 300
# Увеличение буферов для высокоскоростных сетей
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
Для Nginx или Envoy также увеличьте worker_connections в их конфигурации соответственно. Проверьте эффект с помощью ss -ltn для просмотра состояния портов и netstat -s для статистики TCP.
Настройки ядра для контейнерных кластеров: баланс между isolation и производительностью
В Docker или Kubernetes неправильные настройки памяти приводят к throttling контейнеров.
# Политика overcommit памяти (рекомендуется 1 для контейнеров)
vm.overcommit_memory = 1
# Агрессивная очистка page cache для предотвращения swap
vm.vfs_cache_pressure = 500
# Настройки для cgroup v2 через systemd (в файле /etc/systemd/system.conf)
DefaultMemoryAccounting=yes
DefaultTasksAccounting=yes
# Отключение сетевых фильтров для CNI (Calico, Flannel)
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
Для оптимизации планировщика CPU (CFS) для контейнеров можно настроить cpu.cfs_period_us и cpu.cfs_quota_us на уровне cgroup. Подробнее о производительности контейнерных технологий в современных сценариях можно узнать в объективных тестах Docker, Kubernetes и LXC в 2026 году.
Тонкая настройка дискового I/O и планировщиков для NVMe и SSD
Для NVMe дисков часто оптимальным является планировщик none, который минимизирует накладные расходы.
# Установка планировщика для NVMe (например, /dev/nvme0n1)
echo "none" > /sys/block/nvme0n1/queue/scheduler
# Увеличение максимального количества сегментов в запросе
echo "256" > /sys/block/nvme0n1/queue/max_segments
# Увеличение глубины очереди
echo "1024" > /sys/block/nvme0n1/queue/nr_requests
Для SSD (SATA, SAS) может быть лучше mq-deadline или bfq. Проверьте текущий планировщик: cat /sys/block/sda/queue/scheduler. Для баз данных (PostgreSQL, MySQL) критически важны настройки, связанные с fsync. Рассмотрите увеличение vm.dirty_background_bytes и vm.dirty_bytes вместо ratio для систем с большим RAM.
Полный набор готовых конфигураций для различных серверных сценариев, включая шаблоны для баз данных и файловых хранилищ, доступен в практическом руководстве по глубокой оптимизации Linux-серверов.
Оптимизация управления памятью и кэширования: от swappiness до hugepages
Неправильное управление памятью вызывает лавинообразную подкачку (swap storms) или излишнее кэширование, которое замедляет приложения.
Борьба с лавинообразной подкачкой (swap storms) и настройка политик dirty pages
Swap storm возникает, когда система пытается выгрузить слишком много данных на диск одновременно. Основной параметр контроля - vm.swappiness. Значение от 1 до 10 часто оптимально для серверов, чтобы система использовала swap только в крайней необходимости.
vm.swappiness = 10
Для серверов баз данных с частыми записями можно установить vm.swappiness=1 или даже 0, но это рискованно при полном заполнении памяти. Политики записи "dirty" страниц на диск управляются параметрами vm.dirty_ratio и vm.dirty_background_ratio. Для систем с большим RAM и быстрыми SSD (NVMe) рекомендуются более агрессивные значения.
# Процент памяти, при котором процессы начинают блокироваться на записи
vm.dirty_ratio = 20
# Процент памяти, при котором фоновая очистка начинается
vm.dirty_background_ratio = 5
# Альтернативно, можно задать абсолютные значения в байтах
vm.dirty_background_bytes = 1073741824 # 1GB
vm.dirty_bytes = 4294967296 # 4GB
Мониторинг эффекта: sar -r 1 показывает использование памяти и swap, cat /proc/meminfo дает детали по Dirty и Writeback.
Transparent Hugepages и кэширование файлов: тонкая настройка под нагрузку
Transparent Hugepages (THP) могут улучшить производительность для некоторых приложений, но вредны для других, например, для определенных версий Redis или при высокой фрагментации памяти.
# Проверка текущего режима THP
cat /sys/kernel/mm/transparent_hugepage/enabled
# Установка режима 'madvise' (только для областей, явно запрошенных через madvise)
echo "madvise" > /sys/kernel/mm/transparent_hugepage/enabled
Режим always может вызывать проблемы с памятью. Режим never полностью отключает THP. Для управления размером page cache используйте параметр vm.vfs_cache_pressure. Значение выше 100 (например, 500) делает ядро более агрессивным в очистке кэша. Очистить кэш можно командой sync && echo 3 > /proc/sys/vm/drop_caches, но это временное решение для тестов.
Чеклист внедрения и проверки: от диагностики до тонкой настройки
Следуйте этой последовательности для безопасной и эффективной оптимизации.
Последовательность действий для безопасной оптимизации
- Диагностика. Используйте команды из первого раздела (
vmstat,iostat,sar) для определения узких мест. Зафиксируйте базовые метрики. - Выбор сценария. Определите тип сервера: веб-сервер/API, контейнерный кластер (Kubernetes node), сервер базы данных.
- Применение базовых конфигураций. Добавьте соответствующие параметры ядра и сети из второго раздела в новый файл
/etc/sysctl.d/99-optimizations.conf. Примените командойsysctl -p /etc/sysctl.d/99-optimizations.conf. Для настроек через/sysиспользуйтеsystemd-tmpfilesдля сохранения изменений после reboot. - Настройка памяти и кэширования. Установите параметры
vm.swappiness,vm.dirty_*и настроите THP из третьего раздела в соответствии с вашим сценарием. - Нагрузочное тестирование и измерение. Проведите тест, имитирующий рабочую нагрузку. Снова используйте инструменты диагностики для сравнения метрик с исходными.
- Тонкая настройка. На основе результатов теста корректируйте параметры. Например, если сетевые задержки остались высокими, увеличивайте буферы TCP дальше.
Если изменение вызвало проблему (например, нестабильность), откатите его: удалите строку из файла 99-optimizations.conf и выполните sysctl -p или верните значение параметра /sys в исходное состояние.
Для комплексного подхода к оптимизации веб-приложений, включая диагностику на всех уровнях, обратитесь к пошаговому гайду по диагностике и оптимизации производительности веб-приложений для DevOps.
Таблица-шпаргалка ключевых параметров и их значений
| Параметр | Веб**-**сервер/API | Контейнерный кластер | Сервер БД | Эффект | Команда проверки |
|---|---|---|---|---|---|
net.ipv4.tcp_fastopen |
3 | 3 | 3 | Ускорение установки TCP соединений | sysctl net.ipv4.tcp_fastopen |
net.core.somaxconn |
4096 | 4096 | 1024 | Увеличение очереди принятых соединений | sysctl net.core.somaxconn |
vm.swappiness |
10 | 30 | 1 | Склонность к использованию swap | sysctl vm.swappiness |
vm.dirty_ratio |
20 | 30 | 10 | Максимум "dirty" памяти перед блокировкой | sysctl vm.dirty_ratio |
vm.dirty_background_ratio |
5 | 10 | 2 | Начало фоновой очистки "dirty" памяти | sysctl vm.dirty_background_ratio |
| Планировщик I/O для NVMe | none |
none |
none |
Минимизация накладных расходов | cat /sys/block/nvme0n1/queue/scheduler |
Эта таблица служит отправной точкой. Точные значения могут потребовать корректировки под ваше оборудование и нагрузку. Все приведенные настройки проверены на ядрах Linux 5.15+ и 6.x и актуальны для дистрибутивов Ubuntu 22.04/24.04, CentOS Stream/RHEL 9 и их производных в 2026 году.
Для получения других проверенных инструкций по администрирования Linux и автоматизации задач DevOps ознакомьтесь с сборником практических материалов по DevOps и Linux администрированию 2026.
Если ваша работа связана с интеграцией ИИ-сервисов, вам может быть полезен агрегатор API для нейросетей AiTunnel. Он предоставляет единый интерфейс для доступа к более 200 моделей, включая GPT, Gemini и Claude, без необходимости использования VPN и с оплатой в рублях.