Вопрос или проблема
Довольно загруженный прокси-сервер имеет много “SYNs к сокетам LISTEN, которые были сброшены”.
Я узнал, что одной из причин может быть слишком маленький размер очереди ожидания. Но в этом случае значение “раз число переполнения очереди прослушивания сокета” должно быть равно (чему это не соответствует).
Так какая же может быть причина такого поведения? Возможно, неисправная сетевая карта?
У нас есть 5 прокси, в 2 из которых эти два числа не равны, так что эта проблема, похоже, возникает именно там.
Вот вывод команды netstat:
$ netstat -s | grep -i list
238627 раз очередь ожидания сокета переполнилась
8610307 SYNs к сокетам LISTEN сброшены
Серверы обрабатывают трафик IPv4 и IPv6, может быть, это помогает?
Эти счетчики в конечном итоге приходят из ядра и сопоставляются с счетчиками LINUX_MIB_LISTENOVERFLOWS
и LINUX_MIB_LISTENDROPS
. Вы можете увидеть из исходного кода net/ipv4/tcp_ipv4.c(tcp_v4_syn_recv_sock) примерно в строке #1392, что когда LINUX_MIB_LISTENOVERFLOWS
увеличивается, LINUX_MIB_LISTENDROPS
также будет увеличен, но есть условия выхода, при которых может увеличиваться только последний, так что это не ошибка, что они не совпадают.
В том же файле вы можете увидеть этот код:
1291 int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
1292 {
1293 /* Никогда не отвечать на SYN, отправленные на широковещательный или мультивещательный адрес */
1294 if (skb_rtable(skb)->rt_flags & (RTCF_BROADCAST | RTCF_MULTICAST))
1295 goto drop;
1296
1297 return tcp_conn_request(&tcp_request_sock_ops,
1298 &tcp_request_sock_ipv4_ops, sk, skb);
1299
1300 drop:
1301 NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
1302 return 0;
1303 }
Таким образом, вы можете увидеть, что по крайней мере одной из причин является SYN на широковещательный или мультивещательный адрес.
@andresp
Документация по “net.ipv4.tcp_rmem” кажется, утверждает совершенно обратное
Это значение не переопределяет net.core.rmem_max
Ответ или решение
Что вызывает «SYN to LISTEN sockets dropped»
Когда вы видите сообщение о сброшенных синхронизациях "SYN to LISTEN sockets dropped" на загруженном прокси-сервере, это может указывать на несколько проблем, которые требуют детального анализа. Давайте разберем возможные причины и факторы, которые могут приводить к этому поведению.
1. Общая информация о проблеме
В вашем примере, в результате использования команды netstat
, вы обнаружили следующие значения:
- 238,627 раз очередь прослушивания сокета переполнилась.
- 8,610,307 SYN-ов было сброшено на прослушивающие сокеты.
На первый взгляд, высокая разница между количеством переполнений очереди и сброшенных SYN-ов может вызвать недоумение. Это происходит из-за различных условий, при которых каждый из этих счетчиков инкрементируется.
2. Размер очереди прослушивания
Первое, что следует проверить, это размер "backlog" в настройках вашего сервера. Если размер очереди прослушивания сокета слишком мал, это может привести к сбоям в обработке SYN-запросов. Увеличение значения backlog до подходящего уровня может помочь справиться с нагрузкой.
В дополнение, если размер очереди слишком мал для текущих нагрузок сервера, стоит вручную увеличить его с помощью настройки net.core.somaxconn
, которая отвечает за максимальное количество ожидающих соединений в очереди прослушивания.
sysctl -w net.core.somaxconn=1024
3. Потеря SYN-запросов из-за UDP-трафика
Как упоминалось, в вашей ситуации может иметь место потеря SYN-запросов, отправленных на широковещательные или многоадресные адреса. Это может происходить в сетях, где серверы получают множество неожиданных запросов. При получении таких запросов сервер может игнорировать их, что также ведет к увеличению счетчика сброшенных SYN-ов, но не увеличивает количество переполнений очереди.
4. Настройки системных буферов
В вашем случае использование системных буферов wmem
и rmem
, которые по умолчанию имеют значения около 212992 байт, также может быть причиной проблемы. При высокой загруженности сервера такие размеры буферов могут быть недостаточны для поддержки значительного количества соединений и их обработки.
Поэтому разумно установить значения буферов на более высокие пределы, например, 8 МБ:
sysctl -w net.core.wmem_default=8388608
sysctl -w net.core.rmem_default=8388608
Этот подход может значительно снизить количество сброшенных SYN-запросов.
5. Сетевые проблемы
На конце, вероятные аппаратные или программные неисправности сетевых интерфейсов (NIC) тоже могут стать причиной проблемы. Проверьте состояние сетевых адаптеров и убедитесь, что все драйверы обновлены. Если сбросы продолжаются, имеет смысл тестировать серверы с помощью другого сетевого оборудования, чтобы исключить проблему с оборудованием.
Заключение
Проблема с "SYN to LISTEN sockets dropped" на вашем прокси-сервере может быть вызвана многими факторами: от недостаточного размера очереди прослушивания до сетевых ошибок и неправильно настроенных системных буферов. Рекомендуется провести полное обследование сервера, включая настройки сетевого стека и состояние оборудования, чтобы выявить и устранить основную причину сбросов.