Тюнинг сетевого стека Linux через sysctl помогает, когда передача упирается в регулируемый им лимит. Ниже – ориентиры для TCP на VPS: что проверять в бенчмарке сетевых sysctl Linux и какие параметры дают эффект.

Какие сетевые sysctl дают измеримый прирост?

Эффект дают параметры, которые снимают подтверждённое ограничение: например, предел TCP-буфера или очереди новых соединений. Прирост нужно проверить на той же нагрузке вместе с задержками и ошибками. Если скорость ограничивает процессор, приложение или канал провайдера, увеличение сетевых лимитов само по себе эту проблему не решит.

Сначала симптом

Бенчмарк сетевых sysctl Linux должен воспроизводить проблему: медленную передачу файла или отказы при наплыве клиентов. Исходный прогон показывает скорость, число ошибок и повторных передач TCP, загрузку ядер. Для запросов приложения нужны медиана и p99 – граница времени ответа для 99% запросов.

Где задерживается пакет

В VPS с virtio-net пакет проходит через сокет, стек гостя, виртуальный адаптер и сеть хоста. Команда ss -tim показывает состояние TCP и память сокета, nstat – сетевые счётчики, tc -s qdisc – статистику очередей отправки. Sysctl для пропускной способности действует лишь на своём участке: sysctl гостя не меняет настройки хоста.

Когда нужны буферы

Настройка TCP-буферов Linux имеет смысл, если их лимит мешает передаче. Ориентир bandwidth-delay product – скорость канала, умноженная на RTT, время пути туда и обратно. При 1 Гбит/с и 50 мс это 6,25 МБ данных в пути, а не готовый размер буфера.

Максимумы tcp_rmem и tcp_wmem нужно сопоставить с ss -tim и настройками приложения. Если автоматическая настройка буферов не достигает предела, его увеличение не поможет.

Какие популярные значения являются карго-культом?

Огромные буферы и очереди без проверки их заполнения – самый частый случай копирования чужой конфигурации. Больший лимит не ускорит обработку данных приложением. При перегрузке длинная очередь может лишь увеличить ожидание, поэтому полезность изменения определяют по скорости, ошибкам и задержкам при одинаковой нагрузке, а не по самому значению.

Очередь новых соединений

Для тюнинга somaxconn и backlog важны оба ограничения: net.core.somaxconn и значение listen() приложения. Они ограничивают очередь установленных соединений, ожидающих accept(). Рост ListenOverflows и ListenDrops в nstat – повод проверить её. Число полуоткрытых соединений ограничивает tcp_max_syn_backlog.

Что проверить у BBR

Бенчмарк BBR в Linux требует одинаковых RTT, потерь и скорости канала. Алгоритм соединения виден в ss -ti. Настройки очереди отправки (qdisc) при сравнении должны совпадать. Кроме скорости, важны задержки и доля канала, оставшаяся другим потокам. Смена алгоритма не гарантирует выигрыша.

По одному изменению

Netem задаёт задержку и потери на отдельном стенде. Для TCP его размещают на входе принимающего узла. Повторный исходный прогон помогает отличить эффект настройки от колебаний сети. Без устойчивой разницы результат нейтральный, а ухудшение задержек или ошибок – причина отката.

Как провести корректный тест до и после изменений?

1. Сохранить версию ядра, значения sysctl, нагрузку и исходные метрики.

2.  Изменить один параметр и повторить прогоны при тех же условиях.

3.  Вернуть прежнее значение, сравнить скорость, ошибки, p99 latency и нужный счётчик.

Если предел находится на хосте

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

Как закрепить результат

Значения нужно читать и менять в network namespace – сетевом окружении нужного процесса. Пробное применение на одном сервере должно дать повторяемое улучшение до записи в /etc/sysctl.d/. Для отката нужно вернуть прежнее значение через sysctl -w и убрать постоянную настройку из файла.

Тюнинг сетевого стека Linux через sysctl стоит ограничить изменениями с подтверждённым эффектом и проверенным откатом.

Измерение лага репликации PostgreSQL под нагрузкой помогает найти этап, где копится WAL. Разберём физическую репликацию PostgreSQL 18.

Какая метрика лага отражает задержку, видимую пользователю?

На асинхронной реплике replay_lag приближённо показывает задержку появления последних изменений. Отсчёт идёт от сохранения WAL на основном сервере до получения подтверждения его применения на реплике. Для проверки конкретной транзакции отслеживают появление её контрольной записи на реплике в новом снимке данных.

sent, write, flush и replay как разные виды отставания

Для бенчмарка лага репликации PostgreSQL нужны четыре позиции WAL: sent – отправлено, write – записано в ОС, flush – сохранено на диск, replay – применено. Основной сервер показывает их в pg_stat_replication, получая последние три от реплики. pg_wal_lsn_diff считает разрывы в байтах: текущий LSN–sent, sent–write, write–flush, flush–replay.

Топология, слоты и режим подтверждения транзакций

На лаг в pg_stat_replication влияют режим репликации и частота отчётов. Поэтому до теста фиксируют версии, число реплик, synchronous_standby_names, synchronous_commit и слоты. Удержание WAL слотами ограничивает max_slot_wal_keep_size. Лимит проверяется при checkpoint.

Одна временная шкала primary и standby

Опрос обоих серверов пишет LSN и разрывы в CSV с шагом 1 с и метками UTC. Часы узлов синхронизируют. pg_last_xact_replay_timestamp() даёт время commit/abort последней применённой транзакции с основного сервера. При простое её возраст растёт даже у догнавшей реплики, lag может стать NULL.

Как создать и измерить лаг репликации под нагрузкой?

На тестовом стенде постепенно увеличивают нагрузку записи через pgbench и регулярно снимают позиции WAL с обоих серверов. Разрывы между этапами показывают, где растёт очередь, а метрики сети, CPU и дисков помогают найти причину. Если мощности хватает, нагрузка может вообще не вызвать заметного отставания.

Рост WAL, постоянная нагрузка и прекращение записи

В CSV отмечают фазы pgbench. Для расчёта скорости WAL прирост текущего LSN делят на интервал между замерами. Лаг LSN PostgreSQL выражают в байтах. Чтобы измерить время catch-up, после остановки записи фиксируют конечный LSN и ждут, пока реплика его применит.

Когда sent–write растёт из-за сети или receiver

За этим разрывом могут стоять сеть, запись WAL или задержка отчёта реплики. Причину ищут по пропускной способности, потерям и работе walreceiver. p99 лага streaming replication считают отдельно по фазам, указав единицы и шаг опроса.

Где именно копится очередь

Оба разрыва живут на реплике, но упираются в разное: первый в диск, второй в применение WAL.

Как разделить сетевое, дисковое и replay-узкие места?

1.  sent–write проверяют вместе с сетью и приёмником WAL: сам разрыв не доказывает сетевую проблему.

2.  write–flush сопоставляют с задержками fsync и очередью диска реплики.

3.  Для flush–replay проверяют CPU, I/O и конфликты запросов, учитывая отставание flush.

При synchronous replication synchronous_commit задаёт условие завершения COMMIT: remote_apply требует применения WAL на выбранных синхронных репликах.

Почему standby может задерживать применение WAL

Задержка replay WAL под нагрузкой возможна и при стабильном WAL generation rate: конфликт с запросом задерживает применение WAL. Увеличение max_standby_streaming_delay продлевает ожидание. Отмены запросов видны в pg_stat_database_conflicts. hot_standby_feedback уменьшает конфликты очистки ценой накопления старых версий строк на основном сервере.

Пороги, привязанные к байтам и времени восстановления

Порог потери данных задают по RPO, а отставание данных и время catch-up ограничивают отдельно. Сохранённый на диск реплики WAL применяется и после отказа основного сервера. Причину уточняют по network RTT, CPU и I/O обоих узлов.

Измерение лага репликации PostgreSQL под нагрузкой даёт основу для оповещений по этапам: важны размер очереди и скорость её роста. Оповещение по одному порогу lag в секундах такой картины не даёт.