linux – IO等等导致如此大的减速(EXT4 JDB2在99%IO)在Mysql Co
我正在编写一个索引器,使用
python,它将文档编入索引并将它们插入到数据库中,在它是单个进程之前,但现在我使用4个并行进程运行它进行多处理.每次文本提取后,它都插入数据库并执行提交.
现在它遇到了IO问题,主要的IO问题不是我的过程而是EXT4的jdb2,journeling系统.它是99.99%并且在每次MySQL提交时等待CPU等待CPU. 我看到许多人在互联网上遇到这个问题,他们的解决方案是使用barrier = 0挂载.会完全禁用日记功能吗?我的服务器有UPS并且很想做到这一点,我应该吗? 解决方法
弹性和性能之间总是存在折衷.
对于ext4上的MySQL,barrier = 1默认确实会导致速度减慢,但是第一个操作不应该是禁用日记或打开data = writeback. 首先,如果弹性非常重要,那么备用电池的RAID肯定是值得的. 我选择的挂载选项,尤其是非备用电池的RAID是: /dev/mapper/vg-mysql--data /var/lib/mysql/data ext4 defaults,noatime,nodiratime,barrier=1,data=ordered 0 0 这是故意不使用data = writeback,因为我不想冒文件系统损坏的风险,导致“崩溃和日志恢复后”旧数据出现在文件中“(引用来自man mount). my.cnf中关于I / O相关设置的完全弹性的理想配置是: [mysqld] sync_binlog = 1 innodb_flush_log_at_trx_commit = 1 我选择了以下一系列权衡以提高性能: > sync_binlog = 0:这是我改变完全弹性的第一个MySQL配置.这样做的原因是它提供了显着的性能改进,特别是在binlog_format = row(不幸的是Jira需要)的情况下.我在群集中使用了足够多的MySQL副本,如果binlog被断电情况损坏,我会从另一个副本执行二进制副本. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |