¿Cómo puedo monitorear la longitud de la cola de aceptación?

Tengo una hipótesis: a veces las conexiones TCP llegan más rápido que mi servidor accept(). Hacen cola hasta que la cola se desborda y luego hay problemas.

¿Cómo puedo confirmar que esto está sucediendo?

¿Puedo monitorear la longitud de la cola de aceptación o el número de desbordamientos? ¿Hay un mostrador expuesto en alguna parte?

linux networking monitoring

— Phil Frost
fuente

Usted está buscando netstat.

— Satō Katsura

Por lo que puedo decir, netstatsolo muestra las longitudes de la cola de envío y recepción, que no es lo mismo que la cola de aceptación.

— Phil Frost

Sí, no se muestra por defecto. man netstat | less +/Flags

— Satō Katsura

No estoy seguro de cómo esos indicadores me dicen la longitud de la cola de aceptación; de hecho netstat, no parece mostrarse Flagsen absoluto para las conexiones TCP. A partir de una pequeña prueba, parece que las conexiones se muestran como ESTABLISHEDen netstat, incluso si trato de abrir conexiones a un proceso que lo hace listen()pero nunca accept().

— Phil Frost

Bien, mirando las fuentes parece que esas banderas son para sockets UNIX. Sin SYN_RECVembargo, para TCP podría contar . No hay otra cola más allá de eso. Supongo que se le puede decir al kernel de alguna manera que registre los paquetes descartados debido a demasiadas conexiones entreabiertas, pero han pasado más de 10 años desde que examiné las redes con Linux, así que no tengo idea de cómo hacerlo. En una nota al margen: no está esperando accept()que haga su trabajo, está esperando ACKque lleguen s de los hosts de conexión para completar las conexiones.

— Satō Katsura

Respuestas:

Para verificar si su cola se desborda, use netstat o 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

Referencia: https://perfchron.com/2015/12/26/investigating-linux-network-issues-with-netstat-and-nstat/

Para monitorear los tamaños de las colas, use el comando ss y busque enchufes SYN-RECV.

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

Referencia: https://blog.cloudflare.com/syn-packet-handling-in-the-wild/

— lfmunoz
fuente

Sysdig proporcionará parte de esta información al final de cada acceptllamada al sistema, como queuelenargumento. También muestra la longitud de la cola como 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

Que yo sepa, no proporciona ningún mecanismo para saber exactamente cuándo o cuántas veces se ha desbordado la cola. Y sería engorroso integrar esto con monitoreo periódico por collectdo similar.

— Phil Frost
fuente

Lo que está buscando es la entrada en la salida del comando sysctl -a como tal :::

net.ipv4.tcp_max_sync_backlog = 4096

En el caso del ejemplo anterior, el retraso de las conexiones de estado SYN es máximo 4096. Puede aumentar eso en función de la cantidad de RAM que hay en su servidor. Considero que la acumulación de 32K es un buen comienzo para el ajuste de servidores web con mucha carga.

También asegúrese de que lo siguiente NO esté establecido en One (1) ::

net.ipv4.tcp_abort_on_overflow = 0

De lo contrario, definitivamente descartará los paquetes si hay un desbordamiento de la acumulación.

Puede verificar fácilmente a través de

"acumulación de sysctl -a | egrep"

"sysctl -a | desbordamiento de egrep"

Además, puede encontrar la etiqueta "descartada" debajo de

"ifconfig -a"

salida del comando. Eso muestra cuántos paquetes se descartaron para cada interfaz junto con otros datos y errores, etc.

Para registrar paquetes descartados hay un artículo de paywall en RHEL 7 ::

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

Para más investigación, puede leer:

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

Establece aquí según Steven's Book Illustrated TCP / IP:

"El límite de la cola se aplica a la suma de [...] el número de entradas en la cola de conexión incompleta [...] y [...] el número de entradas en la cola de conexión completa [...]".

Por lo tanto, también establece que:

"La cola de conexión completada casi siempre está vacía porque cuando se coloca una entrada en esta cola, la llamada del servidor para aceptar regresa y el servidor retira la conexión completa de la cola".

Por lo tanto, la cola de aceptación puede parecer completamente vacía y tendrá que ajustar su (posiblemente en este caso) servidor Web Apache para aceptar más rápidamente las conexiones ubicadas en la cola "total agregada".

— mkzia
fuente

Si bien parece haber información útil aquí, no estoy seguro de que responda la pregunta. Si pregunto: "¿Cuál es la mayor cantidad de personas que han estado en este auditorio alguna vez?", Y usted señala un letrero en la pared que brinda la máxima capacidad, no ha respondido la pregunta.

— Scott

De hecho, estoy buscando la longitud actual de la cola, no la longitud máxima de la cola.

— Phil Frost

Debería ser tcp_max_syn_backlog, no tcp_max_SYNC_backlog como en su respuesta

— DevilaN

Sí ... y StackOverflow te da un mensaje de error retrasado cuando intentas cambiarlo: "Las ediciones deben tener al menos 6 caracteres; ¿hay algo más que mejorar en esta publicación?"

— Aaron C. de Bruyn