Solución 1:
Finalmente encontré la configuración que realmente limitaba el número de conexiones:net.ipv4.netfilter.ip_conntrack_max . Esto se configuró en 11 776 y lo que sea que establezca es la cantidad de solicitudes que puedo atender en mi prueba antes de tener que esperar tcp_fin_timeout segundos para que haya más conexiones disponibles. El conntrack table es lo que usa el kernel para rastrear el estado de las conexiones, así que una vez que está lleno, el kernel comienza a descartar paquetes e imprimir esto en el registro:
Jun 2 20:39:14 XXXX-XXX kernel: ip_conntrack: table full, dropping packet.
El siguiente paso fue hacer que el kernel reciclara todas esas conexiones en el TIME_WAIT estado en lugar de descartar paquetes. Podría hacer que eso suceda activando tcp_tw_recycle o aumentando ip_conntrack_max ser mayor que el número de puertos locales disponibles para conexiones por ip_local_port_range . Supongo que una vez que el kernel está fuera de los puertos locales, comienza a reciclar las conexiones. Esto usa más conexiones de seguimiento de memoria, pero parece la mejor solución que activar tcp_tw_recycle ya que los documentos implican que eso es peligroso.
Con esta configuración puedo ejecutar ab todo el día y nunca quedarme sin conexiones:
net.ipv4.netfilter.ip_conntrack_max = 32768
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_max_orphans = 8192
net.ipv4.ip_local_port_range = 32768 61000
El tcp_max_orphans la configuración no tuvo ningún efecto en mis pruebas y no sé por qué. Creo que cerraría las conexiones en TIME_WAIT estado una vez que había 8192 de ellos pero no hace eso para mí.
Solución 2:
Realmente desea ver lo que el sistema de archivos /proc tiene para ofrecerle a este respecto.
- Guía de ajuste de TCP del Departamento de Energía de EE. UU.
- Parámetros de ajuste de TCP para diferentes sistemas operativos
- "Administrar Linux sobre la marcha" de IBM
- Documentación en LinuxInsight.com frente a /proc/sys/net/ipv4
En esa última página, puede encontrar lo siguiente que le interese:
- /proc/sys/net/ipv4/tcp_max_orphans, que controla el número máximo de sockets que tiene el sistema no unido a algo. Aumentar esto puede consumir hasta 64 kbytes de memoria no intercambiable por socket huérfano .
- /proc/sys/net/ipv4/tcp_orphan_retries, que controla la cantidad de reintentos antes de que un socket quede huérfano y cerrado. Hay una nota específica en esa página sobre servidores web que es de su interés directo...
Solución 3:
No creo que haya un sintonizable para configurar eso directamente. Esto entra en la categoría de ajuste de TCP/IP. Para averiguar qué puede sintonizar, pruebe 'man 7 tcp'. El sysctl ('man 8 sysctl') se usa para configurarlos. 'sysctl-a | grep tcp' le mostrará la mayor parte de lo que puede ajustar, pero no estoy seguro de si lo mostrará todo. Además, a menos que esto haya cambiado, los sockets TCP/IP se abren como descriptores de archivos. Así que esta y la siguiente sección en ese enlace podrían ser lo que está buscando.
Solución 4:
Intente configurar lo siguiente y configurar tcp_fin_timeout. Esto debería cerrar TIME_WAIT más rápido.
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
Solución 5:
El stock apache(1) solía venir predefinido para admitir solo 250 conexiones simultáneas; si quería más, había un archivo de encabezado para modificar para permitir más sesiones simultáneas. No sé si esto sigue siendo cierto con Apache 2.
Además, debe agregar una opción para permitir muchos más descriptores de archivos abiertos para la cuenta que ejecuta Apache, algo que los comentarios anteriores no señalan.
Preste atención a la configuración de su trabajador y qué tipo de tiempos de espera de mantenimiento de actividad tiene dentro de Apache, cuántos servidores de repuesto tiene ejecutándose a la vez y qué tan rápido se están eliminando estos procesos adicionales.