我们公司正在生产中使用TokuDB,我们有很多问题试图减轻我们的奴隶的滞后。很奇怪因为我们说的是很少的几排..。但有了一些数据,它就滞后了。
奴隶是一个只读DB。
有关更多信息,我们将使用:
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz (4核)
RAM: 16 RAM
2Tb ST2000DM001 (EXT4文件系统)
在这里,您可以看到一些I/O性能输出。我把它粘贴在这篇文章之外,因为我认为这样会更容易阅读。
iostat -x 1输出,当我们有滞后情况时,http://paste.laravel.com/bjv
fio,用于磁盘I/O:http://paste.laravel.com/bjG
我们做了一些磁盘调整,摘自史蒂文·科洛纳( Steven )的书http://www.scalingphpbook.com:
noop。noatime和nodiratime in /etc/fstab/etc/security/limits.conf中增加了打开的文件数:*软nofile 999999 *硬nofile 999999
我们在配置中做了一些调整:
主控
# * 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奴隶
# * 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发布于 2012-11-21 14:53:45
由于@symcbean的帮助,我认为这个问题已经解决了。
我禁用了障碍,设置了data=ordered,使用了异步提交和校验和。最后,我们迁移到MariaDB,但仍然拥有TokuDB。
我忘记提到,我们也设置了tokudb_cache_size = 8G,正如TokuDB所建议的,50%的物理内存
https://serverfault.com/questions/450048
复制相似问题