サーバーと仮想マシン

Linuxのダーティ・レシオとダーティ・バックグラウンド・レシオ：書き込みパフォーマンスを最適化するための微調整

どのように linux dirty また、「dirty background ratio」を設定することでページキャッシュを制御し、書き込みスループット、レイテンシ、データ整合性を最適化できます。これにより、具体的な閾値を設定し、フラッシャーを適切なタイミングで起動させ、ブロックを回避し、ワークロードの書き込みパフォーマンスを向上させることができます。.

中心点

まず冒頭で、本題に深く入る前に、主なポイントを簡単にまとめます。.

わいせつなページ RAMにデータをキャッシュし、多数の小さなアクセスをまとめて、より効率的なI/O操作を行います。.
ダーティ・バックグラウンド・レシオ バックグラウンドでフラッシャースレッドを起動し、気づかれないうちにゴミの量を抑制します。.
ダーティレシオ ハードリミットを超えた場合、書き込み中のプロセスの処理を抑制します。.
関係これら2つの値によって、レイテンシのピーク値、スループット、およびバッファサイズが決まります。.
Bytesのバリエーション (dirty_bytes) は、大規模なサーバーにおいて、よりきめ細かな絶対的な制御を可能にします。.

「ダーティ・ページズ」を理解する

プロセスがデータを書き込むと、そのデータはまず ページキャッシュ そして、カーネルがそれらをディスクにフラッシュできるまで「ダーティ」としてマークされます。このバッファリングにより、アプリケーションの処理が高速化されます。なぜなら、RAMはどのSSDやHDDよりも反応が速く、小さな書き込みが大きな連続転送へとまとまるからです。私は常に、どれだけの「ダーティ」を許容するかを念頭に置いています。なぜなら、バッファが多すぎるとキューが長くなったり、クラッシュ時に未保存のデータが増えるリスクが高まるからです。その仕組みを理解していれば、ライトバック、レイテンシ、ストレージへの負荷について、より適切な判断を下すことができます。この件に関する簡単な解説記事はこちら：ライトバックキャッシュこの仕組みを明確に整理するのに役立ちます。.

データ整合性、fsync、およびクラッシュウィンドウ

これらの閾値は、パフォーマンスだけでなく、リスクの許容範囲にも影響を与えます。私はこれを簡単な経験則で概算しています。最大不安定データ量を、デバイスの持続的なスループットで割ると、バッファが空になるまでの時間が大まかに算出されます。例：4 GBのダーティデータを許容し、ターゲットメディアの転送速度が500 MB/sの場合、書き込みが完了するまで約8秒かかります。この間に停電やカーネルパニックが発生すると、直近の書き込みデータが失われる可能性があります。.

アプリケーションは、次の方法でウィンドウを fsync() 或いは fdatasync() サイズを縮小します。というのも、こうしたアクセスはファイルシステムに、データ（ジャーナリングモードによってはメタデータも）をメディアに書き込むことを強いるからです。これはコストがかかりますが、データベースやジャーナルにとっては不可欠です。私は、ダーティ・リミットが同期の挙動と整合するように注意しています。頻繁な fsync()-閲覧数は、より低い ダーティレシオ, 、そうすることで、もともと定期的に永続化が行われている場合、カーネルによる追加のスループット抑制を防ぐことができる。逆に、フラッシュがめったに行われないappend中心のログについては、許容できるデータ損失リスクを常に考慮した上で、より大きなバッファサイズを設定してもよい。.

バリアや書き込み順序も重要です。最新のファイルシステムでは、FUA/フラッシュコマンドを使用して、コントローラのキャッシュを正しくクリアしています。パワーロスプロテクション（PLP）のないメディアでは、バッファサイズが大きいほどリスクが高まりますが、PLPや書き込みキャッシュの保護機能があれば、より大きなバッファを使用することも多くの場合許容されます。.

Dirty Background Ratio：ソフトな閾値

と一緒に ダーティ・バックグラウンド・レシオ 利用可能なストレージの何パーセントに達した時点で、フラッシャー・スレッドがバックグラウンドでの書き込みを開始するかを指定します。この値はアプリケーションをブロックするものではなく、バッファが溢れ出さないよう、静かにクリーンアップ作業を開始します。数値を低く設定すると、バックグラウンドでの書き込みは頻繁になりますが、その頻度は均一になり、レイテンシのピークが平滑化されます。数値を高く設定すると、より多くのバッファが許容されるため、大規模なシーケンシャル書き込みではスループットが向上しますが、突然のフラッシュが発生した場合、著しいI/Oのピークを引き起こす可能性があります。通常、デフォルト値は10％前後ですが、私はメディア、ワークロード、セキュリティ要件に応じてこの閾値を調整しています。.

ダーティ・レシオ：急ブレーキ

パラメータ ダーティレシオ これは、十分なページが書き戻されるまで、カーネルが書き込みプロセスを制限する閾値を示します。この厳格な制限は、メモリが永続化されていないデータの洪水にさらされるのを防ぎ、アプリケーションがさらにデータを生成しようとした瞬間に直接影響を及ぼします。データベースの場合、クエリの応答時間を一定に保ち、長時間のフラッシュ処理が発生しないように、この値を比較的低く設定しています。一方、バックアップジョブでは、大きなブロックを効率的に転送するために、より大きなバッファを使用します。一般的なデフォルト値は20％から40％の間ですが、私は常に実際の負荷に合わせてこの範囲を調整しています。.

相互作用と典型的な関係

これらの2つの閾値は、 タンデム これらは組み合わさって初めて効果を発揮します。私は、カーネルが適時にバックグラウンドで起動し、ハードブレーキンの発動が稀になるよう、常に dirty_background_ratio を dirty_ratio より低く設定しています。目安として、ハードリミットの4分の1から半分、例えば20に対して5～10といった値をよく採用しています。こうすることで、スループットを不必要に低下させることなく、Writebackを十分に早い段階で開始できます。この比率を誤ると、スロットリングが早すぎたり、バックグラウンド処理が遅すぎて、顕著なレイテンシーのピークが発生したりすることになります。.

デバイスごとの制御とブロック層の細かさ

グローバルな制限に加え、デバイスレベルにも注目する価値があります。Linuxは、いわゆる 対応デバイス (bdi)。In /sys/class/block//bdi/ 私は次のようなパラメータが max_ratio, 、これは、グローバルに許可された「ダーティ・バジェット」のうち、個々のデバイスがどれだけの量を引き出せるかを決定するものです。低速と高速のドライブが並列に構成されたシステムでは、低速のストレージがボトルネックにならないよう、その使用量を制限しています。.

また、以下によるブロック・レイヤーの帯域制限も関連しています。 /sys/block//queue/wbt_lat_usec （書き込みスロットリング）。これにより、目標レイテンシを設定します。書き込み負荷がこの目標時間を超えると、カーネルが書き込み負荷を抑制します。 SATA HDDの場合、インタラクティブ性を確保するために、控えめな値を設定するようにしています。非常に高速なNVMeドライブでは、コントローラーが並列処理能力を最大限に発揮できるよう、目標レイテンシを無効にするか、あるいは値を大きくします。 I/Oスケジューラ（mq-deadline、BFQ、none）は状況に応じて選択します。BFQは、負荷が混在する対話型システムに適していますが、なしあるいは、NVMe での純粋なスループットジョブでは、mq-deadline が最も良好に動作することが多い。.

相互作用が鍵となる：もし ダーティ・バックグラウンド・レシオ 低い設定であっても、WBTによってデバイスが厳しく制限されると、それでも目に見えるボトルネックが発生します。そのため、私は両方のレベルを同時に調整しています――バッファサイズにはグローバルなダーティ・リミットを、レイテンシ保護にはブロック・レイヤーを設定しています。.

Ratio 対 Bytes：デフォルト値とバリエーション

リソースを多く消費するシステムでは RAM パーセンテージ値はすぐに大きな絶対値へと膨れ上がります。そのため、私はむしろ `dirty_bytes` や `dirty_background_bytes` を使って絶対的な上限を設定し、バッファ容量を約2～8 GBに明確に制限するようにしています。これにより、メモリ構成の大幅な変動から制御を切り離し、永続化されていないデータの量を予測可能な範囲に抑えることができます。選択は動的に行います。RAM容量が少ない小規模なサーバーの場合、多くの場合、パーセンテージで十分です。大容量のサーバーを運用する場合は、バイト単位の値を使用した方が計画が立てやすくなります。.

パラメータ	意味	一般的なデフォルト	いつ変更すればよいですか？	ヒント
vm.dirty_background_ratio	の開始背景のフラッシュパーセント	≈ 10%	レイテンシの変動や、非常に高速なSSD/NVMeの場合	低いほどレイテンシが低くなり、高いほどバッファ容量が増える
vm.dirty_ratio	ハードスロットル限界パーセント	≈ 20–40%	データベースでは低く、バックアップでは高い	高すぎる → フラッシュ時にブロックが発生する可能性がある
vm.dirty_background_bytes	バックグラウンド・フラッシュの開始はバイト	Ratioを使用する場合は無効にする	大容量のRAM、固定のバッファ先	Ratioパラメータを無効にする
vm.dirty_bytes	厳しい「ドロセル」制限がバイト	Ratioを使用する場合は無効にする	大容量のRAM、設定可能な上限	Ratioパラメータを無効にする

ワークロードのシナリオと推奨事項

次のような順次書き込み負荷 バックアップ 大きなバッファと適度なバックグラウンド書き込みの恩恵を受けられます。これは、カーネルがメディアに一括して書き込みを行えるためです。ここでは、dirty_ratio を30～40パーセント、dirty_background_ratio を10～20パーセントに設定することが多いです。データベースや小規模なランダムI/Oアプリケーションは、予測可能なレイテンシが不可欠であるため、ハードレイテンシを10～15％、ソフトレイテンシを3～5％に設定しています。 Webサーバーとアプリケーションサーバーが混在する環境では、ハード15～20％、ソフト5～10％が良好な妥協点となります。これらの範囲はあくまで出発点であり、最終的にはシステムの実際の測定結果が重要となります。.

ファイルシステムの側面とマウントオプション

ライトバックパスはファイルシステムで終了する――その戦略がレイテンシとセキュリティを左右する。Ext4では data=ordered (デフォルト) は、ジャーナルのコミット前にユーザーデータを書き込みます；; data=ライトバック レイテンシを低減しますが、クラッシュ後に古いデータが失われるリスクがあります。このパラメータは コミット （秒）は、ジャーナルの永続化頻度を制御します。間隔を短くするとデータ損失は減りますが、I/O負荷は増えます。XFSは洗練されたログ設計を採用しており、大規模な ログサイズ また、適切なアライメントはスループットの高いジョブに役立ちます。BtrfsはCopy-on-Writeによって書き込みをまとめて処理します。これによりレイテンシが安定しますが、小規模なランダム書き込みや容量の限られたSSDでは、断片化を引き起こす可能性があります。次のようなオプションは nodatacow レイテンシーの急上昇が発生した場合、特定のパスや対象を絞ったデフラグに役立ちます。.

また、私は以下の点にも留意しています relatime/ノータイム （メタデータの書き込みを削減）、, 怠け者 （mtime/atime の更新が遅延し、より永続的になる）こと、およびジャーナリング・バリア。特に RAID コントローラや仮想マシン（VM）においては、キャッシュの挙動が適切であることが極めて重要です。書き込みキャッシュの設定が誤っていると、ダーティ・チューニングの努力がすべて無駄になってしまいます。.

ダイレクトI/O、O_SYNC、およびアプリケーションの挙動

すべてのアプリケーションがページキャッシュを経由するわけではありません。 O_DIRECT 或いは O_SYNC/O_DSYNC 一部のプロセスはキャッシュの一部を迂回したり、即時の永続化を要求したりします。データベースは通常、WAL／リドゥログを同期的に書き込み、データ領域を非同期的に書き込みます。私は特に非同期パス向けにダーティ閾値を調整していますが、同期パスについては高速なジャーナル（NVMe、専用LUN）を通じてレイテンシを保証しています。アプリケーションが非常に頻繁に fsync() 呼び出す場合、大きなバッファはあまり役に立ちません。その場合、レイテンシは、よりもむしろコントローラ、キュー深度、およびI/Oスケジューラに大きく依存するからです。 ダーティレシオ.

実践的なチューニングの手順

変更を行うたびに、私は 実績値 をもって sysctl vm.dirty_ratio そして sysctl vm.dirty_background_ratio, 、現状を記録するためです。短期的なテストの場合は、値を直接 /proc/sys/vm/例えば echo 15 > /proc/sys/vm/dirty_ratio そして echo 5 > /proc/sys/vm/dirty_background_ratio. 調整が永続的なものである場合、それを /etc/sysctl.conf 或いは /etc/sysctl.d/*.conf. 変更は sysctl -p すぐに実行し、その効果を速やかに測定できるようにします。システムルールについてさらに深く学びたい方には、実践的なヒントが役立ちます。 sysctlの調整本番サーバー上で。.

値の導出：計算例

私は具体的な数値から始めるのが好きです。例1：64 GBのRAMとNVMeを搭載したWeb／アプリサーバー。目標は低レイテンシです。私は dirty_background_bytes=1073741824 (1 GB) および dirty_bytes=3221225472 (3 GB)。NVMeの持続スループットが2 GB/sの場合、空にするのに約0.5～1.5秒かかります。これはインタラクティブな負荷には適しています。例2：128 GBのRAMを搭載したバックアップノード、800 MB/sの高速SATA-RAID。私は以下を選択します dirty_background_ratio=10, dirty_ratio=35. 絶対値では、それぞれ約12.8 GBと44.8 GBであり、RAIDの空にする処理には16～56秒かかります。このジョブは対話型ではないため、これでも問題ありません。.

例 3：256 GB の RAM を搭載したデータベースサーバー。ジャーナルは NVMe に、データは SSD アレイに保存。異常値を避けるため、絶対値で制限を設定します： dirty_background_bytes=2147483648 (2 GB)、, dirty_bytes=8589934592 (8 GB)。これにより、クラッシュウィンドウのサイズを予測可能に保ち、チェックポイント通過時の急ブレーキを軽減します。.

ライトバックのタイミングおよび関連パラメータ

閾値以外にも影響を与えるのは タイマー ライトバックの挙動、ひいてはアプリケーションの操作感。これによって vm.dirty_writeback_centisecs カーネルフラッシャーを起動させる間隔を制御し、一方 vm.dirty_expire_centisecs ダーティページの最大保持時間を定義します。間隔を短くすると、フラッシュの頻度は高くなりますが、その量は少なくなります。間隔を長くするとI/O呼び出しを節約できますが、より大きなバッチになるリスクがあります。私は、高速なNVMeドライブでのフラッシュ間隔が長すぎるなど、測定結果に明らかなデメリットが示された場合にのみ、これらの値を調整します。ここで体系的なアプローチをとることで、書き込みバックの活動が過度に活発になったり、逆に鈍すぎたりするといった揺れ動きを回避できます。.

モニタリングと微調整

調整を行った後、私は観察している 継続的 成果や副作用を可視化するための指標。 /proc/meminfo 「Dirty」と「Writeback」を確認して、バッファの状態やアクティブなフラッシュを確認します。iostat、sar、atop などのツールを使えば、スループット、キュー、レイテンシの傾向を把握できます。メトリクスに関する適切な入門情報として、こちらの記事が参考になります。 I/O待機時間の分析. まずこのデータに基づいて、予期せぬ副作用が生じないように、段階的に制限を緩和または強化していきます。.

コンテナ、cgroups、および公平なリソース配分

コンテナ環境では、ワークロードは同じカーネルメカニズムを共有します。Cgroup-Writeback は、ダーティページをその発生源に確実に割り当てる役割を果たします。個々のテナントが過度にバッファリングを行う場合、cgroupsのI/Oコントローラ（blkcg）を使用して、コンテナごとの帯域幅やIOPSを制限しています。ホストレベルでの絶対バイト数制限（ダーティバイト) 1人のゲストが「ダーティ・バジェット」の全量を食い尽くすのを防ぐ。さらに、以下を通じてメモリ使用量を制限している。 メモリ.max, 、これにより、Writebackがグローバルな負荷がかかってから初めて反応するのを防ぐためです。目標は変わりません。ゲストの負荷が、ホスト全体の ダーティレシオ 強制する。.

ホスティング環境とVM

マルチテナント環境やVMでは、以下の点に注意しています オーバーブッキング RAMとI/Oについては、パーセンテージ制限が異なる影響を及ぼすためです。絶対バイト数による制限を設けることで、個々のゲストが過剰なバッファを蓄積して、隣接するゲストの処理を遅らせるのを防ぐことができます。また、ストレージの重複排除、バルーニング、コントローラキャッシュも考慮に入れています。これらはバッファリング効果に重畳して影響を与えるためです。マネージドサーバーの場合、プロバイダーが適切なデフォルト設定を行うことで、顧客は安定した応答時間を体験できるようになり、その価値は十分にあります。独自のノードを運用している場合は、ワークロードクラスごとに明確に定義されたプロファイル設定を活用することでメリットが得られます。.

よくある誤解と障害

„「バッファが増えれば、スループットもますます向上する。」“ ランダムな負荷が多いワークロードや、キュー深度が小さいデバイスでは不適切です。バッファが大きすぎると、フラッシュバーストやキューの滞留が発生します。.
„「dirty_ratioはReadsに影響を与えません。」“ 間接的にはそう言えるでしょう。激しいライトバック処理はキャッシュページを追い出し、読み取りレイテンシを増加させます。.
„「バイトと理性は相乗効果を生む。」“ いいえ。Bytesのバリエーションを設定すると、それに対応するRatioのバリエーションは無効になります。一意性を保つようにしてください。.
„「fsync() を実行すると、ダーティ・リミットは意味をなさなくなる。」“ いいえ。頻繁に同期を行うとリスクの発生期間は短縮されますが、残りの負荷については引き続き許容限界値が適用されます。.
„「高速なデータストレージがあれば、何でも解決する。」“ ただし、ブロックレイヤーが帯域制限を行っている場合（WBT）や、ファイルシステムのマウント設定が最適でない場合は例外です。.
„「Drop_caches はチューニングツールです。」“ キャッシュをクリアすると、測定値が歪み、レイテンシーの急上昇を悪化させます。本番環境では、これを避けるようにしています。.

トラブルシューティング：典型的な症状と対処法

山積み 遅延ピーク, 、まずバックグラウンドのしきい値を下げて、フラッシュ処理がより早く開始され、大規模な書き込みの波が発生しにくくするようにします。アプリケーションが断続的に停止する場合は、通常、ハードリミットが高すぎるか、あるいはストレージメディアが発生するフラッシュバーストに対応しきれていないことが原因です。そのような場合は、dirty_ratioを下げ、リードアヘッドの設定を確認し、ファイルシステムのジャーナリングオプションを見直します。非常に高速なNVMeハードウェアの場合は、スループットを人為的に制限しないよう、バックグラウンドのしきい値を段階的に引き上げます。変更を行うたびに、直感ではなく測定結果に基づいて対応します。.

実践のための簡単なまとめ

少数の 調整ネジ これにより、Linuxが書き込みデータをバッファリングする方法、フラッシャがいつ起動するか、そしてカーネルがいつパフォーマンスを抑制するかを制御できます。「Dirty Background Ratio」は静かなクリーンアップを可能にし、「Dirty Ratio」はRAM使用量をより厳しく制限します。この2つの値のバランスによって、システムが「安定したレイテンシ」を重視するか、「最大スループット」を重視するかが決まります。私はデフォルト設定を記録し、少しずつ変更を加え、測定結果を徹底的に分析しています。そうすることで、ワークロード、メディア、リスクを適切にバランスさせ、実際の運用において顕著な速度向上をもたらす設定が完成します。.