Mysql alto uso de ram

ricm · 7 Octubre 2024

Estimados, tengo un servidor web pequeñito que hasta hace poco andaba de lo mas tranqui. Cuando cambie version de linux, y de mysql 5.7 a 8, el consumo de ram se fue a las nubes.
Mi servidor corre apache, php y mysql.

Como soy nuevo no se por donde comenzar a atacar el problema así que aquí van unas capturas

Zuljin · 7 Octubre 2024

El paso de 5.7 a 8 es un cambio grande en cuanto a arquitectura así que es totalmente factible que coma más memoria.

¿Te es posible abrir un MySql Workbench y monitorear el estado de la memoria?

ricm · 7 Octubre 2024

Zuljin dijo:
El paso de 5.7 a 8 es un cambio grande en cuanto a arquitectura así que es totalmente factible que coma más memoria.

¿Te es posible abrir un MySql Workbench y monitorear el estado de la memoria?

No conocía el programa. Voy a instalar y ver que onda.

A priori, dirías que el nunero de procesos de mysqld es alto?

Zuljin · 7 Octubre 2024

Se ven hartos procesos la verdad pero evidentemente no tengo idea de la arquitectura de tu aplicación.

Estoy pensando en modo Oracle, pero creo que debe a que tu MySQL abre un proceso por cada llamada (dedicado) y puede existir alguna configuración que abre un proceso por cada X llamadas (dispatcher).

unreal4u · 8 Octubre 2024

40% de 1GB no es tanto, además parece tener el espacio para ocuparlos.

Me imagino que dp de la migración reiniciaste el proceso? Puede ser que durante la migración interna de data haya tenido que allocar más ram.

Saludos.

epic · 9 Octubre 2024

uhmm pero a priori igual tienes muy poca memoria ram... deberías comenzar buscando en la documentación los requisitos mínimos de mysql, pero supongo que la 8 debería consumir mas maquina que la 5.7.

stargeizer · 9 Octubre 2024

Si realmente es tu servidor, prueba agregando o modificando lo siguiente en tu my.cnf, apartado [mysqld]

Código:

performance_schema = 0
show_compatibility_56 = 1

Prueba con eso y cuentas que pasa. (Ojo, dependiendo de que distro usas, my.cnf puede estar hasta en 5 ubicaciones diferentes... mlocate/locate será tu amigo en este caso, supongo)

unreal4u · 9 Octubre 2024

epic dijo:
uhmm pero a priori igual tienes muy poca memoria ram... deberías comenzar buscando en la documentación los requisitos mínimos de mysql, pero supongo que la 8 debería consumir mas maquina que la 5.7.

no es tanto lo que requiere, tengo instancias de mysql corriendo con 256MB de RAM funcionando de lo más bien como en la pega que tiene 104GB en RAM:

Saludos.

unreal4u · 9 Octubre 2024

stargeizer dijo:
Si realmente es tu servidor, prueba agregando o modificando lo siguiente en tu my.cnf, apartado [mysqld]

Código:

performance_schema = 0 show_compatibility_56 = 1

Prueba con eso y cuentas que pasa. (Ojo, dependiendo de que distro usas, my.cnf puede estar hasta en 5 ubicaciones diferentes... mlocate/locate será tu amigo en este caso, supongo)

Para qué usar eso? :S pésimo consejo considerando que ni siquiera sabes cómo se ve su data, qué motor está ocupando ni cómo se ve su configuración actual :S Hay mucho que ganar por otros lados primero, pero... "depende".

Además, desactivando o activando esas opciones puede que sea contraproducente y que le dificulte el posterior análisis.

Saludos.

epic · 9 Octubre 2024

unreal4u dijo:
no es tanto lo que requiere, tengo instancias de mysql corriendo con 256MB de RAM funcionando de lo más bien como en la pega que tiene 104GB en RAM:

Ver adjunto 38509

Saludos.

pero también dependerá de tu aplicación, por ejemplo de como hace las consultas, que tan pesadas sean las querys, etc.... Ahora no se cuanto era el consumo antes de upgradear a la versión 8.
Seria bueno que analizara si el aumento del consumo es por algunas consultas en particular , fijarse cuales son y ver si se pueden optimizar.
Lo otro, quizás anteriormente en la 5.7 tenia configuraciones de cache y buffer y ahora no las tiene.

Por otro lado la versión 8 debería consumir mas recursos que la 5.7, en detalle no se que % pero eso habría que sumarlo.

PD: Otro punto... quizas tus memorias son mas eficientes que las de @ricm

stargeizer · 9 Octubre 2024

unreal4u dijo:
unreal4u dijo:

Para qué usar eso? :S pésimo consejo considerando que ni siquiera sabes cómo se ve su data, qué motor está ocupando ni cómo se ve su configuración actual :S Hay mucho que ganar por otros lados primero, pero... "depende".

Además, desactivando o activando esas opciones puede que sea contraproducente y que le dificulte el posterior análisis.

Saludos.

Haz clic para expandir...

Normalmente estaría de acuerdo contigo, pero si lo que busca en su servidor "pequeño" (por lo que el OP indica, asumo que 1 GB de RAM en estos días lo es), entonces lo que se puede intentar es usar el modo de compatibilidad con mysql 5.6.

Deshabilitar performance_schema disminuirá el consumo de RAM, a costa de un uso mayor de disco duro.
usar show_compatibility_56, hará que la base de datos que se este usando use la compatibilidad con mysql 5.6, que usa menos recursos que el motor nuevo de mysql 5.8-8.xx

Ambas opciones juntas deberían devolverle alrededor de un 50-60% de RAM usada, que es lo que se persigue en este caso, sin tener que recurrir a métodos más invasivos.

Si este método funciona, lo mas seguro es que sea debido a que Mysql 5.7-8.xx dejaron de usar Jemalloc como gestor de memoria, y en su lugar, usan el gestor de memoria provisto por glibc, y es un hecho conocido que la librería glibc tiende a privilegiar velocidad de acceso a los datos, a costa de un mayor uso de RAM.

unreal4u · 9 Octubre 2024

stargeizer dijo:
Normalmente estaría de acuerdo contigo, pero si lo que busca en su servidor "pequeño" (por lo que el OP indica, asumo que 1 GB de RAM en estos días lo es), entonces lo que se puede intentar es usar el modo de compatibilidad con mysql 5.6.

Deshabilitar performance_schema disminuirá el consumo de RAM, a costa de un uso mayor de disco duro.
usar show_compatibility_56, hará que la base de datos que se este usando use la compatibilidad con mysql 5.6, que usa menos recursos que el motor nuevo de mysql 5.8-8.xx

Ambas opciones juntas deberían devolverle alrededor de un 50-60% de RAM usada, que es lo que se persigue en este caso, sin tener que recurrir a métodos más invasivos.

Si este método funciona, lo mas seguro es que sea debido a que Mysql 5.7-8.xx dejaron de usar Jemalloc como gestor de memoria, y en su lugar, usan el gestor de memoria provisto por glibc, y es un hecho conocido que la librería glibc tiende a privilegiar velocidad de acceso a los datos, a costa de un mayor uso de RAM.

A ver... a lo que voi es: para qué? A largo plazo esos hacks sólo le producirán más dolores de cabeza en cuanto a mantención futura: significa más dolores de cabeza por algo que "quizás" funcione como un parche?

La RAM está para ser ocupada y el servidor en sí parece estar corriendo bien, de hecho todavía le queda un 40% de espacio. Lo único que sí haría es habilitar un poco de swap ya que si se queda sin RAM se para el equipo por completo, pero sin métricas más completas es difícil saber si esto fue algo temporal (migración de 5.7 a 8.0) o algo establecido, por algo pregunté si había reiniciado mysql dp de la migración: he visto que en estos casos es probable que haya ocupado mucha más ram que lo que ocuparía de costumbre por el simple hecho de quizás haber tenido que meter todas las tablas a RAM de forma temporal por la migración de datos, aquí estaba jugando con un dataset y apliqué una migración que ocupaba cerca de 600MB de RAM, dp de reiniciar el servicio el consumo estable bajó a unos 300MB:

(dp de eso me puse a jugar con otras cosas y le di más RAM a ese equipo, pero como dije, era para jugar con la db)

---

Así que primero: reiniciar mysql y habilitar swap. Ver dp de un par de días el consumo de RAM. Sólo si el OP considera que el consumo de RAM sigue siendo excesivo y le produce problemas empezar a meter mano tuneando la base: dependiendo del motor que ocupe (innodb? myisam?) empezar a jugar con eso para empezar a aprender tb el cómo se comporta la base de datos a fin de obtener los resultados más rápidos posibles con la menor cantidad de recursos posibles.

Deshabilitr el performance_schema es como cortarse las manos pq en ese momento estás pedaleando con los pies. Claro, no las necesitas... pero cuando las necesites ese tesoro en datos no estará: lo peor de todo es que es el futuro y no lo sacarán, así que suerte con tratar de entender cómo se comporta tu db sin esos datos: es un parche más que una solución.

Saludos.

ricm · 9 Octubre 2024

Hola a todos, estoy leyendo sus respuestas y se las agradezco mucho.

El sitio es una especie de wiki hecha por mi, con los problemas que ello puede llevar con respecto a la calidad del codigo. Recibe algo asi como 1000 visitas de google al dia. El sitio anda bien y rapido, pero cuando quiero hacer por ejemplo apt update o upgrade, se demora muchisimo, asumo por falta de ram.

En estoy momentos estoy instalando mysql workbench que recomendo zuljin, y ademas instale ya mysqltuner en el servidor. Que mas podria ser de utilidad postear?

sudo mysqltuner
>> MySQLTuner 1.7.13 - Major Hayden <[email protected]>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering

[--] Skipped version check for MySQLTuner script
[OK] Logged in using credentials from Debian maintenance account.
[!!] Currently running unsupported MySQL version 8.0.39-0ubuntu0.20.04.1
[OK] Operating on 64-bit architecture

-------- Log file Recommendations ------------------------------------------------------------------
[--] Log file: /var/log/mysql/error.log(0B)
[OK] Log file /var/log/mysql/error.log exists
[OK] Log file /var/log/mysql/error.log is readable.
[!!] Log file /var/log/mysql/error.log is empty
[OK] Log file /var/log/mysql/error.log is smaller than 32 Mb
[OK] /var/log/mysql/error.log doesn't contain any warning.
[OK] /var/log/mysql/error.log doesn't contain any error.
[--] 0 start(s) detected in /var/log/mysql/error.log
[--] 0 shutdown(s) detected in /var/log/mysql/error.log

-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA
[--] Data in InnoDB tables: 11.4M (Tables: 67)
[OK] Total fragmented tables: 0

-------- Analysis Performance Metrics --------------------------------------------------------------
[--] innodb_stats_on_metadata: OFF
[OK] No stat updates during querying INFORMATION_SCHEMA.

-------- Security Recommendations ------------------------------------------------------------------
[--] Skipped due to unsupported feature for MySQL 8

-------- CVE Security Recommendations --------------------------------------------------------------
[OK] NO SECURITY CVE FOUND FOR YOUR VERSION

-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 1d 19h 34m 59s (203K q [1.297 qps], 52K conn, TX: 54M, RX: 22M)
[--] Reads / Writes: 99% / 1%
[--] Binary logging is enabled (GTID MODE: OFF)
[--] Physical Memory : 965.1M
[--] Max MySQL memory : 459.1M
[--] Other process memory: 343.6M
[--] Total buffers: 176.0M global + 1.9M per thread (151 max threads)
[--] P_S Max memory usage: 72B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 237.9M (24.65% of installed RAM)
[OK] Maximum possible memory usage: 459.1M (47.57% of installed RAM)
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 0% (0/203K)
[OK] Highest usage of available connections: 21% (33/151)
[!!] Aborted connections: 3.02% (1602/52981)
[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[--] Query cache have been removed in MySQL 8
[OK] Sorts requiring temporary tables: 0% (50 temp sorts / 21K sorts)
[!!] Joins performed without indexes: 1403
[OK] Temporary tables created on disk: 0% (0 on disk / 55K total)
[OK] Thread cache hit rate: 99% (33 created / 52K connections)
[OK] Table cache hit rate: 92% (1K open / 1K opened)
[OK] Open file limit used: 0% (6/10K)
[OK] Table locks acquired immediately: 100% (206 immediate / 206 locks)
[OK] Binlog cache memory access: 100.00% (194 Memory / 194 Total)

-------- Performance schema ------------------------------------------------------------------------
[--] Memory used by P_S: 72B
[--] Sys schema is installed.

-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is disabled.

-------- MyISAM Metrics ----------------------------------------------------------------------------
[!!] Key buffer used: 18.2% (3M used / 16M cache)
[!!] Cannot calculate MyISAM index size - re-run script as root user

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 0
[OK] InnoDB File per table is activated
[OK] InnoDB buffer pool / data size: 128.0M/11.4M
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (75 %): 48.0M * 2/128.0M should be equal 25%
[OK] InnoDB buffer pool instances: 1
[--] Number of InnoDB Buffer Pool Chunk : 1 for 1 Buffer Pool Instance(s)
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 99.99% (29725025 hits/ 29726987 total)
[!!] InnoDB Write Log efficiency: 60.95% (2065 hits/ 3388 total)
[OK] InnoDB log waits: 0.00% (0 waits / 1323 writes)

-------- AriaDB Metrics ----------------------------------------------------------------------------
[--] AriaDB is disabled.

-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.

-------- XtraDB Metrics ----------------------------------------------------------------------------
[--] XtraDB is disabled.

-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.

-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] Binlog format: ROW
[--] XA support enabled: ON
[--] Semi synchronous replication Master: Not Activated
[--] Semi synchronous replication Slave: Not Activated
[--] This is a standalone server

-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
Reduce or eliminate unclosed connections and network issues
Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
Adjust your join queries to always utilize indexes
Before changing innodb_log_file_size and/or innodb_log_files_in_group read this: https://bit.ly/2TcGgtU
Variables to adjust:
join_buffer_size (> 256.0K, or always use indexes with JOINs)
innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.

Tambien se la siguiente imagen presumo que quedan conexiones abiertas durante mucho tiempo no? lo digo por la duracion de tantos procesos mysqld. Asumo que 1 proceso = 1 conexion aunque no se si es asi.

Zuljin · 9 Octubre 2024

Coincido con @unreal4u : la memoria está para usarse aunque veo que estás justito: sobre el 75% de RAM utilizada. ¿Puedes asignarle un poquito más?

La cantidad de procesos no le afecta a la máquina porque de lo contrario estarías sufriendo por alto consumo de CPU (lo cual no es el caso). Además no estás llegando al límite según lo que veo en tu status

[OK] Highest usage of available connections: 21% (33/151)

Lo que si me llama la atención es esto

[!!] Joins performed without indexes: 1403

Me sorprende que los desarrolladores de wiki sean tan laxos para meter índices pero bueno, pasa hasta en las mejores familias.

ricm · 9 Octubre 2024

Zuljin dijo:
Coincido con @unreal4u : la memoria está para usarse aunque veo que estás justito: sobre el 75% de RAM utilizada. ¿Puedes asignarle un poquito más?

La cantidad de procesos no le afecta a la máquina porque de lo contrario estarías sufriendo por alto consumo de CPU (lo cual no es el caso). Además no estás llegando al límite según lo que veo en tu status

[OK] Highest usage of available connections: 21% (33/151)

Lo que si me llama la atención es esto

[!!] Joins performed without indexes: 1403

Me sorprende que los desarrolladores de wiki sean tan laxos para meter índices pero bueno, pasa hasta en las mejores familias.

Siii pero eso es mi culpa en todo caso =(
He creado indices, todo parece indicar que alguno me quedo malo, o olvidado. No se me ocurre como saber cual es el que falta puntualmente o que query es la problematica. Solo se me ocurre con slow query log pero podria pescar cualquier cosa.

ricm · 9 Octubre 2024

Mirando mis query que usen JOIN me encontre con esto:
Es una función para elegir un tema al azar que se ejecuta en cada visita, según mi seria extraño tener un indice en esto no?

PHP:

function azar($limit)
{
    global $conexion;
    $sql = "SELECT palabra FROM articulos AS r1 JOIN (SELECT (RAND() * (SELECT MAX(id) FROM articulos)) AS id) AS r2 WHERE r1.id >= r2.id ORDER BY r1.id ASC LIMIT $limit";
    $result = $conexion->query($sql);
    $row = $result->fetch_all(MYSQLI_ASSOC);
    if ($result->num_rows > 0) {
        return $row;
    } else {
        return false;
    }
}

epic · 9 Octubre 2024

en temas de programación no cacho mucho... pero claramente:

1.- optimizar tus consultas
2.- Tunnear la conf de mysql
3.- No le puedes asignar mas memoria ram a la maquina ???

unreal4u · 9 Octubre 2024

ricm dijo:
Mirando mis query que usen JOIN me encontre con esto:
Es una función para elegir un tema al azar que se ejecuta en cada visita, según mi seria extraño tener un indice en esto no?

PHP:

function azar($limit) { global $conexion; $sql = "SELECT palabra FROM articulos AS r1 JOIN (SELECT (RAND() * (SELECT MAX(id) FROM articulos)) AS id) AS r2 WHERE r1.id >= r2.id ORDER BY r1.id ASC LIMIT $limit"; $result = $conexion->query($sql); $row = $result->fetch_all(MYSQLI_ASSOC); if ($result->num_rows > 0) { return $row; } else { return false; } }

Ejecuta esa query en mysql workspace con un EXPLAIN delante del select y pastea la salida.

Saludos.

unreal4u · 9 Octubre 2024

ricm dijo:
Mirando mis query que usen JOIN me encontre con esto:
Es una función para elegir un tema al azar que se ejecuta en cada visita, según mi seria extraño tener un indice en esto no?

PHP:

function azar($limit) { global $conexion; $sql = "SELECT palabra FROM articulos AS r1 JOIN (SELECT (RAND() * (SELECT MAX(id) FROM articulos)) AS id) AS r2 WHERE r1.id >= r2.id ORDER BY r1.id ASC LIMIT $limit"; $result = $conexion->query($sql); $row = $result->fetch_all(MYSQLI_ASSOC); if ($result->num_rows > 0) { return $row; } else { return false; } }

Pd: esa conexión global puede que esté dejando abierto las conexiones, tb con mysql workspace puedes ver cuáles clientes están conectados y qué están haciendo.

Puedes probar eliminando esa query de forma temporal y revisando qué tal anda dp de un par de días. Wiki está hecho para servir cantidades industriales de datos así que ellos deben tener sus estructuras y conexiones bien definidos y en orden.

Y por último... Reiniciaste mysql dp del upgrade inicial?

Saludos.

Soza · 9 Octubre 2024

PID 0 dando problemas como siempre al no poder reasignar bien los recursos cuando son pocos.

Mysql alto uso de ram

☭

Fundador

☭

Fundador

I solve problems.

Pro

Who cares?

I solve problems.

I solve problems.

Pro

Who cares?

I solve problems.

☭

Fundador

☭

☭

Pro

I solve problems.

I solve problems.

Linux