Cada aplicación respaldada por MySQL puede beneficiarse de un servidor de base de datos finamente ajustado. El equipo de soporte heroico de Liquid Web se ha encontrado con numerosas situaciones a lo largo de los años en las que algunos ajustes menores han marcado una gran diferencia en el rendimiento del sitio web y de la aplicación. En esta serie de artículos, hemos resumido algunas de las recomendaciones más comunes que han tenido el mayor impacto en el rendimiento.
Comprobación previa al vuelo
Este artículo se aplica a la mayoría de los servidores MySQL VPS basados en Linux. Esto incluye, entre otros, servidores dedicados tradicionales y servidores VPS en la nube que ejecutan una variedad de distribuciones comunes de Linux. El artículo se puede utilizar con los siguientes tipos de sistemas Liquid Web:
- CentOS 6x/7x administrado por el núcleo
- Ubuntu 14.04/16.04 administrado por el núcleo
- CPanel de CentOS 6/7 completamente administrado
- Completamente administrado CentOS 7 Plesk Onyx 17
- Servidores Linux autogestionados
Esta serie de artículos asume la familiaridad con los siguientes conceptos básicos de administración del sistema:
- Conexiones SSH y navegación básica del entorno de shell de línea de comandos estándar de Linux.
- Abrir, editar y guardar archivos en Vim o en un editor de sistema elegido.
- Modo interactivo de MySQL y sintaxis general de consulta de MySQL.
¿Qué es la optimización de MySQL?
No existe una definición claramente definida para el término Optimización de MySQL. Puede tener un significado diferente según la persona, el administrador, el grupo o la empresa. Para esta serie de artículos sobre la optimización de MySQL, definiremos la optimización de MySQL como: La configuración de un servidor MySQL o MariaDB que se ha configurado para evitar los cuellos de botella que se encuentran comúnmente y que se analizan en esta serie de artículos.
¿Qué es un cuello de botella?
Muy similar al cuello de una botella de refresco, un cuello de botella como término técnico es un punto en una aplicación o configuración de servidor donde una pequeña cantidad de tráfico o datos pueden pasar sin problemas. Sin embargo, un volumen mayor del mismo tipo de tráfico o datos se ve obstaculizado o bloqueado y no puede funcionar correctamente tal cual. Vea el siguiente ejemplo de un cuello de botella de configuración:
En este ejemplo, el servidor es capaz de manejar 10 conexiones simultáneamente. Sin embargo, la configuración solo acepta 5 conexiones. Este problema no se manifestaría siempre que hubiera 5 o menos conexiones a la vez. Sin embargo, cuando el tráfico aumenta hasta 10 conexiones, la mitad de ellas comienzan a fallar debido a los recursos no utilizados en la configuración del servidor. Los ejemplos anteriores ilustran la forma del cuello de botella de la que deriva su nombre frente a una configuración optimizada que corrige el cuello de botella.
¿Cuándo debo optimizar mi base de datos MySQL?
Idealmente, el ajuste del rendimiento de la base de datos debe realizarse con regularidad y antes de que la productividad se vea afectada. Es una práctica recomendada realizar auditorías semanales o mensuales del rendimiento de la base de datos para evitar que los problemas afecten negativamente a las aplicaciones. Los síntomas más evidentes de los problemas de rendimiento son:
- Las consultas se acumulan y nunca se completan en la tabla de procesos de MySQL.
- Las aplicaciones o los sitios web que usan la base de datos se vuelven lentos.
- Errores de tiempos de espera de conexión, especialmente durante las horas pico.
Si bien es normal que haya varias consultas simultáneas ejecutándose a la vez en un sistema ocupado, se convierte en un problema cuando estas consultas tardan demasiado en finalizar con regularidad. Aunque el umbral específico varía según el sistema y la aplicación, los tiempos de consulta promedio que exceden varios segundos se manifestarán como una ralentización dentro de las aplicaciones y los sitios web adjuntos. Estas ralentizaciones a veces pueden comenzar de a poco y pasar desapercibidas hasta que un gran aumento de tráfico llega a un cuello de botella en particular.
Identificación de problemas de rendimiento
Saber cómo examinar la tabla de procesos de MySQL es vital para diagnosticar el cuello de botella específico que se está encontrando. Hay varias formas de ver la tabla de procesos según su servidor y preferencia en particular. Para abreviar, esta serie se centrará en los métodos más comunes utilizados a través del acceso Secure Shell (SSH):
Método 1. Uso de la tabla de procesos de MySQL
Utilice el 'mysqladmin ' herramienta de línea de comando con la bandera 'processlist ' o 'proc ' para abreviar. (Agregando la bandera 'estadísticas ' o 'estadística ' para abreviar mostrará las estadísticas de ejecución de las consultas desde el último reinicio de MySQL).
Comando:
estadística de proceso de mysqladmin Salida:
+-------+------+-----------+-----------+---- -----+------+-------+ | identificación | Usuario | Anfitrión | base de datos | Comando | Tiempo | Estado | Información | Progreso | +-------+------+-----------+-----------+---------+ ------+-------+---------------------+----------+ | 77255 | raíz | servidor local | empleados | Consulta | 150 | | llamar a While_Loop2() | 0.000 | | 77285 | raíz | servidor local | | Consulta | 0 | inicio | mostrar lista de procesos | 0.000 | +-------+------+-----------+-----------+---------+ ------+-------+---------------------+----------+ Tiempo de actividad:861755 Subprocesos:2 Preguntas:20961045 Consultas lentas:0 Aperturas:2976 Vaciar tablas:1 Tablas abiertas:1011 Consultas por segundo promedio:24.323 Método 2:Uso de la tabla de procesos de MySQL
Ejecute la consulta 'show processlist;' desde el indicador del modo interactivo de MySQL. (Añadiendo la ' lleno ’ el modificador del comando deshabilita el truncamiento de Información columna . Esto es necesario cuando se visualizan consultas largas).
Comando:
mostrar lista de procesos; Salida:
MariaDB [(none)]> muestra la lista completa de procesos; +-------+------+-----------+-----------+---------+ ------+-------+-----------------------+----------+ | Identificación | Usuario | Anfitrión | base de datos | Comando | Tiempo | Estado | Información | Progreso | +-------+------+-----------+-----------+---------+ ------+-------+-----------------------+----------+ | 77006 | raíz | servidor local | empleados | Consulta | 151 | NULO | llamar a While_Loop2() | 0.000 | | 77021 | raíz | servidor local | NULO | Consulta | 0 | inicio | mostrar la lista completa de procesos | 0.000 | +-------+------+-----------+-----------+---------+ ------+-------+-----------------------+----------+ Uso del registro de consultas lentas
Otra herramienta valiosa en MySQL es la función de registro de consultas lentas incluida. Esta característica es el método preferido para encontrar consultas de ejecución prolongada con regularidad. Hay varias directivas disponibles para ajustar esta función. Sin embargo, las configuraciones más comúnmente necesarias son:
| slow_query_log | activar/desactivar el registro de consultas lentas |
| archivo_de_registro_consulta_lenta | nombre y ruta del archivo de registro de consultas lentas |
| tiempo_de_consulta_largo | tiempo en segundos/microsegundos definiendo una consulta lenta |
Estas directivas se establecen dentro de la sección [mysqld] del archivo de configuración de MySQL ubicado en /etc/my.cnf y requerirán un reinicio del servicio de MySQL antes de que surtan efecto. Vea el siguiente ejemplo para formatear:
Advertencia:existe un gran problema de espacio en disco con el archivo de registro de consultas lentas, que debe atenderse continuamente hasta que se deshabilite la función de registro de consultas lentas. Tenga en cuenta que cuanto menor sea la directiva long_query_time, más rápido llenará una partición de disco el registro de consultas lentas. motor=innodb innodb_buffer_pool_size=128M innodb_log_file_size=128M max_connections=300 key_buffer_size =8M slow_query_log=1 slow_query_log_file=/var/lib/mysql/slowquery.log long_query_time=5Una vez que el registro de consultas lentas esté habilitado, deberá realizar un seguimiento periódico para revisar las consultas rebeldes que deben ajustarse para un mejor rendimiento. Para analizar el archivo de registro de consultas lentas, puede analizarlo directamente para revisar su contenido. El siguiente ejemplo muestra las estadísticas de la consulta de muestra que duró más de los 5 segundos configurados:
PrecauciónSe ha producido un impacto en el rendimiento al habilitar la función de registro de consultas lentas. Esto se debe a las rutinas adicionales necesarias para analizar cada consulta, así como a la E/S necesaria para escribir las consultas necesarias en el archivo de registro. Debido a esto, se considera una buena práctica en los sistemas de producción deshabilitar el registro de consultas lentas. El registro de consultas lentas solo debe permanecer habilitado durante un tiempo específico cuando se buscan consultas problemáticas que puedan estar afectando la aplicación o el sitio web.# Time:180717 0:23:28 # User@Host:root[root] @ localhost [] # Thread_id:32 Schema:empleados QC_hit:No # Query_time:627.163085 Lock_time:0.000021 Rows_sent:0 Rows_examined:0 # Rows_affected:0 use empleados; ESTABLECER marca de tiempo =1531801408; llamar a While_Loop2(); Opcionalmente, puede usar la herramienta de línea de comandos mysqldumpslow, que analiza el archivo de registro de consultas lentas y agrupa consultas similares excepto valores de datos numéricos y de cadena:
~ $ mysqldumpslow -a /var/lib/mysql/slowquery.log Lectura del registro de consultas lentas de mysql desde /var/lib/mysql/slowquery.log Recuento:2 Tiempo=316,67 s (633 s) Bloqueo=0,00 s (0s) Rows_sent=0.5 (1), Rows_examined=0.0 (0), Rows_affected=0.0 (0), root[root]@localhost call While_Loop2() (Para obtener información sobre el uso, visite la documentación de MySQL aquí: mysqldumpslow:resumen de los archivos de registro de consultas lentas)
Conclusión
Así concluye la primera parte de nuestra serie de Optimización de base de datos y nos brinda una base sólida a la que referirnos con fines de evaluación comparativa. Aunque los problemas de la base de datos pueden ser complicados, nuestra serie desglosará estos conceptos para proporcionar medios para optimizar su base de datos a través de la conversión de bases de datos, la conversión de tablas y la indexación.
¿Cómo podemos ayudar?
¡Nos enorgullecemos de ser los seres humanos más serviciales en Hosting™!
Nuestros equipos de soporte están compuestos por técnicos experimentados en Linux y administradores de sistemas talentosos que tienen un conocimiento profundo de múltiples tecnologías de alojamiento web, especialmente las que se analizan en este artículo.
Si tiene alguna pregunta con respecto a esta información, siempre estamos disponibles para responder cualquier consulta con temas relacionados con este artículo, las 24 horas del día, los 7 días de la semana, los 365 días del año.
Si usted es un servidor VPS totalmente administrado, dedicado en la nube, nube privada de VMWare, servidor principal privado, servidores en la nube administrados o propietario de un servidor dedicado y no se siente cómodo con la realización de cualquiera de los pasos descritos, le se puede contactar por teléfono al @ 800.580.4985, un chat o un ticket de soporte para ayudarlo con este proceso.
