11 votos

Optimización de rendimiento de una Alta Carga de Apache Servidor

Estoy buscando a entender algunos de los problemas de rendimiento del servidor me estoy viendo con una (para nosotros) muy cargado servidor web. El medio ambiente es el siguiente:

  • Debian Lenny (todos los paquetes estables + parcheado para las actualizaciones de seguridad)
  • Apache 2.2.9
  • PHP 5.2.6
  • Amazon EC2 gran ejemplo

El comportamiento que estamos viendo es que la web normalmente se siente sensible, pero con un poco de retraso para iniciar el manejo de una solicitud-a veces, una fracción de un segundo, a veces de 2 a 3 segundos en nuestras horas de uso. La carga real en el servidor en el que se informa como muy alta, a menudo 10.xx o 20.xx según informó top. Además, la ejecución de otras cosas en el servidor durante estos tiempos (aun vi) es muy lento, por lo que la carga es definitivamente allí. Curiosamente Apache sigue siendo muy sensible, aparte de que el retraso inicial.

Tenemos Apache configurado de la siguiente manera, utilizando prefork:

StartServers          5
MinSpareServers       5
MaxSpareServers      10
MaxClients          150
MaxRequestsPerChild   0

Y KeepAlive como:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

Buscando en el servidor de la página estado, incluso en estos tiempos de carga pesada estamos rara vez de golpear el cliente cap, suele servir entre 80-100 solicitudes y muchos de los que en el keepalive del estado. Que me dice para descartar la solicitud inicial lentitud como "en espera de un controlador", pero puedo estar equivocado.

Amazon CloudWatch seguimiento me dice que aun cuando nuestro sistema operativo informa de una carga de > 15, nuestro ejemplo de utilización de la CPU es entre el 75-80%.

Un resultado de ejemplo top:

top - 15:47:06 up 31 days,  1:38,  8 users,  load average: 11.46, 7.10, 6.56
Tasks: 221 total,  28 running, 193 sleeping,   0 stopped,   0 zombie
Cpu(s): 66.9%us, 22.1%sy,  0.0%ni,  2.6%id,  3.1%wa,  0.0%hi,  0.7%si,  4.5%st
Mem:   7871900k total,  7850624k used,    21276k free,    68728k buffers
Swap:        0k total,        0k used,        0k free,  3750664k cached

La mayoría de los procesos de aspecto:

24720 www-data  15   0  202m  26m 4412 S    9  0.3   0:02.97 apache2                                                                       
24530 www-data  15   0  212m  35m 4544 S    7  0.5   0:03.05 apache2                                                                       
24846 www-data  15   0  209m  33m 4420 S    7  0.4   0:01.03 apache2                                                                       
24083 www-data  15   0  211m  35m 4484 S    7  0.5   0:07.14 apache2                                                                       
24615 www-data  15   0  212m  35m 4404 S    7  0.5   0:02.89 apache2            

Un resultado de ejemplo vmstat , al mismo tiempo, como el anterior:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 8  0      0 215084  68908 3774864    0    0   154   228    5    7 32 12 42  9
 6 21      0 198948  68936 3775740    0    0   676  2363 4022 1047 56 16  9 15
23  0      0 169460  68936 3776356    0    0   432  1372 3762  835 76 21  0  0
23  1      0 140412  68936 3776648    0    0   280     0 3157  827 70 25  0  0
20  1      0 115892  68936 3776792    0    0   188     8 2802  532 68 24  0  0
 6  1      0 133368  68936 3777780    0    0   752    71 3501  878 67 29  0  1
 0  1      0 146656  68944 3778064    0    0   308  2052 3312  850 38 17 19 24
 2  0      0 202104  68952 3778140    0    0    28    90 2617  700 44 13 33  5
 9  0      0 188960  68956 3778200    0    0     8     0 2226  475 59 17  6  2
 3  0      0 166364  68956 3778252    0    0     0    21 2288  386 65 19  1  0

Y por último, la salida de Apache server-status:

Server uptime: 31 days 2 hours 18 minutes 31 seconds
Total accesses: 60102946 - Total Traffic: 974.5 GB
CPU Usage: u209.62 s75.19 cu0 cs0 - .0106% CPU load
22.4 requests/sec - 380.3 kB/second - 17.0 kB/request
107 requests currently being processed, 6 idle workers

C.KKKW..KWWKKWKW.KKKCKK..KKK.KKKK.KK._WK.K.K.KKKKK.K.R.KK..C.C.K
K.C.K..WK_K..KKW_CK.WK..W.KKKWKCKCKW.W_KKKKK.KKWKKKW._KKK.CKK...
KK_KWKKKWKCKCWKK.KKKCK..........................................
................................................................

Desde mi limitada experiencia me extraer las siguientes conclusiones/preguntas:

  • Podemos estar permitiendo demasiadas KeepAlive de las solicitudes

  • Veo pasar algún tiempo de espera para la IO en el vmstat aunque no de forma consistente y no un montón (creo?) así que no estoy seguro de que este es un gran tema de preocupación o no, yo soy el menos experimentado con vmstat

  • También en vmstat, veo en algunas iteraciones de una serie de procesos que están esperando a ser atendidos, que es lo que estoy atribución de la carga de la página inicial de retraso en nuestro servidor web, posiblemente erróneamente

  • Nos sirven una mezcla de contenido estático (75% o más) y el guión de contenido, y el contenido del script es a menudo bastante uso intensivo del procesador, por lo que encontrar el equilibrio adecuado entre los dos es importante; a largo plazo queremos mover la estática en otros lugares para optimizar ambos servidores, pero nuestro software no está listo para que el día de hoy

Estoy feliz de proporcionar información adicional si alguien tiene alguna idea, la otra nota es que esta es una de alta disponibilidad de la instalación de producción así tengo dudas de hacer retoques después de ajustar, y es la razón por la que no he jugado con cosas como el KeepAlive valor mí todavía.

9voto

beans Puntos 887

Tiene dos filas de su vmstat que muestran la CPU, el tiempo de espera es bastante alto, y alrededor de aquellos, que hacen un buen número de escrituras (io - bo) y el cambio de contexto. Me gustaría ver lo que la escritura de los bloques, y cómo eliminar que esperar. Creo que la mayoría de la mejora podría ser encontrado en la mejora de su e / s de disco. Verificación de syslog - set para escribir de forma asincrónica. Asegúrese de que su controlador de caché de escritura está trabajando (check-usted puede tener un mal de la batería).

Keepalive no es la causa de su perf problema, se ahorra tiempo en la configuración de la conexión si no estás ejecutando una caché en el frente. Puede ser que te topes MaxSpareServers un poco, así que en una crisis no estás esperando que todos los tenedores.

2voto

Alex Puntos 5342

Usted debe considerar la instalación de una asincronía en el proxy inverso, debido a una serie de procesos en W estado es bastante alto también. Apache procesos parecen pasar mucho tiempo en el envío de contenido a los clientes lentos a través de la red, está bloqueado en eso. Nginx o lighttpd como un frontend para tu servidor Apache puede reducir a una serie de procesos en W estado de forma espectacular. Y sí, usted debe limitar a un número de keepalive solicitudes. Probablemente vale la pena intentarlo, a su vez keepalive off.

Por CIERTO, 107 Apache procesos son demasiado altos para el 22 de rps, yo era capaz de servir de 100-120 rps usando sólo 5 Apache procesos. Probablemente, el siguiente paso es el perfil de su aplicación.

1voto

MagicAndi Puntos 10128

Voy a empezar por admitir que yo no se mucho acerca de la ejecución de las cosas en las nubes, pero basado en mi experiencia en otros lugares, yo diría que este webserver de configuración refleja bastante bajo volumen de tráfico. Que el runqueue es tan grande sugiere que simplemente no hay suficiente CPU disponible para tratar con él. Qué más hay en el runqueue?

Podemos estar permitiendo demasiadas solicitudes de KeepAlive

No keeplive todavía mejora el rendimiento, los navegadores modernos son muy inteligentes acerca de saber cuándo canalización y cuándo ejecutar las peticiones en paralelo, a pesar de un tiempo de espera de 5 segundos es todavía bastante alto, y usted tiene un MONTÓN de servidores de espera - a menos que usted tiene ENORMES problemas de latencia, me gustaría recomendar el arranque de este hasta 2-3. Este debe acortar la runqueue un poco.

Si no has conseguido ya mod_deflate instalado en el servidor web - entonces yo te recomiendo hacerlo - y agregar el ob_gzhandler() para sus scripts PHP. Usted puede hacer esto como un auto-anteponer:

if(!ob_start("ob_gzhandler")) ob_start();

(sí, copression utiliza más recursos de la CPU - pero usted debe guardar la CPU en general por obtención de los servidores de la runqueue más rápido / menos los paquetes TCP - y como un bono, su sitio es también más rápido).

Me gustaría recomendar el establecimiento de un límite superior en MaxRequestsPerChild - decir algo así como 500. Esto sólo permite una cierta rotación en los procesos en caso de que usted tiene una pérdida de memoria en algún lugar. Sus procesos httpd aspecto a ser ENORME - asegúrese de que ha eliminado cualquier módulos de apache que no necesita y asegúrese de que está para servir contenido estático con buena información de almacenamiento en caché.

Si usted todavía está viendo problemas, entonces el problema es, probablemente, dentro del código PHP (si cambia a usar fastCGI, esto debe ser evidente, sin ningún tipo de penalización de rendimiento).

actualización

Si el contenido estático no varían mucho a través de las páginas, entonces también podría ser vale la pena experimentar con:

if (count($_COOKIE)) {
    header('Connection: close');
}

en los scripts de PHP.

0voto

evcz Puntos 51

usted debe considerar la activación de keepalive como un primer intento...

con 107 solicitud procesada me gustaría seguir MaxSpareServers más alta de lo que se establece...

En mi humilde opinión, en el largo plazo nginx como proxy inverso para el contenido estático se debe tomar en consideración

0voto

Paul S Puntos 176

Primera sugerencia: deshabilitar conexiones abiertas. Sólo he necesitado cuando pude identificar una situación específica que el rendimiento aumentado, pero en general las peticiones/seg disminuyó con el Keepalive habilitado.

Segunda sugerencia: Establecer un MaxRequestsPerChild. Me hago eco de symcbean aquí, que le ayudará con el proceso de transferencia en el caso de una pérdida de memoria. 500 es un buen punto de partida.

Tercera Sugerencia: Aumentar MaxClients. Un estadio de cálculo para esto es (física de la memoria - la memoria utilizada por los no-proceso httpd)/tamaño de cada proceso httpd. Dependiendo de cómo httpd fue compilado, este número se amplía a 255. Yo uso 250 para mi de los servidores públicos para lidiar con google/yahoo/MS rastreo de los sistemas.

Vuelta Sugerencia: Aumentar MaxSpareServers: algo así como 4-5x MinSpareServers.

Baring esas sugerencias no me gustaría ver a un equilibrio de carga con proxy inverso o memcache para DB.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: