質問 :ダーティ ページとは何ですか?その目的は何ですか?
アプリケーション/データベース プロセスが仮想ページを物理メモリに追加する必要があるが、空き物理ページが残っていないときはいつでも、OS は残りの古いページをクリアする必要があります。
古いページがまったく書き込まれていない場合、このページを保存する必要はなく、データ ファイルから簡単に復元できます。ただし、古いページが既に変更されている場合は、後でアプリケーション/データベースを再利用できるようにどこかに保存する必要があります。これはダーティ ページと呼ばれます。
OS はそのようなダーティ ページをスワップ ファイルに保存します (したがって、物理メモリから削除できるため、別の「新しい」ページを物理メモリに保存できます)。大量のデータがページ キャッシュからダーティ ページ領域に削除される場合、これにより重大な IO が発生する可能性があります。実際のスワップ デバイスがローカル ディスク ( sda ) に配置されている場合はボトルネックになり、ローカル ディスクがローカル ルート ( OS ) ディスクによっても使用されている場合はさらに問題が発生します。
Linux のページ キャッシュは単なるディスク キャッシュであり、OS に追加のパフォーマンスをもたらし、ファイルに対する集中的な高い読み取り/書き込みに役立ちます。
ページキャッシュの「サブ」製品はダーティページです。これは上記の例で説明されています。アプリケーションがファイルへの書き込みまたはファイルの作成を行うたびに、ダーティ ページが観察されることもあります。最初の書き込みはページ キャッシュ領域で行われます。したがって、10 MB のファイルの作成は非常に高速です。
# dd if=/dev/zero of=testfile.txt bs=1M count=100 10+0 records in 10+0 records out 10485760 bytes (100 MB) copied, 0,1121043 s, 866 MB/s
そのファイルは実際のディスクではなくメモリ領域に作成されるため、応答時間が非常に高速です。 OS では、そのようなことは /proc/meminfo に記録され、さらに「Dirty:
」に記録されます。上記のコマンドが実行される前に – /proc/meminfo と「Dirty」行を書き留めます:
# more /proc/meminfo | grep -i dirty Dirty: 96 kB
コマンド実行後:
# more /proc/meminfo | grep -i dirty Dirty: 102516 kB
OS またはアプリケーション/データベースは定期的に同期を開始し、実際の testfile.txt をディスクに書き込みます:
# more /proc/meminfo | grep -i dirty Dirty: 76 kB
現在、たとえば Oracle データベースでは、OS がクラッシュしたり、SAN LUn に障害が発生した場合に、データが危険にさらされるなどの理由で、メモリ領域への書き込みを許可していません。そのため、Oracle データベースはデータを「同期」する必要があるため、データベースがさらに書き込み要求をスローする前に、ディスク/LUN などのバックエンドですべての書き込みを確認する必要があります。
通常、データベース/アプリケーションは定期的にキャッシュを削除するため、ダーティ ページは小さなチャンクでディスクに書き込まれます。場合によっては、アプリケーション/データベースがページ キャッシュ メカニズムを適切に構成していない可能性があるため、ダーティ ページのサイズが大きくなることがあります。
そのため、ダーティ ページはスワップ ファイル ( Swap area ) だけでなく、ディスク内の特別な領域 ( LUN/file-system ) にも書き込むことができます。たとえば、後でスワップ ファイルから再利用される 100MB を超えるスワップ ファイルを作成すると、スワップ デバイスで不要な IO 問題が発生する可能性があります。エンタープライズ システムは、ソリッド ステート ドライブ (SSD) または専用 LUN の下の OS にスワップ ファイルとスワップ領域を保存するため、ローカル ディスクのパフォーマンスは影響を受けません (通常、スワップ領域はローカル ディスク上に作成されるため)。
場合によっては、アプリケーション/データベースに内部的な問題が発生し、ダーティ ページがスワップ ファイルとして書き込まれますが、再利用されることはありません。これにより、スワップ領域が拡大し、ローカル ディスクで不要な IO が発生し、OS で大量のスワップが使用されます。
OS がどの段階でダーティ ページをディスク層にダンプしようとするかを調べるには、ここで仮想メモリに関する公式のカーネル ドキュメントを確認し、次のような設定を探してください。
vm.dirty_background_ratio vm.dirty_ratio vm.swappiness
そして
dirty_background_ratio dirty_ratio dirty_background_bytes dirty_expire_centisecs
上記の設定は、OS に「ベスト プラクティス」設定がないため、データベース/アプリケーションの要件ごとに調整する必要があります。これらは、DB/APP の負荷/構成ごとに調整されます。
アプリケーション/データベースがメモリ ページを物理メモリで解放することを要求するときはいつでも、OS はすべてをページ キャッシュに保持する傾向があるため、OS はページの一部を再割り当てし、それらをダーティとしてマークする必要があります。アプリケーション/データベース エンドが適切に調整およびスケーリングされている場合、このプロセスは正常に機能します。そうでない場合、OS はすべてのダーティ ページをスワップ ディスクに書き戻す必要があるため、非常に積極的な swappiness が発生します。これは vm.swappiness 設定で制御できます。
アプリケーション/データベースが一致する swappiness を行う場合、スワップ デバイスで重大な IO 書き込みが発生し、重大なシステム ストールが発生する可能性があります。アプリケーション/データベースがメモリ管理に関して適切に構成されていることを常に確認してください。
説明したように、すべてのページがダーティとしてマークされるわけではありません – ほとんどの未使用のページは、ダーティとしてマークされるのではなく破棄されます (すべて、既に割り当てられているページが変更されたかどうかによって異なります)
どの PID がスワップ領域を使用しているかを確認するには、以下のコマンドを使用できます:
for file in /proc/*/status
do
awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file
done | sort -k 2 -n -r 「消費された」スワップ領域の解放は本当に制限されています。通常、PID が適切に終了するか、単にシャットダウンされた場合、スワップ領域は再利用されますが、PID が強制終了されるか、segfault のように異常終了した場合、スワップ領域が消費されたままになる可能性があります。別のオプションは、再起動することです。swapoff および swapon コマンドを実行すると、深刻な問題が発生したり、システム パニック状態に陥ったりする可能性があります。