Высокая загрузка ЦП MySQL и низкая загрузка оперативной памяти
У меня следующие характеристики:
8vCPUS / 32 ГБ памяти / 160 ГБ диск, размещенный в Digital Ocean
Веб-приложение построено на Laravel (PHP) и в настоящее время обслуживает 550 одновременных пользователей.
Это процессы:
17767 mysql 20 0 29.160g 4.160g 18804 S 214.3 13.2 25:55.25 mysqld
20455 www-data 20 0 496504 45364 31252 S 19.9 0.1 0:11.90 apache2
21849 www-data 20 0 496420 44828 30868 S 10.4 0.1 0:08.25 apache2
20470 www-data 20 0 494500 43232 31188 S 8.8 0.1 0:09.81 apache2
2422 www-data 20 0 496436 41656 27660 R 8.5 0.1 0:02.39 apache2
29369 www-data 20 0 494324 42960 31048 R 8.5 0.1 0:04.87 apache2
28830 www-data 20 0 494320 41632 29700 S 8.1 0.1 0:02.57 apache2
21160 www-data 20 0 496392 44796 30804 S 7.8 0.1 0:08.95 apache2
20899 www-data 20 0 494424 42572 30552 R 7.2 0.1 0:07.29 apache2
20971 www-data 20 0 496432 45092 31060 S 6.8 0.1 0:07.21 apache2
21589 www-data 20 0 496468 44692 30612 S 6.5 0.1 0:06.98 apache2
32660 www-data 20 0 496520 44816 30796 R 6.5 0.1 0:03.80 apache2
21650 www-data 20 0 494460 42984 30996 S 5.5 0.1 0:06.84 apache2
...
...
...
Использование ЦП из MYSQL составляет 214%, и кажется, что ни одно из моих усилий не помогло уменьшить это число.
Глядя на графики, предоставленные Digital Ocean, текущее общее использование ЦП составляет на 80% всего, а ОЗУ на жалких 25%. Это странно? У меня всегда было впечатление, что, когда дело касается производительности, обычно является ОЗУ, а не ЦП.
Вот мои настройки MYSQL
key_buffer_size = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 16
myisam-recover-options = BACKUP
max_connections = 500
wait_timeout = 20000
query_cache_limit = 2M
query_cache_size=0
query_cache_type=0
tmp_table_size = 320M
max_heap_table_size = 320M
log_error = /var/log/mysql/error.log
expire_logs_days = 10
max_binlog_size = 100M
innodb_buffer_pool_size=22G
innodb_buffer_pool_instances=22
innodb_log_file_size=5G
innodb_read_io_threads=8G
innodb_write_io_threads=8G
Я чувствую, что исчерпал все возможности. Я просмотрел множество сообщений в Интернете, я скорректировал многие переменные, такие как innodb_buffer_pool_size , innodb_buffer_pool_instance и т. Д., Чтобы лучше представить оборудование, используйте тюнер mysql и следовал всем его рекомендациям , Я провел много-много часов, просматривая каждый бит кода, регистрируя все запросы и запросы, которые выполняются медленно, и оптимизировал до чертиков приложение, и это также дало минимальную разницу. Что-то мне не хватает? Или я нахожусь в точке, где мне нужно снова усилить сервер? Использование плунжера на 25% необычно низкое ....
Любое предложение будет огромной помощью. Ура.
Я не могу комментировать из-за отсутствия репутации. Я здесь новенький! Но считайте это комментарием.
Некоторые вещи следует учесть. Inno_buffer_pool_size кажется чрезмерным согласно документам;* «Размер буферного пула всегда должен быть равен или кратен innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances» *
У меня была похожая проблема несколько месяцев назад, и после изменения всего, что я мог придумать, я наконец решил ее, сделав резервную копию config (в моем случае /etc/my.cnf.d/server.cnf) и удалив все, кроме необходимых вещей, таких как привязка IP-адреса и порта.
После перезагрузки mysql проблема исчезла, поэтому я понял, что это была комбинация изменений, которые я сделал. Я повторно вводил каждое изменение, перезагружая каждый раз, пока исходная проблема не появлялась снова. Я не могу вспомнить, какой это был вариант, но я повозился и настроил его лучше.
Не похоже, что подкачка является проблемой для вас, но следите за любой заменой диска, которая может произойти.
Опять же, это комментарий. :)
Вам необходимо опубликовать как минимум вывод
SHOW FULL PROCESSLIST;
И оттуда, возможно, включить медленное ведение журнала запросов:
slow_query_log = 1
long_query_time = 0
А затем, через некоторое время, опубликуйте вывод:
mysqldumpslow -st /path/to/slow.log | head -100
Затем мы можем посмотреть, какие запросы потребляют ваш ЦП, и можно ли сделать так, чтобы они потребляли меньше ЦП.
Оптимизация производительности базы данных - это 5% конфигурация и 95% оптимизация запросов, если конфигурация не является действительно патологической неправильно. Опять же, патологически неправильная конфигурация вероятна, если вы поверили всему, что вам сказал mysqltuner, например 8 млрд io потоков ...
innodb_read_io_threads=8G
innodb_write_io_threads=8G
NO !!
Каждый io_thread требует некоторого количества RAM, CPU, System и т.д. "8" - это разумно; «8G» очень неразумно. Я удивлен, что система не вышла из строя.
Вы меняли какие-либо другие настройки?