Mysql alto uso de ram

muy weno el mysqltunner siempre da buenas observaciones
Solo me llama la atención porque de la actualización, solo por nueva versión?

Al final que hiciste? xD

pregunta:
que motor esta usando? innodb o myisam ?

en la configuracion que cantidad tiene definida en el buffer de innodb ? por defecto a veces puede quedar en 512MB, y si la db pesa eso o mas, perfectamente tratara de subir la mayor cantidad de datos a la ram.

el tema de la consulta variada y random puede aplicar si trata de filtrar por datos no indizados, lo que provocara que se lea la tabla completa de disco a memoria para hacer el filtado.

se ven consultas o conexiones pegadas/funcionando en la consola? lease : show processlist:

los "subprocesos" que se visualizan en Htop puede que sean hilos secundarios de mysql, que pueden ser conexiones activas o queryes en ejecucion, asi que con el comando anterior en mysql deberia indicarte como esta funcionando y que esta corriendo en el momento.

dato: en HTOP puedes usar la tecla H para activar/desactivar la vista de "threads", y asi ver los recursos unificados por proceso unico

ricm dijo:

Si reinicié. Comenzó usando menos ram pero fue subiendo durante el día.

Igual el sitio no anda mal, quizás es un poco la ansiedad de ver la ram usada finalmente.

Haz clic para expandir...

igual 1GB es poquito para estandares actuales, quizas debas mirar la conf y ver los tamaños de bufferes y caches de querys
tambien noto que no tienes Swap , y con esa cantidad de Ram quizas te convenga agregar unos 4 GB de memoria swap en un archivo:

asi movera paginas sin usar a la swap y liberara memoria para procesos en uso (igual puede ser necesario definir el nivel de cacheado y swappiness )

Hot take: hoy en día para bases pequeñas y con baja concurrencia es mejor usar SQLite

Aerodynamic dijo:

Hot take: hoy en día para bases pequeñas y con baja concurrencia es mejor usar SQLite

Haz clic para expandir...

Siempre y cuando no necesites transacciones o la consistencia de una base de datos relacional.

Y no es un hot-take, SQLite tiene su espacio, sobretodo en ambientes donde se leen muchos datos pero no se escriben de vuelta: por algo tb está embebido en un montón de software: firefox y Chrome por ejemplo lo ocupan para guardar datos, mientras que Windows 10 y Android lo ocupan para lo mismo, pero a nivel de OS.

Así que como ves, SQLite no es tan impopular, lo que pasa es que está más escondido jajajaj

En el caso de la wiki, dudo que tengan una conexión disponible para SQLite y si la tienen, debe ser para guardar otro tipo de datos y no necesariamente el de los artículos.

Saludos.

epic dijo:

Al final que hiciste? xD

Haz clic para expandir...

Disminuir la cantidad de consultas a la base pesada usando una segunda base de datos más liviana para las funciones que no necesiten detalles.

Uso más extensivo en php de mysql close(), no se si esto sea buena idea pero estoy probando.

Active slow query log y no encontró nada sobre 3 segundos, salvo ciertas operaciones muy puntuales qué hice yo a mano.

Show processlist usualmente esta vacío pq las consultas son respondidas casi instantáneamente.

Las bases son innodb.


Igual mi sospecha principal es que algo extraño ocurrió en el cambio de versiones de sql, como configuraciones no óptimas arrastradas de versiones anteriores por ejemplo, aunque no he podido pillar cual, ni he tenido el tiempo de hacer una instalación limpia.

y el buffer innodb en cuanto estaba ?
si no esta definido en la conf, se puede obtener desde la consola de mysql

tambien revisar el tamaño de las caches de temporales y querys, aunque si no son muy grandes no se deberian llenar demasiado.

el tema de cerrar las conexiones esta bien, no es sano mantener conexiones activas si no se van a utilizar (conectar, hacer todas las consultas utiles, entregar resultado, cerrar conexion ), pero tambien puede variar si es que hay mas tareas en paralelo