私は巨大な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最後に、朝にクローンジョブとして実行する方法が常にあります。