puertos - ver conexiones activas linux

Aumentando la cantidad máxima de conexiones tcp/ip en Linux

Question

Estoy programando un servidor y parece que mi número de conexiones es limitado, ya que mi ancho de banda no está saturado, incluso cuando configuré el número de conexiones como "ilimitado".

¿Cómo puedo aumentar o eliminar un número máximo de conexiones que mi caja Ubuntu Linux puede abrir a la vez? ¿El sistema operativo lo limita, o es el enrutador o el ISP? ¿O es otra cosa?

Answer 1

El número máximo de conexiones se ve afectado por ciertos límites tanto en el lado del cliente como del servidor, aunque de forma un poco diferente.

En el lado del cliente: aumente el rango del puerto epidérmico y disminuya el tcp_fin_timeout

Para conocer los valores predeterminados:

sysctl net.ipv4.ip_local_port_range
sysctl net.ipv4.tcp_fin_timeout

El rango del puerto epidérmico define la cantidad máxima de sockets de salida que un host puede crear desde una dirección IP particular. fin_timeout define el tiempo mínimo que estos sockets se mantendrán en el estado TIME_WAIT (inutilizable después de ser usado una vez). Los valores predeterminados usuales del sistema son:

• net.ipv4.ip_local_port_range = 32768 61000
• net.ipv4.tcp_fin_timeout = 60

Esto básicamente significa que su sistema no puede garantizar consistentemente más de (61000 - 32768) / 60 = 470 tomas por segundo. Si no está satisfecho con eso, puede comenzar aumentando el port_range . Establecer el rango a 15000 61000 es bastante común en estos días. Puede aumentar aún más la disponibilidad al disminuir fin_timeout . Supongamos que hace ambas cosas, debería ver más de 1500 conexiones salientes por segundo, más fácilmente.

Para cambiar los valores :

sysctl net.ipv4.ip_local_port_range="15000 61000"
sysctl net.ipv4.tcp_fin_timeout=30

Lo anterior no debe interpretarse como los factores que afectan la capacidad del sistema para realizar conexiones de salida por segundo. Pero más bien estos factores afectan la capacidad del sistema para manejar conexiones concurrentes de manera sostenible durante largos períodos de "actividad".

Los valores predeterminados de Sysctl en un cuadro de linux típico para tcp_tw_recycle y tcp_tw_reuse serían

net.ipv4.tcp_tw_recycle=0
net.ipv4.tcp_tw_reuse=0

Estos no permiten una conexión desde un socket "usado" (en estado de espera) y obligan a los sockets a durar el ciclo completo time_wait . Recomiendo configurar:

sysctl net.ipv4.tcp_tw_recycle=1
sysctl net.ipv4.tcp_tw_reuse=1

Esto permite un ciclo rápido de los sockets en el estado time_wait y reutilizarlos. Pero antes de hacer este cambio, asegúrese de que esto no entre en conflicto con los protocolos que usaría para la aplicación que necesita estos sockets.

En el lado del servidor: el valor de net.core.somaxconn tiene un rol importante. Limita el número máximo de solicitudes en cola a un socket de escucha. Si está seguro de la capacidad de su aplicación de servidor, amplíela desde la predeterminada 128 a algo así como 128 a 1024. Ahora puede aprovechar este aumento modificando la variable de retraso de escucha en la llamada de escucha de su aplicación, a un entero igual o superior.

sysctl net.core.somaxconn=1024

txqueuelen parámetro txqueuelen de tus tarjetas ethernet también tiene un rol que jugar. Los valores predeterminados son 1000, así que aumente hasta 5000 o incluso más si su sistema puede manejarlo.

ifconfig eth0 txqueuelen 5000
echo "/sbin/ifconfig eth0 txqueuelen 5000" >> /etc/rc.local

Del mismo modo, net.core.netdev_max_backlog los valores de net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog . Sus valores predeterminados son 1000 y 1024 respectivamente.

sysctl net.core.netdev_max_backlog=2000
sysctl net.ipv4.tcp_max_syn_backlog=2048

Ahora recuerde iniciar las aplicaciones del lado del cliente y del servidor incrementando los ulimts FD en el shell.

Además de la técnica anterior más popular utilizada por los programadores es reducir el número de llamadas de escritura tcp . Mi propia preferencia es utilizar un buffer en el que presiono los datos que deseo enviar al cliente, y luego, en los puntos apropiados, escribo los datos almacenados en el socket real. Esta técnica me permite usar grandes paquetes de datos, reducir la fragmentación, reducir la utilización de mi CPU tanto en el terreno del usuario como a nivel del kernel.

Answer 2

En un nivel de aplicación, aquí hay algo que un desarrollador puede hacer:

Del lado del servidor:

1. Compruebe si el equilibrador de carga (si lo tiene), funciona correctamente.

2. Convierta los tiempos de espera TCP lentos en 503 Respuesta inmediata rápida. Si carga el equilibrador funciona correctamente, debe seleccionar el recurso de trabajo para servir, y es mejor que colgarlo allí con masajes de error inesperados.

Por ejemplo: si está utilizando un servidor de nodos, puede usar toobusy desde npm. Implementación algo así como:

var toobusy = require(''toobusy'');
app.use(function(req, res, next) {
if (toobusy()) res.send(503, "I''m busy right now, sorry.");
else next();
});

¿Por qué 503? Aquí hay algunas buenas ideas para la sobrecarga: http://ferd.ca/queues-don-t-fix-overload.html

También podemos hacer algo de trabajo en el lado del cliente:

1. Intente agrupar llamadas en lote, reduzca el tráfico y el número total de solicitudes b / n cliente y servidor.

2. Intente crear una capa intermedia de caché para manejar solicitudes duplicadas innecesarias.

Answer 3

Hay un par de variables para establecer la cantidad máxima de conexiones. Lo más probable es que te estés quedando sin números de archivo primero. Compruebe ulimit -n. Después de eso, hay configuraciones en / proc, pero las predeterminadas son decenas de miles.

Más importante aún, parece que estás haciendo algo mal. Una sola conexión TCP debería ser capaz de usar todo el ancho de banda entre dos partes; si no es:

• Compruebe si la configuración de su ventana TCP es lo suficientemente grande. Los valores predeterminados de Linux son buenos para todo, excepto el enlace inet muy rápido (cientos de mbps) o enlaces satelitales rápidos. ¿Cuál es tu ancho de banda * producto de retraso?
• Verifique la pérdida de paquetes usando ping con paquetes grandes ( ping -s 1472 ...)
• Verifique la limitación de velocidad. En Linux, esto está configurado con tc
• Confirma que el ancho de banda que crees que existe realmente existe usando, por ejemplo, iperf
• Confirma que tu protocolo es sensato. Recuerde la latencia.
• Si se trata de una LAN gigabit +, ¿puedes usar paquetes jumbo? ¿Eres tú?

Posiblemente he entendido mal. Tal vez estés haciendo algo como Bittorrent, donde necesitas muchas conexiones. Si es así, debes averiguar cuántas conexiones estás usando en realidad (prueba netstat o lsof ). Si ese número es sustancial, puede:

• Tienen mucho ancho de banda, por ejemplo, 100mbps +. En este caso, puede que necesite subir el ulimit -n . Aún así, ~ 1000 conexiones (predeterminadas en mi sistema) son bastantes.
• Tiene problemas de red que ralentizan sus conexiones (por ejemplo, pérdida de paquetes)
• Haga que algo más lo frene, por ejemplo, el ancho de banda IO, especialmente si lo está buscando. ¿Has comprobado iostat -x ?

Además, si está utilizando un enrutador NAT de nivel de consumidor (Linksys, Netgear, DLink, etc.), tenga en cuenta que puede superar sus capacidades con miles de conexiones.

Espero que esto provea algo de ayuda. Realmente estás haciendo una pregunta de networking.

Answer 4

Para mejorar la respuesta dada por derobert,

Puede determinar cuál es su límite de conexión del sistema operativo catting nf_conntrack_max.

Por ejemplo: cat / proc / sys / net / netfilter / nf_conntrack_max

Puede usar la siguiente secuencia de comandos para contar el número de conexiones tcp a un rango determinado de puertos tcp. Por defecto 1-65535.

Esto confirmará si está maximizando su límite de conexión al sistema operativo.

Aquí está el guión.

#!/bin/bash
OS=$(uname)
case "$OS" in
''SunOS'')
AWK=/usr/bin/nawk
;;
''Linux'')
AWK=/bin/awk
;;
''AIX'')
AWK=/usr/bin/awk
;;
esac
netstat -an | $AWK -v start=1 -v end=65535 '' $NF ~ /TIME_WAIT|ESTABLISHED/ && $4 !~ /127/.0/.0/.1/ {
if ($1 ~ //./)
{sip=$1}
else {sip=$4}
if ( sip ~ /:/ )
{d=2}
else {d=5}
split( sip, a, /:|/./ )
if ( a[d] >= start && a[d] <= end ) {
++connections;
}
}
END {print connections}''