本系统使用了docker搭建mysql，redis，java环境
top发现load average就算在没什么压力的情况总是保持在5以上，cpu使用率不高，内存也正常
于是检查磁盘io，
iostat -x -k -d 1时%util经常会到90
iotop时有个[jdb2/sda2]的长时间占用io
jbd的全拼是journaling block driver 文件系统的日志功能，jbd2是ext4文件系统版本；可以肯定的是对文件系统的操作太频繁，导致IO压力过大。
导致jbd2 io高的原因有：
1.磁盘故障
2.kernel问题
3.进程的sync操作频繁
主要针对sync操作频繁进行检查
1.先开启内核trace检查
echo 1 > /sys/kernel/debug/tracing/events/jbd2/jbd2_commit_flushing/enable
echo 1 > /sys/kernel/debug/tracing/events/ext4/ext4_sync_file_enter/enable
cat /sys/kernel/debug/tracing/trace_pipe
输出结果：
-
jbd2/sda3-8-506 [002] .... 1090561.509809: jbd2_commit_flushing: dev 8,3 transaction 7037013 sync 0
-
mysqld-2507 [002] .... 1090561.559324: ext4_sync_file_enter: dev 8,3 ino 27107339 parent 27107332 datasync 0
-
mysqld-2507 [001] .... 1090561.583960: ext4_sync_file_enter: dev 8,3 ino 27107471 parent 27107462 datasync 0
-
mysqld-2507 [001] .... 1090561.603836: ext4_sync_file_enter: dev 8,3 ino 27107473 parent 27107462 datasync 0
-
mysqld-2513 [006] .... 1090562.186306: ext4_sync_file_enter: dev 8,3 ino 27107337 parent 27107332 datasync 0
-
jbd2/sda3-8-506 [002] .... 1090562.186528: jbd2_commit_flushing: dev 8,3 transaction 7037014 sync 0
-
mysqld-2516 [003] .... 1090565.296380: ext4_sync_file_enter: dev 8,3 ino 27107334 parent 27107332 datasync 0
-
jbd2/sda3-8-506 [001] .... 1090565.299525: jbd2_commit_flushing: dev 8,3 transaction 7037015 sync 0
-
mysqld-2516 [007] .... 1090565.393030: ext4_sync_file_enter: dev 8,3 ino 27107334 parent 27107332 datasync 0
-
jbd2/sda3-8-506 [005] .... 1090565.393183: jbd2_commit_flushing: dev 8,3 transaction 7037016 sync 0
-
mysqld-2509 [010] .... 1090565.453053: ext4_sync_file_enter: dev 8,3 ino 27107333 parent 27107332 datasync 0
-
jbd2/sda3-8-506 [001] .... 1090565.453682: jbd2_commit_flushing: dev 8,3 transaction 7037017 sync 0
-
mysqld-2506 [005] .... 1090565.502064: ext4_sync_file_enter: dev 8,3 ino 27107333 parent 27107332 datasync 0
-
jbd2/sda3-8-506 [002] .... 1090565.502375: jbd2_commit_flushing: dev 8,3 transaction 7037018 sync 0
-
mysqld-2516 [002] .... 1090565.508614: ext4_sync_file_enter: dev 8,3 ino 27107334 parent 27107332 datasync 0
-
jbd2/sda3-8-506 [001] .... 1090565.628007: jbd2_commit_flushing: dev 8,3 transaction 7037019 sync 0
-
mysqld-2506 [003] .... 1090565.628038: ext4_sync_file_enter: dev 8,3 ino 27107473 parent 27107462 datasync 0
-
mysqld-2506 [001] .... 1090565.818821: ext4_sync_file_enter: dev 8,3 ino 27107336 parent 27107332 datasync 0
-
mysqld-2516 [003] .... 1090565.818928: ext4_sync_file_enter: dev 8,3 ino 27107334 parent 27107332 datasync 0
-
jbd2/sda3-8-506 [002] .... 1090565.819140: jbd2_commit_flushing: dev 8,3 transaction 7037020 sync 0
-
mysqld-2513 [007] .... 1090565.844790: ext4_sync_file_enter: dev 8,3 ino 27107337 parent 27107332 datasync 0
-
jbd2/sda3-8-506 [001] .... 1090565.888444: jbd2_commit_flushing: dev 8,3 transaction 7037021 sync 0
-
mysqld-2509 [010] .... 1090566.453295: ext4_sync_file_enter: dev 8,3 ino 27107333 parent 27107332 datasync 0
-
jbd2/sda3-8-506 [001] .... 1090566.453648: jbd2_commit_flushing: dev 8,3 transaction 7037022 sync 0
-
mysqld-2505 [003] .... 1090566.602429: ext4_sync_file_enter: dev 8,3 ino 27107333 parent 2710733
大量的mysql datasync
使用strace看一下它在做什么
strace -f -p 2505
试着优化mysql减少io
set global sync_binlog=100;
set global innodb_flush_log_at_trx_commit=2;
这种控制通过变量 innodb_flush_log_at_trx_commit 的值来决定。该变量有3种值：0、1、2，默认为1。但注意，这个变量只是控制commit动作是否刷新log buffer到磁盘。
-
当设置为1的时候，事务每次提交都会将log buffer中的日志写入os buffer并调用fsync()刷到log file on disk中。这种方式即使系统崩溃也不会丢失任何数据，但是因为每次提交都写入磁盘，IO的性能较差。
-
当设置为0的时候，事务提交时不会将log buffer中日志写入到os buffer，而是每秒写入os buffer并调用fsync()写入到log file on disk中。也就是说设置为0时是(大约)每秒刷新写入到磁盘中的，当系统崩溃，会丢失1秒钟的数据。
-
当设置为2的时候，每次提交都仅写入到os buffer，然后是每秒调用fsync()将os buffer中的日志写入到log file on disk。
在主从复制结构中，要保证事务的持久性和一致性，需要对日志相关变量设置为如下：
-
如果启用了二进制日志，则设置sync_binlog=1，即每提交一次事务同步写到磁盘中。
-
总是设置innodb_flush_log_at_trx_commit=1，即每提交一次事务都写到磁盘中。
上述两项变量的设置保证了：每次提交事务都写入二进制日志和事务日志，并在提交时将它们刷新到磁盘中。
jbd2的io明显的下降了, load average也相应的降下来了。
2020-12-19
这个方法没能解决系统慢的问题，下一步检查业务和缓存策略。
阅读(3918) | 评论(0) | 转发(0) |
