Nossa empresa está usando TokuDB
na produção e estamos tendo muitos problemas tentando atenuar o atraso em nosso escravo. É muito estranho, porque estamos falando de poucas linhas ... mas com alguns dados fica defasada.
O escravo é um banco de dados somente leitura.
Para mais informações, estamos usando:
CPU : CPU Intel (R) Core (TM) i5-2400 a 3.10GHz (4 núcleos)
RAM : 16 GB
HDD : 2Tb ST2000DM001 (sistema de arquivos EXT4)
Aqui você pode ver algumas saídas de desempenho de E / S. Eu colo fora deste post, porque acho que dessa maneira será mais fácil para a leitura.
iostat -x 1
output, quando temos uma situação de atraso
link
fio
, para E / S de disco:
link
Fizemos alguns ajustes no disco, extraídos do link do livro de Steven Corona:
- Alterou o agendador de E / S para
noop
.
- Desligou os tempos de acesso ao sistema de arquivos,
noatime
e nodiratime
in /etc/fstab
- Aumentou o número de arquivos abertos em
/etc/security/limits.conf
:
* soft nofile 999999
* hard nofile 999999
Alguns ajustes que fizemos na configuração:
MESTRE
# * Query Cache Configuration
query_cache_limit = 0
query_cache_size = 0
query_cache_type = 0
innodb_file_per_table = 1
innodb_file_format = barracuda
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 1
innodb_log_file_size = 128M
innodb_buffer_pool_size = 13500M
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_io_capacity = 180
innodb_thread_concurrency = 4
ESCRAVO
# * Query Cache Configuration
query_cache_limit = 0
query_cache_size = 0
query_cache_type = 0
innodb_file_per_table = 1
innodb_file_format = barracuda
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 2
sync_binlog = 1
innodb_log_file_size = 128M
innodb_buffer_pool_size = 13500M
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_io_capacity = 180
innodb_thread_concurrency = 4