サーバーと仮想マシン

ZFS ARCキャッシュ：メモリ使用量を正しく理解する

ZFS ARC RAMを積極的に活用して、頻繁に読み込まれるブロックを迅速に提供すると同時に、実際のメモリ使用量を負荷に応じて動的に調整します。一見高いように見える使用量を正しく解釈する方法、重要な指標とは何か、そして以下を避けつつキャッシュサイズを確実に制御する方法について説明します。 パフォーマンス を失う。.

中心点

概要を素早く把握できるよう、重要な内容をまとめ、明確にするために重要なキーワードを強調しておきます。概要.

ARCサイズ: 動的、zfs_arc_max/min で制御可能
回収可能: キャッシュRAMは、必要に応じて即座に解放される
命中率: 高いヒット率は、キャッシュの有効な活用を示している
L2ARC: SSD/NVMeへの追加であり、RAMの代わりにはならない
データセットのルール: プライマリキャッシュ／セカンダリキャッシュの微調整

私は日常生活でこれらのポイントを活用し、読み進める距離を短くし、記憶の負担を軽減しています。 共有する. ARCが満杯であることは、活発に使用されていることを示しており、不具合や隠れた問題があることを示すものではない。漏れ. スワッピングやOOMイベントが発生して初めて、明確な制限を設けます。その後、測定値を用いて変更内容を検証し、段階的に フレーム. こうして、他のサービスの動作を妨げたり、リスクを伴う性急な判断を下したりすることなく、システムのパフォーマンスを維持しています。選ぶ.

ARCがメモリ内で実際に行っていること

ARCは適応型読み取りキャッシュであり、以下を組み合わせています MRU （最近使用した）と MFU （頻繁に使用される）。この組み合わせは、私のワークロードが生成するパターンに自動的に適応し、最大の効果をもたらすブロックを正確に用意してくれます。これにより、アクセスがRAMから直接行われ、 プレート あるいはSSD。特に繰り返し行われるアクセスではその恩恵を大いに受けています。というのも、一致するデータが見つかるたびにヒット率が上がるからです。 お問い合わせ. 特にVMイメージ、データベース、そして多数の小さなファイルにおいて、キャッシュはその真価を発揮します。.

まさにこの作業方法のせいで、RAMが「満杯」に見えてしまうのですが、それでも私は引き続き リザーブ があります。使用中のキャッシュは、プロセスがメモリを要求した時点でいつでも解放可能です。このように、システムはアイドル状態の容量を放置せずに積極的に活用しつつ、それでも負荷のピークを コントロール. ファイルシステムの直接比較に興味がある方は、私の簡潔な性能比較。そこでは、実際のワークロードにおいて、賢いキャッシュが単なる理論.

なぜRAMの使用量が多いことが望ましいのか

ARCにおいて、システムが真のメモリ不足に陥らない限り、私は「満杯」のRAMを好意的に評価する 苦しんでいる. ZFSは、アプリケーションが拡大すると即座にキャッシュメモリを解放し、目標サイズを継続的に調整します。一般的なツールでは、このRAMは「使用中」と表示されますが、実際には新しいプロセスに対して遅延なく処分とあります。真のボトルネックは、スワッピング、顕著なラグ、あるいはOOMキラーの動作によって初めて明らかになります。理解を深めるには、以下を参照すると良いでしょう。ページキャッシュの違い, 、OSのキャッシュとARCが相互に連携しており、両方が目に見える消費量に影響を与えるため 刻印する.

したがって、重要なのは文脈であり、モニタリングツールの「空き容量 0 GB」と表示された単一のスクリーンショットそのものではない。恐怖. さらに、I/O待機時間、スワップの使用状況の推移、および主要サービスの負荷プロファイルも確認します。これらの値に異常が見られない場合は、ARCに余裕を持たせ、繰り返し行われる読み取り処理を最大限に 拍車をかける. ボトルネックが生じた場合は、ARCを厳しく引き上げるのではなく、上限を適度に引き上げるようにしている。 切り取る. これにより、キャッシュによる効率化とアプリケーションの要件とのバランスが保たれます。.

ZFSによるARCサイズの決定方法

設定がない場合、ZFSは利用可能な容量に基づいて適切な上限値を設定します。 RAM. 私は2つのパラメータを用いてこのダイナミクスを制御しています： zfs_arc_max 上限として、および zfs_arc_min 下限として。zfs_arc_max が 0 または未設定の場合、ZFS は自動的に適切な範囲を選択します。多くの場合、その範囲は メモリー. 負荷のピーク時にはARCは縮小しますが、zfs_arc_minを下回らないように設定されており、これにより重要なブロックがRAMに残るようになります。制限を厳しすぎると、ヒット率が低下し、読み取りI/Oがより頻繁に プレート 後ろの方。

ここでいう「実用性」とは、RAMが十分にあると大きなキャッシュを確保でき、それがデータベースやVMホスティングにおいて大きな 事業所. 他のサービス用のストレージが不足している場合は、zfs_arc_maxを意図的に制限し、zfs_arc_minは柔軟に設定しています。段階的にテストを行い、その影響を観察した上で、実際の傾向値に基づいて調整しています。これにより、一時的なピークによって構成支配している。段階的な調整を行うことで、問題のない信頼できる動作が得られる。 サプライズ.

ARC指標の正しい読み方

状況を把握するために、主要な指標を定期的に確認し、その関連性をわかりやすい形で整理しています。 テーブル 。arcstat や arc_summary といったツールは継続的にデータを提供しており、私はそれをプール I/O やアプリケーションのメトリクスと関連付けています。その際、個々の異常値よりも全体像の方が重要であり、図. ヒットとミスの比率は、キャッシュが作業負荷を適切にカバーできているかどうかを示す重要な指標です。ヒット率が高いことは、安定したパフォーマンスと、 RAM そこにいる。

キーパーソン	説明	注意していること
ARCサイズ	現在のキャッシュサイズは RAM	負荷がかかると伸び、必要に応じて目に見えて縮む
ARC c / c_max	目標値および最大目標値	高負荷時のc_maxへの接近、静止時の空気
成功／失敗	以下の期間における成功・失敗の記録スタート	ミスが常に高い？処理量またはキャッシュポリシーを確認してください
ヒット率	総アクセス数に対するヒット数は %	反復回数が多い場合：80～90回（%）が現実的、それ以外はそれより少ない

これらの値をもとに、具体的な対策を講じます。十分な空きRAMがあるにもかかわらずヒット率が低いままの場合は、zfs_arc_maxを慎重に増やし、その様子を観察します。 トレンド. アプリケーションに負荷がかかっている場合は、設定を緩和し、レイテンシとI/O負荷を再度測定します。キャッシュを拡大しても負荷が軽減されない場合、多くの場合、アクセスパターンが非常にランダムであり、キャッシュの効果が低下していることが原因です。 サーブ. 。その場合、データのローカル化の向上やワークロードの分割といった他の対策の方が、たいていより効果的です。単にキャッシュ容量を増やすだけでは、すべての問題を解決できるわけではありません。問題.

ARCの意思決定プロセス：ゴーストリストと調整

そのほか MRU そして MFU ARCは、いわゆる ゴーストリスト (MRU／MFU-Ghost)。これらは、最近追い出されたブロックのメタデータのみを含んでいます。もし、これらのブロックが上書き直後に再び現れた場合、ZFSはそれに対応する領域のサイズが小さすぎたという兆候と解釈し、MRUとMFUの間で容量を再配分します。このように学ぶキャッシュは、誤った予測に基づいて自動的に動作します。実際には、変動するパターン（例えば、夕方のバッチ処理ウィンドウなど）は、数サイクル経つと、手動で介入することなく、より適切に処理されるようになります。.

この文脈において、私はとりわけ、ミスが波のように発生し、その後、命中率が目に見えて変化するかどうかを観察しています 引き寄せる. そのような状況が発生すると、ARCロジックは期待通りに機能します。繰り返し実行してもミス率が高いままの場合は、多くの場合、ワーキングセットが利用可能なキャッシュ容量を上回っているか、アクセスパターンが ランダム.

ARCが実際に邪魔になるのはいつなのか

共有ホスティング環境では、多くのサービスとメモリを共有しているため、負荷の高いARCがあると、動作が重くなり、スワッピングが発生してしまうことがあります。 促進する. 仮想化ホストの運用者は、この板挟みをよく知っている。どのVMもRAMが増えれば喜ぶ一方で、ZFSもキャッシュリソースを使いたがるからだ。数ギガバイト程度の小規模なシステムでは、サービスの応答時間が圧迫されないよう、制限を厳しく設定している装置. アプリケーションの動作が重くなったり、スワップ使用量が増加したり、OOMキラーによるアラートが発生したりすると、問題が顕在化します。こうした状況では、明確な上限を設定し、その後、システムに数日間かけて比較.

症状、発生時刻、および影響を受けた箇所を記録しています サービス内容. ボトルネックが常に同じ時間帯に発生する場合は、バックアップウィンドウの設定、インデックス作成の制限、大規模なスキャン作業の時期変更などの対策を検討します。組織的な対策でピーク負荷を緩和できない場合に限り、技術的な対応や制限値の調整を行います。オン. 。この順序により、柔軟性が保たれ、デリケートな生産環境への性急な介入を防ぐことができる。これにより、キャッシュ、I/O、およびアプリケーションの相互作用を把握し続けることができる クリア.

コンテナ、Cgroups、およびNUMAの特記事項

コンテナ環境では、ARCは ホスト全体で また、cgroupによる制限も受けません。Podやコンテナがメモリ制限に達しても、ホストがARCや他のプロセスによって負荷がかかるのを防ぐことはできません。そのため、ホスト上でシステムサービスとZFS用に固定のバッファを確保し、物理RAMが限界まで消費されないようコンテナの制限を設定しています。また、NUMAシステムでは、レイテンシが増加するため、ノード間の頻繁なアクセスを避けるよう注意しています。大規模なVMを均等に分散させ、1つの ホスト これにより、予期せぬ事態を未然に防ぐことができます。.

設計におけるベストプラクティス

専用のファイルサーバーでは、他のプロセスがメモリをあまり消費しないため、ARCに60～80 %のRAMを割り当てるようにしています。需要. もしその横でコンテナや小規模なサービスを含むスタックが稼働している場合は、50～60の%から開始し、動的な負荷状況を監視します。ハイパーバイザー上では、VMが十分な専用RAMを確保できるよう、30～40の%を設定することがよくありますある. zfs_arc_min は通常、zfs_arc_max の 25～50 % に設定しています。これにより、負荷がピークに達した際にもキャッシュが縮小できるようになります。変更は段階的に行い、数日間測定値を分析しています。より.

上限をギリギリに設定するのではなく、急増に備えて余裕を持たせるように計画しています縫う. 書き込みウィンドウ、バックアップ、再インデックス処理の際には、システムが代替手段のないスワッピングに陥らないよう、意図的に余裕を持たせています。変更のたびに、ヒット率が依然として適正かどうか、またアプリケーションの応答速度が向上しているかを確認します。読み取りパフォーマンスが高水準を維持し、ボトルネックが解消された場合は、その値を承認し、理由. このドキュメントは、今後の生産能力に関する問題に対処する上で大いに役立ちます。.

圧縮ARCとプリフェッチの微調整

多くのワークロードは、 圧縮ARC: ZFSはデータを圧縮した状態でキャッシュに保持し、アクセス時に初めて解凍します。これによりRAMを節約し、実質的なキャッシュの有効範囲を広げることができます。その際、私は CPU-負荷に注意――CPUへの依存度が非常に高いシステムでは、必ずしもメリットが上回るわけではありません。明確に 圧縮可能な データ（ログ、テキスト、エントロピーの低いVMイメージ）の場合、その効果はたいてい顕著です。さらに、 ZFSプリフェッチ (zfetch) は連続したパターンを検出し、次のブロックを事前に読み込みます。キャッシュしたくない長いストリーム読み取り（バックアップやメディアパイプラインなど）の場合、前述の通り primarycache をメタデータに重点的に割り当て、それ以外の場合は zfetch に デフォルト. プリフェッチを強制的に無効にすると、混合負荷の場合にミスが増加することが多く、私にとっては例外であり、通常のことではありません。.

永続的な設定を確実に適用する

ARCの閾値は、私が設定します しつこい, 、再起動後も設定が維持されるようにし、変更は控えめに少しずつ行ってください。容量を増やすことは問題ありません。システムは追加された領域を徐々に利用していきます。. 沈下一時的にエヴィクションの増加やI/Oの増加につながる可能性があるため、私は10～20-%単位で値を下げ、24～48時間経過を観察しています。大規模な構成変更やカーネル／ZFSのアップデート後は、値が依然として妥当かどうかを確認します。新しいバージョンでは、自動ヒューリスティックが変更.

L2ARCを賢く活用する

SSD/NVMe上のL2ARCはキャッシュを拡張し、特に大規模でキャッシュに適したデータ量において、顕著な スラスト. 測定値から、RAM-ARCが常に限界状態で動作しており、フラッシュ側の余裕がまだあることが確認できてから初めてこれを使用します。重要：L2ARCはRAMの代わりにはなりません。キャッシュされたブロックのメタデータはメインのARCに保存される必要があるためです。滞在. したがって、L2ARCのサイズが大きすぎるとRAMの消費量が増加し、設定が適切でない場合はパフォーマンスが低下することさえあります。L2ARCへの書き込みにはI/O帯域幅が必要となり、 CPU, 、それを見逃すわけにはいきません。.

L2ARCは、処理対象のデータ量がRAMの容量を上回るものの、VMイメージや多数の小さなファイルなど、常に類似したファイルが対象となる場合に効果を発揮します。 オブジェクト. 拡張を行う前に、I/O統計を確認し、フラッシュ側に空き容量があり、すでに限界状態になっていないかをチェックします。これらの条件が整っていれば、L2ARCは多くの場合、一貫して低いレイテンシを実現します。正確なモニタリング、十分なRAMの予備容量、そして適切に設定されたL2ARCの組み合わせがあって初めて、期待通りの効果. 大容量のSSDを無闇に追加しても、真のボトルネックが解消されることはめったにない。.

L2ARCの詳細：ウォームアップ段階と持続性

L2ARCには ウォームアップ段階: 作成直後や再起動直後は、最初は空の状態、あるいはまだ完全に利用できない状態になります。最新の実装ではメタデータを永続的に保持できるため、L2ARCはより早く再び 事業所. とはいえ、データの書き込みには時間がかかり、I/O帯域幅を消費します。フィードを不必要に制限することはしませんが、プライマリワークロードのために十分な余裕を残しています。特に重要なのは、L2ARCがログやトランザクションワークロードと同じSSDに負荷をかけないようにすることです。専用の低レイテンシデバイスと、L2ARC用に現実的に算出されたRAMの割り当てが不可欠です。ヘッダー は必須です。.

データセットの設定：primarycache および secondarycache

データセットのオプションでキャッシュを調整し、ARCとL2ARCが正しいコンテンツを読み込めるようにします ホールド. primarycache は、データやメタデータがメイン ARC に格納されるかどうかを制御し、secondarycache は L2ARC の内容を決定します。大規模で連続的なストリーム（メディアアーカイブなど）の場合、ARC にメタデータを保持し、実際のデータストリームは保持しないだけで十分なことがよくあります。 バッファ. メタデータが中心となるワークロードでは、レイテンシを低減するためにデータとメタデータをキャッシュします。この分離により、無駄を防ぎ、関連性の高い アクセス.

私は、すべてのプールに対して一律に同じルールを適用するのではなく、データセットごとに的を絞ってテストを行っています。 セット. primarycache/secondarycache を適切に設定することで、不要な I/O を削減し、ヒット率を向上させることができます。その結果、システム動作が安定し、応答時間をより予測しやすくなることがよくあります。ここでも、「測定、調整、再測定」という流れが重要です。小節. 。こうした細かい調整こそが、しばしば決定的な仕上げをもたらすものだ。.

重複排除（DDT）の特例とRAM要件

アクティベート 重複排除, 、効率を維持するために重複排除テーブル（DDT）をRAMに保持する必要があるため、メモリ使用量が著しく増加します。一意のブロックごとにメタデータが発生し、一般的なブロックサイズでは、その合計がすぐに数ギガバイトに達してしまいます。 RAMが不足すると、ZFSはDDTへのアクセスをディスクに移行するため、レイテンシが増加し、ARCの空き容量が圧迫されます。私の経験則としては、高い冗長性が確保されている場合（例：VDI、同一のVMイメージなど）にのみ重複排除を有効にし、十分な RAM 利用可能です。そうでない場合は圧縮多くの場合、はるかに効果的な手段となる。.

モニタリングとトラブルシューティング

安定した運用を確保するため、ARCサイズ、ヒット率、I/Oプロファイル、およびシステム全体の 保管荷重. ARCが常に限界状態にあってもアプリケーションに支障が出ない場合は、そのままにしておきます。スワッピングが発生したり、OOMに近づいている兆候が見られた場合は、範囲を制限し、主な原因を分析します。併せて以下を確認すると役立ちます。 vm.vfs_cache_pressure, 、dentry/inodeキャッシュと残りのメモリの比率を バランス. 私は価値観を孤立してではなく、常に文脈の中で捉えています。.

arcstat/arc_summary、zpool、iostat、そして top/htop/free/vmstat といったツールが、必要な情報を提供してくれます。証拠. ピークと処理ウィンドウを照合し、問題が再現されるかどうかを確認します。ボトルネックが繰り返し発生する場合は、時間枠、スロットリング、またはキャッシュ制限を調整します。曲線が平坦化し、アプリケーションの処理速度が維持される場合は、 セッティング. そうすることで、その場限りの出来事に反応するのではなく、数週間、数ヶ月かけて経験を積み重ねていくのです。.

ARC、ダーティデータ、ZIL/SLOG の違いを理解する

全体像としては、ARCに加え、 不正確なデータ （変更済みで、まだディスクに書き込まれていないブロック）がRAMを占有します。この領域は上限に達するまで拡大し、その後非同期的に解放されます。書き込み負荷が高い場合、ダーティデータが一時的に膨れ上がり、ZFSがスロットリング機構で対応する前にシステムの動作を遅くすることがあります。さらに、 ZIL (ZFS Intent Log) 同期書き込み；高速なSLOGは役立つが、ARCのRAM消費量を削減するわけではない。私はこれらの点を明確に区別している：ヒット率が良好であるにもかかわらず書き込みレイテンシが顕著に高い場合は、多くの場合、ARCのサイズが大きすぎるというよりも、ダーティデータやログのボトルネックが原因であることが多い。 アーク そこにいる。

測定手法：時間枠とトレンド分析

多くのZFSカウンターは、それ以来累積的に ボート 実行する際は、日単位または週単位で分析を行います。レート（ヒット/秒、ミス/秒）を算出し、I/O待ち時間やCPU負荷と比較します。大規模な設定変更後は、比較値を「リセット」するか、その時点を明記して、影響を明確に特定できるようにしています。ヒット率はワークロードごとの時間帯（本番のピーク時間、夜間、バッチ処理）ごとに評価しています。そうしないと、単一の総合数値が実際の状況を覆い隠してしまうからです。 ボトルネック.

実例：64 GB RAMを搭載したオールラウンドサーバー

Webアプリケーション、データベース、バックアップを混在させたサーバーは、微調整を行わなければ、すぐに30～40 GBを消費してしまう アーク. 。ただし、このデータベースはかなりの量のRAMを必要とするため、zfs_arc_maxを約24～28 GB、zfs_arc_minを8～12 GBに設定しています。数日後、スワップ使用率が低下し、レイテンシも安定していることが確認できました。一方で、頻繁にアクセスされるデータは引き続きキャッシュ内に保持されています。うそ. データベースとARCに同時に入力されるトラフィックのピークがなくなるため、システムの応答性が向上している。この適度なトラフィック抑制により、スループットが維持され、応答時間が顕著に改善される。 日常業務.

次のステップでは、データセットを最適化します。大規模な逐次バックアップの場合、ARC内の純粋なデータの割合を減らし、メタデータを優先させます。 にとって. ヒット率は引き続き良好な水準を維持しており、同時に夜間帯におけるRAMへの負荷も低下しています。改修完了後は、モニタリングを通じて状況を注視し、問題が継続する場合にのみ対応します。 トレンド. 生産環境においては、長期的な安定性が短期的なベンチマークを上回る。そのため、キャッシュは利益をもたらすものであり、警戒や厳しい措置を招く原因にはならない。 スロットル.

簡単にまとめると

私は、ARCのメモリ使用量が高いことを、アクティブな状態の兆候だと捉えています。 使用方法 欠点としてではなく。ZFSは必要に応じてキャッシュを解放しますが、zfs_arc_max と zfs_arc_min によってその範囲が明確に定められています。定義. 。セットアップは、ヒット率、ARCサイズ、I/Oプロファイルといった適切な指標によって初めて意味を持つようになります。L2ARCやデータセットのオプションは、RAMが不足したり、データ量が大幅に増えたりした際に、さらなる調整手段を提供してくれます。 である. これらの基本原則を心に留めておけば、ZFSを長期的に高速かつ省エネで、信頼性の高い状態で運用できます。 応答時間.