Ajustes del kernel para muchas conexiones abiertas

Mida primero

ss -s
cat /proc/sys/fs/file-nr
nstat -az TcpExtListenOverflows TcpExtListenDrops

ListenOverflows subiendo significa que la cola de aceptación está llena y el kernel está descartando handshakes completados. Ese es un problema específico con una solución específica. La mayoría de los otros síntomas no se resuelven con sysctl en absoluto, y ajustar una máquina que no está bajo presión solo mueve el fallo eventual a algún lugar más difícil de encontrar.

Los ajustes que merecen su lugar

# /etc/sysctl.d/90-connections.conf
fs.file-max = 2097152
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 32768
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_mtu_probing = 1
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

sysctl --system
sysctl net.ipv4.tcp_congestion_control

Lo que hace cada uno:

• somaxconn limita la cola de escucha, y su aplicación todavía tiene que pedirlo. En nginx eso es listen ... backlog=65535; en la mayoría de los lenguajes es el segundo argumento de listen().
• ip_local_port_range importa en el lado del cliente. Un proxy que abre conexiones salientes a un solo destino agota los puertos efímeros alrededor de veintiocho mil con el rango predeterminado.
• tcp_tw_reuse permite que el kernel reutilice sockets TIMEWAIT para nuevas conexiones salientes. Seguro. Su primo `tcptw_recycle` fue eliminado de Linux en 4.12, y cualquier guía que todavía lo recomiende fue escrita antes de 2017.
• fq con bbr es una mejora real en rutas largas o con pérdida, y un lavado en rutas cortas y limpias. Ambos están en los kernels estándar.

Seguimiento de conexiones

Un firewall con estado da a cada conexión una entrada conntrack, y la tabla tiene un techo. Al alcanzarlo, se descartan paquetes y se escribe nf_conntrack: table full en el registro del kernel.

sysctl net.netfilter.nf_conntrack_max net.netfilter.nf_conntrack_count

Auméntelo si tiene memoria — cada entrada cuesta unos pocos cientos de bytes:

net.netfilter.nf_conntrack_max = 1048576

Donde la carga de trabajo es un servicio público sin estado, la mejor respuesta es no rastrearlo:

table inet raw {
  chain prerouting {
    type filter hook prerouting priority raw;
    tcp dport 443 notrack
  }
}

Los límites que systemd ignora

/etc/security/limits.conf se aplica a los inicios de sesión a través de PAM. No tiene ningún efecto sobre un servicio iniciado por systemd, por lo que aumentar nofile allí y reiniciar nginx no cambia absolutamente nada. Establézcalo en la unidad:

mkdir -p /etc/systemd/system/nginx.service.d
cat > /etc/systemd/system/nginx.service.d/limits.conf <<EOF
[Service]
LimitNOFILE=1048576
EOF
systemctl daemon-reload
systemctl restart nginx

Verifique contra el servicio en ejecución en lugar del archivo que acaba de escribir:

systemctl show nginx -p LimitNOFILE

Tres cosas que no hacer

• No pegue un archivo sysctl de cincuenta líneas de un foro. La mitad apunta a un kernel que no se ha enviado en una década, y una línea romperá silenciosamente el descubrimiento de MTU de ruta.
• No aumente tcp_rmem y tcp_wmem sin una ruta larga y ancha que lo justifique. En una ruta de un milisegundo, buffers más grandes compran latencia y presión de memoria.
• No desactive tcp_timestamps. Pierde la estimación de ida y vuelta y PAWS, y gana un rumor sobre el rendimiento.

Mida de nuevo después de cada cambio, un cambio a la vez, y mantenga el archivo en control de versiones para que la próxima persona pueda ver lo que hizo y por qué.