Tengo un problema con el uso de CPU en el sitio web que usa WordPress, Apache y MySQL. Durante el día, de vez en cuando, el uso de la CPU por parte de MySQL y Apache sube hasta el 2400% (tengo 24 núcleos en total), el servidor se congela y la carga promedio sube a 24.
Recientemente, hubo un poco más de tráfico de lo habitual, pero esto no debería ser permanente, ¿verdad? Actualicé el kernel, la base de datos, las bibliotecas y reinicié muchas veces. Y aun así se congela. He mirado la lista de procesos de la base de datos, pero no hay nada extraordinario. En la base de datos hay cantidades bastante grandes de datos. Hace apenas un par de semanas funcionaba bien y ahora no. Por lo tanto, no deberían ser consultas no optimizadas.
¿Cuáles pueden ser las causas de tal comportamiento?
Actualizar:
el resultado de A) MOSTRAR ESTADO GLOBAL COMO 'com_%r%_table';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Com_alter_table | 5 |
| Com_create_table | 34 |
| Com_drop_table | 0 |
| Com_rename_table | 0 |
| Com_show_create_table | 0 |
+-----------------------+-------+
5 rows in set (3.04 sec)
B) MOSTRAR ESTADO GLOBAL COMO '% de tiempo de actividad';
+---------------------------+--------+
| Variable_name | Value |
+---------------------------+--------+
| Uptime | 455524 |
| Uptime_since_flush_status | 455524 |
+---------------------------+--------+
2 rows in set (0.01 sec)
C) MOSTRAR ESTADO GLOBAL COMO '%dirty%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_dirty | 0 |
| Innodb_buffer_pool_bytes_dirty | 0 |
+--------------------------------+-------+
2 rows in set (0.00 sec)
ps todavía tengo problemas con el servidor. Necesitaba cambiar el juego de caracteres en una de las bases de datos y me llevó poco más de un día terminarlo, con sólo 400.000 filas. Antes me llevaba algo de tiempo, pero no tanto. Me preguntaba, ¿podría ser que después del ataque DDOS, pueda haber algunos cambios en la base de datos, de modo que funcione peor?
Actualización 2:
resultados de mysqltuner:
[--] Skipped version check for MySQLTuner script
[OK] Logged in using credentials from Debian maintenance account.
[OK] Currently running supported MySQL version 8.0.26-0ubuntu0.20.04.2
[OK] Operating on 64-bit architecture
-------- Log file Recommendations ------------------------------------------------------------------
[OK] Log file /var/log/mysql/error.log exists
[--] Log file: /var/log/mysql/error.log(0B)
[--] Log file /var/log/mysql/error.log is empty. Assuming log-rotation. Use --server-log={file} for explicit file
-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA
[--] Data in InnoDB tables: 262.4G (Tables: 179)
[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: 5d 11h 4m 6s (15M q [31.945 qps], 191K conn, TX: 80G, RX: 2G)
[--] Reads / Writes: 99% / 1%
[--] Binary logging is enabled (GTID MODE: OFF)
[--] Physical Memory : 31.4G
[--] Max MySQL memory : 9.8G
[--] Other process memory: 0B
[--] Total buffers: 176.0M global + 65.1M per thread (151 max threads)
[--] P_S Max memory usage: 72B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 9.8G (31.14% of installed RAM)
[OK] Maximum possible memory usage: 9.8G (31.14% of installed RAM)
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 0% (0/15M)
[!!] Highest connection usage: 100% (151/151)
[OK] Aborted connections: 0.09% (174/191712)
[!!] 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% (0 temp sorts / 5M sorts)
[OK] No joins without indexes
[OK] Temporary tables created on disk: 0% (0 on disk / 2M total)
[OK] Thread cache hit rate: 92% (15K created / 191K connections)
[OK] Table cache hit rate: 99% (21M hits / 21M requests)
[OK] table_definition_cache(2000) is upper than number of tables(506)
[OK] Open file limit used: 0% (6/10K)
[OK] Table locks acquired immediately: 100% (9 immediate / 9 locks)
[OK] Binlog cache memory access: 99.57% (25538 Memory / 25647 Total)
-------- Performance schema ------------------------------------------------------------------------
[--] Memory used by P_S: 72B
[--] Sys schema is installed.
-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is disabled.
-------- MyISAM Metrics ----------------------------------------------------------------------------
[--] MyISAM Metrics are disabled on last MySQL versions.
-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 0
[OK] InnoDB File per table is activated
[!!] InnoDB buffer pool / data size: 128.0M/262.4G
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (75 %): 48.0M * 2/128.0M should be equal to 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: 98.29% (925392031 hits/ 941450541 total)
[!!] InnoDB Write Log efficiency: 309.39% (25100125 hits/ 8112662 total)
[!!] InnoDB log waits: 0.00% (65 waits / 33212787 writes)
-------- Aria Metrics ------------------------------------------------------------------------------
[--] Aria Storage Engine not available.
-------- 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 persistent connections to reduce connection usage
Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
Before changing innodb_log_file_size and/or innodb_log_files_in_group read this: *link*
Variables to adjust:
max_connections (> 151)
wait_timeout (< 28800)
interactive_timeout (< 28800)
innodb_buffer_pool_size (>= 262.4G) if possible.
innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
innodb_log_buffer_size (>= 16M)
Actualización 3:
Hoy mi servidor se congeló nuevamente. El proceso que sobrecargó la CPU fue el apache2. He logrado detener el servicio. Y de repente todo empezó a funcionar sin problemas. Intenté hacer la copia de seguridad de la base de datos, la que tiene muchas filas, y funcionó bien. Pero, después de un tiempo, todo se congeló nuevamente: el uso de la CPU por parte de algunos procesos fue del 2400%, el promedio de carga superó el 24. Entonces, mi sugerencia es que no sea Apache el que cargue la CPU, ni MySQL tampoco. Algunos de los procesos, como htop o gzip, que estoy usando para la copia de seguridad, también tienen un uso elevado de CPU, de vez en cuando. ¿Qué podría ser entonces? ¿Podría ser esto el resultado de un ataque DDOS y, de ser así, cómo puedo solucionarlo?
Respuesta1
Velocidad por segundo = RPS
Sugerencias a considerar para su sección my.cnf [mysqld]
innodb_buffer_pool_size=22G # from 128M to better accomodate your 262G of data
max_connections=256 # from 151 since you have had all connections used
thread_cache_size=150 # from 9 to reduce threads_created RPhr of 111
innodb_log_file_size=4G # from 50M to support more than and hour before rotation
innodb_log_buffer_size=1G # from 16M to support ~ 30 min before write to media
El rendimiento debería mejorarse significativamente. Hay muchas más oportunidades para mejorar el rendimiento. Vea el perfil para obtener información de contacto y secuencias de comandos de utilidad descargables de forma gratuita para mejorar el rendimiento.
Respuesta2
Es muy difícil decirlo, pero estás diciendo que estás ejecutando WordPress y que tus 24 núcleos alcanzan su punto máximo al 100%, solo recuerda que una sola consulta no puede usar solo 1 hilo a la vez.
Entonces, algo suena como un rendimiento de consulta muy malo y no va directamente a su servidor web Apache. ¿Ha probado el complemento "WP Redis Cache" para almacenar en caché sus consultas en Redis y guardar la búsqueda de consultas?
El siguiente complemento que puede intentar instalar es "Query Monitor". Le mostrará las consultas SQL que realiza sobre la marcha. Es una muy buena herramienta de depuración para WordPress.
Recuerde que si está desarrollando sus propios complementos en WordPress, debe encargarse de Redis usted mismo utilizando las funciones integradas para almacenar en caché el resultado de su consulta.
Y al final de esta forma de depurar, le recomendaré que habilite la consulta de registro lento para MySQL para todo lo que dure más de 1 segundo; puede encontrar consultas en las que falta el índice de las columnas.