MySQLサーバーでのCPUシステム時間の使用率が高い
少し前に、MySQLデータベースの1つで高いCPUシステム時間を経験し始めました。このデータベースもディスク使用率が高いため、それらが接続されていることがわかりました。また、SSDへの移行をすでに計画していたため、両方の問題を解決できると考えました。
それは役に立ちました...しかし、長くはありませんでした。
移行後2週間、CPUグラフは次のようになりました： 
しかし、今はこれに戻ります： 
これはどこからともなく発生し、負荷やアプリケーションロジックに明らかな変化はありませんでした。
DB統計：
- MySQLバージョン-5.7.20
- OS-Debian
- DBサイズ-1.2Tb
- RAM-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
その他の観察
ピーク負荷時のmysqlプロセスのperf：
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に多くの時間を費やしていることを示しています。残念ながら運が悪いのに、これらのロックがどこから来ているのかについての手掛かりを得ることを望んでいました。
高負荷時のクエリプロファイルは、極端な量のコンテキストスイッチを示します。私はselect * from MyTableを使用しました（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
Peter Zaitsevは最近コンテキストスイッチについて post を作成しました。
ただし、現実の世界では、クエリごとのコンテキストスイッチが10未満であれば、競合が大きな問題になることを心配する必要はありません。
しかし、600を超えるスイッチが表示されます。
何がこれらの症状を引き起こし、それに対して何ができるのでしょうか？私はこの問題に関するポインタや情報に感謝します。これまでに出くわしたすべてはかなり古く、そして/または決定的ではありません。
追伸必要に応じて、追加情報を喜んで提供します。
SHOW GLOBAL STATUSおよびSHOW VARIABLESの出力
投稿サイズ制限を超えているため、こちらに投稿できません。
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
この問題の正確な原因がわからなかったのですが、いくつかの閉鎖を提供するために、何ができるかをお話します。
私たちのチームはいくつかの負荷テストを行い、MySQLがメモリの割り当てに問題があると結論付けました。そのため、彼らはjemallocの代わりにglibcを使用してみましたが、問題は解決しました。 jemallocを本番環境で6か月以上使用していますが、この問題は二度と発生しません。
jemallocの方が優れているとか、誰もがMySQLと一緒に使うべきだと言っているのではありません。しかし、私たちの特定のケースでは、glibcが正しく機能していなかったようです。
コミットごとのフラッシュを伴う600q/sの書き込みは、おそらく現在の回転ディスクの制限に達しています。 SSDに切り替えると、プレッシャーが軽減されます。
（SSDを取得する前の）迅速な修正は、おそらくこの設定に変更することです：
innodb_flush_log_at_trx_commit = 2
しかし、その変更を行う際の警告を読んでください。
その設定and SSDがあれば、さらに成長できます。
別の可能な修正は、いくつかの書き込みを単一のCOMMITに結合することです（ロジックに違反していない場合）。
ほとんどの場合、CPUやI/Oが高いのは、インデックスが不十分であるか、クエリの形式が不適切であるか、あるいはその両方が原因です。 long_query_time=1でスローログをオンにし、しばらく待ってから、何が表示されるかを確認します。クエリを入手したら、SELECT、EXPLAIN SELECT ...、SHOW CREATE TABLEを提供します。書き込みクエリの同上。これらから、おそらくCPUやI/Oを使いこなすことができます。現在の設定が3であっても、pt-query-digestは興味深いものを見つける可能性があります。
5 "実行中"のスレッドでは、多くの競合があることに注意してください。これは、ご指摘のスイッチングなどを引き起こしている可能性があります。クエリをより速く完了する必要があります。 5.7では、システムmay 100 runningスレッドでキールオーバーします。コンテキストスイッチ、ミューテックス、ロックなどのコンテキストスイッチ、ミューテックス、ロックなどが増加すると、すべてのスレッドの速度が低下し、throughputが改善されず、latencyが機能しなくなります。
問題を分析する別の方法については、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スレッド以上runningを示している場合、その時点でシステムパフォーマンスが低下している可能性があります。クライアントを調整することで接続数を調整することを検討してください。 Apache、Tomcatなどを使用していますか？ 70 Threads_runningは、これを実行しているときにSHOWでシステムに問題が発生したことを示します。
各COMMITのステートメントの数を増やす（妥当な場合）と、パフォーマンスが向上する場合があります。
innodb_log_file_sizeは15 GBで、必要以上に大きいですが、変更する必要はないようです。
通常、数千のテーブルは良い設計ではありません。
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のROLLBACK。 -ロールバックの頻度が多すぎる場合は、アプリのロジックが非効率的である可能性があります。
( Innodb_row_lock_waits ) = 632,292 / 3158494 = 0.2 /sec-行ロックの取得に遅延が発生する頻度。 -最適化できる複雑なクエリが原因である可能性があります。
( Innodb_dblwr_writes ) = 97,725,876 / 3158494 = 31 /sec-「ダブルライトバッファ」はディスクに書き込みます。 「ダブルライト」は信頼性の高い機能です。新しいバージョン/構成の中には、それらを必要としないものがあります。 -（その他の問題の症状）
( 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 mayサーバーにストレスをかける
( Queries ) = 9,678,805,194 / 3158494 = 3064 /sec-クエリ（SP内を含む）-> 3000 mayサーバーにストレスをかける
( Created_tmp_tables ) = 1,107,271,497 / 3158494 = 350 /sec-複雑なSELECTの一部として「temp」テーブルを作成する頻度。
( Created_tmp_disk_tables ) = 297,023,373 / 3158494 = 94 /sec-複雑なSELECTの一部としての作成頻度disk "temp"テーブル-tmp_table_sizeとmax_heap_table_sizeを増やします。 MyISAMの代わりにMEMORYを使用する場合の一時テーブルのルールを確認してください。おそらく、マイナーなスキーマまたはクエリの変更により、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
私の2セント。
「iostat -xk 5」を実行して、ディスクにまだ問題があるかどうかを確認してください。また、CPUシステムはシステムコード（カーネル）に関連しています。新しいdisk/drivers/configを再確認してください。
非常に忙しい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
私の期待は、SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_pages_dirty'の結果が徐々に減少することです。これらの提案を適用しました。 1/13/18には、400万を超えるダーティページがありました。
これらがお役に立てば幸いです。これらは動的に変更できます。さらに多くの機会が存在します。それらが必要な場合は、お知らせください。
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/aZAu2zZ からこの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;
1時間以内に監視リクエストを実行して、ページが汚れている状態を確認します。
最初と1時間後にカウントを教えてください。
My.cnfに変更を適用して、ページのダーティリダクションを長期的に改善します。