У меня следующие характеристики:
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" *
У меня была аналогичная проблема несколько месяцев назад, и после изменения всего, что я мог придумать, я наконец решил ее, сделав резервную копию файла конфигурации (в моем случае /etc/my.cnf.d/server.cnf) и удалив все за исключением самого необходимого, такого как привязка IP-адреса и порта.
После перезагрузки mysql проблема исчезла, поэтому я понял, что это была комбинация внесенных мной изменений. Я повторно вводил каждое изменение, перезагружая каждый раз, пока исходная проблема не возникла снова. Я не могу вспомнить, какой это был вариант, но я повозился и настроил его лучше.
Не похоже, что подкачка является проблемой для вас, но следите за любой заменой диска, которая может произойти.
Опять же, это комментарий. :)
Вам необходимо опубликовать хотя бы вывод
ПОКАЗАТЬ ПОЛНЫЙ СПИСОК ПРОЦЕССОВ;
И оттуда, возможно, включите медленное ведение журнала запросов:
slow_query_log = 1
long_query_time = 0
А затем через некоторое время опубликуйте вывод:
mysqldumpslow -s t /path/to/slow.log | голова -100
Затем мы можем посмотреть, какие запросы потребляют ваш процессор, и можно ли заставить их потреблять меньше ресурсов процессора.
Оптимизация производительности базы данных - это 5% конфигурации и 95% оптимизации запросов, если конфигурация действительно патологически неверна. Опять же, патологически неправильная конфигурация вероятна, если вы поверили всему, что вам сказал mysqltuner, например 8 млрд io потоков ...
innodb_read_io_threads=8G
innodb_write_io_threads=8G
НЕТ !!
Каждый io_thread требует некоторого количества ОЗУ, ЦП, системы и т. Д. "8" разумно; «8G» - это очень неразумно. Я удивлен, что система не вылетела.
Вы меняли какие-то другие настройки?