mysql - Очень медленный ответ даже при большом количестве доступного соединения

Question

Я запускаю этот сервер для целей интеллектуального анализа данных. Он выполняет несколько вычислительных приложений для интеллектуального анализа данных параллельно и делает одновременный доступ к серверу MySQL.

Вот конфигурации.

конфигурации сервера: 8 ядро ​​Intel Xeon, 16gb RAM, GB SAS диск 500

MySQL my.cnf

[client] 
#password = [your_password] 
port  = 3306 
socket  = /var/lib/mysql/mysql.sock 

[mysqld] 
# generic configuration options 
port       = 3306 
socket      = /var/lib/mysql/mysql.sock 
datadir      = /database/mysql 
log_bin      = OFF 
expire-logs-days    = 3 
pid-file      = /database/mysql/localhost.localdomain.pid 
back_log      = 50 
max_connections    = 3000 
max_connect_errors   = 100 
table_open_cache    = 2048 
max_allowed_packet   = 16M 
binlog_cache_size    = 1M 
max_heap_table_size   = 64M 
read_buffer_size    = 128M 
read_rnd_buffer_size   = 32M 
sort_buffer_size    = 32M 
join_buffer_size    = 8M 
thread_cache_size    = 8 
thread_concurrency   = 4 
query_cache_size    = 64M 
query_cache_limit    = 2M 
ft_min_word_len    = 4 
default-storage-engine  = innodb 
thread_stack     = 192K 
transaction_isolation   = REPEATABLE-READ 
tmp_table_size    = 64M 
log-bin      = mysql-bin 
binlog_format     = mixed 
server-id      = 1 
key_buffer_size    = 32M 
bulk_insert_buffer_size  = 64M 
myisam_sort_buffer_size  = 128M 
myisam_max_sort_file_size  = 10G 
myisam_repair_threads   = 1 
myisam_recover 
innodb_additional_mem_pool_size = 32M 
innodb_buffer_pool_size  = 4G 
innodb_data_file_path   = ibdata1:10M:autoextend 
#innodb_data_home_dir   = <directory> 
innodb_write_io_threads  = 8 
innodb_read_io_threads  = 8 
#innodb_force_recovery  = 6 
innodb_thread_concurrency  = 0 
innodb_flush_log_at_trx_commit= 2 
#innodb_fast_shutdown 
innodb_log_buffer_size  = 8M 
innodb_log_file_size   = 1G 
innodb_log_files_in_group  = 3 
#innodb_log_group_home_dir 
innodb_max_dirty_pages_pct = 90 
#innodb_flush_method   = O_DSYNC 
innodb_lock_wait_timeout  = 120 

[mysqldump 
quick 
max_allowed_packet   = 16M 

[mysql] 
auto-rehash 

[myisamchk] 
key_buffer_size    = 512M 
sort_buffer_size    = 512M 
read_buffer     = 8M 
write_buffer     = 8M 

[mysqlhotcopy] 
interactive-timeout 

[mysqld_safe] 
open-files-limit    = 8192 

Есть только 2 пользователей, которые имеют доступ к этому серверу, который включает меня. В час пик я получаю это

mysql > show processlist 
... 
120 rows in set 

Это показывает, что около 120 соединений устанавливаются с сервером MySQL в часы пик вычислений. MySQL потребляет около 9,5 гб памяти и использует 98-99% процессор, с которым я все еще могу жить. Но за это время сборка front-end-сайта с php/javascript занимает около 1 - 2 минут, потому что mysql очень медленно реагирует в течение этих часов. Обычно это занимает от 890 до 4 секунд.

Я хочу знать, как оптимизировать конфигурацию сервера mysql. В настоящее время, как видно из опубликованного my.cnf, буферный пул имеет 4 ГБ, а максимальное количество соединений - 3000. Все таблицы Innodb с соответствующими индексами, но в моем случае безопасность транзакций не является проблемой, основной и единственной проблемой является производительность. Приложения для интеллектуального анализа данных используют MySQL C API Connector, и каждый из них имеет около 24 параллельных потоков, которые равны 24 одновременным подключениям к MySQL

Как я могу дополнительно оптимизировать конфигурацию сервера mysql, чтобы получить разумное время отклика около 10 - 15 секунд для доступа к передней панели. Пожалуйста, дайте мне знать, есть ли способ оптимизировать это дальше.

Answer 1

Вы действительно должны посвятить другой сервер только для интеллектуального анализа данных и настроить репликацию между серверами MySQL. Приложение для интеллектуального анализа данных должно использовать транзакции для объединения нескольких небольших запросов в блоки. Таким образом, ваш сайт не будет ждать выполнения других запросов, и синхронизация будет выполнена в фоновом режиме без видимого отставания.

Другим вариантом является кеширование как можно больше и надеемся, что пользователь не будет запрашивать данные, которые не находятся в кеше при тяжелых часах.

Но я предпочитаю делать обе эти вещи, поэтому у вас будет 100% надежное обслуживание.