MySQL服务器上CPU系统时间占用率高

有点背景了，前段时间我们开始在我们的一个MySQL数据库上经历了很高的CPU系统时间。该数据库还受到磁盘利用率高的困扰，因此我们认为这些东西是连接的。由于我们已经计划将其迁移到SSD，因此我们认为它将解决这两个问题。

它有帮助...但是持续了很长时间。

迁移后的几周内，CPU图形如下：

但是现在我们回到了这一点：

这无处不在，没有在负载或应用程序逻辑上进行任何明显的更改。

数据库统计：

• MySQL版本-5.7.20
• 操作系统-Debian
• DB大小-1.2Tb
• 内存-700Gb
• CPU核心-56
• 窥探负载-大约5kq / s的读取，600q / s的写入（尽管选择查询通常非常复杂）
• 线程-50个正在运行，300个已连接
• 它有大约300个表，全部是InnoDB

MySQL配置：

[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /opt/mysql-data
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
explicit_defaults_for_timestamp

sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

log-error = /opt/mysql-log/error.log

# Replication

server-id = 76

gtid-mode = ON
enforce-gtid-consistency = true

relay-log = /opt/mysql-log/mysql-relay-bin
relay-log-index = /opt/mysql-log/mysql-relay-bin.index
replicate-wild-do-table = dbname.%

log-bin = /opt/mysql-log/mysql-bin.log
expire_logs_days = 7
max_binlog_size = 1024M
binlog-format = ROW
log-bin-trust-function-creators = 1
log_slave_updates = 1

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

# Here goes

skip_name_resolve = 1
general_log = 0
slow_query_log = 1
slow_query_log_file = /opt/mysql-log/slow.log
long_query_time = 3

max_allowed_packet = 16M
max_connections = 700
max_execution_time = 200000

open_files_limit = 32000
table_open_cache = 8000
thread_cache_size = 128
innodb_buffer_pool_size = 550G
innodb_buffer_pool_instances = 28
innodb_log_file_size = 15G
innodb_log_files_in_group = 2
innodb_flush_method = O_DIRECT

max_heap_table_size = 16M
tmp_table_size = 128M
join_buffer_size = 1M
sort_buffer_size = 2M

innodb_lru_scan_depth = 256

query_cache_type = 0
query_cache_size = 0

innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:30G 

其他观察

PERF峰值加载期间的MySQL过程的：

68,31%    68,31%  mysqld  [kernel.kallsyms]    [k] _raw_spin_lock                                                                                                                                                                                                        
   - _raw_spin_lock                                                                                                                                                                                                                                                          
      + 51,63% 0x7fd118e9dbd9                                                                                                                                                                                                                                                
      + 48,37% 0x7fd118e9dbab                                                                                                                                                                                                                                                
+   37,36%     0,02%  mysqld  libc-2.19.so         [.] 0x00000000000f4bd9                                                                                                                                                                                                    
+   33,83%     0,01%  mysqld  libc-2.19.so         [.] 0x00000000000f4bab                                                                                                                                                                                                    
+   26,92%     0,00%  mysqld  libpthread-2.19.so   [.] start_thread                                                                                                                                                                                                          
+   26,82%     0,00%  mysqld  mysqld               [.] pfs_spawn_thread                                                                                                                                                                                                      
+   26,82%     0,00%  mysqld  mysqld               [.] handle_connection                                                                                                                                                                                                     
+   26,81%     0,01%  mysqld  mysqld               [.] do_command(THD*)                                                                                                                                                                                                      
+   26,65%     0,02%  mysqld  mysqld               [.] dispatch_command(THD*, COM_DATA const*, enum_server_command)                                                                                                                                                          
+   26,29%     0,01%  mysqld  mysqld               [.] mysql_parse(THD*, Parser_state*)                                                                                                                                                                                      
+   24,85%     0,01%  mysqld  mysqld               [.] mysql_execute_command(THD*, bool)                                                                                                                                                                                     
+   23,61%     0,00%  mysqld  mysqld               [.] handle_query(THD*, LEX*, Query_result*, unsigned long long, unsigned long long)                                                                                                                                       
+   23,54%     0,00%  mysqld  mysqld               [.] 0x0000000000374103                                                                                                                                                                                                    
+   19,78%     0,00%  mysqld  mysqld               [.] JOIN::exec()                                                                                                                                                                                                          
+   19,13%     0,15%  mysqld  mysqld               [.] sub_select(JOIN*, QEP_TAB*, bool)                                                                                                                                                                                     
+   13,86%     1,48%  mysqld  mysqld               [.] row_search_mvcc(unsigned char*, page_cur_mode_t, row_prebuilt_t*, unsigned long, unsigned long)                                                                                                                       
+    8,48%     0,25%  mysqld  mysqld               [.] ha_innobase::general_fetch(unsigned char*, unsigned int, unsigned int)                                                                                                                                                
+    7,93%     0,00%  mysqld  [unknown]            [.] 0x00007f40c4d7a6f8                                                                                                                                                                                                    
+    7,57%     0,00%  mysqld  mysqld               [.] 0x0000000000828f74                                                                                                                                                                                                    
+    7,25%     0,11%  mysqld  mysqld               [.] handler::ha_index_next_same(unsigned char*, unsigned char const*, unsigned int)                                                                                                                                       

它表明mysql在spin_locks上花费了大量时间。我希望从中获得一些线索，可悲的是，这些运气来自哪里。

高负载期间的查询配置文件显示大量上下文切换。我使用了MyTable中的select *，其中pk = 123，MyTable大约有90M行。配置文件输出：

Status               Duration CPU_user CPU_system Context_voluntary Context_involuntary Block_ops_in Block_ops_out Messages_sent Messages_received Page_faults_major Page_faults_minor Swaps Source_function       Source_file          Source_line
starting             0,000756 0,028000 0,012000   81                1                   0            0             0             0                 0                 0                 0                             
checking permissions 0,000057 0,004000 0,000000   4                 0                   0            0             0             0                 0                 0                 0     check_access          sql_authorization.cc 810
Opening tables       0,000285 0,008000 0,004000   31                0                   0            40            0             0                 0                 0                 0     open_tables           sql_base.cc          5650
init                 0,000304 0,012000 0,004000   31                1                   0            0             0             0                 0                 0                 0     handle_query          sql_select.cc        121
System lock          0,000303 0,012000 0,004000   33                0                   0            0             0             0                 0                 0                 0     mysql_lock_tables     lock.cc              323
optimizing           0,000196 0,008000 0,004000   20                0                   0            0             0             0                 0                 0                 0     optimize              sql_optimizer.cc     151
statistics           0,000885 0,036000 0,012000   99                6                   0            0             0             0                 0                 0                 0     optimize              sql_optimizer.cc     367
preparing            0,000794 0,000000 0,096000   76                2                   32           8             0             0                 0                 0                 0     optimize              sql_optimizer.cc     475
executing            0,000067 0,000000 0,000000   10                1                   0            0             0             0                 0                 0                 0     exec                  sql_executor.cc      119
Sending data         0,000469 0,000000 0,000000   54                1                   32           0             0             0                 0                 0                 0     exec                  sql_executor.cc      195
end                  0,000609 0,000000 0,016000   64                4                   0            0             0             0                 0                 0                 0     handle_query          sql_select.cc        199
query end            0,000063 0,000000 0,000000   3                 1                   0            0             0             0                 0                 0                 0     mysql_execute_command sql_parse.cc         4968
closing tables       0,000156 0,000000 0,000000   20                4                   0            0             0             0                 0                 0                 0     mysql_execute_command sql_parse.cc         5020
freeing items        0,000071 0,000000 0,004000   7                 1                   0            0             0             0                 0                 0                 0     mysql_parse           sql_parse.cc         5596
cleaning up          0,000533 0,024000 0,008000   62                0                   0            0             0             0                 0                 0                 0     dispatch_command      sql_parse.cc         1902

彼得·扎伊采夫做了后最近关于上下文切换，在那里，他说：

但是，在现实世界中，如果每个查询的上下文切换少于十个，我就不必担心争用会成为大问题。

但是它显示了600多个开关！

什么会导致这些症状，该怎么办？我会很高兴就此提出任何建议或信息，到目前为止，我所遇到的一切都是过时的和/或不确定的。

PS我将很乐意提供其他信息（如果需要）。

显示全局状态和显示变量的输出

我无法在这里发布，因为内容超出了发布大小限制。

显示全球状态
显示变量

iostat

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7,35    0,00    5,44    0,20    0,00   87,01

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
fd0               0,00     0,00    0,00    0,00     0,00     0,00     8,00     0,00   32,00   32,00    0,00  32,00   0,00
sda               0,04     2,27    0,13    0,96     0,86    46,52    87,05     0,00    2,52    0,41    2,80   0,28   0,03
sdb               0,21   232,57   30,86  482,91   503,42  7769,88    32,21     0,34    0,67    0,83    0,66   0,34  17,50

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9,98    0,00   77,52    0,46    0,00   12,04

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
fd0               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
sda               0,00     1,60    0,00    0,60     0,00     8,80    29,33     0,00    0,00    0,00    0,00   0,00   0,00
sdb               0,00   566,40   55,60  981,60   889,60 16173,60    32,90     0,84    0,81    0,76    0,81   0,51  53,28

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          11,83    0,00   72,72    0,35    0,00   15,10

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
fd0               0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
sda               0,00     2,60    0,00    0,40     0,00    12,00    60,00     0,00    0,00    0,00    0,00   0,00   0,00
sdb               0,00   565,20   51,60  962,80   825,60 15569,60    32,32     0,85    0,84    0,98    0,83   0,54  54,56

更新2018-03-15

> show global status like 'uptime%'
Uptime;720899
Uptime_since_flush_status;720899

> show global status like '%rollback'
Com_rollback;351422
Com_xa_rollback;0
Handler_rollback;371088
Handler_savepoint_rollback;0

每次提交刷新600q / s可能会达到当前旋转磁盘的极限。切换到SSD可以减轻压力。

快速解决方案（在获得SSD之前）可能是更改为以下设置：

innodb_flush_log_at_trx_commit = 2

但是请阅读有关进行此更改的警告。

具有该设置和 SSD，将使您进一步发展。

另一个可能的解决方法是将某些写入合并为一个COMMIT（不违反逻辑）。

几乎总是，CPU和/或I / O较高是由于索引质量较差和/或查询格式不正确所致。使用打开日志long_query_time=1，等待一段时间，然后查看结果。在手的查询，提供SELECT，EXPLAIN SELECT ...和SHOW CREATE TABLE。同上的写查询。通过这些，我们可能可以驯服CPU和/或I / O。即使您使用的当前设置3，pt-query-digest也可能会发现一些有趣的东西。

注意，在50个 “正在运行”的线程中，有很多争用；您可能注意到这可能导致切换等。我们需要获取查询才能更快地完成。使用5.7，系统可能会使 100个正在运行的线程崩溃。上下文切换，互斥锁，锁等增加到超过约64个，共同降低了每个线程的速度，从而导致吞吐量没有任何提高，而等待时间却越来越长。

对于分析问题的其他方法，请提供SHOW VARIABLES和SHOW GLOBAL STATUS？这里有更多讨论。

变量和状态分析

（对不起，解决您的问题没有任何提示。）

观察结果：

• 版本：5.7.20-log
• 700 GB的RAM
• 正常运行时间= 36d 13:21:34
• 您不在Windows上运行。
• 运行64位版本
• 您似乎正在完全（或主要）在运行InnoDB。

更重要的问题：

为复杂的查询创建了许多临时表，尤其是基于磁盘的临时表。我们希望慢速日志能够识别一些可以改进的查询（通过索引/重新格式化等）。其他指标是没有索引的连接和sort_merge_passes; 但是，这些都不是结论性的，我们需要查看查询。

Max_used_connections = 701是> = Max_connections = 700，因此可能有一些连接被拒绝。另外，如果那表明运行了 64个以上的线程，那么那时系统性能可能会受到影响。考虑通过限制客户端来限制连接数。您在使用Apache，Tomcat还是其他工具？70 Threads_running表示在执行此操作时SHOW，系统出现故障。

COMMIT在合理的情况下，增加每个语句的数量可能有助于执行某些操作。

innodb_log_file_size，其容量为15GB，超出了必要的大小，但我认为无需更改它。

数千张桌子通常不是一个好的设计。

eq_range_index_dive_limit = 200关注我，但我不知道该如何建议。这是一个故意的选择吗？

为什么会有这么多的CREATE + DROP程序？

为什么有那么多SHOW命令？

详细信息和其他观察结果：

( Innodb_buffer_pool_pages_flushed ) = 523,716,598 / 3158494 = 165 /sec -写（冲洗）-检查innodb_buffer_pool_size

( table_open_cache ) = 10,000 -要缓存的表描述符的数量-通常好几百个。

( (Innodb_buffer_pool_reads + Innodb_buffer_pool_pages_flushed) ) = ((61,040,718 + 523,716,598) ) / 3158494 = 185 /sec -InnoDB I / O

( Innodb_dblwr_pages_written/Innodb_pages_written ) = 459,782,684/523,717,889 = 87.8% -好像这些值应该相等？

( Innodb_os_log_written ) = 1,071,443,919,360 / 3158494 = 339226 /sec-这表明InnoDB有多忙。-非常忙的InnoDB。

( Innodb_log_writes ) = 110,905,716 / 3158494 = 35 /sec

( Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group / innodb_log_file_size ) = 1,071,443,919,360 / (3158494 / 3600) / 2 / 15360M = 0.0379 -比率-（请参阅分钟）

( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 3,158,494 / 60 * 15360M / 1071443919360 = 791-InnoDB日志轮换之间的分钟数，从5.6.8开始，可以动态更改。一定还要更改my.cnf。-（建议每两次轮换60分钟有点随意。）调整innodb_log_file_size。（无法在AWS中更改。）

( Com_rollback ) = 770,457 / 3158494 = 0.24 /sec-InnoDB中的回滚。-回滚频率过高可能表明应用程序逻辑效率低下。

( Innodb_row_lock_waits ) = 632,292 / 3158494 = 0.2 /sec-行锁延迟的频率。-可能是由可以优化的复杂查询引起的。

( Innodb_dblwr_writes ) = 97,725,876 / 3158494 = 31 /sec-“ Doublewrite缓冲区”写入磁盘。“ Doublewrites”是一种可靠性功能。一些较新的版本/配置不需要它们。-（其他问题的症状）

( Innodb_row_lock_current_waits ) = 13-InnoDB表上的操作当前正在等待的行锁数。零是很正常的。-发生了什么大事了？

( innodb_print_all_deadlocks ) = OFF-是否记录所有死锁。-如果您遇到死锁困扰，请将其打开。警告：如果您有很多死锁，这可能会在磁盘上写入很多内容。

( local_infile ) = ON -local_infile = ON是潜在的安全问题

( bulk_insert_buffer_size / _ram ) = 8M / 716800M = 0.00%-多行INSERT和LOAD DATA的缓冲区-太大可能会威胁RAM大小。太小会阻碍这种操作。

( Questions ) = 9,658,430,713 / 3158494 = 3057 /sec-查询（在SP之外）-“ qps”-> 2000 可能使服务器承受压力

( Queries ) = 9,678,805,194 / 3158494 = 3064 /sec-查询（包括SP内部）-> 3000 可能会使服务器承受压力

( Created_tmp_tables ) = 1,107,271,497 / 3158494 = 350 /sec -作为复杂SELECT的一部分创建“临时”表的频率。

( Created_tmp_disk_tables ) = 297,023,373 / 3158494 = 94 /sec- 作为复杂SELECT的一部分创建磁盘 “临时”表的频率-增加tmp_table_size和max_heap_table_size。在使用MEMORY代替MyISAM时检查临时表的规则。较小的架构或查询更改也许可以避免使用MyISAM。更好的索引和重新编制查询更有可能会有所帮助。

( (Com_insert + Com_update + Com_delete + Com_replace) / Com_commit ) = (693300264 + 214511608 + 37537668 + 0) / 1672382928 = 0.565-每次提交的语句（假设所有InnoDB）–低：可能有助于在事务中将查询分组在一起；高：长时间的交易使各种各样的事情紧张。

( Select_full_join ) = 338,957,314 / 3158494 = 107 /sec -不带索引的联接-向JOIN中使用的表添加合适的索引。

( Select_full_join / Com_select ) = 338,957,314 / 6763083714 = 5.0% -无索引连接选择的百分比-将适当的索引添加到JOIN中使用的表中。

( Select_scan ) = 124,606,973 / 3158494 = 39 /sec -全表扫描-添加索引/优化查询（除非它们是很小的表）

( Sort_merge_passes ) = 1,136,548 / 3158494 = 0.36 /sec -重分类-增加sort_buffer_size和/或优化复杂查询。

( Com_insert + Com_delete + Com_delete_multi + Com_replace + Com_update + Com_update_multi ) = (693300264 + 37537668 + 198418338 + 0 + 214511608 + 79274476) / 3158494 = 387 /sec -每秒写入-50次写入/秒+日志刷新可能会最大化普通驱动器的I / O写入容量

( ( Com_stmt_prepare - Com_stmt_close ) / ( Com_stmt_prepare + Com_stmt_close ) ) = ( 39 - 38 ) / ( 39 + 38 ) = 1.3%-您是否要关闭准备好的报表？-添加关闭。

( Com_stmt_close / Com_stmt_prepare ) = 38 / 39 = 97.4%-应关闭准备好的语句。-检查所有Prepared语句是否都为“ Closed”。

( innodb_autoinc_lock_mode ) = 1-加莱拉（Galera）：欲望2 – 2 =“交错”；1 =“连续”是典型的；0 =“传统”。

( Max_used_connections / max_connections ) = 701 / 700 = 100.1% -峰值连接百分比-增加max_connections和/或减少wait_timeout

( Threads_running - 1 ) = 71 - 1 = 70 -活动线程（收集数据时并发）–优化查询和/或架构

异常大：（ 其中大多数来自非常繁忙的系统。）

Com_commit = 529 /sec
Com_create_procedure = 0.01 /HR
Com_drop_procedure = 0.01 /HR
Com_delete = 12 /sec
Com_delete_multi = 63 /sec
Com_insert = 219 /sec
Com_kill = 0.69 /HR
Com_reset = 0.0011 /HR
Com_revoke = 0.0023 /HR
Com_select = 2141 /sec
Com_show_binlogs = 12 /HR
Com_show_create_func = 0.011 /HR
Com_show_privileges = 0.0034 /HR
Com_show_profile = 0.027 /HR
Com_show_profiles = 0.028 /HR
Com_show_slave_status = 0.037 /sec
Com_show_storage_engines = 12 /HR
Com_show_warnings = 0.14 /sec
Com_slave_stop = 0.0011 /HR
Com_update_multi = 25 /sec
Created_tmp_files = 0.3 /sec
Handler_commit = 3251 /sec
Handler_external_lock = 18787 /sec
Handler_prepare = 615 /sec
Handler_read_first = 239 /sec
Handler_read_key = 173669 /sec
Handler_read_next = 1291439 /sec
Handler_read_prev = 28535 /sec
Handler_read_rnd = 32789 /sec

（继续）

Innodb_buffer_pool_bytes_dirty = 7.03e+10
Innodb_buffer_pool_pages_data = 3.41e+7
Innodb_buffer_pool_pages_dirty = 4.29e+6
Innodb_buffer_pool_pages_misc = 2.15e+6
Innodb_buffer_pool_pages_total = 3.62e+7
Innodb_data_fsyncs = 132 /sec
Innodb_data_writes = 232 /sec
Innodb_data_written = 5440151 /sec
Innodb_dblwr_pages_written = 145 /sec
Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group = 582.3MB
Innodb_pages_written = 165 /sec
Innodb_row_lock_time = 5.97e+7
Innodb_rows_deleted + Innodb_rows_inserted = 2180 /sec
Innodb_rows_inserted = 2155 /sec
Innodb_rows_read = 1398531 /sec
Max_used_connections = 701
Open_tables = 10,000
Select_full_range_join = 2.57e+7
Select_range = 130 /sec
Sort_range = 30 /sec
Sort_scan = 332 /sec
Table_open_cache_hits = 9354 /sec
Threads_running = 71
eq_range_index_dive_limit = 200
innodb_purge_threads = 4
innodb_thread_sleep_delay = 16,925

我们从未弄清楚是什么原因导致此问题，但是为了提供一些解决方法，我将告诉我可以解决的问题。

我们的团队进行了一些负载测试，得出的结论是MySQL分配内存有麻烦。因此他们尝试使用jemalloc代替，glibc问题消失了。我们已经jemalloc在生产中使用超过6个月，而再也没有看到此问题。

我并不是说这jemalloc更好，或者每个人都应该将其与结合使用MySQL。但是对于我们的具体情况来说似乎glibc运作不当。

我的2美分。

运行“ iostat -xk 5”以尝试查看磁盘是否仍然存在问题。CPU系统也与系统代码（kernell）有关，请仔细检查新的磁盘/驱动程序/配置。

对my.cnf / ini [mysqld]部分的建议，非常忙

max_heap_table_size=128M  # from 16M to match tmp_table_size
innodb_lru_scan_depth=100  # from 256 to reduce depth every second
innodb_change_buffer_max_size=15  # from 25 max used misc is 6%
innodb_flush_neighbors=0  # from 1 with SSD there is no rotational delay
innodb_read_ahead_threshold=8  # from 56 to expedite RD nxt extent
read_rnd_buffer_size=128K  # from 256K to reduce RD RPS

我的期望是，像“ innodb_buffer_pool_pages_dirty”这样的SHOW GLOBAL STATUS的结果逐渐减少；应用这些建议。在1/13/18，您有超过4M的脏页。

希望这些帮助。这些可以动态修改。还有更多机会，如果您需要，请告诉我。

在测试了30K IOPS（我们需要大量IOPS进行随机写入）的情况下，请考虑my.cnf / ini [mysqld]部分的建议

innodb_io_capacity_max=20000  # from 2000 and keep top 10000 free for now
innodb_io_capacity=10000  # from 200 to ensure we stay away from the limits

可以使用SET GLOBAL进行动态更改，并应迅速减少innodb_buffer_pool_pages_dirty。

COM_ROLLBACK每4秒平均为1的原因将一直存在性能问题，直到解决。

@chimmi 2018年4月9日，从https://pastebin.com/aZAu2zZ0提取此MySQL脚本 ，以快速检查可以在SLEEP中设置的已使用或已释放nn秒的全局状态资源。这将使您查看是否有人帮助降低您的COM_ROLLBACK频率。希望通过电子邮件收到您的来信。

您的SHOW GLOBAL STATUS表示innodb_buffer_pool_pages_dirty为4,291,574。

要监视当前计数，

SHOW GLOBAL STATUS LIKE '%pages_dirty';

为了鼓励减少此数量，

SET GLOBAL innodb_flushing_avg_loops=5;

在一个小时内，运行监控器请求以查看页面脏污的情况。

请在开始和一个小时后让我知道您的人数。

将更改应用到my.cnf可以长期改善页面不脏状况。