speed site how expiration check cache accelerate mysql performance wordpress

mysql - site - wp super cache config



Mysqltuner sugerencias y cambios en my.cnf (5)

Tenía esta pregunta en Serverfault durante unos días sin suerte.

He ejecutado mysqltuner.pl en un VPS y tengo un montón de preguntas sobre las sugerencias sobre las variables a cambiar. Estoy seguro de que estas son preguntas generales con respuestas complejas.

No soy lo suficientemente conocedor como para escribir consultas y probarlas en el servidor, pero estoy tratando de obtener un rendimiento un poco más del servidor que ejecuta cinco sitios de WordPress con> 200,000 páginas vistas por mes.

Optimicé la base de datos a través de phpmyadmin (y lo hago regularmente), pero el sintonizador aún dice que hay tablas fragmentadas. Y debido a que esto es WordPress, no puedo cambiar las consultas en el código central.

Pero, ¿cuánto debería aumentar las variables como query_cache_size e innodb_buffer_pool_size? ¿Y las otras variables Innodb?

Algunas de las variables sugeridas no existen en my.cnf, como table_cache, y están marcadas en el informe del sintonizador, etc. ¿Puedo agregarlas a my.cnf?

(¿Y por qué se duplica este bloque en my.cnf? ¿Puedo eliminar el duplicado?)

set-variable = innodb_buffer_pool_size=2M set-variable = innodb_additional_mem_pool_size=500K set-variable = innodb_log_buffer_size=500K set-variable = innodb_thread_concurrency=2

Debajo está el my.cnf y el resultado de mysqltuner:

Contenido de my.cnf:

query-cache-type = 1 query-cache-size = 8M set-variable=local-infile=0 datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql old_passwords=1 skip-bdb set-variable = innodb_buffer_pool_size=2M set-variable = innodb_additional_mem_pool_size=500K set-variable = innodb_log_buffer_size=500K set-variable = innodb_thread_concurrency=2 [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid skip-bdb set-variable = innodb_buffer_pool_size=2M set-variable = innodb_additional_mem_pool_size=500K set-variable = innodb_log_buffer_size=500K set-variable = innodb_thread_concurrency=2

Salida de mysqltuner:

------- General Statistics -------------------------------------------------- [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 5.0.45 [!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM -------- Storage Engine Statistics ------------------------------------------- [--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 133M (Tables: 637) [--] Data in InnoDB tables: 10M (Tables: 344) [--] Data in MEMORY tables: 126K (Tables: 2) [!!] Total fragmented tables: 69 -------- Security Recommendations ------------------------------------------- [OK] All database users have passwords assigned -------- Performance Metrics ------------------------------------------------- [--] Up for: 1d 6h 24m 13s (2M q [22.135 qps], 116K conn, TX: 4B, RX: 530M) [--] Reads / Writes: 97% / 3% [--] Total buffers: 35.0M global + 2.7M per thread (100 max threads) [OK] Maximum possible memory usage: 303.7M (8% of installed RAM) [OK] Slow queries: 0% (4/2M) [OK] Highest usage of available connections: 53% (53/100) [OK] Key buffer size / total MyISAM indexes: 8.0M/46.1M [OK] Key buffer hit rate: 99.6% (749M cached / 2M reads) [OK] Query cache efficiency: 32.2% (685K cached / 2M selects) [!!] Query cache prunes per day: 948863 [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 660K sorts) [!!] Temporary tables created on disk: 46% (400K on disk / 869K total) [!!] Thread cache is disabled [!!] Table cache hit rate: 0% (64 open / 24K opened) [OK] Open file limit used: 10% (109/1K) [OK] Table locks acquired immediately: 99% (2M immediate / 2M locks) [!!] InnoDB data size / buffer pool: 10.6M/2.0M -------- Recommendations ----------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance Enable the slow query log to troubleshoot bad queries When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses Set thread_cache_size to 4 as a starting value Increase table_cache gradually to avoid file descriptor limits Variables to adjust: query_cache_size (> 8M) tmp_table_size (> 32M) max_heap_table_size (> 16M) thread_cache_size (start at 4) table_cache (> 64) innodb_buffer_pool_size (>= 10M)

Esta no es una respuesta directa a su pregunta, pero en mi experiencia, WordPress puede optimizarse muy bien utilizando el almacenamiento en caché en los servidores frontend. También, en su mayoría, WordPress parece estar vinculado a la CPU en las máquinas frontend que no están en la base de datos. (es posible que desee comprobar que efectivamente está optimizando el cuello de botella).

Echa un vistazo a "w3 total cache", por ejemplo. Usarlo con APC debería ser el enfoque más simple. Asegúrese de echar un vistazo al tamaño de apc.shm_size (en php.ini) y la proporción de aciertos de caché (se debe suministrar alguna utilidad de información de APC con w3tc).

He visto las instancias de WordPress ejecutarse sin problemas en un solo servidor con esa configuración y mucho más de 200,000 vistas de página por mes.

Haré mi mejor esfuerzo para ayudar aquí. El informe MysqlTuner implica que tienes 4 GB de RAM en este VPS, por lo que mis sugerencias se basan en eso.

query_cache_size - Esta es la cantidad de RAM que MySQL puede usar para almacenar en caché los resultados de las consultas de la base de datos. Los resultados almacenados en el caché de consultas se devuelven mucho más rápido que las selecciones normales, por lo que esta variable puede acelerar significativamente las cosas (más que cualquiera de los otros cambios sugeridos).

Exactamente cuál es el valor correcto para usted llevará algunos experimentos. Actualmente tienes este conjunto en 8M. Si tienes 4GB de RAM en esta caja, comenzaría en 64M, aumentando a 128M y luego a 256M si es necesario. Después de cada cambio, deje las cosas por unos días y luego vuelva a ejecutar MysqlTuner y compare el porcentaje de ''Eficacia de la caché de consultas'' con el que tenía antes. Para un servidor que hospeda principalmente 5 blogs de Wordpress, dudo que veas ninguna mejora más allá de 256M, y no recomendaría ir más allá de la octava parte de tu RAM total.

Personalmente, encuentro que Munin (una herramienta de monitoreo de servidores gratuita) es muy útil para vigilar este tipo de cosas. Por ejemplo, aquí está el gráfico de MySQL de uno de mis cuadros:

Gráfico de MySQL de Munin http://tim.incutio.com/mysql-queries.png

El área de color verde claro muestra las selecciones de MySQL normales que golpean la base de datos. El área rosa muestra los seleccionados servidos por el caché, así que rosa = bueno.

tmp_table_size : para algunas consultas complejas (particularmente aquellas que usan GROUP BY o clasificación compleja), MySQL necesita primero crear una tabla temporal que contenga los datos y luego ejecutar algunas operaciones en ella para crear el conjunto de resultados. Tratará de crear estas tablas temporales en la memoria, ya que es mucho más rápido que crearlas en el disco; pero para grandes conjuntos de resultados esto no siempre es posible. tmp_table_size controla este umbral.

No me puedo imaginar que Wordpress esté haciendo consultas muy complejas, así que no me iría por la borda con esta. MysqlTuner sugiere un valor superior a 32 MB, por lo que debe comenzar con 64M y ver cómo esto afecta el valor ''Tablas temporales creadas en el disco'' después de unos días. Establezca max_heap_table_size mientras está en ello, como sugiere.

thread_cache_size - Wordpress no usa las conexiones persistentes por defecto (lo cual es bueno), por lo que cada solicitud hace una nueva conexión a su base de datos y luego cierra esto una vez que se ha generado la página. Esta sobrecarga no es significativa, pero usar thread_cache_size permite a MySQL reutilizar estos hilos de conexión, lo que ayudará un poco.

Me gustaría ir con el valor sugerido de 4, que me imagino estará bien, a menos que obtengas una gran cantidad de usuarios simultáneos.

table_cache - Estoy un poco confuso con esto, parece estar relacionado con el caché de MySQL de la estructura de la tabla. Me gustaría ir con 128 para esto.

innodb_buffer_pool_size - esta es la cantidad de memoria que MySQL puede usar para almacenar índices y datos para tablas InnoDB. Esto me desconcierta un poco, ya que no creo que Wordpress use InnoDB para nada, ¿tiene también otros sitios en este servidor?

Para responder a sus otras preguntas, la configuración después de [mysqld_safe] solo se aplica al daemon de MySQL en modo seguro, en lugar de MySQL en general, por eso algunas de las variables están duplicadas. Si cambia innodb_buffer_pool_size, querrá cambiar el primero. Las variables que no están en el archivo pueden agregarse, sí, pero agregarlas encima del bloque [mysqld_safe] por la misma razón.

Por último, dado que estás de humor para optimizar, si aún no estás usando un caché de bytecode de PHP como APC , vale la pena explorarlo. APC puede proporcionar algunas mejoras de velocidad significativas a las aplicaciones PHP sin ningún efecto negativo.

Hay más herramientas para sintonizar su base de datos mysql: http://www.day32.com/MySQL/ y http://www.maatkit.org/doc/ y http://hackmysql.com/mysqlsla

En la mayoría de los casos, no es necesario escribir consultas y probarlas en el servidor. Simplemente habilite el registro lento de consultas para identificar sus consultas lentas, agréguelos con mysqlsla y explíquelos con maatkit:

Puede pegar las consultas más lentas de los resultados de mysqla en un archivo de texto y ejecutarlas con maatkit.

mk-visual-explain –host hostname –user username –password passwort –database / databasename -c query1.sql >> query1_data.txt

-

mk-query-profiler –host hostname –user username –password passwort –database / databasename query1_data.txt >> query1_data.txt

A menudo, la elección de una nueva versión de mysql es fundamental para el rendimiento. Experimenté que los planes de ejecución para consultas complejas son muy diferentes cuando se compara, por ejemplo, MySQL 5.0.23 a 5.1.4. Se ejecutan en nuestro entorno mucho más rápido con 5.1.4.

Puede encontrar mucha información útil sobre mysql en http://www.mysqlperformanceblog.com/ y en el libro "High Performance MySQL".

Tabe Cache: según el libro "el caché de tablas almacena objetos que representan tablas. Cada objeto del caché contiene el archivo .frm analizado de la tabla asociada más otros datos, según el motor de almacenamiento de la tabla.

El diseño del caché de tabla es un poco centrado en MyISAM: esta es una de las áreas donde la separación entre el servidor y el motor de almacenamiento no está completamente limpia, por razones históricas. La memoria caché de tabla es un poco menos importante para InnoDB, porque InnoDB no se basa en ella para tantos propósitos (como mantener descriptores de archivos, tiene su propia versión de una memoria caché de tabla para este propósito). Sin embargo, incluso InnoDB se beneficia del almacenamiento en caché de los archivos .frm analizados ".

Si sube el caché de tabla, puede haber errores con el límite de archivos abiertos. También necesita aumentar la variable open_files_limit en el servidor y quizás el límite de archivos abiertos del sistema operativo: http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/ .

Thread Cache:

La caché de subprocesos contiene los subprocesos que actualmente no están asociados con una conexión pero que están listos para servir nuevas conexiones. Siempre que MySQL tenga un hilo libre en el caché, puede responder muy rápidamente a las solicitudes de conexión, ya que no tiene que crear un nuevo hilo para cada conexión.

[!!] Tablas temporales creadas en el disco: 46% (400K en disco / 869K en total) Si tmp_table_size y max_heap_table_size aún no están configurados, increméntelos. Las operaciones de disco son muy lentas en comparación con las operaciones de RAM. ¿WordPress usa muchas columnas blob / text? entonces no verá muchos beneficios, porque las columnas BLOB y Text no están permitidas en las tablas de memoria.

[OK] Mayor uso de conexiones disponibles: 53% (53/100) Para ahorrar RAM, puede disminuir las conexiones máximas permitidas. Por otro lado, es posible que se quede sin conexiones en las horas punta.

¡Usar una caché de código de operación para PHP es una muy buena idea!

Mis recomendaciones para tunning MySQL para WP:

Las tablas de la base de datos deben optimizarse periódicamente (y repararse si es necesario) para un rendimiento óptimo.

Recomiendo usar el complemento WP-DBManager, que proporciona esta funcionalidad, así como la copia de seguridad de la base de datos, todo lo cual es crucial para cualquier instalación de blog.

WP-DBManager le permite programar y olvidar, y se encargará de todo el trabajo de forma automática.

Otra alternativa es optimizar y reparar manualmente su tabla a través de una herramienta como phpmyadmin .

MySQL Query Cache guarda los resultados de las consultas en caso de que la consulta vuelva a aparecer. Sin embargo, solo sabe cómo guardar el texto de byte de las consultas, no sus versiones compiladas, por lo que pequeños cambios en la consulta crearán diferentes entradas de caché. Actívelo si no tiene identificadores únicos en cada consulta. Puede habilitarlo agregando lo siguiente a /etc/my.cnf:

query_cache_type = 1 query_cache_size = 26214400