Base de datos de Wordpress lenta: ¿debo cambiar a InnoDB?

Question

Base de datos de Wordpress lenta: ¿debo cambiar a InnoDB?

#1 de RolandoMySQLDBA (10 votos)
#2 de anu (5 votos)

10

Tengo un sitio de WordPress con más de 10k publicaciones, y las cosas empiezan a ser muy lentas cada vez que agrego y edito publicaciones. Las páginas se cargan de forma agradable y rápida para los usuarios, junto con las listas de publicaciones de administración, pero es cuando se producen escrituras o actualizaciones, el servidor va al 100% de la CPU y tarda mucho tiempo (a veces más que el tiempo de espera de PHP de los 60).

Estoy pensando que es probable que esto suceda con el bloqueo a nivel de tabla de MyISAM, y estoy pensando en cambiar esto a InnoDB. ¿Cuáles son las implicaciones de hacer esto?

Algunas estadísticas:

select  - per hour ~22k
update  - per hour ~7.6k
set option  - per hour ~7k

Sé que hay muchas otras optimizaciones que puedo hacer, pero creo que esto podría tener el mayor impacto.

Gracias

Editar : he encontrado uno de los principales problemas que causan la lentitud, fue YARPP (el complemento de Yet Related Related Posts) que regenera la "relación" cada vez, y esto parece deberse. a las 2k + etiquetas que tenemos. Desactivé la opción "considerar etiquetas" y se aceleró considerablemente.

Además, otros complementos que regeneran cosas pueden causar este tipo de problemas, como algunos complementos de mapa del sitio XML.

Por lo tanto, mi problema inmediato se resolvió, aunque aún me encantaría escuchar una buena respuesta a InnoDB vs MyISAM para Wordpress.

database mysql optimization innodb

pregunta Adam Heath 24.02.2011 - 12:34

2 respuestas

Lea otras preguntas en las etiquetas database mysql optimization innodb

¿Por qué? doing_wp_cron se adjunta a mis URL WP 3.8 Color de administrador predeterminado para todos los usuarios

score 10 · Answer 1

De hecho, me cambiaría a InnoDB. El bloqueo de tablas / filas ha sido discutido por muchos. Siempre elegiría InnoDB sin duda. Sin embargo, hay otra razón profunda para seleccionando InnoDB ... CACHING .

Si bien la mayoría de las personas se jactan de que MyISAM es más rápido para las lecturas, la mayoría de las personas olvidan que la cantidad de caché de MyISAM, que se denomina caché de claves (establecida por key_buffer_size), solo almacena en caché las páginas de índice de archivos. Nunca cachea las páginas de datos. Tiene un máximo oficial de 4 GB en sistemas de 32 bits. 8 GB es el mejor máximo para 64 bits.

El grupo de búferes InnoDB almacena en caché los datos y las páginas de índice. Dependiendo del servidor que tenga, puede almacenar en caché todo el conjunto de datos en la RAM. Puede ajustar InnoDB para hasta un 80% de RAM y un 10% para DB Conenctions, y dejar un 10% para el sistema operativo. Esto es cierto incluso para diferentes sistemas operativos .

He recomendado estas cosas para los clientes de Drupal con un éxito maravilloso. También se aplica a Wordpress . He proporcionado soporte de base de datos para clientes con WordPress. Las mismas mejoras.

Siempre puede configurar memoria para InnoDB más efectivamente que puedes más MyISAM. Siempre hay una forma de ajustar Tweek InnoDB para satisfacer sus necesidades de rendimiento . A medida que sus datos crezcan, finalmente se convertirse en un requisito .

score 5 · Answer 2

InnoDB probablemente no lo ayudará: el bloqueo a nivel de fila / página ayuda a mitigar la contención, pero no parece que ese sea su problema.

Hay muchas cosas por ahí que sugieren que MyISAM es más lento que InnoDB en el escenario promedio del blog (muchas más lecturas que escrituras).

Antes de hacer un cambio, al menos debes hacer lo siguiente

ejecuta mysqltuner, que te dará algunos consejos de configuración (no es infalible o, sin embargo, todo lo sabe)
active el registro de consultas lento, déjelo por un día o más, y luego comience a revisar el registro y EXPLIQUE las consultas para ver qué está pasando

Por experiencia personal, descubrí que agregar un índice a un campo no indexado en wp_comments me ayudó enormemente en mi situación particular (períodos de comentarios incómodos, donde más o menos personas podrían estar tratando de comentar al mismo tiempo), y es posible ¡descubrir qué consultas se están ejecutando lentamente y por qué puede llevarlo a una mejor comprensión del problema y una solución REAL!