У меня есть сервер MySQL, работающий на CentOS.
Недавно у меня возникла проблема, которая случается каждые 2 дня. Сервер работает быстро и нормально, но затем он внезапно становится очень медленным, пока я не перезапущу MySQL, затем он возвращается в обычное состояние.
Такое случалось со мной пару раз, поэтому на этот раз я сделал 2 скриншота перед тем, как запустить service mysqld restart
.
Перед перезапуском:
После перезапуска:
Большинство моих таблиц - это InnoDB, некоторые - MyISAM. (4 таблицы MyISAM, 38 таблиц InnoDB)
my.cnf:
[mysqld]
bulk_insert_buffer_size = 8M
concurrent_insert = 2
connect_timeout = 30
default-storage-engine = MyISAM
innodb_buffer_pool_size=1300M
innodb_file_per_table=1
interactive_timeout = 1000
join_buffer_size=128M
key_buffer_size = 1200M
local-infile=0
slow_query_log=1
long_query_time=0.5
#skip-grant-tables
max_allowed_packet = 900M
max_connections = 40000
max_heap_table_size = 256M
max_user_connections = 10000
max_write_lock_count = 8
myisam_max_sort_file_size = 256M
myisam_sort_buffer_size = 64M
open_files_limit = 10192
query_alloc_block_size = 65536
query_cache_limit = 256M
query_cache_size = 384M
query_cache_type = 1
query_prealloc_size = 262144
range_alloc_block_size = 4096
read_buffer_size = 4M
read_rnd_buffer_size = 16M
sort_buffer_size = 4M
table_cache = 8048
table_open_cache = 8000
thread_cache_size = 50
tmp_table_size = 256M
transaction_alloc_block_size = 4096
transaction_prealloc_size = 4096
#innodb_force_recovery=5
wait_timeout = 1000
max_connect_errors = 5000
open-files = 50000
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС, КАК "% connect%";
+--------------------------+--------+
| Variable_name | Value |
+--------------------------+--------+
| Aborted_connects | 0 |
| Connections | 859148 |
| Max_used_connections | 103 |
| Ssl_client_connects | 0 |
| Ssl_connect_renegotiates | 0 |
| Ssl_finished_connects | 0 |
| Threads_connected | 1 |
+--------------------------+--------+
ПОКАЗАТЬ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ КАК 'thread_%';
+---------------------------+---------------------------+
| Variable_name | Value |
+---------------------------+---------------------------+
| thread_cache_size | 50 |
| thread_concurrency | 10 |
| thread_handling | one-thread-per-connection |
| thread_pool_idle_timeout | 60 |
| thread_pool_max_threads | 500 |
| thread_pool_oversubscribe | 3 |
| thread_pool_size | 8 |
| thread_pool_stall_limit | 500 |
| thread_stack | 294912 |
+---------------------------+---------------------------+
ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС, КАК 'thread_%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_cached | 49 |
| Threads_connected | 1 |
| Threads_created | 372 |
| Threads_running | 1 |
+-------------------+-------+
ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС КАК 'key_%';
+------------------------+---------+
| Variable_name | Value |
+------------------------+---------+
| Key_blocks_not_flushed | 0 |
| Key_blocks_unused | 1003901 |
| Key_blocks_used | 3365 |
| Key_blocks_warm | 0 |
| Key_read_requests | 99176 |
| Key_reads | 3052 |
| Key_write_requests | 29353 |
| Key_writes | 29347 |
+------------------------+---------+
ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС КАК «Q%»;
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| Qcache_free_blocks | 961 |
| Qcache_free_memory | 400828904 |
| Qcache_hits | 1634009 |
| Qcache_inserts | 1201887 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 59970 |
| Qcache_queries_in_cache | 1467 |
| Qcache_total_blocks | 3926 |
| Queries | 5316596 |
| Questions | 5187929 |
+-------------------------+-----------+
ПОКАЗАТЬ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ КАК '_size';
Empty set
Это скорее проблема загрузки клиента, чем проблема сервера с утечкой памяти. Потоки демона используют примерно одно или два ядра. Чем они заняты? Что говорит SHOW FULL PROCESSLIST?
Перезапуск сделал гораздо больше, чем просто сбросил состояние демона. Он уничтожил 587 процессов, которые предположительно имели активные соединения порта 3306 (или AF_UNIX) с сервером. Что они делали? Довольны ли вы тем, что они делали? Регистрировали ли они во время перезагрузки фатальные ошибки, которые вас огорчают? Может быть, им нужно выполнить какую-то задачу, а затем отключиться и выйти?
Перезапуск - это быстрое решение, но похоже, что вы хотите понять, как нагрузка на клиента растет все больше и больше в течение 48 часов, предшествующих перезапуску.
Для немедленного облегчения после просмотра справочного руководства подумайте
set global read_rnd_buffer_size=256K; # from 16M per connection
Это можно делать динамически.
Для входа в систему после этого не потребуется 16M на вход. Зачем читать 16M (даже если это из RAM), когда 256K будет нормально? После размещения других запрошенных элементов у меня будут дополнительные предложения.
----- 2017 11 04 ------------- Следующие предложения требуют вашего исследования, прежде чем внедрять ТОЛЬКО один элемент в день. Некоторые могут применяться динамически. Предлагаемые значения cfg / ini следуют за разделом [mysqld] и могут быть изменены, добавлены или удалены.
max_connections=200 #from 40000 to support your 103 max_used_connections
max_user_connections=200 #from 10000 to be matched with max_connections
key_buffer_size REMOVE for default of 64M. less than 1% of 1200MB used
thread_cache_size=100 #from 50 to support your 103 max_used_connections - cap at 100 per V8
thread_concurrency=33 #from 10 for about 30% active
max_connect_errors=10 #from 5000, to better control hacker passwd guessing
innodb_print_all_deadlocks=1 # from OFF, if you ever have one, you need this data in error log
#### these are PER CONNECTION values driving your RAM footprint up the wall
#read_buffer_size or REMOVE for default of 128K vs 4M RAM
#read_rnd_buffer_size or REMOVE for default of 256K vs 16M RAM
#join_buffer_size or REMOVE for default of 128K vs 128MB RAM
Использование MySQLCalculator.com поможет вам узнать, сколько оперативной памяти вам может потребоваться, если 40000 одновременных подключений могут быть успешными (что вряд ли когда-либо произойдет) - потребуется около 6 террабайт оперативной памяти.
Для дополнительного анализа результатов, отражающих внесенные изменения, ПОСЛЕ 7 дней безотказной работы, пожалуйста, опубликуйте полные текстовые результаты
SHOW GLOBAL STATUS;
SHOW GLOBAL VARIABLES;
SHOW ENGINE INNODB STATUS;
и репост завершить my.cnf.