Рекомендуемые настройки поддержки активности TCP для занятого сервера
У нас есть некоторые проблемы с сетевым таймаутом на сервере Debian, который довольно занят и поддерживает несколько подключений к ряду других серверов в сети.
Вот наши текущие настройки поддержки активности TCP в sysctl.conf:
net.ipv4.tcp_keepalive_time=60
net.ipv4.tcp_keepalive_intvl=90
net.ipv4.tcp_keepalive_probes=3
Возможно, есть проблема с этим.
Какие настройки keepalive рекомендуются для занятого сервера?
2 ответа
tcp keepalive отличается от nginx/apache keepalive.
tcp keepalive сохраняет соединение открытым в случае возникновения ошибки. Как будто клиент не получил запрос, поэтому он может повторить попытку через то же соединение. Теперь это случается редко, и общее практическое правило заключается в том, что вы хотите поддерживать высокий tcp keepalive на сервере NAT, чтобы он не терял отображение от клиента к серверу NATed за ним. Мы работаем с рекламными серверами, которые обслуживают миллионы, где-то около 40 миллионов соединений в день на сервер, и наша поддержка активности выглядит
"net.ipv4.tcp_keepalive_intvl" => 2,
"net.ipv4.tcp_keepalive_probes" => 3,
"net.ipv4.tcp_keepalive_time" => 5,
Я все еще чувствую, что время удержания 5 секунд слишком велико, и с учетом характера нашего бизнеса, когда мы не возвращаем объявление через 50 мс, тогда время ожидания клиента. Поэтому я, вероятно, уменьшу это до 1. Я просто медленно понижаю это значение, чтобы не вызывать каких-либо серьезных проблем. Я не рекомендовал бы то же самое, так как все варианты использования различны.
Так что, как я уже сказал, он сильно отличается от поддержки активности nginx/apache. Это более постоянные связи. Таким образом, он может подключиться один раз и повторно использовать это подключение снова. Это поможет уменьшить задержку между клиентом и хостом.
Скорее всего, если у вас не закончились порты tcp, то изменение поддержки активности tcp не изменит ничего, что вы видите с таймаутами.
Какие у вас таймауты? Поддержание TCP не поможет, если сервер занят, чтобы ответить вовремя. Это поможет определить, когда TCP-соединение больше не работает из-за сбоя однорангового узла или какого-либо фильтра пакетов между закрытыми состояниями из-за неактивности соединения.