Detectar con cuánta tensión está actualmente la base de datos mysql con PHP

Question

Estoy desarrollando una gran aplicación web y quiero que se modifique dependiendo de un factor que se relaciona con el estrés bajo el que se encuentra actualmente la base de datos.

No estoy seguro de cuál sería el más preciso/efectivo/más fácil. Estoy considerando tal vez la cantidad de conexiones actuales o el tiempo de respuesta del servidor o el uso de la CPU.

¿Qué sería lo mejor y posible?

Gracias

Answer 1

pregunta interesante. Lo que REALMENTE desea es una forma de que PHP le haga dos preguntas al servidor mySQL:

servidor, ¿está utilizando casi toda su capacidad de CPU?

servidor, ¿está utilizando casi toda su capacidad de disco IO?

Según las respuestas, supongo que quiere simplificar el trabajo de su aplicación web PHP ... quizás eliminando algún tipo de capacidad de búsqueda, o almacenando en caché algunos datos de forma más agresiva.

Si tiene un intérprete de comandos para su servidor mysql (linux o bsd), sus dos preguntas pueden responderse observando el resultado de estos dos comandos.

sar -u 1 10  # the %idle column tells you about unused cpu cycles 
    sar -d 1 10  # the %util column tells you which disks are busy and how busy. 

Pero no hay una pequeña consulta que obtenga estos datos de mySQL en su aplicación.

Editar: una posibilidad es escribir un pequeño truco PERL u otro programa simple que se ejecute en su servidor, se conecte a la base de datos local, y de vez en cuando (una vez por minuto) determine% inactivo y% util y actualiza una pequeña tabla de una fila en su base de datos. Podrías, sin demasiados problemas, añadir cosas como cuán llenos están tus discos a esta mesa, si te importa. Entonces su aplicación PHP puede consultar esta tabla. Este es un uso ideal del método de acceso MEMORIA. En cualquier caso, manténgalo simple: no quiere que su monitoreo afecte su servidor.

Un segundo mejor truco que PUEDE hacer de su cliente.

Emita el comando SHOW PROCESSLIST FULL, cuente el número de filas (procesos mySQL) para las cuales el comando es "Query", y si tiene muchas de ellas, considere que es una gran carga de trabajo.

También puede agregar los valores de Tiempo para los procesos que tienen Consulta de estado y usar un valor alto de ese tiempo como umbral.

EDIT: si se está ejecutando en el servidor MySQL 5, y su cuenta de servidor tiene acceso a la INFORMATION_SCHEMA amueblado-MySQL, se puede utilizar una consulta directamente para obtener los datos de proceso que he mencionado:

SELECT (COUNT(*)-1) P.QUERYCOUNT, SUM(P.TIME) QUERYTIME 
FROM information_schema.PROCESSLIST P 
WHERE P.COMMAND = 'Query' 

COUNT (*) - 1: porque la consulta anterior en sí cuenta como una consulta.

Tendrá que juguetear con los valores de umbral para que esto funcione bien en producción.

Es una buena idea que la aplicación web PHP se descargue cuando el servidor de la base de datos no pueda mantener el ritmo. Aún así, una mejor idea es identificar sus consultas de larga ejecución y optimizarlas.

Answer 2

La consulta de MySQL Profiler hace lo que busca.

http://dev.mysql.com/tech-resources/articles/using-new-query-profiler.html

Si prefiere pagar dinero para conseguir un perfilador gráfica a continuación, probar esto:

http://www.jetprofiler.com/

Answer 3

La cantidad de "estrés" bajo la base de datos no es muy real. Lo importante es identificar qué tan escalable es la aplicación, y la extenet a la cual la base de datos está contribuyendo a un rendimiento inaceptable. Esto suena como un escape, pero no tiene mucho sentido dedicar tiempo y esfuerzo a algo sin un objetivo claro de lo que pretendes lograr.

Lo más importante es comenzar a registrar los tiempos de respuesta del nivel de microsegundo en los registros del servidor web y habilitar el registro lento de consultas en mysql. Luego prueba tu DBMS para ver qué es lento, qué lento y que te golpean con frecuencia, y qué se ralentiza a medida que aumenta la demanda.

Ciertamente, si tiene problemas de rendimiento, empiece por mirar la CPU, el uso de la memoria y las E/S, pero estos son principalmente síntomas de un problema de rendimiento, no indicadores verdaderos. Puede tener un 10% de uso de la CPU y su sistema podría estar funcionando como un perro, o un 95% de uso y funcionando como un galgo;).

carga del sistema (es decir, la longitud media de la cola de ejecución es un mejor indicador que la CPU -. Pero aún así la medición de una symtpom En lentitud general relacionados con la base de datos suele ser principalmente acerca de E/S problemas, y por lo general resuelve mediante ajuste SQL

.

C.