Solución 1:
El problema puede ser que esté recibiendo demasiadas interrupciones en su tarjeta de red. Si el ancho de banda no es el problema, la frecuencia es el problema:
-
Suba los búferes de envío/recepción en la tarjeta de red
ethtool -g eth0
Le mostrará la configuración actual (256 o 512 entradas). Probablemente pueda elevarlos a 1024, 2048 o 3172. Más probablemente no tenga sentido. Esto es solo un búfer de anillo que solo se llena si el servidor no puede procesar los paquetes entrantes lo suficientemente rápido.
Si el búfer comienza a llenarse, el control de flujo es un medio adicional para decirle al enrutador o conmutador que reduzca la velocidad:
-
Active el control de flujo de entrada/salida en el servidor y los puertos del conmutador/enrutador al que está conectado.
ethtool -a eth0
Probablemente mostrará:
Pause parameters for eth0:
Autonegotiate: on
RX: on
TX: on
Compruebe /var/log/messages para conocer la configuración actual de eth0. Busca algo como:
eth0:el enlace está activo a 1000 Mbps, dúplex completo, control de flujo tx y rx
Si no ve tx y rx, los administradores de su red deben ajustar los valores en el conmutador/enrutador. En Cisco que está activado el control de flujo de recepción/transmisión.
Cuidado: Al cambiar estos valores, su enlace bajará y subirá durante un tiempo muy corto (menos de 1 segundo).
-
Si todo esto no ayuda, también puede reducir la velocidad de la tarjeta de red a 100 MBit (haga lo mismo en los puertos del conmutador/enrutador)
ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100
Pero en su caso yo diría:aumente los búferes de recepción en el búfer de anillo de la NIC.
Solución 2:
La siguiente puede no ser la respuesta definitiva, pero definitivamente presentará algunas ideas
Intente agregarlos a sysctl.conf
## tcp selective acknowledgements.
net.ipv4.tcp_sack = 1
##enable window scaling
net.ipv4.tcp_window_scaling = 1
##
net.ipv4.tcp_no_metrics_save = 1
Mientras que el tcp ck selectivo es bueno para un rendimiento óptimo en el caso de una red de gran ancho de banda. Pero ten cuidado con otros inconvenientes. Los beneficios del escalado de ventana se describen aquí. En cuanto a la tercera opción de sysctl:de forma predeterminada, TCP guarda varias métricas de conexión en la caché de ruta cuando se cierra la conexión, de modo que las conexiones establecidas en un futuro cercano puedan usarlas para establecer las condiciones iniciales. Por lo general, esto aumenta el rendimiento general, pero a veces puede causar una degradación del rendimiento. Si se establece, TCP no almacenará en caché las métricas al cerrar las conexiones.
Consulte con
ethtool -k ethX
para ver si la descarga está habilitada o no. La descarga de suma de comprobación de TCP y la descarga de segmento grande son compatibles con la mayoría de las NIC de Ethernet actuales y aparentemente Broadcom también lo admite.
Intenta usar la herramienta
powertop
mientras la red está inactiva y cuando se alcanza la saturación de la red. Esto definitivamente mostrará si las interrupciones de la NIC son las culpables. El sondeo de dispositivos es una respuesta a tal situación. FreeBsd admite el interruptor de sondeo dentro de ifconfig, pero Linux no tiene esa opción. Consulte esto para habilitar el sondeo. Dice que BroadCom también admite encuestas, lo cual es una buena noticia para usted.
Es posible que el ajuste de paquetes gigantes no sea suficiente para usted, ya que mencionó que su tráfico se compone principalmente de paquetes pequeños. ¡Pero pruébalo de todos modos!
Solución 3:
Noté en la lista de ajustes que las marcas de tiempo están desactivadas, por favor no hagas eso. Ese es un viejo recuerdo de los días de antaño cuando el ancho de banda era realmente caro y la gente quería ahorrar unos pocos bytes/paquete. La pila TCP lo utiliza, por ejemplo, en estos días para saber si un paquete que llega a un socket en "CLOSE_WAIT" es un paquete antiguo para la conexión o si es un paquete nuevo para una conexión nueva y ayuda en los cálculos de RTT. Y guardar los pocos bytes para una marca de tiempo no es NADA en comparación con las direcciones IPv6 que se van a agregar. Desactivar las marcas de tiempo hace más daño que bien.
Esta recomendación para desactivar las marcas de tiempo es solo un retroceso que sigue pasando de una generación de administradores de sistemas a la siguiente. Algo así como una "leyenda urbana".
Solución 4:
necesita distribuir la carga entre todos los núcleos de la CPU. Inicie 'irqbalance'.
Solución 5:
En mi caso solo una única afinación:
net.ipv4.tcp_timestamps = 0
hizo un cambio muy grande y útil, el tiempo de carga del sitio disminuyó en un 50%.