☰

メモリが十分であるにもかかわらず、ディレクトリ巡回キャッシュは削除されますか？

tag-icon • tag-icon linux directory cache
メモリが十分であるにもかかわらず、ディレクトリ巡回キャッシュは削除されますか？

私は巨大なMercurialリポジトリを持っています。 （ディレクトリがどれだけ多いかを推測してください。思ったよりも多いです。）基本的なリポジトリ操作を実行するのに必要な時間は、次の例に示すように、システムバッファキャッシュがホットかコールドかによって大きく異なります（1つのコマンドが別のコマンドとして実行されます。される）。

bash> time hg status

real    0m41.809s
user    0m0.815s
sys     0m0.217s

bash> time hg status

real    0m0.858s
user    0m0.679s
sys     0m0.175s

数日間（再起動せずに）マシンを使用しないと、キャッシュが冷えて再実行するのに長い時間がかかりますhg status。ディレクトリはまったくまたはほとんど変更されていませんが（mtimesを確認して確認します）、RAMがたくさんあります（ページキャッシュを数えることはすべて使用されません。として確認free）。

それでは、メモリ不足はありませんが、なぜdentryまたはinodeキャッシュからエントリが削除されますか？どこかに最大サイズがありますか？興味深いことに、私はfree4GBを超える「バッファ」列を見たことがありません。システムがバッファキャッシュがこの値より大きくなることを拒否するかどうかはわかりません。

答え1

ディレクトリナビゲーションに最も重要なキャッシュは inode キャッシュです。これはfree表示された「キャッシュ」グラフには含まれていません。これはカーネルデータ（ "平らな"). 各スラブプールが占めるメモリの量を確認できます/proc/slabinfo（これはルートアクセスが必要です）。slabtopあります。

</proc/slabinfo awk '{print $1, $3*$4}' |sort -k2n

一般的なシステムでは、inodeキャッシュへの圧力は夜間に発生します。データベースの更新働くこれを避ける方法を見つけたら、教えてください。

inodeキャッシュプールのサイズは固定されておらず、メタデータキャッシュとデータキャッシュの比率によって決まります。vm.vfs_cache_pressure範囲。これを試してみることもできます。より低い値（デフォルトは100）を使用して、キャッシュ内のより多くのエントリを保持し、夜間のクローンジョブのエントリが置き換えられないようにするか、またはより高い値をhg使用してナイトクローンジョブのエントリが置き換えられないようにします。アイテムは置き換えられません。 RAMを汚染するために残された。

hg status最後に、朝にクローンジョブとして実行する方法が常にあります。

関連情報