Gestión de memoria MySQL, asignadores de memoria y sistema operativo

Cuando los usuarios experimentan problemas de uso de memoria con cualquier software, incluido MySQL®, su primera respuesta es pensar que es un síntoma de pérdida de memoria. Como esta historia mostrará, este no es siempre el caso.

Esta historia es sobre un error.

Todos los clientes de Soporte de Percona son elegibles para las correcciones de errores, pero sus opciones varían. Por ejemplo, a los clientes Advanced + se les ofrece una compilación HotFix antes del lanzamiento público del software con el parche. Los clientes Premium ni siquiera necesitan usar el software Percona: podemos llevar nuestros parches upstream para ellos. Pero para los productos Percona, todos los niveles de Soporte tienen derecho a tener una solución.

Sin embargo, esto no significa que corregiremos cualquier comportamiento inesperado, incluso si aceptamos que ese comportamiento es un error válido. Una de las razones de tal decisión podría ser que, si bien el comportamiento es claramente incorrecto para los productos Percona, sigue siendo una cuestión de funcionalidad.

Un error como un caso de estudio

Un buen ejemplo reciente de tal caso es PS-5312 – el error es repetible con upstream y se informa a bugs.mysql.com/95065

Esto informa una situación en la que el acceso al índice de texto completo de InnoDB conduce a un aumento en el uso de la memoria. Comienza cuando alguien consulta un índice de texto completo, crece al máximo y no se publica durante mucho tiempo.

Yura Sorokin por el equipo de ingeniería de Percona investigó si se trata de una fuga de memoria y descubrió que no lo es.

Cuando InnoDB resuelve una consulta de texto completo, crea mucha memoria en la función
fts_query_frase_búsqueda Este archivo puede crecer hasta 80 MB. Además, tiene una gran cantidad de bloques (
mem_block_t ) que no siempre se utilizan de forma continua y esto, a su vez, conduce a la fragmentación de la memoria.

En función
salga , el chip de memoria se libera. InnoDB hace esto para cada uno de los bloques asignados. Al final de la función, llame
gratis() que pertenece a una de las bibliotecas de asignación de memoria, como
Malluc o
jemalloc
. si tu
mysqld desde el punto de vista, todo está bien hecho: no hay pérdida de memoria.

Sin embargo, mientras
gratis() debe liberar memoria cuando se le llama, no hay necesidad de devolverlo al sistema operativo. Si el asignador de memoria decide que pronto se requerirán los mismos bloques de memoria, aún se puede mantener
mysqld proceso. Esto explica por qué puedes ver esto.
mysqld siempre usa mucha memoria después de que finaliza el trabajo y se realizan todas las desasignaciones.

Esto en la práctica no es un gran problema y no debería causar daños. Pero si necesita que la memoria regrese al sistema operativo más rápido, también puede probar asignadores de memoria alternativos. jemalloc. Este último se ha intentado solucionar el problema con PS-5312.

Otro factor que mejora la gestión de la memoria es la cantidad de núcleos de la CPU: cuanto más usamos para probar, más rápido se devuelve la memoria al sistema operativo. Esto probablemente se puede explicar por el hecho de que si tiene varias CPU, el asignador de memoria puede dedicar una de ellas solo para liberar memoria para el sistema operativo.

La primera implementación del índice de texto completo de InnoDB introdujo esta falla. Como nuestro ingeniero Yura Sorokin encontrar:

Opciones de reparación

Tenemos algunas opciones para arreglar esto:

  1. Cambiar la implementación del índice de texto completo de InnoDB
  2. Use una biblioteca de memoria personalizada como jemalloc

Ambos tienen sus ventajas y desventajas.

Opción 1 significa que estamos introduciendo una incompatibilidad ascendente, lo que puede generar errores extraños en versiones futuras. Esto también significa una reescritura completa del código de texto completo de InnoDB, que siempre es arriesgado en las versiones GA, utilizadas por nuestros clientes.

opcion 2 significa que podemos detectar fallas en el jemalloc biblioteca que está diseñada para el rendimiento y no para una asignación de memoria más segura.

Así que tenemos que elegir entre estas dos soluciones no ideales.

Entonces Opción 1 puede dar lugar a una situación en la que Percona Server sea incompatible con el upstream, preferimos opcion 2 y espere la corrección de este error en sentido ascendente.

Conclusiones

Si usted es un alto uso de memoria por el
mysqld proceso, no siempre es un síntoma de una pérdida de memoria. Puede usar la herramienta de memoria en Performance Scheme para saber cómo usar la memoria asignada. Pruebe bibliotecas de memoria alternativas para una mejor asignación de memoria y asignación de memoria. Buscar en el manual de usuario
LD_PRECARGA para saber cómo encajan en estas páginas aquí y aquí.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario