La mejor configuración de sysctl.conf para alta carga: servidor de transmisión de contenido extremadamente ocupado

¿Cuál es la mejor configuración sysctl.conf para un servidor de transmisión de contenido extremadamente ocupado y de alta carga? El servidor obtiene el contenido de servidores remotos como amazon, s3, etc. luego usa php para transmitir dinámicamente el contenido al usuario sin guardarlo en el disco duro. php usa CURL para recuperar el archivo, luego usa flush () para transmitirlo simultáneamente, por lo que no funciona mucho el disco duro ... solo la red y el ancho de banda.

El servidor es quad core xeon, con NIC full duplex de 1 Gbit, 8 gb de RAM y 500 GB x 2 en RAID. El uso de memoria del servidor y la carga de la CPU es bastante bajo.

Estamos ejecutando debian lenny y lighttpd2 en él (sí, sé que aún no se ha lanzado :-)) con php 5.3.6 y php fastcgi con spawn-fcgi se unen en 4 zócalos unix diferentes con 20 hijos cada uno. El número máximo de solicitudes fcgi es 20, con el módulo mod_balancer en configuración lighttpd2 para equilibrar las solicitudes fastcgi entre estos 4 sockets en la configuración SQF (cola corta primero).

Nuestros servidores usan mucho ancho de banda, es decir, la conexión de red está ocupada todo el tiempo. Justo después de 100 a 200 conexiones paralelas, el servidor comienza a ralentizarse y finalmente deja de responder, comienza a dar errores de tiempo de espera de conexión. Cuando tuvimos cpanel, nunca tuvimos errores de tiempo de espera, por lo que no puede ser un problema de script. Debe ser un problema de configuración de red.

Configuración de lighttpd2: los procesos de trabajo = 8, las solicitudes de mantener vivo son 32, el tiempo de espera inactivo de mantener vivo es de 10 segundos y las conexiones máximas son de 8192.

Nuestros contenidos actuales de sysctl.conf son:

net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_tw_recycle = 1

# Increase maximum amount of memory allocated to shm

kernel.shmmax = 1073741824

# This will increase the amount of memory available for socket input/output queues
net.ipv4.tcp_rmem = 4096 25165824 25165824
net.core.rmem_max = 25165824
net.core.rmem_default = 25165824
net.ipv4.tcp_wmem = 4096 65536 25165824
net.core.wmem_max = 25165824
net.core.wmem_default = 65536
net.core.optmem_max = 25165824

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

# you shouldn't be using conntrack on a heavily loaded server anyway, but these are
# suitably high for our uses, insuring that if conntrack gets turned on, the box doesn't die
# net.ipv4.netfilter.ip_conntrack_max = 1048576
#  net.nf_conntrack_max = 1048576

# For Large File Hosting Servers
net.core.wmem_max = 1048576
net.ipv4.tcp_wmem = 4096 87380 524288

El ajuste del rendimiento y la identificación de cuellos de botella como este son un problema difícil de resolver, y con frecuencia requieren mucha información para diagnosticar. La clave del proceso es pasar por el proceso que usa y ver si puede encontrar qué recurso se está agotando. Cuando dijo que el servidor no responde a php, pero html todavía sirve, ese es un punto de datos interesante. ¿Qué es diferente entre cómo se sirven? Puede ser un desbordamiento sutil del búfer de red, o puede ser más básico que eso. Es posible que simplemente haya agotado el límite del proceso secundario de 20 niños fcgi, y todos están ocupados sirviendo datos, mientras que las nuevas solicitudes se atascan en la cola de escucha (y finalmente se agota el tiempo de espera) esperando que aparezca un proceso fcgi php.

El verdadero truco cuando se trata de obtener visibilidad en el cuadro es iniciar sesión en el cuadro cuando se producen problemas y comenzar a recopilar información.

Para saber cuántos procesos php se están ejecutando, debería poder ejecutar algo como esto:

ps auxgmww | grep php

Y si desea contarlos en lugar de contarlos usted mismo, puede hacer algo como esto:

ps auxgmww | grep php | wc -l

Volviendo a su pregunta original sobre el ajuste del rendimiento, antes de cambiar syctl.conf es posible que desee ver qué le dice su servidor cuando se produce el problema, puede averiguarlo haciendo lo siguiente:

sysctl -a > sysctl.txt

Y luego vea su archivo de texto: es una gran cantidad de datos, pero antes de ajustar cualquier valor dado, vea si la salida de sysctl informa algo sobre lo que está usando actualmente para ese sintonizable y lo que podría estar consumiendo. Un ejemplo son los archivos abiertos, que puede ver una salida de muestra aquí:

fs.file-nr = 3456   0   102295

Eso nos dice que estamos usando descriptores de archivos 3456, pero nuestro límite es 102295, por lo que no estamos cerca de nuestro límite. Si el primer número hubiera estado en el rango de 100000, eso le indicaría que se está quedando sin descriptores de archivo y eso es lo que necesita ajustar.