Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Значительно выросла (с 10% до 60%) нагрузка на SSD сразу же после апгрейда с Percona 5.5.37 на 5.6 (Сейчас стоит MySQL 5.6.26, изначально ставили Percona 5.6 - та же ситуация).
Конфигурация MySQL не изменялась. Приложения, работающие с БД - тоже.
Расписываю более детально конфигурацию сервера. Надеюсь поможете разобраться в причине.
Железо: Core i7-4770 CPU @ 3.40GHz, 32GB RAM, SSD mirror
ОС: FreeBSD 9.3-RELEASE-p24
ФС: ZFS + LZ4 compression
БД MySQL (в 95% используется InnoDB) расположена на SSD (zfs mirror) 2x по 240Gb Intel 530 Series
NAME USED AVAIL REFER
ssdpool/mysqldb 108G 105G 108G
my.cnf
[client]
port = 3306
socket = /tmp/mysql.sock
[mysqld]
log_bin_trust_function_creators = 1
ssl=1
ssl_ca=/usr/local/etc/mysql-ssl/ca-cert.pem
ssl_cert=/usr/local/etc/mysql-ssl/server-cert.pem
ssl_key=/usr/local/etc/mysql-ssl/server-key.pem
character-set-server=utf8
skip-character-set-client-handshake
interactive_timeout = 500
wait_timeout = 500
innodb_doublewrite = 0
sql-mode = "NO_UNSIGNED_SUBTRACTION"
port = 3306
socket = /tmp/mysql.sock
back_log = 50
max_connections = 300
max_connect_errors = 10
table_open_cache = 5000
table_definition_cache = 5000
max_allowed_packet = 16M
binlog_cache_size = 16M
max_heap_table_size = 512M
sort_buffer_size = 2M
join_buffer_size = 2M
thread_cache_size = 40
thread_concurrency = 8
query_cache_size = 256M
query_cache_limit = 32K
ft_min_word_len = 4
thread_stack = 192K
transaction_isolation = READ-COMMITTED
tmp_table_size = 512M
server-id=3
relay-log=slave-relay-bin
relay-log-index=slave-relay-bin.index
log-slave-updates=1
replicate-do-db=_table
log-bin = mysql-bin
binlog-do-db = _table
binlog_format=mixed
expire_logs_days=10
log_warnings = 2
log_error
slow_query_log
long_query_time = 20
tmpdir = /tmp/mysql
key_buffer_size = 1G
bulk_insert_buffer_size = 16M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover=backup,force
innodb_checksum_algorithm = crc32
innodb_buffer_pool_instances = 2
innodb_flush_neighbors = 0
innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 14G
innodb_data_file_path = ibdata1:100M:autoextend
innodb_write_io_threads = 16
innodb_read_io_threads = 16
innodb_thread_concurrency = 16
innodb_flush_log_at_trx_commit = 0
innodb_log_buffer_size = 8M
innodb_log_file_size = 128M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 90
innodb_flush_method=O_DIRECT
innodb_lock_wait_timeout = 120
innodb_file_per_table = 1
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-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 = 32000
Неактивен
В 5.6 трогали алгоритм адаптивного скидывания на диск. Если у Вас есть реплика с 5.5, на которой можно посравнивать, то можно включить статистику InnoDB (set global innodb_monitor_enable = '%') и посмотреть на статистику в INFORMATION_SCHEMA.INNODB_METRICS. Как минимум, интересно посмотреть на количество грязных страниц и уровни flush.
P.S. Может оказаться полезным посмотреть вот на эту статью (и комментарии) — http://code.openark.org/blog/mysql/the-mystery-of-mysql-5-6-excessive-buffer-pool-flushing — ребята там не решили проблему, но как минимум нарисовали много разных графиков, которые можно посравнивать.
Неактивен
К сожалению реплики с 5.5 нет, а когда была - возникли проблемы (уже не вспомню с чем), в итоге пришлось реплику держать на 5.6, поэтому сравнить не с чем.
mysql> select name, count,comment from INNODB_METRICS where name like '%pool%';
+--------------------------------+--------------+--------------------------------------------------------------------------------------------------------+
| name | count | comment |
+--------------------------------+--------------+--------------------------------------------------------------------------------------------------------+
| metadata_mem_pool_size | 16777216 | Size of a memory pool InnoDB uses to store data dictionary and internal data structures in bytes |
| buffer_pool_size | 15032385536 | Server buffer pool size (all buffer pools) in bytes |
| buffer_pool_reads | 11641765 | Number of reads directly from disk (innodb_buffer_pool_reads) |
| buffer_pool_read_requests | 226667617773 | Number of logical read requests (innodb_buffer_pool_read_requests) |
| buffer_pool_write_requests | 10686665056 | Number of write requests (innodb_buffer_pool_write_requests) |
| buffer_pool_wait_free | 0 | Number of times waited for free buffer (innodb_buffer_pool_wait_free) |
| buffer_pool_read_ahead | 7109273 | Number of pages read as read ahead (innodb_buffer_pool_read_ahead) |
| buffer_pool_read_ahead_evicted | 7266 | Read-ahead pages evicted without being accessed (innodb_buffer_pool_read_ahead_evicted) |
| buffer_pool_pages_total | 917504 | Total buffer pool size in pages (innodb_buffer_pool_pages_total) |
| buffer_pool_pages_misc | 53172 | Buffer pages for misc use such as row locks or the adaptive hash index (innodb_buffer_pool_pages_misc) |
| buffer_pool_pages_data | 862291 | Buffer pages containing data (innodb_buffer_pool_pages_data) |
| buffer_pool_bytes_data | 14127775744 | Buffer bytes containing data (innodb_buffer_pool_bytes_data) |
| buffer_pool_pages_dirty | 15013 | Buffer pages currently dirty (innodb_buffer_pool_pages_dirty) |
| buffer_pool_bytes_dirty | 245972992 | Buffer bytes currently dirty (innodb_buffer_pool_bytes_dirty) |
| buffer_pool_pages_free | 2041 | Buffer pages currently free (innodb_buffer_pool_pages_free) |
| log_lsn_buf_pool_oldest | 0 | The oldest modified block LSN in the buffer pool |
+--------------------------------+--------------+--------------------------------------------------------------------------------------------------------+
подскажите, пожалуйста, на какие соотношения значений стоит обратить внимание?
Неактивен
10% грязных страниц. Теоретически, не так много. А запись лога транзакций сильно отстает (то же самое, но %log%)?
Можно попробовать поднять innodb_adaptive_flushing_lwm, но учтите, что при заполнении буфера, оно будет сбрасывать еще более интенсивно.
Ну и памяти для транзакций я бы тоже добавил. При 14 гигабайтах буферпула держать 8 мегабайт под транзакции, кажется, маловато.
innodb_log_buffer_size = 8M # -> 128M
innodb_log_file_size = 128M # -> 512M, потребует корректную остановку, удаление файликов и поднятие заново
Неактивен
Вот, в принципе сейчас можно сказать, что нагрузка на диски практически зашкаливает.
mysql> select name, count,comment from INNODB_METRICS where name like '%pool%';
+--------------------------------+--------------+--------------------------------------------------------------------------------------------------------+
| name | count | comment |
+--------------------------------+--------------+--------------------------------------------------------------------------------------------------------+
| metadata_mem_pool_size | 16777216 | Size of a memory pool InnoDB uses to store data dictionary and internal data structures in bytes |
| buffer_pool_size | 15032385536 | Server buffer pool size (all buffer pools) in bytes |
| buffer_pool_reads | 14199369 | Number of reads directly from disk (innodb_buffer_pool_reads) |
| buffer_pool_read_requests | 252728900491 | Number of logical read requests (innodb_buffer_pool_read_requests) |
| buffer_pool_write_requests | 12679375876 | Number of write requests (innodb_buffer_pool_write_requests) |
| buffer_pool_wait_free | 0 | Number of times waited for free buffer (innodb_buffer_pool_wait_free) |
| buffer_pool_read_ahead | 8516549 | Number of pages read as read ahead (innodb_buffer_pool_read_ahead) |
| buffer_pool_read_ahead_evicted | 8004 | Read-ahead pages evicted without being accessed (innodb_buffer_pool_read_ahead_evicted) |
| buffer_pool_pages_total | 917504 | Total buffer pool size in pages (innodb_buffer_pool_pages_total) |
| buffer_pool_pages_misc | 52006 | Buffer pages for misc use such as row locks or the adaptive hash index (innodb_buffer_pool_pages_misc) |
| buffer_pool_pages_data | 863967 | Buffer pages containing data (innodb_buffer_pool_pages_data) |
| buffer_pool_bytes_data | 14155235328 | Buffer bytes containing data (innodb_buffer_pool_bytes_data) |
| buffer_pool_pages_dirty | 10699 | Buffer pages currently dirty (innodb_buffer_pool_pages_dirty) |
| buffer_pool_bytes_dirty | 175292416 | Buffer bytes currently dirty (innodb_buffer_pool_bytes_dirty) |
| buffer_pool_pages_free | 1531 | Buffer pages currently free (innodb_buffer_pool_pages_free) |
| log_lsn_buf_pool_oldest | 0 | The oldest modified block LSN in the buffer pool |
+--------------------------------+--------------+--------------------------------------------------------------------------------------------------------+
16 rows in set (0.00 sec)
mysql> select name, count,comment from INNODB_METRICS where name like '%log%';
+-------------------------------+--------------+--------------------------------------------------------------------+
| name | count | comment |
+-------------------------------+--------------+--------------------------------------------------------------------+
| buffer_page_read_undo_log | 0 | Number of Undo Log Pages read |
| buffer_page_written_undo_log | 0 | Number of Undo Log Pages written |
| os_log_bytes_written | 535988267008 | Bytes of log written (innodb_os_log_written) |
| os_log_fsyncs | 3823114 | Number of fsync log writes (innodb_os_log_fsyncs) |
| os_log_pending_fsyncs | 1 | Number of pending fsync write (innodb_os_log_pending_fsyncs) |
| os_log_pending_writes | 0 | Number of pending log file writes (innodb_os_log_pending_writes) |
| purge_undo_log_pages | 0 | Number of undo log pages handled by the purge |
| log_checkpoints | 0 | Number of checkpoints |
| log_lsn_last_flush | 0 | LSN of Last flush |
| log_lsn_last_checkpoint | 0 | LSN at last checkpoint |
| log_lsn_current | 0 | Current LSN value |
| log_lsn_checkpoint_age | 0 | Current LSN value minus LSN at last checkpoint |
| log_lsn_buf_pool_oldest | 0 | The oldest modified block LSN in the buffer pool |
| log_max_modified_age_async | 0 | Maximum LSN difference; when exceeded, start asynchronous preflush |
| log_max_modified_age_sync | 0 | Maximum LSN difference; when exceeded, start synchronous preflush |
| log_pending_log_writes | 0 | Pending log writes |
| log_pending_checkpoint_writes | 0 | Pending checkpoints |
| log_num_log_io | 0 | Number of log I/Os |
| log_waits | 48 | Number of log waits due to small log buffer (innodb_log_waits) |
| log_write_requests | 1261143182 | Number of log write requests (innodb_log_write_requests) |
| log_writes | 3796821 | Number of log writes (innodb_log_writes) |
| innodb_log_flush_usec | 0 | Time (in microseconds) spent to flush log records |
+-------------------------------+--------------+--------------------------------------------------------------------+
22 rows in set (0.00 sec)
innodb_adaptive_flushing_lwm результата не давал, пробовал.
>innodb_log_buffer_size = 8M # -> 128M
>innodb_log_file_size = 128M # -> 512M, потребует корректную остановку, удаление файликов и поднятие заново
на данный момент не применил
mysql> show engine innodb status\G select sleep(60); show engine innodb status\G
Log sequence number 34655213372464
1 row in set (0.02 sec)
1 row in set (1 min 0.01 sec)
Log sequence number 34655536662467
1 row in set (0.06 sec)
mysql> select (34655536662467 - 34655213372464) / 1024 / 1024 as MB_per_min;
+--------------+
| MB_per_min |
+--------------+
| 308.31337261 |
+--------------+
1 row in set (0.00 sec)
Неактивен
300 мегабайт в минуту — это 5 мегабайт в секунду, кажется, это для ssd вообще ни о чем. А сколько реально пишется?
Неактивен
Да, ни о чем и было, до апгрейда mysql
сейчас SSD работают как HDD, совсем чуть чуть быстрее. avio зашкаливает. На SSD только mysql db.
из atop:
DSK | ada2 | | busy 41% | read 191 | | write 720 | KiB/r 47 | | KiB/w 46 | MBr/s 2.95 | | MBw/s 10.99 | avq 0.00 | | avio 101 ms |
DSK | ada3 | | busy 27% | read 172 | | write 731 | KiB/r 50 | | KiB/w 46 | MBr/s 2.82 | | MBw/s 10.99 | avq 0.00 | | avio 79.7 ms |
примерно так, но нагрузка уже относительно спала.
Отредактированно ap87 (06.11.2015 11:55:03)
Неактивен
Вы уверены, что дело в MySQL? 10 мегабайт в секунду пишется на ssd, как-то очень странно.
Ну то есть попробуйте прямо вот последовательно в них пописать и посмотреть, какой там пик. Я совсем не верю в эти чиселки. SSD работает обычно на порядок быстрее:
# dd if=/dev/zero of=tst bs=102400 count=10240
10240+0 records in
10240+0 records out
1048576000 bytes (1,0 GB) copied, 3,38898 s, 309 MB/s
Неактивен
ноли не показатель, но:
dd if=/dev/zero of=tst bs=102400 count=10240
10240+0 records in
10240+0 records out
1048576000 bytes transferred in 1.432550 secs (731964580 bytes/sec)
нет, дело точно не SSD, тестировали. Изменилась только версия MySQL
Неактивен
Окей, тогда почему 10.99 мегабайт записи в секунду делают 41% busy time? Чиселки изнутри MySQL и снаружи сходятся — 5 мегабайт логов + те же данные в основной датасет дают 10 мегабайт в секунду. Мне всё еще кажется, что что-то не так с дисковой подсистемой.
Как просто потестировать дисковую подсистему не знаю, я бы взял bonnie++ и с помощью нее погонял randomio на этой системе.
Неактивен
Вероятно дело в параллельных потоках чтения и записи. К сожалению, их число не мониторил... Но попробую воспроизвести одинаковые операции на 5.5 и на 5.6 с одинаковыми конфигами
Точно дело не в дисковой подсистеме, точно дело в новом MySQL
Неактивен
Я верю в то, что MySQL может писать больше в новой версии. У нас нету чиселок сравнения из 5.5, поэтому я не могу сравнить, и к задачке подхожу с точки зрения «Есть сервер 5.6, он пишет много». Вот «много» я не вижу.
Если сможете ту же нагрузку показать на 5.5, можно будет посравнивать чиселки. Альтернативно очень интересно, что скажет bonnie++ на вашей системе.
Неактивен
Страниц: 1