Высокая загрузка ЦП Apache/MySQL
У меня проблема с использованием ЦП на веб-сайте, использующем WordPress, Apache и MySQL. В течение дня время от времени загрузка ЦП MySQL и Apache возрастает до 2400% (У меня всего 24 ядра), сервер зависает, средняя нагрузка доходит до 24.
Недавно, было немного больше трафика, чем обычно, но это не должно быть постоянным, верно? Обновлял ядро, базу, библиотеки, много раз перезагружал. И все равно замерзает. Я посмотрел список процессов БД, но ничего экстраординарного там нет. В базе есть довольно большие объемы данных. Буквально пару недель назад все работало нормально, а сейчас нет. Таким образом, это не должны быть неоптимизированные запросы.
Каковы могут быть причины такого поведения?
Обновите:
результат 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)SHOW GLOBAL STATUS LIKE 'uptime%';
+---------------------------+--------+
| Variable_name | Value |
+---------------------------+--------+
| Uptime | 455524 |
| Uptime_since_flush_status | 455524 |
+---------------------------+--------+
2 rows in set (0.01 sec)
C)ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС, КАК '%dirty%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_dirty | 0 |
| Innodb_buffer_pool_bytes_dirty | 0 |
+--------------------------------+-------+
2 rows in set (0.00 sec)
п.с. У меня до сих пор проблемы с сервером. Мне нужно было изменить набор символов в одной из баз данных, и это заняло чуть больше суток, всего 400 000 строк. Раньше это занимало некоторое время, но не так много. Мне было интересно, может ли быть так, что после DDOS-атаки могут быть какие-то изменения в базе данных, чтобы она работала хуже?
Обновление 2:
Результаты 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)
Обновление 3:
Сегодня мой сервер снова завис. Процесс, который перегрузил ЦП, был apache2. Мне удалось остановить службу. И вдруг все стало работать гладко. Я попытался сделать резервную копию базы данных с большим количеством строк, и это сработало просто отлично. Но,через какое-то время опять все зависло:Загрузка ЦП некоторыми процессами была на уровне 2400%, средняя загрузка превысила 24. Так вот, мое предположение, что не апач нагружает ЦП, не MySQL. Некоторые процессы, такие как htop или gzip, которые я использую для резервного копирования, также время от времени сильно загружают ЦП. Что это может быть тогда? Может ли это быть результатом DDOS-атаки, и если да, то как это исправить?
Очень трудно сказать, но вы говорите, что используете WordPress, и ваши 24 ядра работают на 100%, просто помните, что один запрос не может использовать только 1 поток за раз.
Итак, что-то звучит как очень плохая производительность запросов, а не напрямую на ваш веб-сервер Apache. Пробовали ли вы плагин «WP Redis Cache» для кэширования ваших запросов в Redis, чтобы сохранить поиск запросов?
Следующим плагином, который вы можете попробовать установить, является «Монитор запросов». Он покажет вам SQL-запросы, которые вы вызываете на лету, это очень хороший инструмент отладки для WordPress.
Помните, что если вы разрабатываете собственные плагины для WordPress, вам следует позаботиться о Redis самостоятельно, используя встроенные-функции для кэширования результатов запроса.
И в конце этого способа отладки я рекомендую вам включить медленный-запрос журнала для MySQL для всего, что превышает 1 секунду, вы можете найти запрос, где индекс для столбца(s)/не хватает.
Rate Per Second = RPS
Рекомендации для раздела 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
Производительность должна быть значительно улучшена. Есть много других возможностей для повышения производительности. Просмотрите профиль для получения контактной информации и бесплатных загружаемых служебных сценариев для повышения производительности.