Если вы дошли до точки, когда обычные настройки sysctl и iptables перестали спасать, а сервисы всё равно падают под нагрузкой, пора выйти за рамки «стандартного» сетевого стека Linux. В этой статье разберём, как настраивать сетевой стек так, чтобы он не просто «держал» трафик, а предсказуемо и надёжно работал под сотнями тысяч соединений, тысячами RPS и высокой частотой переподключений.
Мы не будем разбирать базовые вещи вроде net.ipv4.tcp_syncookies или net.core.somaxconn — это уже должны быть у вас включены. Если нет — остановитесь и сначала закройте базу, иначе вся дальнейшая тонкая настройка превратится в попытку тюнинговать двигатель, у которого наполовину откручены болты крепления. Речь пойдёт про прикладные настройки, которые реально влияют на производительность и отказоустойчивость в продакшене: от TCP‑параметров до планировщиков очередей, от настройки сетевых карт до мониторинга и отладки.
На практике я не раз сталкивался с ситуацией, когда сервис начинал сыпать ошибками при нагрузке в 60–70% от расчётной, а команда грешила на код приложения. Копали неделю, а проблема сидела в перегруженном стеке TCP и одном неверно выставленном параметре очереди сетевой карты. С тех пор я начинаю диагностику подобных инцидентов именно с сетевого стека.
Зачем вообще трогать сетевой стек
Прежде чем ковыряться в sysctl, важно понимать, что именно мы хотим получить. Я не раз видел, как инженеры накатывали на сервер десяток параметров из случайного г