¿Qué tipo de pruebas debo ejecutar para determinar cuellos de botella en mi servidor? Estoy tratando de optimizar así puedo mantener picos de carga pesada cuando ocurren. Estoy corriendo Ubuntu en un entorno LAMP.
Respuestas
¿Demasiados anuncios?
Yo recomiendo instalar primero un marco de registros, tales como munin, de modo que usted tiene algunos datos disponibles en su base de carga y durante los picos en su servidor. A continuación, me gustaría supervisar las consultas en SQL server (especialmente las consultas lentas).
Con esta información, ya se puede determinar si la forma extraordinaria de estas situaciones o si simplemente añadir el último clavo a una elevada carga de máquina y lo que sucede, tal como se ejecuta fuera de la RAM, ciertos procesos están golpeando el disco, a veces, o su CPU es el problema.
gfrizzle
Puntos
4518
Esta es una pregunta muy amplia. Para medir cualquier cosa, lo primero que necesita un rendimiento de línea de base del indicador. Instale munin y munin-node y evaluar su línea de base. collectd y el venerable SNMP también son opciones, pero no es muy amigable con el usuario.
Piense acerca de su aplicación. Es la base de datos pesados? Un montón de IO? CPU (codificación de vídeo)? Realizar algunas web normales de aplicación de las tareas y ver donde su cuellos de botella siquiera existe, en primer lugar. El uso de otras herramientas como siege, abo JMeter a automatizar estas tareas.
Después de haber establecido el punto de partida de las métricas y los puntos de rotura, se puede ver dónde mejorar. Como se ha dicho, esta es una cuestión amplia y por lo tanto tiene un lugar amplio espectro de respuesta:
I/O bound: Está usted de golpear la base de datos innecesariamente? ¿Cuál es su caché de consultas? ¿Usted necesita para optimizar escribe o lee? ¿Necesita un servidor de base de datos independiente?
A depender de la memoria: Si no estás de base de datos I/O bound y tienen tanto como usted puede en la memoria, es el conjunto de datos es demasiado grande para la memoria disponible? ¿Cuál es la tasa de aciertos de caché? Es usted el uso de una caché independiente marco como
memcached?CPU: Es la aplicación capaz de tomar ventaja de varios núcleos y/o trabajadores? ¿Usted sufre de hilo de bloqueo o problemas de contención? Considere el uso de un servidor web ligero como
nginxen lugar de Apache, o un proxy inverso de la instalación. También puede ser relevantesysctl.conf(kernel) parámetros que se pueden cambiar.La red de la envolvente: muy poco probable que en esta etapa del juego.
Otros puntos y consideraciones:
Algunos optimización rápida en tu DB se puede hacer con mysqltuner.pl.
Probar y simular tráfico real tan estrechamente como sea posible (se repiten los registros de acceso es un buen comienzo).
Si alguna vez golpeó el área de swap en el disco en una base de datos de producción, en un mundo de dolor.
tl;dr Gráfico de todo lo que usted considere pertinente, golpeó su duro del servidor, ajuste, repita.
Johan Dahlin
Puntos
6296
Lo que yo he encontrado mejor es realizar un análisis de la capacidad antes de la implementación. Sin embargo, hay un gran artículo sobre exactamente lo que usted está buscando, espero que esto ayude.
http://blog.inarow.net/post/227533559/four-steps-to-diagnose-your-lamp-application
1) realizar un Seguimiento de las Consultas de MySQL tomar más de un segundo 2) el Monitor de PHP el Uso de la Memoria Y de Registro de Apache Tiempos de Entrega 3) Registro de Errores de PHP 4) Tomar Instantáneas en un Nivel de sistema operativo
También me gustaría añadir JMeter en esto. http://jakarta.apache.org/jmeter/
