У нас возникают проблемы с тайм-аутом сети на сервере Debian, который довольно загружен и поддерживает несколько подключений к ряду других серверов в сети.
Вот наши текущие настройки поддержки активности TCP в sysctl.conf:
net.ipv4.tcp_keepalive_time=60
net.ipv4.tcp_keepalive_intvl=90
net.ipv4.tcp_keepalive_probes=3
Возможно, с ними проблема.
Какие настройки поддержки активности рекомендуются для загруженного сервера?
поэтому tcp keepalive отличается от nginx / apache keepalive.
tcp keepalive сохраняет соединение открытым в случае возникновения ошибки. Как будто клиент не получил запрос, поэтому он может повторить попытку через то же соединение. Это случается редко, и общее практическое правило состоит в том, что вы хотите поддерживать высокий уровень активности TCP на сервере NAT, чтобы он не терял сопоставление от клиента к серверу с NAT. Мы запускаем рекламные серверы, которые обслуживают миллионы где-то около 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 Keepalive не изменит ничего, что вы видите с таймаутами.
Какие у вас таймауты сети? TCP keep alive не поможет, если сервер занят, чтобы вовремя ответить. Это поможет только определить, когда TCP-соединение больше не работает из-за сбоя однорангового узла или какой-либо пакетный фильтр между закрытыми состояниями из-за неактивности соединения.