Estamos ejecutando Maria DB 10.6.9 en CentOS y observamos que continúa aumentando el uso de memoria. Especificaciones del servidor: RAM - 128 GB vCPU - 48 Swap - 100 GB
Hemos configurado innodb_buffer_pool a 65 GB
Sin embargo, el uso de la memoria es el siguiente actualmente:
Y seguimos viendo que el intercambio continúa aumentando.
El servidor está dedicado a Mariadb y no se ejecutan otras aplicaciones que no sean Mariadb.
Nuestras cargas disminuyen por la noche, pero no parece que veamos a MariaDB recuperarse ni liberar memoria.
Tenemos un servidor de base de datos similar que ejecuta MySQL 5.7.38 y no vemos ningún problema similar.
Cualquier idea que pueda ayudarnos a comprender lo siguiente será muy apreciada:
- ¿Para qué se utiliza la memoria dentro de mariadb?
- ¿Qué tablas están cargadas en la memoria que podrían estar provocando un mayor uso de la memoria?
- ¿Cómo analizar más a fondo cualquier herramienta que pueda darnos una idea del uso de la memoria de mariadb?
¿Alguna otra información que pueda necesitar para ayudarle a comprender mejor nuestra situación?
A continuación encontrará el estado de Innodb a partir de ahora: Estado de InnoDB
[Se solicita información adicional]
R:https://justpaste.it/cs5vw
B:https://justpaste.it/9868l
C:https://justpaste.it/8q99c
D:https://justpaste.it/byhv5
MI:https://justpaste.it/cgnum
GRAMO:https://justpaste.it/ba5if
ARRIBA:https://justpaste.it/dd57f
Información adicional Parte 2
1)https://jpst.it/30ItC- arriba -b -n 1
2)https://jpst.it/30OBo- arriba -b -n 1 -H
3)https://jpst.it/30OGm- ulimit -a
4)https://jpst.it/30OKb- iostato -xm 5 3
5)https://jpst.it/30OME- gl -h
6)https://jpst.it/30OPx- gratis -h
7)https://jpst.it/30OQF- gato /proc/meminfo
8)https://jpst.it/30OTB- df -yo
Respuesta1
Posibles causas de utilización de la memoria.
Generalmente vemos recuentos equilibrados en com_perpare_sql, com_execute_sql y com_dealloc_sql. En su programa, el estado global com_dealloc_sql (cerrar) se perdió 151,033 veces, lo que significa que los recursos no se liberaron en 36 días.
Generalmente vemos recuentos equilibrados en com_stmt_prepare, com_stmt_execute y com_stmt_close. En el estado global de su programa, com_stmt_close se perdió 373,474 veces, lo que significa que los recursos no se liberaron en 36 días.
Hubo 68.677 eventos de clientes abortados contados a un ritmo de 78 por hora que podrían estar contribuyendo a la observación.
A veces se puede evitar el recuento de com_rollback de 117,323 con un promedio de reversión cada 27 segundos. El procesamiento de reversión requiere muchos recursos. Busque 'cómo evitar la reversión de MySQL'.
Ver perfil para información de contacto, por favor. Muchas variables globales podrían ajustarse para mejorar el rendimiento.