Как я могу контролировать длину очереди приема?

У меня есть гипотеза: иногда TCP-соединения приходят быстрее, чем мой сервер accept(). Они выстраиваются в очередь до тех пор, пока очередь не переполнится, а затем возникают проблемы.

Как я могу подтвердить, что это происходит?

Могу ли я контролировать длину очереди приема или количество переполнений? Где-нибудь выставлен счетчик?

linux networking monitoring

— Фил Фрост
источник

Ты ищешь netstat.

— Satō Katsura

Насколько я могу судить, netstatпоказывает только длину очереди отправки и получения, которая не совпадает с длиной очереди приема.

— Фил Фрост

Да, это не показано по умолчанию. man netstat | less +/Flags

— Satō Katsura

Я не уверен, как эти флаги говорят мне длину очереди приема - фактически netstat, кажется, вообще не показывается Flagsдля соединений TCP. После небольшого тестирования похоже, что соединения показываются как ESTABLISHEDна netstat, даже если я пытаюсь открыть соединения с процессом, который делает, listen()но никогда accept().

— Фил Фрост

Правильно, глядя на источники, кажется, что эти флаги предназначены для сокетов UNIX. Для TCP вы можете просто посчитать SYN_RECV. За этим нет другой очереди. Я предполагаю, что ядру можно как-то сказать записывать пропущенные пакеты из-за слишком большого числа полуоткрытых соединений, но прошло более 10 лет с тех пор, как я смотрел на работу в сети с Linux, поэтому я понятия не имею, как это сделать. На заметку: вы не ждете, accept()чтобы выполнить свою работу, вы ждете, когда ACKs прибудут с подключающихся хостов, чтобы завершить соединения.

— Satō Katsura

Ответы:

Чтобы проверить, не переполнена ли ваша очередь, используйте netstat или nstat

[centos ~]$ nstat -az | grep -i listen
TcpExtListenOverflows           3518352            0.0
TcpExtListenDrops               3518388            0.0
TcpExtTCPFastOpenListenOverflow 0  0.0

[centos ~]$ netstat -s | grep -i LISTEN
    3518352 times the listen queue of a socket overflowed
    3518388 SYNs to LISTEN sockets dropped

Ссылка: https://perfchron.com/2015/12/26/investigating-linux-network-issues-with-netstat-and-nstat/

Чтобы отслеживать размеры очереди, используйте команду ss и найдите сокеты SYN-RECV.

$ ss -n state syn-recv sport = :80 | wc -l
119

Ссылка: https://blog.cloudflare.com/syn-packet-handling-in-the-wild/

— lfmunoz
источник

Sysdig предоставит часть этой информации в конце каждого acceptсистемного вызова в качестве queuelenаргумента. Он также показывает длину очереди как queuemax.

7598971 21:05:30.322229280 1 gunicorn (6451) < accept fd=13(<4t>127.0.0.1:45882->127.0.0.1:8003) tuple=127.0.0.1:45882->127.0.0.1:8003 queuepct=0 queuelen=0 queuemax=10

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

— Фил Фрост
источник

То, что вы ищете, это запись в выводе команды sysctl -a как таковой :::

net.ipv4.tcp_max_sync_backlog = 4096

В приведенном выше примере, резерв соединений состояния SYN составляет максимум 4096. Вы можете увеличить его в зависимости от того, сколько оперативной памяти находится на вашем сервере. Я считаю, что отставание в 32K является хорошим началом для настройки сильно загруженных веб-серверов.

Также убедитесь, что следующее НЕ установлено в One (1):

net.ipv4.tcp_abort_on_overflow = 0

В противном случае он определенно отбросит пакеты, если будет переполнение невыполненной работы.

Вы можете легко проверить через

"sysctl -a | egrep backlog"

"sysctl -a | egrep overflow"

Кроме того, вы можете найти «уронили» ярлык под

"ifconfig -a"

вывод команды. Это показывает, сколько пакетов было отброшено для каждого интерфейса вместе с другими данными и ошибками и т. Д.

Для регистрации пропущенных пакетов есть статья о платном доступе на RHEL 7:

https://access.redhat.com/solutions/1191593

Для дальнейшего исследования вы можете прочитать:

http://veithen.io/2014/01/01/how-tcp-backlog-works-in-linux.html

Здесь говорится в соответствии с «Книгой, иллюстрированной TCP / IP» Стивена:

«Ограничение очереди относится к сумме […] количества записей в очереди неполных соединений […] и […] количества записей в очереди завершенных соединений […].»

Отсюда также говорится, что:

«Завершенная очередь соединений почти всегда пуста, потому что, когда запись помещается в эту очередь, возвращается запрос сервера о принятии, и сервер удаляет завершенное соединение из очереди».

Следовательно, очередь приема может казаться совершенно пустой, и вам придется настроить свой (возможно, в этом случае) сервер веб-Apache, чтобы он быстрее принимал соединения, помещенные в очередь «общая совокупность».

— mkzia
источник

Хотя здесь, кажется, есть некоторая полезная информация, я не уверен, что она отвечает на вопрос. Если я спрашиваю: «Какое количество людей когда-либо было в этой аудитории одновременно?», И вы указываете на знак на стене, который дает максимальную вместимость, вы не ответили на вопрос.

— Скотт

На самом деле я ищу текущую длину очереди, а не максимальную длину очереди.

— Фил Фрост

Это должен быть tcp_max_syn_backlog, а не tcp_max_SYNC_backlog, как в вашем ответе

— DevilaN

Да ... и StackOverflow выдает запаздывающее сообщение об ошибке при попытке изменить его: "Изменения должны содержать не менее 6 символов; есть ли что-то еще, что можно улучшить в этом посте?"

— Аарон К. де Брюн