MySQLインスタンスが「同期インデックスを実行中」にストールする

12

問題

InnoDBテーブルを持つデータベースを実行する（ほとんどの場合）MySQL 5.6.20のインスタンスは、すべてのINSERT、UPDATE、およびDELETEクエリが「クエリ終了」状態のままで、1〜4分間、すべての更新操作に対して時々ストールします。これは明らかに最も不幸なことです。MySQLのスロークエリログは、非常に些細なクエリでさえ、異常なクエリ時間を記録しています。何百ものものが、失速が解決された時点に対応する同じタイムスタンプで記録されます。

# Query_time: 101.743589  Lock_time: 0.000437 Rows_sent: 0  Rows_examined: 0
SET timestamp=1409573952;
INSERT INTO sessions (redirect_login2, data, hostname, fk_users_primary, fk_users, id_sessions, timestamp) VALUES (NULL, NULL, '192.168.10.151', NULL, 'anonymous', '64ef367018099de4d4183ffa3bc0848a', '1409573850');

デバイス統計は増加していますが、この時間枠ではI / Oの負荷は過剰ではありません（この場合、上記のステートメントのタイムスタンプによると、更新は14:17:30から14:19:12に失速しました）。

# sar -d
[...]
02:15:01 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
02:16:01 PM    dev8-0     41.53    207.43   1227.51     34.55      0.34      8.28      3.89     16.15
02:17:01 PM    dev8-0     59.41    137.71   2240.32     40.02      0.39      6.53      4.04     24.00
02:18:01 PM    dev8-0    122.08   2816.99   1633.44     36.45      3.84     31.46      1.21      2.88
02:19:01 PM    dev8-0    253.29   5559.84   3888.03     37.30      6.61     26.08      1.85      6.73
02:20:01 PM    dev8-0    101.74   1391.92   2786.41     41.07      1.69     16.57      3.55     36.17
[...]
# sar
[...]
02:15:01 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
02:16:01 PM     all     15.99      0.00     12.49      2.08      0.00     69.44
02:17:01 PM     all     13.67      0.00      9.45      3.15      0.00     73.73
02:18:01 PM     all     10.64      0.00      6.26     11.65      0.00     71.45
02:19:01 PM     all      3.83      0.00      2.42     24.84      0.00     68.91
02:20:01 PM     all     20.95      0.00     15.14      6.83      0.00     57.07

たいていの場合、mysqlのスローログで、最も古いクエリのストールは、VARCHARプライマリキーと全文検索インデックスを持つ大規模な（〜10 M行）テーブルへのINSERTであることがわかります。

CREATE TABLE `files` (
  `id_files` varchar(32) NOT NULL DEFAULT '',
  `filename` varchar(100) NOT NULL DEFAULT '',
  `content` text,
  PRIMARY KEY (`id_files`),
  KEY `filename` (`filename`),
  FULLTEXT KEY `content` (`content`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

さらなる調査（SHOW ENGINE INNODB STATUS）では、実際に常にフルテキストインデックスを使用したテーブルの更新が停止の原因であることが示されています。「SHOW ENGINE INNODB STATUS」のそれぞれのTRANSACTIONSセクションには、実行中の最も古いトランザクションに関する次の2つのようなエントリがあります。

---TRANSACTION 162269409, ACTIVE 122 sec doing SYNC index
6 lock struct(s), heap size 1184, 0 row lock(s), undo log entries 19942
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_1" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_2" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_3" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_4" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_5" trx id 162269409 lock mode IX
TABLE LOCK table "vw"."FTS_000000000000224a_00000000000036b9_INDEX_6" trx id 162269409 lock mode IX
---TRANSACTION 162269408, ACTIVE (PREPARED) 122 sec committing
mysql tables in use 1, locked 1
1 lock struct(s), heap size 360, 0 row lock(s), undo log entries 1
MySQL thread id 165998, OS thread handle 0x7fe0e239c700, query id 91208956 192.168.10.153 root query end
INSERT INTO files (id_files, filename, content) VALUES ('f19e63340fad44841580c0371bc51434', '1237716_File_70380a686effd6b66592bb5eeb3d9b06.doc', '[...]
TABLE LOCK table `vw`.`files` trx id 162269408 lock mode IX

そのため、重いフルテキストインデックスアクションが実行されています（doing SYNC index）、すべてのテーブルに対するすべての後続更新が停止します。

ログから、のundo log entries数doing SYNC indexは20,000に達するまで〜150 / sで進んでおり、その時点で操作が完了しているように見えます。

この特定のテーブルのFTSサイズは非常に印象的です。

# du -c FTS_000000000000224a_00000000000036b9_*
614404  FTS_000000000000224a_00000000000036b9_INDEX_1.ibd
2478084 FTS_000000000000224a_00000000000036b9_INDEX_2.ibd
1576964 FTS_000000000000224a_00000000000036b9_INDEX_3.ibd
1630212 FTS_000000000000224a_00000000000036b9_INDEX_4.ibd
1978372 FTS_000000000000224a_00000000000036b9_INDEX_5.ibd
1159172 FTS_000000000000224a_00000000000036b9_INDEX_6.ibd
9437208 total

この問題は、次のようなFTSデータサイズが大幅に小さいテーブルでも引き起こされます。

# du -c FTS_0000000000002467_0000000000003a21_INDEX*
49156   FTS_0000000000002467_0000000000003a21_INDEX_1.ibd
225284  FTS_0000000000002467_0000000000003a21_INDEX_2.ibd
147460  FTS_0000000000002467_0000000000003a21_INDEX_3.ibd
135172  FTS_0000000000002467_0000000000003a21_INDEX_4.ibd
155652  FTS_0000000000002467_0000000000003a21_INDEX_5.ibd
106500  FTS_0000000000002467_0000000000003a21_INDEX_6.ibd
819224  total

これらの場合の失速の時間もほぼ同じです。開けました開発者がこれを調べることができるように、bugs.mysql.comでバグた。

屋台の性質により、最初にログフラッシュアクティビティが原因であると疑われました。 疑われ、MySQL 5.5のログフラッシュパフォーマンスの問題に関するこのPerconaの記事では、非常によく似た症状が説明されていますが、このデータベースの単一のMyISAMテーブルへのINSERT操作ストールの影響も受けるため、これはInnoDBのみの問題ではないようです。

それにもかかわらず、10秒ごとの「LOG」セクションの出力の値を追跡することにLog sequence numberし Pages flushed up toました。2つの値の間の広がりが減少しているため、ストール中にフラッシュアクティビティが継続しているように見えます。SHOW ENGINE INNODB STATUS

Mon Sep 1 14:17:08 CEST 2014 LSN: 263992263703, Pages flushed: 263973405075, Difference: 18416 K
Mon Sep 1 14:17:19 CEST 2014 LSN: 263992826715, Pages flushed: 263973811282, Difference: 18569 K
Mon Sep 1 14:17:29 CEST 2014 LSN: 263993160647, Pages flushed: 263974544320, Difference: 18180 K
Mon Sep 1 14:17:39 CEST 2014 LSN: 263993539171, Pages flushed: 263974784191, Difference: 18315 K
Mon Sep 1 14:17:49 CEST 2014 LSN: 263993785507, Pages flushed: 263975990474, Difference: 17377 K
Mon Sep 1 14:17:59 CEST 2014 LSN: 263994298172, Pages flushed: 263976855227, Difference: 17034 K
Mon Sep 1 14:18:09 CEST 2014 LSN: 263994670794, Pages flushed: 263978062309, Difference: 16219 K
Mon Sep 1 14:18:19 CEST 2014 LSN: 263995014722, Pages flushed: 263983319652, Difference: 11420 K
Mon Sep 1 14:18:30 CEST 2014 LSN: 263995404674, Pages flushed: 263986138726, Difference: 9048 K
Mon Sep 1 14:18:40 CEST 2014 LSN: 263995718244, Pages flushed: 263988558036, Difference: 6992 K
Mon Sep 1 14:18:50 CEST 2014 LSN: 263996129424, Pages flushed: 263988808179, Difference: 7149 K
Mon Sep 1 14:19:00 CEST 2014 LSN: 263996517064, Pages flushed: 263992009344, Difference: 4402 K
Mon Sep 1 14:19:11 CEST 2014 LSN: 263996979188, Pages flushed: 263993364509, Difference: 3529 K
Mon Sep 1 14:19:21 CEST 2014 LSN: 263998880477, Pages flushed: 263993558842, Difference: 5196 K
Mon Sep 1 14:19:31 CEST 2014 LSN: 264001013381, Pages flushed: 263993568285, Difference: 7270 K
Mon Sep 1 14:19:41 CEST 2014 LSN: 264001933489, Pages flushed: 263993578961, Difference: 8158 K
Mon Sep 1 14:19:51 CEST 2014 LSN: 264004225438, Pages flushed: 263993585459, Difference: 10390 K

そして14:19:11に広がりが最小に達したので、ここでフラッシング活動は停止したようで、失速の終わりにちょうど一致します。しかし、これらの点から、InnoDBログフラッシュを原因として却下しました。

  • フラッシュ操作がデータベースへのすべての更新をブロックするには、「同期」である必要があります。つまり、ログスペースの7/8を占有する必要があります。
  • innodb_max_dirty_pages_pctフィルレベルで始まる「非同期」フラッシュフェーズが先行します。
  • LSNはストール中も増加し続けるため、ログアクティビティは完全に停止しません
  • MyISAMテーブルのINSERTも影響を受けます
  • アダプティブフラッシュのpage_cleanerスレッドは、DMLクエリを停止させることなく動作し、ログをフラッシュするようです：

LSN-PagesFlushed

（数字は([Log Sequence Number] - [Pages flushed up to]) / 1024からSHOW ENGINE INNODB STATUS）

この問題は、設定により多少緩和されたようです innodb_adaptive_flushing_lwm=1ようで、ページクリーナーに以前よりも多くの作業を行わせます。

にerror.logはストールと一致するエントリはありません。SHOW INNODB STATUS約24時間の操作後の抜粋は次のようになります。

SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 789330
OS WAIT ARRAY INFO: signal count 1424848
Mutex spin waits 269678, rounds 3114657, OS waits 65965
RW-shared spins 941620, rounds 20437223, OS waits 442474
RW-excl spins 451007, rounds 13254440, OS waits 215151
Spin rounds per wait: 11.55 mutex, 21.70 RW-shared, 29.39 RW-excl
------------------------
LATEST DETECTED DEADLOCK
------------------------
2014-09-03 10:33:55 7fe0e2e44700
[...]
--------
FILE I/O
--------
[...]
932635 OS file reads, 2117126 OS file writes, 1193633 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 17.00 writes/s, 1.20 fsyncs/s
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Main thread process no. 54745, id 140604272338688, state: sleeping
Number of rows inserted 528904, updated 1596758, deleted 99860, read 3325217158
5.40 inserts/s, 10.40 updates/s, 0.00 deletes/s, 122969.21 reads/s

したがって、はい、データベースにはデッドロックがありますが、それらは非常にまれです（「最新」は統計が読み込まれる約11時間前に処理されました）。

特に通常の操作やストール中に、「SEMAPHORES」セクションの値を一定期間追跡しようとしました（MySQLサーバーのプロセスリストをチェックし、いくつかの診断コマンドをログ出力に実行する小さなスクリプトを作成しました明らかな失速の）。数値はさまざまな時間枠にわたって取得されているため、結果をイベント/秒に正規化しました。

                          normal   stall
                          1h avg  1m avg
OS WAIT ARRAY INFO: 
    reservation count      5,74    1,00
    signal count          24,43    3,17
Mutex spin waits           1,32    5,67
    rounds                 8,33   25,85
    OS waits               0,16    0,43
RW-shared spins            9,52    0,76
    rounds               140,73    13,39
    OS waits               2,60    0,27
RW-excl spins              6,36    1,08
    rounds               178,42   16,51
    OS waits               2,38    0,20

ここで何を見ているのかよくわかりません。ほとんどの数値は桁違いに減少しています-おそらく更新操作の中止、「Mutex spin waits」と「Mutex spin rounds」が原因で、両方とも4倍に増加しています。

これをさらに調査すると、ミューテックス（SHOW ENGINE INNODB MUTEX）のリストには、通常の動作時とストール時の両方で、〜480のmutexエントリがリストされています。innodb_status_output_locksそれが私にもっと詳細を提供するかどうかを見ることができるようになりました。

構成変数

（私はそれらのほとんどを明確な成功なしにいじくりました）：

mysql> show global variables where variable_name like 'innodb_adaptive_flush%';
+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| innodb_adaptive_flushing     | ON    |
| innodb_adaptive_flushing_lwm | 1     |
+------------------------------+-------+
mysql> show global variables where variable_name like 'innodb_max_dirty_pages_pct%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_max_dirty_pages_pct     | 50    |
| innodb_max_dirty_pages_pct_lwm | 10    |
+--------------------------------+-------+
mysql> show global variables where variable_name like 'innodb_log_%';
+-----------------------------+-----------+
| Variable_name               | Value     |
+-----------------------------+-----------+
| innodb_log_buffer_size      | 8388608   |
| innodb_log_compressed_pages | ON        |
| innodb_log_file_size        | 268435456 |
| innodb_log_files_in_group   | 2         |
| innodb_log_group_home_dir   | ./        |
+-----------------------------+-----------+
mysql> show global variables where variable_name like 'innodb_double%';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| innodb_doublewrite | ON    |
+--------------------+-------+
mysql> show global variables where variable_name like 'innodb_buffer_pool%';
+-------------------------------------+----------------+
| Variable_name                       | Value          |
+-------------------------------------+----------------+
| innodb_buffer_pool_dump_at_shutdown | OFF            |
| innodb_buffer_pool_dump_now         | OFF            |
| innodb_buffer_pool_filename         | ib_buffer_pool |
| innodb_buffer_pool_instances        | 8              |
| innodb_buffer_pool_load_abort       | OFF            |
| innodb_buffer_pool_load_at_startup  | OFF            |
| innodb_buffer_pool_load_now         | OFF            |
| innodb_buffer_pool_size             | 29360128000    |
+-------------------------------------+----------------+
mysql> show global variables where variable_name like 'innodb_io_capacity%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| innodb_io_capacity     | 200   |
| innodb_io_capacity_max | 2000  |
+------------------------+-------+
mysql> show global variables where variable_name like 'innodb_lru_scan_depth%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_lru_scan_depth | 1024  |
+-----------------------+-------+

すでに試したこと

  • クエリキャッシュを無効にする SET GLOBAL query_cache_size=0
  • 増加している innodb_log_buffer_size128Mに
  • 遊んでinnodb_adaptive_flushing、innodb_max_dirty_pages_pctそれぞれの_lwmの値（それがデフォルトに設定された私の変化に先立って）
  • 増加innodb_io_capacity（2000）およびinnodb_io_capacity_max（4000）
  • セッティング innodb_flush_log_at_trx_commit = 2
  • innodb_flush_method = O_DIRECTで実行（はい、永続的な書き込みキャッシュを備えたSANを使用します）
  • / sys / block / sda / queue / schedulerの設定noopまたはdeadline
mysql  innodb  myisam  mysql-5.6 
— syneticon-dj
ソース
innodb_io_capacity、innodb_io_capacity_max、innodb_lru_scan_depthの値は何ですか？これらの値をより高い（より適切な）値に設定すると、ログ領域を解放できます。
— モーガントッカー14
デフォルト-200、2000、および1024。2000、4000、および2000に変更し、LSNとページフラッシュ値の間のスプレッドが再び<1,000 Kに減少しました。しかし、これがログの問題かどうかわかりませんそもそもスペース。
— syneticon-dj 14
確かにそうではないようです。私はまだ屋台を見ています-それらは発生の期間や頻度であまり変化していません。私のLSN /チェックポイントロギングは、ストール中に1-2分で約3 Mにいくらか増加する絶対拡散数が著しく低いことを示しています（おそらく、未完了のトランザクションによりフラッシュ不可能なログ使用が発生します）。ストールが解決された時点から開始するチェックポイント。
— syneticon-dj 14
innodb_adaptive_flushing_lwmを1に設定する必要があるかどうかはわかりません-これはログスペースの割合であり、適応フラッシュが開始されます（デフォルト：10）。
— モーガントッカー
@MorganTockerこれは、ログスペースの使用率が問題の一部であると疑ったため、ほとんどの場合、アダプティブフラッシュが何でもフラッシュするように設定しました。この問題はデフォルト値の10でも発生しました。トラブルシューティングのために変更しました。
— syneticon-dj

回答:

6

Windowsで実行されているバージョン5.6.12および5.6.16の2台のサーバーで、それぞれスレーブのペアで同じ問題が発生していました。私たちは、あなたのように、ほぼ2か月間困惑しました。

解決策：

set global binlog_order_commits = 0;

変数の詳細については、https：//dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#sysvar_binlog_order_commitsを参照して ください。

説明：

InnoDBフルテキストは、ディスク上の実際のフルテキストインデックスに適用する必要がある変更を含むキャッシュ（デフォルトでは8Mのサイズ）を使用します。

キャッシュがいっぱいになると、キャッシュに含まれていたデータをマージする作業を実行するためにいくつかのトランザクションが作成されます-これは大量のランダムIOになる傾向があるため、フルテキストインデックス全体をロードできない限りバッファプール、それは長くて遅いトランザクションです。

binlog_order_commitsをtrueに設定すると、長時間実行されるfts_sync_indexトランザクションの後に開始された挿入と更新を含むすべてのトランザクションは、コミットする前に完了するまで待機する必要があります。

これは、バイナリログが有効になっている場合にのみ問題です

— ダニエル・ゴールディング
ソース
これは、私が見た問題の解決策である可能性が非常に高いようです。どのようにして回避策を思いついたのですか？また、私の場合、フルテキストインデックスはバッファプール（サイズは最大30G）に収まりますが、操作はレイテンシに大きく依存しているように見えました。MySQLのI / Oスタックはストレージレイテンシを処理する際に非常に非効率的であるという印象を受けているため、この問題はおそらく両方の組み合わせです-非効率性とバイナリロギング構成の不適切なデフォルト。
— syneticon-dj
どうしてそんなに長い間気付かれないのだろうか。確かに、非SSDストレージでFTSとbinlogを有効にしてInnoDBを実行している人はもっといますか？
— syneticon-dj
幸運。ロックアップ中に「show engine innodb status」をキャプチャできたのと同じポイントに到達しました。FTSインデックスを持つテーブルに大量の行を挿入する小さなプログラムと、2番目のテーブルを更新して更新時間を記録する別のプログラムを作成しました。ローカルマシンとライブサーバーのセットアップの違いを1つずつ確認するまで、FTSキャッシュフラッシュを一時停止して更新をブロックすることはできませんでした。binlogをオンにすると、問題が再現されたため、binlogオプションを読みました。
— ダニエルゴールディング
1
MySQL開発チームが最終的に（キューに入って15か月後に！）報告されたバグのステータスを「検証済み」に設定し、少なくとも開発チームの誰かが解決策について考えているように見えることに注意してください。言うまでもありませんが、MySQLの使用は完了です。永久に、私は願っています。
— syneticon-dj
4

ログフラッシュの歴史的な問題と、アダプティブフラッシュの仕組みを説明してみましょう。

  • REDOログはリングバッファー設計です。それらは書き込まれるだけで（通常の操作では読み取られません）、クラッシュリカバリで提供されます。私は、タンクのトレッドに似たリングバッファを記述するのが好きです。

  • InnoDBには、まだディスク上で変更されていない変更が含まれている場合、ログファイルスペースを上書きできません。そのため、歴史的に、InnoDBは1秒あたり一定量の作業（で構成innodb_io_capacity）を試行し、それが十分でない場合は、ログスペースがいっぱいになります。ストールは、スペースを突然解放するために同期フラッシュが必要になると発生し、通常はバックグラウンドタスクが突然フォアグラウンドになります。

  • この問題に対処するために、適応フラッシュが導入されました。時によってはどこ10％（デフォルト）ログスペース消費、バックグラウンド作業が次第に積極的になって起動します。これの目的は、突然の失速ではなく、パフォーマンスの「短いディップ」になります。

  • アダプティブフラッシュとは別に、ワークロードに十分なログスペースを確保することが重要innodb_log_file_sizeです（4Gの値は現在非常に安全です）。そして、innodb_io_capacityそれinnodb_lru_scan_depthが現実的な値に設定されていることを確認してください。アダプティブフラッシュ10％innodb_adaptive_flushing_lwmは、あまり深く入り込まないもので、スペース不足に対する防御メカニズムのようなものです。

— モーガン・トッカー
ソース
2

InnoDBに競合の軽減をもたらすために、で遊ぶことができますinnodb_purge_threads。

MySQL 5.6より前は、マスタースレッドがすべてのページフラッシュを実行していました。MySQL 5.6では、別のスレッドで処理できます。innodb_purge_threadsMySQL 5.5のデフォルト値は0で、最大1です。MySQL5.6では、デフォルトは1で最大32です。

設定はinnodb_purge_threads実際に何をしますか？

ゼロ以外の値は、1つ以上のバックグラウンドスレッドでパージ操作を実行します。これにより、InnoDB内の内部競合が減少し、スケーラビリティが向上します。値を1より大きくすると、多数の個別のパージスレッドが作成され、DML操作が複数のテーブルで実行されるシステムの効率が向上します。

まず、innodb_purge_threadsを4に設定して、InnoDBページのフラッシュが削減されるかどうかを確認します。

更新2014-09-02 12:33 EDT

モーガントッカーは、ページクリーナーが被害者であり、MySQL 5.7がそれに対処できることを以下のコメントで指摘しました。それにもかかわらず、あなたの状況はMySQL 5.6にあります。

もう一度見てみると、innodb_max_dirty_pages_pctが50になっていることがわかりました。

MySQL 5.5+のinnodb_max_dirty_pages_pctのデフォルトは75です。これを下げると、フラッシュによる失速の発生率が増加します。私は3つのことをします

更新2014-09-03 11:06 EDT

フラッシュ動作を変更する必要がある場合があります

以下を動的に設定してみてください

SET GLOBAL flush = 1;
SET GLOBAL flush_time = 10;

これらの変数flushおよびflush_timeは、10秒ごとにテーブルの開いているファイルハンドルを閉じることにより、フラッシュをより積極的にします。MyISAMはデータをキャッシュしないため、間違いなくメリットがあります。MyISAMテーブルへのすべての書き込みには、テーブル全体のロックが必要で、その後にアトミック書き込みが必要です。ディスクの変更はOSに依存します。

この方法でInnoDBをフラッシュするには、mysqlを再起動する必要があります。表示するオプションは、innodb_flush_log_at_trx_commitおよびinnodb_flush_methodです。です。

再起動する前に、これらを追加してください

[mysqld]
flush = 1
flush_time = 10
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT

このルートに進む前に、ジャーナリングが問題かどうかを確認する必要があります。このクールなmysqlperformanceブログの投稿を見ました O_DIRECTのが原因でカーネルの偽造されています。同じ投稿では、影響を受けるMyISAMについても言及しています。

前にこの投稿について書いた：innodb_flush_method = O_DSYNCのときにib_logfileがO_SYNCで開かれた

試してみる ！！！

— RolandoMySQLDBA
ソース
1
明確にするために：このワークロードは、スレッドをパージするのではなく、ページクリーナースレッドに負荷をかけると考えています。複数のページクリーナーは5.7の機能ですが、5.6ではさらに設定を行うことができます。参照：mysqlserverteam.com/mysql-5-7-improves-dml-oriented-workloads
— モーガン
@MorganTocker @RolandoMySQLDBA sar -d出力で私が際立っていたことのawait1つは、ストール中にスループットが低下する間、ほぼ10倍に上昇することです。I / Oスケジューラやファイルシステムのジャーナリングなど、MySQLの外部に問題があると思われますか？
— ジェームズL 14
innodb_purge_threads（再起動が必要）を除いて、提案されたほとんどのパラメーターを変更しました。それは問題に対してあまり役に立たなかった。そして、MyISAMテーブルの挿入もストールしているため、ここではInnoDBエンジンは問題ではないと考えさせられます。
— syneticon-dj 14
innodb_read_io_threadsおよびinnodb_write_io_threadsの設定を投稿してください。ファイル名を指定して実行SHOW GLOBAL VARIABLES LIKE '%io_threads';
— RolandoMySQLDBA
1
@ syneticon-dj MySQLの外部から同じファイルシステムへの書き込みはどうですか？それらも同様に停止していますか？
— ジェームズL 14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.