Sysctl для серверов с большим числом подключений

Когда сервер обслуживает сотни тысяч TCP-сессий, стандартные настройки ядра Linux могут стать узким местом.

TIME_WAIT, переполнение очередей сокетов и медленный отклик — типичные признаки. Тут на помощь приходят параметры sysctl.

Основные настройки

⏺net.ipv4.ip_local_port_range — диапазон локальных портов для исходящих соединений. Увеличение диапазона помогает избежать исчерпания портов при массовых подключениях.
⏺net.ipv4.tcp_tw_reuse — разрешает повторное использование сокетов в состоянии TIME_WAIT для новых исходящих соединений.
⏺net.ipv4.tcp_tw_recycle — ускоряет очистку TIME_WAIT (не рекомендуется для NAT).
⏺net.core.netdev_max_backlog — размер очереди пакетов в драйвере сети. Увеличение помогает при пиках входящего трафика.

Измеряем эффект

➖До изменений:

ss -s | grep TIME-WAIT
cat /proc/sys/net/core/netdev_max_backlog

➖Применяем sysctl:

sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
sudo sysctl -w net.core.netdev_max_backlog=5000

➖После изменений: повторяем измерения TPS (запросов в секунду) и TIME_WAIT.

➖Вывод: больше соединений проходит без ошибок, очередь пакетов меньше переполняется, нагрузка на сервер равномернее.

Bcachefs теперь «внешне поддерживаемая»

28 августа 2025 года Линус Торвальдс перевёл файловую систему Bcachefs в режим Externally maintained. 

Это значит, что ядро больше не принимает её изменения, а дальнейшая разработка ведётся вне основной кодовой базы.

⏺Причина — конфликты с автором проекта Кентом Оверстритом: он присылает крупные изменения в неподходящее время, нарушая процесс ядра.

Торвальдс считает, что поздние релизы должны лишь исправлять ошибки, а Оверстрит настаивает на срочном исправлении багов для сохранности данных. Bcachefs остаётся экспериментальной ФС.

Logrotate для нестандартных приложений

Стандартные сервисы вроде Nginx или syslog ротируются автоматически, а вот для нестандартных daemon или собственных приложений нужно использовать postrotate, sharedscripts и правильно обрабатывать сигнал HUP.

⏺postrotate — команды после ротации (например, сигнал процессу перечитать лог).
⏺sharedscripts — если несколько файлов ротируются, скрипт выполняется один раз.
⏺HUP — заставляет daemon перечитать файл без перезапуска.

Пример для PostgreSQL:

/var/log/postgresql/*.log {
    daily
    rotate 7
    compress
    delaycompress
    notifempty
    missingok
    sharedscripts
    postrotate
        systemctl reload postgresql > /dev/null 2>/dev/null || true
    endscript
}

Здесь логи сжимаются и хранятся неделю, пустые файлы не ротируются, а PostgreSQL после ротации продолжает писать в новый файл.

Пример для Nginx:

/var/log/nginx/*.log {
    daily
    rotate 14
    missingok
    notifempty
    sharedscripts
    postrotate
        [ -f /run/nginx.pid ] && kill -HUP `cat /run/nginx.pid`
    endscript
}

Можно добавить уведомление админа через mail или Slack.

Мониторинг открытых файлов: lsof

В Linux всё — это файл. Сюда попадают не только документы на диске, но и сокеты, устройства, пайпы.

Иногда это приводит к странным ситуациям: файл вроде удалили, а место на диске не освободилось. Или порт висит занятым, хотя процесс уже остановлен. 

В таких случаях незаменим инструмент lsof (list open files).

Несколько базовых приёмов:
⏺lsof /path/to/file — покажет, какой процесс держит файл открытым. Полезно, если удалённый лог «не освобождает» место.
⏺lsof -i :8080 — кто слушает порт 8080 или держит соединение. Отлично работает при отладке сервисов.
⏺lsof -u www-data — все открытые файлы конкретного пользователя, например, у веб-сервера.

Кроме поиска по файлам и портам, lsof помогает находить процессы с утечками дескрипторов. Иногда сервисы постепенно «съедают» лимит открытых файлов, и тогда lsof -p <PID> покажет, чем именно завален процесс.

🔥 В связке с df и du утилита позволяет быстро вычислить «невидимых пожирателей места», а при отладке сетей — вычленить подозрительные соединения.

Инструмент старый, но до сих пор один из самых надёжных для диагностики.

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое Transparent Hugepage defrag и как это влияет на производительность системы?

✅Ответ: Transparent Hugepage (THP) defrag — это механизм в Linux, который пытается объединять мелкие страницы памяти в большие (HugePages) для оптимизации TLB и уменьшения накладных расходов на управление памятью.

Однако агрессивная дефрагментация может вызвать паузы в работе приложений из-за копирования страниц, поэтому в высоконагруженных системах её часто отключают или настраивают в режиме “madvise”, чтобы влияние на производительность было минимальным.

Поиск «тяжёлых» файлов: ncdu

Когда на сервере заканчивается место, команды вроде du и ls -lh не всегда помогают быстро понять, что именно съедает дисковое пространство. 

На помощь приходит ncdu — интерактивный аналог du, который показывает размер каталогов и файлов в удобной древовидной структуре и позволяет управлять ими прямо из интерфейса.

Например, чтобы проверить логи:

ncdu /var/log

Откроется текстовый интерфейс, где можно быстро сортировать файлы и папки по размеру, перемещать их или удалять.

Это помогает находить крупные логи, временные файлы и другие объекты, которые занимают место, без необходимости писать сложные скрипты.

Плюсы ncdu:
⏺Видно, сколько реально занимает каждая папка.
⏺Можно удалять или перемещать файлы прямо в интерфейсе.
⏺Быстро ориентируетесь на серверах с ограниченным SSD.
⏺Подходит для диагностики как пользовательских, так и системных директорий.

Быстрый поиск строк в логах: ripgrep

Когда на сервере гигабайты логов, а надо срочно найти конкретную ошибку, стандартный grep начинает тормозить.

Здесь помогает ripgrep (rg) — современный инструмент поиска по тексту. 

Он оптимизирован под большие объёмы данных и работает в разы быстрее.

Пример для поиска ошибок во всех логах:

rg "ERROR" /var/log

По умолчанию он рекурсивно обходит каталоги и выводит совпадения с путём к файлу и номером строки.

Если нужен контекст вокруг найденной строки:

rg -C 3 "FATAL" /var/log/postgresql

Так выводятся три строки до и после совпадения — удобно при анализе логов PostgreSQL, Nginx или системных журналов.

⏺ripgrep поддерживает регулярные выражения, можно искать сразу несколько шаблонов и фильтровать файлы по расширениям. Например:

rg -t sql "SELECT.*FROM" /var/log

Вывод ограничится только SQL-логами.

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает механизм Copy-on-Write (CoW) в Linux и зачем он нужен?

✅Ответ: Copy-on-Write (CoW) — это оптимизационный механизм, который позволяет нескольким процессам совместно использовать одну и ту же область памяти до тех пор, пока один из них не попытается ее изменить.

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

BGP PIC (Prefix Independent Convergence)

BGP PIC ускоряет failover, предустанавливая резервный next-hop. 

При падении primary hop трафик мгновенно переключается без полной перерасчётки маршрутов. Обычно обычный BGP failover занимает секунды, с PIC — миллисекунды.

Применяется в WAN и датацентрах с критическим SLA, ECMP-сценариях, L3VPN/EVPN.

Виды:

⏺Core (по префиксу) — precomputed backup next-hop в FIB, переключение мгновенное.
⏺Edge (по соседу) — резерв на уровне BGP-соседа, удобно для PE/CE.

Настройка на Cisco IOS-XR:

router bgp 65001
 address-family ipv4 unicast
  bgp bestpath pic
  network 10.0.0.0 mask 255.255.255.0

Juniper JunOS:

protocols {
 bgp {
  group IBGP {
   type internal;
   local-address 192.168.0.1;
   family inet { unicast; }
   pic;
  }
 }
}

Для проверки failover включают BFD, пингуют primary hop и отключают линк. С BGP PIC потеря пакетов минимальна, трафик идёт на backup сразу.

⚡️Особенности: резервный next-hop должен быть в FIB, потребляет RAM/CPU для precompute, на больших таблицах BGP может потребоваться tuning.

Инкрементальные бэкапы с tar

Помимо привычных архивов, tar умеет делать инкрементальные бэкапы через ключ --listed-incremental.

Он хранит «снимок» метаданных файлов и при следующем запуске берёт только изменения.

Пример:

# первый полный бэкап
tar --listed-incremental=/var/backups/snapshot.file \
    -czf full-backup.tar.gz /home

# инкрементальный
tar --listed-incremental=/var/backups/snapshot.file \
    -czf incr-backup.tar.gz /home

👉 snapshot.file — база, где хранится информация о прошлых бэкапах. Если её удалить, то следующий архив будет снова полным.

Плюсы:
➕экономия места (в архив попадают только изменившиеся файлы);
➕встроено в стандартный tar, не нужны отдельные утилиты;
➕можно комбинировать с cron и хранением на удалённом сервере.

Подходит для небольших серверов, dev-сред и домашних каталогов, где не нужна тяжёлая система бэкапов, но важна скорость и простота.

etckeeper: контроль версий для /etc

Каталог /etc — сердце системы: здесь лежат конфиги сервисов, сетевые настройки, права доступа. 

Проблема в том, что правки накапливаются хаотично - руками, апдейтами пакетов, скриптами. В итоге, когда «вдруг перестало работать», непонятно кто и когда изменил конфиг.

⏺etckeeper решает задачу просто: сохраняет /etc в Git (или другом VCS). Получаем историю изменений, удобный diff и возможность быстро откатить.

Установка (Debian/Ubuntu):

sudo apt install etckeeper git
sudo etckeeper init
sudo etckeeper commit "init"

После этого можно работать как с обычным репозиторием:

sudo git status /etc
sudo git diff /etc/ssh/sshd_config
sudo git log /etc

Фишка — etckeeper интегрируется с apt и yum: перед обновлением пакетов он автоматически делает commit.

Можно добавить git remote и пушить историю в отдельный репозиторий (например, на приватный GitLab или в backup).

Это удобно для серверов, где нужно отслеживать конфиги централизованно.