コンテンツにスキップ 
ページクリーナー MariaDBのスレッドは、InnoDBがバッファプールから変更されたページをディスクに書き込む方法を制御し、それによって書き込み負荷時の応答時間を平滑化します。単一のクリーナースレッドからなる現在のアーキテクチャを理解しておけば、書き込みパスにおけるボトルネックを回避し、 データベース パフォーマンスは安定している。.
中心点
- 建築: クリーナースレッドは、バッファプールインスタンスとは無関係にダーティページをフラッシュします。.
- バージョン: 変数
innodb_page_cleanersMariaDB 10.6 以降では廃止されました。. - LRUの焦点: フラッシュの対象の選定は、LRUの終了時点とチェックポイントの進行状況に基づいて行われます。.
- 神話: スレッド数が多いからといって、必ずしもパフォーマンスが向上するとは限りません。.
- 練習: バッファプールのサイズ、I/O処理能力、およびチェックポイント処理が結果に大きな影響を与えています。.
Page Cleanerが具体的に何をするのか
Page Cleanerスレッドには次のように書かれています ダーティ InnoDBバッファプールからページを戻すことで、ユーザー操作による書き込みが直接ディスクに反映されるのを防ぎます。これにより、書き込み処理とクエリ処理を分離し、特に負荷がピークに達している際、応答時間のばらつきを顕著に低減します。 私はこのクリーナーを「ペースメーカー」と捉えています。つまり、書き込み処理を無秩序な大波として処理するのではなく、適切なサイズに分割して処理する役割を果たしているのです。 このスレッドは、LRUリストの末尾に追いやられたページを処理することで、キャッシュがホットデータ用に迅速に空き状態に戻るよう確保します。同時に、チェックポイント処理を促進し、メモリ内に書き込まれていない変更が過剰に滞留しないようにします。この仕組みを理解すれば、以下の点をより迅速に把握できるようになります。 入出力 ボトルネックがどこにあるのか、あるいはそのボトルネックはキャッシュ容量が小さすぎることに起因するのか、それともダーティページが多すぎることに起因するのか。.
バージョン状況：多数のスレッドを1つに統合
以前は複数のクリーナーを設定することが可能でしたが、MariaDB 10.5.1で変更が開始され、MariaDB 10.6では削除されました innodb_page_cleaners これで決まりだ。それ以来、たった一人の buf_flush_page_cleaner-スレッドがすべてのバッファプールインスタンスの処理を担当します。これにより、調整コストが削減され、チューニングが簡素化されます。これは、優れたアルゴリズムがスレッド数の多さよりも重要であるという認識を反映したものです。 MySQLや古い記事のガイドをそのまま適用しようとすると、現在では効果のないパラメータにすぐに出くわしてしまいます。私は、調整対象と思われる設定を行う前に、まずMariaDBの正確なバージョンを確認するようにしています。そうすることで時間の無駄を避け、 書き込みパス 実際に影響を与える。.
バッファプール、ダーティページ、LRU
バッファプールは、頻繁にアクセスされるデータをRAMに保持し、コストのかかる ディスク-アクセスが発生します。トランザクションによる書き込みが行われると、当初はメモリ内にのみ存在する「ダーティページ」が生成されます。 クリーナーは、LRUが最終的に解放され、頻繁に読み込まれるページがキャッシュの上位に留まるよう、適時にそれらを書き出します。私は、アクティブなバッファプールインスタンスの数やアクセスの分布状況に注意を払っています。並列処理により、待ち行列を緩和できるからです。より深く掘り下げたい方には、以下の実践的なヒントが参考になるでしょう。 バッファプールインスタンス, 、例えばマルチコア・ホストの場合など。最終的に、ダーティ・ページ率によって、フラッシュの頻度が書き込みレートに追いついているか、またキャッシュがその ヒット数 を供給している。
チェックポイントの進捗状況とレイテンシ
チェックポイントは、変更内容が確実にデータストアに保存されている範囲を示すマーカーを設定し、ページクリーナーはこのマーカーを前方へ移動させます。チェックポイントが遅れをとると、ログの使用率とライトアンプリフィケーションが増加し、これはコミット時間やクエリ時のピークn値に現れます。 私は定期的に、チェックポイントの距離がどの程度変動しているか、またクリーナーが過度な変動を引き起こしていないかを確認しています。平滑化がうまくいかない場合、ユーザースレッドがブロックされるようなピーク時間が発生する恐れがあります。基本的な理解を深めるには、以下を参照すると役立ちます。 チェックポイントとライト増幅 ホスティングの文脈において。これらの指標を見れば、早い段階で フラッシュ-作業が期限内に完了するか、それとも後の段階でシステムが慌ただしく遅れを取り戻すことになるか。.
チューニングに関するよくある誤解
多くの人は、バックグラウンドスレッドを増やせば自動的にスループットが向上すると期待していますが、このケースではそうではありません。依然として重要なのは、フラッシュアルゴリズムの品質と、適切な量の 入出力-各インターバルごとの処理。クリーナーの設定が過度にアグレッシブすぎると、短い負荷のピークが発生し、応答時間が長くなってしまいます。逆に、クリーナーの設定が控えめすぎると、ダーティページが過剰に蓄積され、結果として後で大規模なフラッシュの波が発生します。どちらの場合も、レイテンシにおいてアコーディオン効果のような現象が生じます。 そのため、私はメモリサブシステムに適合し、ユーザースレッドへの影響を可能な限り最小限に抑える、均一なパターンを目指しています。 ちっそく.
指標とモニタリング：私が確認していること
意思決定にあたっては、直感ではなく数字を頼りにしています。 ダーティページの割合、チェックポイントの進行状況、書き込みレート、Fsyncレート、そしてリドゥログやデータファイルの待ち時間を監視しています。負荷がかかっているときにコミット時間が変動する場合は、フラッシュバックログやリドゥログファイルのサイズを確認します。 また、LRUリストの末尾にあるページの割合も、エヴィクションの負荷やフラッシュ処理の必要性を示唆しています。IOPSに異常値が見られる場合は、クリーナーが過大なパケットを書き込んでいるか、ストレージの制限に達していることを示しています。これらの測定項目により、ボトルネックがキャッシュサイズにあるのか、, メモリ-スループットまたはフラッシュ戦略に関するもの。.
構成：サイズとI/O容量を適切に選択する
最も重要な調整項目は、バッファプールのサイズ、I/O容量、およびログレイアウトです。 バッファプールを大きくすると読み取り負荷は軽減されますが、ダーティページの割合を無制限に増加させてはなりません。I/O容量に関するパラメータは、単位時間あたりにクリーナーが書き込みを試みる量を制御します。 値が小さすぎるとボトルネックが発生し、大きすぎるとレイテンシプロファイルにスパイクが生じます。私は、抽象的な標準値を鵜呑みにするのではなく、実際のストレージシステムに合わせてこれらの値を調整しています。以下の表は、システムの挙動に影響を与える関連設定をまとめたものです。 フラッシュ-プロセスを形作る。.
| 設定／アスペクト比 | Page Cleanerへの影響 | MariaDBに関する注意事項 | 実用的な指針 |
|---|---|---|---|
innodb_buffer_pool_size | ダーティ・ページの量とエヴィクション圧力に影響を与える | プールが大きくなるほど、一貫したフラッシュのペースが必要になる | RAMを使用するが、OS用の予備を確保し、 クエリ-キャッシュを残す |
innodb_io_capacity / innodb_io_capacity_max | 計画されているフラッシュ作業の範囲は限定的 | SSD/NVMeの実際のIOPSに合わせて調整する | 最初は控えめな金額から始め、その後徐々に増やしていく |
innodb_flush_log_at_trx_commit | Commit-Fsyncの頻度を制御する | 選択は潜伏期間と保存期間に影響を与える | „「1」は保存性が最も高いもの、「2/0」は保存性がやや低いもの レイテンシー |
| リドゥログのサイズ | チェックポイント距離およびフラッシュ波に対して効果を発揮する | サイズが小さすぎると、チェックポイントの頻度が高くなってしまう | 書き込みのピークを平滑化するために、容量を大きくする |
innodb_page_cleaners (旧) | 今日は影響なし | MariaDB 10.6 以降で削除されました | もう触らないで、能動的な行動に集中する パラメータ |
実践ガイド：ステップバイステップでのテスト
設定を変更する前に、負荷がかかった状態での明確なベースラインを確認します。その後、調整を行います。 innodb_io_capacity 少しずつ調整を行い、レイテンシーのピークが減少するかどうかを確認します。フラッシュの波が長く続く場合は、リドゥログのサイズを増やして、チェックポイントに余裕を持たせます。 その後、ホットデータが早すぎるペースで追い出されないよう、バッファプールに十分な空き容量があるかを確認します。各変更については、その効果と副作用が明確に現れるよう、十分な時間を設けます。指標とユーザー体験の両方が同時に改善されて初めて、その変更を ステップ より。
ダブルライト・バッファの影響
ダブルライトバッファは、部分書き込みやブロックの破損からページを保護しますが、同時に書き込みレートやフラッシュパターンにも影響を及ぼします。特に更新比率が高い場合、クリーナーの体感スループットに影響を与える可能性があります。 書き込み順序が永続的に保持される最新のストレージシステムでは、この影響はいくらか緩和されますが、それでもその効果は測定可能です。そのため、私はこの設定を調整する前に、ワークロード、データ整合性に対する要件、および許容可能なレイテンシを確認しています。詳細については、以下の記事で背景情報を確認できます。 ダブルライト・バッファ. これにより、耐用年数と 保護 最小限のレイテンシよりも優先される。.
よくある症状と対処法
CPUに余裕があるにもかかわらずコミット時間が急上昇する場合は、フラッシュのボトルネックやストレージの性能不足が考えられます。IOPSの変動が激しい場合は、フラッシュパケットが大きすぎることを示唆しています。その場合は、I/O容量を下げ、リドゥログのサイズを拡大します。 ダーティページの割合が継続して高い場合は、クリーナーの動作が過度に保守的であるか、バッファプールが小さすぎます。頻繁にアクセスされるページがLRUリストの末尾に急速に追いやられる場合は、キャッシュ容量が不足しているか、書き込み負荷によってプールが過度に圧迫されています。 ホスティング環境では、共有ストレージがボトルネックになることがよくあります。この場合は、1日を通じた負荷測定を行い、必要に応じてより高速なメディアに切り替えるしかありません。私は原因と 効果 今後も明確なままである。.
フラッシュリストとLRUの間で、クリーナーがどのように優先順位を決定するか
InnoDBは書き込みの際、主に2つのソースを区別します。LRUリスト（新しいアクセスに場所を空ける必要があるページ）とフラッシュリスト（ログシーケンス番号が最も古い順に並べられたすべてのダーティページ）です。 ページクリーナーはこれら2つの目標のバランスを取ります。つまり、エヴィクションを避けるためにLRUリストの末尾を整理しつつ、並行してフラッシュリストからページを削除することで、チェックポイントを一定に前進させます。空きバッファ容量が逼迫している場合は、LRUフラッシュが優先されます。 一方、チェックポイントの距離が伸びると、クリーナーはフラッシュ・リストからの処理割合を増やします。この切り替えこそが、ワークロードの変化に伴いレイテンシプロファイルが変化する理由を説明しています。読み取り負荷が高まるとLRUフラッシュが優勢になり、書き込み負荷が高まるとチェックポイント処理が優勢になるのです。 私はモニタリングからこのパターンを読み取り、I/O容量とリドゥログの予備容量のどちらを優先的に調整すべきかを判断しています。.
適応型フラッシング：閾値の正しい解釈
MariaDBは、リドゥの使用量やダーティページの割合に応じて書き込みレートを動的に調整するために、適応型フラッシングを採用しています。実際の運用では、ダーティページの目標値、ローウォーターマーク、および現在の書き込みレートの3つの指標を監視しています。 ダーティページの割合が目標値を上回ると、クリーナーは動作を強化し、下回ると動作を控えめにします。ローウォーターマークが低すぎると、フラッシュが頻繁に実行され、短時間ではあるものの顕著なレイテンシのピークが発生する可能性があります。 一方、閾値が高すぎるとメモリ内に不要なデータが蓄積され、後で大きな負荷の波を引き起こすことになります。私は、メモリシステムの特性に合わせて閾値を調整しています。高速なNVMe SSDは、継続的でやや高いフラッシュレートを処理できますが、低速なシステムでは、より滑らかで小規模なバッチ処理の方が効果的です。.
ストレージ固有のオプションを効果的に活用する
Page Cleanerは真空状態の中で動作するわけではありません。フラッシュ方式の選択やファイルシステムの挙動が、結果に影響を与えます。 innodb_flush_method InnoDBがページを直接（O_DIRECT）書き込むか、OSキャッシュを経由して書き込むかを制御します。 直接書き込みを行うことで、二重キャッシュを回避し、XFS/EXT4 を使用する Linux 環境でのレイテンシを安定させることができます。ただし、ZFS などのファイルシステムでは O_DIRECT の扱いが異なるため、その場合は同期方式（fsync/O_DSYNC) の方が一貫性のあるプロファイルが得られる。さらに、近傍フラッシュについても確認してみる価値がある（隣接するセルをクリアする): HDDアレイでは、隣接するブロックへの同時書き込みが有効な場合もありますが、SSD/NVMeでは、不要な書き込み増幅を避けるために、これを抑制しています。 重要なのは、構成が物理メディアに適していることです。たとえ最高のクリーナーアルゴリズムを採用していても、基盤となるストレージの性能が足を引っ張られてしまっては意味がありません。.
実践におけるモニタリング：役に立つクエリ
状況を素早く把握するために、私は3つの観点、すなわちグローバルステータス値、InnoDBメトリクス、および定期的なダンプを活用しています。.
- 主要指標の概要：
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty%';,... LIKE 'Innodb_os_log_written';,... LIKE 'Innodb_log_waits';. 上昇 ログ待機時間, 、リドゥログの容量が不足しているか、フラッシュ処理が遅すぎる。. - 詳細度：
SHOW ENGINE INNODB STATUS\Gチェックポイントの位置（LSN）、フラッシュリストの長さ、およびボトルネックの兆候を提供します。私は「ログシーケンス番号」と「最後のチェックポイント時刻」を比較して、チェックポイント間隔を推定します。. - より詳細なテレメトリ：
SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE 'buffer_%dirty%';或いは... LIKE 'log_%';短いテストでは見落とされがちな傾向を明らかにします。.
重要なのは相関関係です。コミット遅延がFsyncレートの増加と同時に急増する場合は、クリーナーの設定が厳しすぎる可能性があります。ダーティページ率とチェックポイント間隔が同時に増加する場合は、フラッシュスループットが不足しているか、リドゥログの容量が不足しています。.
ワークロードプロファイル：OLTP、レポート、バルク
ワークロードに応じて、異なる重点を置いています。OLTP環境では、継続的で小規模なフラッシュバッチと狭いレイテンシ帯域を目指しています。ここでは、適度に設定された innodb_io_capacity そして、十分なリドゥ・バッファが不可欠です。レポーティングやETLのウィンドウ期間中は、一時的にフラッシュレートを高くしても構いませんが、ユーザーのピーク時間帯までその状態が続かないよう注意しています。 大量データのロード時には、より大きなリドゥログを優先し、耐久性要件が許す限り、一時的にFsyncの厳格さを緩和することを推奨します（innodb_flush_log_at_trx_commit=2）。これにより、ページクリーナーはユーザーのトランザクションを妨げることなく、継続的に「後処理」を行うことができます。処理が完了したら、日常業務が安定して行えるよう、より厳格な設定値を元に戻します。.
ロングランナー、パージ、および間接的な影響
パージスレッドは別の目的（過去のバージョンの整理）を持っていますが、その処理速度は全体像に影響を与えます。 古いバージョンが長期間残っていると、必要な容量が増加し、メモリやI/Oの負荷の分散が不適切になります。これにより、プールにバインドされるページが増え、LRUがより早く圧迫されるため、間接的にページクリーナーに負荷がかかる可能性があります。 そのため、私はパージの遅延を常に注視し、長期にわたるトランザクションがシステムを「拘束」しないように配慮しています。安定したパージの進行、継続的なクリーナーの動作、バランスの取れた書き込み頻度――これら3つの歯車が互いに噛み合っていなければなりません。.
書き込みパスのトラブルシューティングチェックリスト
- チェックポイント間隔が長く、さらに拡大している？ リドゥログを拡大し、
innodb_io_capacity持ち上げたら、再度状態を確認してください。. - IOPSの変動やコミットのピーク？
innodb_io_capacityわずかに下げる、バッチサイズを平滑化する、ダブルライト効果を考慮する。. - ダーティページの割合が常に高い？バッファプールを拡大するか、適応型フラッシングの設定を厳しくする。ワークロードがホットセットに集中していないか確認する。.
- ログ待機が表示されていますか？ Redoが不足しているか、フラッシュ処理が遅れているかのどちらかです。まずRedoリザーブを増やし、その後、クリーナーのスループットを微調整してください。.
- LSNの進行に不安定さが見られる？フラッシュ・パケットに一貫性がない。安定した進行が見られるようになるまで、値を段階的に変更していく。.
- ストレージ周辺のボトルネック？フラッシュ方式、スケジューラ、およびRAID／SANキャッシュの設定を確認し、ピークIOPSではなく持続的なIOPSを目標値として設定する。.
例：3回のラウンドによる校正
書き込み負荷の高いOLTPインスタンスでは、本番環境のウィンドウ内で負荷測定から始めます。第1ラウンド：リドゥログの充填率とチェックポイント距離を測定します。 ログの使用率はしばしば70～80 %に達しており、距離は大きく変動するため、リドゥサイズを2倍にします。第2ラウンド：再度テストを行ったところ、レイテンシは安定しましたが、時折Fsyncのピークが発生します。そこで、 innodb_io_capacity IOPSの分布が落ち着くまで、適度な設定を維持します。ラウンド3：ダーティページの割合は上限付近にとどまっています。バッファプールにRAMを割り当てることで、LRUの負荷を軽減し、クリーナーの動作をより計画的に行えるようにしました。 結果：Commit-P95は顕著に低下し、IOPS曲線はより平坦になり、チェックポイントも安定して進行している――まさに私が目指していたパターンだ。.
簡単にまとめると
単一のクリーナースレッドが、ダーティページのフラッシュを管理し、チェックポイントの進行を維持し、クエリを激しい書き込みのピークから保護します。 関連する調整項目としては、バッファプールのサイズ、I/O容量、リドゥログのレイアウト、およびストレージシステムの特性が挙げられます。時代遅れの調整項目としては、 innodb_page_cleaners 私はもはやそれらには注目せず、直接的な影響を与える指標に集中しています。 ダーティページ率、チェックポイント間隔、コミット時間といった指標を確認すれば、ボトルネックをより迅速に特定できます。明確なベースラインに基づいた段階的な変更は、副作用を隠すことなく信頼性の高い結果をもたらします。こうして、ページクリーナーはバックグラウンドで静かに動作し、その 応答時間 負荷がかかっても、均一な状態を維持します。.
