PHP / MySQL: ¿Pueden los 12 núcleos de CPU hacer la aplicación más rápido que 6 núcleos de CPU, aunque el uso de CPU siempre es inferior al 40%?

nuestro problema es que MySQL está demorando nuestra aplicación después de que redujimos los núcleos de la CPU, aunque el uso de la CPU siempre es y ha estado por debajo del 40%. Mi pregunta es: ¿fue realmente la reducción de CPU lo que provocó que MySQL fuera lento ahora? ¿O debería estar buscando en otro lado?

Más detalles: mi equipo está ejecutando una aplicación móvil con hasta dos mil usuarios conectados al mismo tiempo. Lanzan hasta 100 solicitudes / segundo al back-end. Estamos usando PHP / MySQL y tenía 12 núcleos de CPU y 8 GB de RAM. La herramienta phpMyAdmin mostró que el uso de la CPU era del 15-25% y el uso de RAM en 1 GB.

Luego redujimos los núcleos de la CPU a 6. El uso de la CPU subió a un 40% como máximo. Sin embargo, frente a una mayor carga (pero no una carga más alta que la que teníamos al ejecutar 12 núcleos), MySQL no puede procesar todas las consultas de inmediato y las consultas se están poniendo en fila retrasando toda nuestra aplicación. Esto no sucedió cuando teníamos 12 núcleos.

Agradecería cualquier pista o sugerencia. Ya estamos llevando a cabo una revisión completa de la configuración del servidor (variable). Estamos usando solo tablas InnoDB.

Muchas gracias, Fman

Me parece que MySQL probablemente esté alcanzando sus límites de E / S. Hicimos una prueba de resistencia en nuestro servidor de base de datos y algo que es crítico para entender los puntos de obstrucción de DB es que cuando agrega o cambia registros, debe escribir un disco ( SELECT puede almacenarse en caché). Entonces, cuando estábamos leyendo nuestro sitio web, manejaba bastante, pero cuando simulamos un checkout (se crearon múltiples registros) se empantanó muy rápido.

En aquel entonces, no teníamos ninguna opción. Los discos SSD eran demasiado caros para aprovisionarse frente a los magnéticos (y nuestro número de cebador superaba con creces cualquier cosa que hayamos alcanzado). Lo mejor que pudimos hacer fue RAID 10. Pero, gracias a las nubes, ahora puede (y de manera económica) tener un servidor de bases de datos bastante potente que manejará las cargas de E / S mucho mejor (especialmente con los precios de SSD cayendo rápidamente). Notará que Amazon vende incluso sus instancias intermedias en la función de IOPS aprovisionadas

Para cualquier aplicación de producción que requiera un rendimiento de E / S rápido y consistente, recomendamos el almacenamiento provisto de IOPS (operaciones de entrada / salida por segundo). El almacenamiento de IOPS provisto es un tipo de almacenamiento que ofrece un rendimiento de rendimiento rápido, predecible y consistente. Cuando crea una instancia de base de datos, especifica una tarifa de IOPS y una asignación de espacio de almacenamiento. Amazon RDS proporciona la tasa y el almacenamiento de IOPS durante toda la vida de la instancia de DB o hasta que la modifique. El almacenamiento de IOPS provisto está optimizado para cargas de trabajo de procesamiento de transacciones en línea (OLTP) intensivas de E / S que tienen requisitos de rendimiento consistentes.

Suena muy parecido a que probablemente tenga una configuración simple (y tal vez incluso aloje su base de datos en el mismo servidor). AWS no es el único juego de la ciudad, pero es posible que desee considerar el cambio a algún tipo de nube, o al menos intensificar algo que pueda manejar las mayores demandas de E / S que está instalando en su servidor. Olvida la cantidad de núcleos. Si su HDD se está ahogando, podría estar ejecutando 72 núcleos y no tener ninguna diferencia de ningún tipo.

Otro consejo: echa un vistazo al sintonizador MySQL . Cuando lo ejecuta, comprueba las estadísticas de la base de datos (cuanto más tiempo se ha estado ejecutando, mejor) y puede recomendar muchos ajustes útiles que también pueden mejorar el rendimiento.