MariaDB系统参数binlog_commit_wait_count引起的单线程单表插入性能低下问题
2018-02-13 00:00
239 查看
binlog_commit_wait_count和binlog_commit_wait_usec两个参数是MariaDB 10.0开始引入的新参数,根据官方文档介绍:
Starting with MariaDB 10.0.18 and MariaDB 10.1.4: If the server detects that one of the committing transactions T1 holds an InnoDB/XtraDB row lock that another transaction T2 is waiting for, then the commit will complete immediately without further delay. This helps avoid losing throughput when many transactions need conflicting locks. This often makes it safe to use this option without losing throughput on a slave with parallel replication, provided the value of slave_parallel_threads is sufficiently high.
Commandline: --binlog-commit-wait-count=#]
Scope: Global
Dynamic: Yes
Data Type: numeric
Default Value: 0
Range: 0 - 18446744073709551615
Introduced: MariaDB 10.0.5
Commandline: --binlog-commit-wait-usec#
Scope: Global
Dynamic: Yes
Data Type: numeric
Default Value: 100000
Range: 0 - 18446744073709551615
Introduced: MariaDB 10.0.5
这两个参数用于并行复制,在并行复制中做一定的延迟,进而使用到组提交这一特性,我的理解是为了提升主从复制的性能,而不影响独立运行的服务器,而实际情况是什么,我们进行如下测试:
测试场景一(binlog_commit_wait_count = 10,binlog_commit_wait_usec系统默认):
10000条数据插入:
测试场景二(binlog_commit_wait_usec设置小于系统默认值):
10000条数据插入:
测试场景三(binlog_commit_wait_usec = 0):
10000条数据插入:
测试场景四(系统默认):
10000条数据插入:
测试场景五(binlog_commit_wait_usec设置小于系统默认值):
10000条数据插入:
结论:
根据官方文档介绍,这两个参数应该只影响主从复制的服务器架构,但实际使用对独立运行的服务器也有很大的影响,使用binlog_commit_wait_count时单表单线程10000条数据插入耗时1分6秒,不是用该参数时单表单线程10000条数据插入耗时不足3秒。同时关闭binlog_commit_wait_usec时单表单线程10000条数据插入耗时5秒多。binlog_commit_wait_usec取6000/默认值/2倍默认值差别不大,所以建议使用默认参数即可。
binlog_commit_wait_count
Description: For use in parallel replication. The binary log can delay the commit step of a transaction until the given number of transactions are all ready to commit together (group commit). The delay will however not be longer than the value set by binlog_commit_wait_usec. The default value of 0 means that no delay is introduced. Setting this value can reduce I/O on the binary log and give an increased opportunity for parallel apply on the slave, but too high a value will decrease the commit throughput. By monitoring the status variable binlog_group_commit_trigger_count (>=MariaDB 10.1.5) it is possible to see how often this is occurring.Starting with MariaDB 10.0.18 and MariaDB 10.1.4: If the server detects that one of the committing transactions T1 holds an InnoDB/XtraDB row lock that another transaction T2 is waiting for, then the commit will complete immediately without further delay. This helps avoid losing throughput when many transactions need conflicting locks. This often makes it safe to use this option without losing throughput on a slave with parallel replication, provided the value of slave_parallel_threads is sufficiently high.
Commandline: --binlog-commit-wait-count=#]
Scope: Global
Dynamic: Yes
Data Type: numeric
Default Value: 0
Range: 0 - 18446744073709551615
Introduced: MariaDB 10.0.5
binlog_commit_wait_usec
Description: For use in parallel replication. The binary log can delay the commit step of a transaction by this many microseconds. By monitoring the status variable binlog_group_commit_trigger_timeout (>=MariaDB 10.1.5) it is possible to see how often group commits are made due to binlog_commit_wait_usec. As soon as the number of pending commits reaches binlog_commit_wait_count, the wait will be terminated, though. Thus, this setting only takes effect if binlog_commit_wait_count is non-zero.Commandline: --binlog-commit-wait-usec#
Scope: Global
Dynamic: Yes
Data Type: numeric
Default Value: 100000
Range: 0 - 18446744073709551615
Introduced: MariaDB 10.0.5
这两个参数用于并行复制,在并行复制中做一定的延迟,进而使用到组提交这一特性,我的理解是为了提升主从复制的性能,而不影响独立运行的服务器,而实际情况是什么,我们进行如下测试:
测试场景一(binlog_commit_wait_count = 10,binlog_commit_wait_usec系统默认):
binlog_commit_wait_count = 10 binlog_commit_wait_usec = 6000
10000条数据插入:
# time mysql sbtest < sbtest.sql real 1m6.715s user 0m0.280s sys 0m0.694s # time mysql sbtest < sbtest.sql real 1m6.700s user 0m0.290s sys 0m0.656s
测试场景二(binlog_commit_wait_usec设置小于系统默认值):
binlog_commit_wait_count = 0 binlog_commit_wait_usec = 6000
10000条数据插入:
# time mysql sbtest < sbtest.sql real 0m2.211s user 0m0.178s sys 0m0.143s # time mysql sbtest < sbtest.sql real 0m2.280s user 0m0.236s sys 0m0.188s
测试场景三(binlog_commit_wait_usec = 0):
binlog_commit_wait_count = 0 binlog_commit_wait_usec = 0
10000条数据插入:
# time mysql sbtest < sbtest.sql real 0m5.266s user 0m0.277s sys 0m0.261s # time mysql sbtest < sbtest.sql real 0m5.852s user 0m0.354s sys 0m0.312s
测试场景四(系统默认):
binlog_commit_wait_count = 0 binlog_commit_wait_usec = 100000
10000条数据插入:
# time mysql sbtest < sbtest.sql real 0m2.598s user 0m0.373s sys 0m0.238s # time mysql sbtest < sbtest.sql real 0m2.542s user 0m0.297s sys 0m0.231s
测试场景五(binlog_commit_wait_usec设置小于系统默认值):
binlog_commit_wait_count = 0 binlog_commit_wait_usec = 200000
10000条数据插入:
# time mysql sbtest < sbtest.sql real 0m2.398s user 0m0.195s sys 0m0.194s # time mysql sbtest < sbtest.sql real 0m2.235s user 0m0.178s sys 0m0.163s
结论:
根据官方文档介绍,这两个参数应该只影响主从复制的服务器架构,但实际使用对独立运行的服务器也有很大的影响,使用binlog_commit_wait_count时单表单线程10000条数据插入耗时1分6秒,不是用该参数时单表单线程10000条数据插入耗时不足3秒。同时关闭binlog_commit_wait_usec时单表单线程10000条数据插入耗时5秒多。binlog_commit_wait_usec取6000/默认值/2倍默认值差别不大,所以建议使用默认参数即可。
相关文章推荐
- IO模式设置网络编程常见问题总结—IO模式设置,阻塞与非阻塞的比较,recv参数对性能的影响—O_NONBLOCK(open使用)、IPC_NOWAIT(msgrcv)、MSG_DONTWAIT(re
- IO模式设置网络编程常见问题总结—IO模式设置,阻塞与非阻塞的比较,recv参数对性能的影响—O_NONBLOCK(open使用)、IPC_NOWAIT(msgrcv)、MSG_DONTWAIT(re
- JVM无法分配问题(系统性能参数调优)
- IO模式设置网络编程常见问题总结—IO模式设置,阻塞与非阻塞的比较,recv参数对性能的影响—O_NONBLOCK(open使用)、IPC_NOWAIT(msgrcv)、MSG_DONTWAIT(re
- IO模式设置网络编程常见问题总结—IO模式设置,阻塞与非阻塞的比较,recv参数对性能的影响—O_NONBLOCK(open使用)、IPC_NOWAIT(msgrcv)、MSG_DONTWAIT(re
- 优化Linux下的内核TCP参数以提高系统性能 (TIME_WAIT处理)
- IO模式设置网络编程常见问题总结—IO模式设置,阻塞与非阻塞的比较,recv参数对性能的影响—O_NONBLOCK(open使用)、IPC_NOWAIT(msgrcv)、MSG_DONTWAIT(re
- 将日志信息(系统性能参数)记录到MongoDB --- 2:写入记录
- wait_fences: failed to receive reply: 10004003问题的引起原因
- 采购订单手工录价和系统给价的定价方式引起的问题
- 优化Linux下的内核TCP参数以提高系统性能
- 系统IO性能参数及不同方案关注点
- 一个大小写引起的SVN无法Commit的问题
- Java_JavaEE_SSH_hibernate向mysql插入数据引起中文乱码问题
- TIME_WAIT状态引起的服务端重启失败问题
- SQLite数据库指令参数出现中文引起执行异常问题处理
- golang函数可变参数传递性能问题
- 解决 C++ 操作 MySQL 大量数据插入效率低下问题
- fsck 修复ext3文件系统(用于linux系统时间不对,文件系统信息有错引起的die with exit status等的一些问题)
- 理解LGWR,Log File Sync Waits以及Commit的性能问题[转]