У меня проблема с загрузкой процессора на сайте, который использует WordPress, Apache и MySQL. В течение дня время от времени загрузка процессора MySQL и Apache достигает 2400% (у меня всего 24 ядра), сервер зависает, средняя загрузка достигает 24.
Недавно трафика было немного больше обычного, но это не должно быть постоянным, верно? Я обновил ядро, базу данных, библиотеки, перезапускал много раз. И все равно зависает. Я посмотрел список процессов БД, но ничего экстраординарного нет. В базе данных довольно большие объемы данных. Еще пару недель назад все работало нормально, а сейчас нет. Так что это не должно быть неоптимизированных запросов.
Каковы могут быть причины такого поведения?
Обновлять:
результат A) ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС, КАК '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) ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС, ТАКОЙ КАК «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)
ps У меня все еще проблемы с сервером. Мне нужно было изменить набор символов в одной из баз данных, и это заняло чуть больше дня, всего 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. Так что, мое предположение, что это не apache загружает ЦП, а не MySQL. Некоторые процессы, такие как htop или gzip, которые я использую для резервного копирования, также время от времени имеют высокую загрузку ЦП. Что же это может быть? Может ли это быть результатом DDOS-атаки, и если да, то как это исправить?
решение1
Скорость в секунду = 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
Производительность должна быть значительно улучшена. Существует множество других возможностей для повышения производительности. Просмотрите профиль для получения контактной информации и бесплатных загружаемых скриптов Utility для повышения производительности.
решение2
Очень сложно сказать, но вы говорите, что используете WordPress, и его 24 ядра загружены на 100%. Просто помните, что один запрос не может использовать только один поток одновременно.
Итак, что-то звучит как очень плохая производительность запросов и не направляется напрямую на ваш веб-сервер Apache. Вы пробовали плагин «WP Redis Cache» для кэширования ваших запросов в Redis для экономии времени поиска запросов?
Следующий плагин, который вы можете попробовать установить, — это «Query Monitor». Он будет показывать вам SQL-запросы, которые вы вызываете, «на лету». Это очень хороший инструмент отладки для WordPress.
Помните, если вы разрабатываете собственные плагины в WordPress, вам следует самостоятельно позаботиться о Redis, используя встроенные функции для кэширования результатов вашего запроса.
И в конце этого способа отладки я порекомендую вам включить медленный запрос журнала для MySQL для всего, что длится более 1 секунды, вы можете обнаружить запросы, в которых индекс для столбца(ов) отсутствует.