Tenho um problema com o uso da CPU no site que usa WordPress, Apache e MySQL. Durante o dia, de vez em quando, o uso da CPU pelo MySQL e Apache sobe para 2400% (tenho 24 núcleos no total), o servidor congela, a carga média sobe para 24.
Recentemente teve um pouco mais de trânsito do que o normal, mas isso não deveria ser permanente, certo? Atualizei o kernel, o banco de dados, as bibliotecas, reiniciei várias vezes. E ainda assim, congela. Examinei a lista de processos do banco de dados, mas não há nada de extraordinário. No banco de dados, existem grandes quantidades de dados. Apenas algumas semanas atrás, funcionou bem e agora não funciona. Portanto, não devem ser consultas não otimizadas.
Quais podem ser as causas de tal comportamento?
Atualizar:
o resultado de A) SHOW GLOBAL STATUS LIKE '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 STATUS GLOBAL COMO 'uptime%';
+---------------------------+--------+
| Variable_name | Value |
+---------------------------+--------+
| Uptime | 455524 |
| Uptime_since_flush_status | 455524 |
+---------------------------+--------+
2 rows in set (0.01 sec)
C) MOSTRAR STATUS 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 Ainda tenho problemas com o servidor. Precisei alterar o conjunto de caracteres de um dos bancos de dados e demorei pouco mais de um dia para terminar, com apenas 400 mil linhas. Antes demorava um pouco, mas não tanto. Fiquei me perguntando, será que após o ataque DDOS pode haver algumas alterações no banco de dados, fazendo com que ele tenha um desempenho pior?
Atualização 2:
Resultados do 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)
Atualização 3:
Hoje meu servidor congelou novamente. O processo que sobrecarregou a CPU foi o apache2. Consegui interromper o serviço. E de repente tudo começou a funcionar bem. Tentei fazer o backup do banco de dados, aquele com muitas linhas, e funcionou perfeitamente. Mas, depois de algum tempo tudo congelou novamente: o uso da CPU por alguns processos estava em 2400%, a média de carga ultrapassou 24. Então, minha sugestão, que não é o apache, que carrega a CPU, nem o MySQL. Alguns dos processos, como htop ou gzip, que estou usando para backup, também apresentam alto uso de CPU de vez em quando. O que poderia ser então? Isso poderia ser o resultado de um ataque DDOS e, em caso afirmativo, como posso corrigi-lo?
Responder1
Taxa por segundo = RPS
Sugestões a serem consideradas para sua seção 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
O desempenho deve ser significativamente melhorado. Existem muito mais oportunidades para melhorar o desempenho. Visualize o perfil para obter informações de contato e scripts de utilitários para download gratuito para melhorar o desempenho.
Responder2
É muito difícil dizer, mas você está dizendo que está executando o WordPress e seu pico de 24 núcleos chega a 100%, lembre-se de que uma única consulta não pode usar apenas 1 thread por vez.
Então, algo parece um desempenho de consulta muito ruim e não é direto para o seu servidor Apache. Você tentou o plug-in "WP Redis Cache" para armazenar em cache suas consultas no Redis para salvar a pesquisa de consulta?
O próximo plugin que você pode tentar instalar é "Query Monitor", ele mostrará as consultas SQL que você está chamando instantaneamente, é uma ferramenta de depuração muito boa para WordPress.
Lembre-se de que, se você estiver desenvolvendo seus próprios plug-ins no WordPress, você mesmo deve cuidar do Redis usando as funções integradas para armazenar em cache o resultado da consulta.
E no final desta forma de depuração, recomendo que você habilite a consulta de log lento para MySQL para tudo acima de 1 segundo, você pode encontrar consultas onde o índice da(s) coluna(s) está/estão faltando.