Descripción de la simultaneidad de subprocesos
Cada conexión de cliente tiene su propio subproceso, y las consultas se ejecutan dentro de ese subproceso. Cada subproceso se ejecuta en un único núcleo. La simultaneidad es el número de subprocesos que se pueden ejecutar al mismo tiempo. De forma predeterminada, el motor de almacenamiento InnoDB ejecutará tantos subprocesos simultáneamente como sea necesario.
InnoDB administra la simultaneidad de subprocesos mediante varios parámetros del servidor. Dos parámetros regulan el número de subprocesos simultáneos:
- innodb_thread_concurrency
- innodb_thread_sleep_delay
El valor predeterminado de innodb_thread_concurrency es cero, lo que significa que InnoDB no impone un límite para el número de subprocesos que se ejecutan simultáneamente. Por lo general, se recomienda no cambiar este parámetro a menos que necesite imponer un límite para el número de subprocesos simultáneos que se pueden ejecutar en cualquier momento.
En el caso de las bases de datos con una carga de trabajo especialmente alta, o cuando sospecha que la simultaneidad es la causa de un rendimiento deficiente, puede imponer un límite para el número de subprocesos que se ejecutan simultáneamente. Un punto de partida consiste en establecer innodb_thread_concurrency en el mismo número, o dos veces el número de núcleos disponibles. Cada consulta solo se puede ejecutar en un núcleo, pero el tiempo de ejecución será extremadamente rápido.
Si un subproceso no se puede ejecutar porque innodb_thread_concurrency ha alcanzado su límite, innodb_thread_sleep_delay define el número de microsegundos que el subproceso espera antes de intentar ejecutarse de nuevo. El valor predeterminado es 10 000 microsegundos. Si el subproceso no puede ejecutarse la segunda vez que lo intenta, se coloca en una cola de subprocesos. El valor de innodb_thread_sleep_delay será correcto para la mayoría de las cargas de trabajo; solo si ejecuta un número extremadamente elevado de consultas muy pequeñas, este valor podría ser demasiado grande y provocar latencia. Sin embargo, antes de cambiar el valor, considere la posibilidad de establecer innodb_adaptive_max_sleep_delay.
innodb_adaptive_max_sleep_delay permite a InnoDB ajustar el valor de innodb_thread_sleep_delay en función de la carga de trabajo actual. El valor predeterminado de innodb_adaptive_max_sleep_delay es 15 000 microsegundos. El retraso del sueño se ajustará hacia arriba o hacia abajo, hasta este máximo.
Sugerencia
Si se ejecuta en hardware adecuado y en la versión 8.0 o posterior de MySQL, es probable que no tenga que cambiar los parámetros de simultaneidad. Si no se ejecuta en la última versión de MySQL, actualice a la última versión antes de ajustar los parámetros de simultaneidad.
Nota:
Al ejecutar hardware local, es difícil comprar nuevo hardware para resolver cuellos de botella de simultaneidad. En estos escenarios, la mejor solución podría ser particionar los datos.
Con Azure Database for MySQL, puede actualizar el nivel de proceso de forma fácil y rentable.
Para las consultas de larga duración, el parámetro innodb_concurrency_tickets define el número de "vales", o la cantidad de trabajo se puede realizar sin realizar más comprobaciones de simultaneidad. Si tiene muchas consultas de larga duración, puede que desee ajustar este valor. Sin embargo, para la mayoría de las cargas de trabajo, no es necesario cambiar este valor.
Por último, el parámetro innodb_commit_concurrency define cuántos subprocesos se pueden confirmar al mismo tiempo. Si ha establecido el valor de innodb_thread_concurrency para limitar el número de subprocesos que se pueden ejecutar simultáneamente, el ajuste de innodb_commit_concurrency en un valor bajo puede resultar más útil. El valor predeterminado es 0, lo que permite que cualquier número de subprocesos se confirmen simultáneamente.
Todos estos parámetros se pueden mostrar y modificar en Azure Portal, en Parámetros del servidor, o mediante la CLI de Azure.
Desde MySQL Workbench puede ver el número de subprocesos creados, el número de subprocesos conectados y el número de subprocesos en ejecución.
Para ver las conexiones de cliente en MySQL Workbench:
- Conéctese al servidor MySQL mediante una conexión con nombre existente o creando una conexión.
- MySQL Workbench se conecta al servidor y abre una pestaña Consulta.
- Seleccione la pestaña Administración.
- En Administración, seleccione Conexiones de cliente. Se proporcionan las métricas siguientes:
- Subprocesos conectados
- Subprocesos en ejecución
- Subprocesos creados
- Subprocesos almacenados en caché
- Total de conexiones
- Límite de conexiones
- Clientes anulados
- Conexiones anuladas
Limitación de conexiones de cliente
MySQL normalmente se ocupa de tantas conexiones de cliente como sea necesario. Sin embargo, si se realizan demasiadas conexiones, cada consulta en ejecución, el tiempo de ejecución puede ralentizarse, hasta que todas las consultas tardan demasiado tiempo en finalizar. Este es el problema de la manada enorme: se agregan nuevas conexiones mientras que las conexiones existentes no se pueden ejecutar en un tiempo razonable.
Azure Database for MySQL permite limitar el número de conexiones al servidor. Este número se muestra en MySQL Workbench como Límite de conexiones y también es un parámetro de Azure Database for MySQL en Parámetros del servidor denominado max_connections. Cuando el número de conexiones alcanza este límite, el servidor no conectará más usuarios hasta que se anule el número de conexiones. Se trata de una protección contra la sobrecarga del servidor y provoca que las consultas tarden un tiempo inaceptable en ejecutarse.
Para cambiar el valor de max_connections, vaya a Azure Portal, vaya al servidor de Azure Database for MySQL y seleccione Parámetros del servidor. En la barra de búsqueda, escriba max_connections para mostrar o editar el valor de max_connections.
Establezca max_connections en 1x, 2x o 4x los núcleos de CPU disponibles. Duplique el número de max_connections hasta que el número de transacciones por segundo ya no aumente. Una vez que la latencia comienza a aumentar, sabe que el número de conexiones no limita el rendimiento.