nscdのキャッシュヒット率を向上させるにはどうすればよいですか？
私の目標： nscdに、かなり大きなDNSキャッシュを利用できるので、過剰なメモリに保持させます。
説明：
私は、広く分散しているが繰り返しの多いユーザーベースを持つWebサーバーを持っています。十分なメモリがあるので、ルックアップをキャッシュすることで応答時間を改善すると思いましたが、nscd -gによると、キャッシュヒット率は6％にすぎません（つまり、nscdはレイテンシを増やす可能性が高いです）キャッシュに保存するか、キャッシュを調べて、ネットワークにアクセスすることで防止するよりも、決して見つからないエントリを探します）：
hosts cache:
yes cache is enabled
yes cache is persistent
yes cache is shared
211 suggested size
216064 total data pool size
2328 used data pool size
36000 seconds time to live for positive entries
20 seconds time to live for negative entries
4455 cache hits on positive entries
0 cache hits on negative entries
17357 cache misses on positive entries
42348 cache misses on negative entries
6% cache hit rate
17 current number of cached values
40 maximum number of cached values
3 maximum chain length searched
0 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/hosts for changes
おそらく、6％のヒット率に大きく貢献しているのは、キャッシュされたエントリが17個しかないことです。 strings /var/db/nscd/hostsを実行すると、作成されたホストキャッシュエントリが主に内部ネットワーク上のマシン用であることがわかります。 Webサイトの毎日の再公開が高速化される可能性が高いため、これらをキャッシュしておくのは良いことですが、私の目標は、実際の構成を変更せずにエンドユーザーエクスペリエンスを高速化することです。
これはnscd.confの関連セグメントです。
threads 10
server-user nscd
debug-level 0
paranoia no
[.....snip......]
enable-cache hosts yes
positive-time-to-live hosts 36000
negative-time-to-live hosts 20
suggested-size hosts 10657
check-files hosts yes
persistent hosts yes
shared hosts yes
max-db-size hosts 33554432
基本的に、ホストキャッシュの正のTTLを信じられないほど高く設定したにもかかわらず、ホストキャッシュがどのように小さいかを理解するための支援が必要です。ヒット率が非常に低くなっているのは、実際にキャッシュされたエントリの数が少ないためだと思います。
ヒット率は6％ですが、私の正のTTL=はかなり大きいため、現在のワークロードはDNSホストルックアップを実行していますが、保存されていません。なぜこれらが保存されないのか、次に何を確認しないのかわかりません。期待していたのは、かなり大きなDNSキャッシュになります。
ヒット率が小さいままだったとしても（つまり、クライアントが思ったほど頻繁に繰り返されていなかった）、それらのDNSルックアップがキャッシュされることを期待していますしかし、発生していないように見える「キャッシュされた値の現在の数」を見てください。
ウェブサーバーのどの部分がDNSルックアップを実行しているのですか？ほとんどのWebサーバー構成では、速度を上げるために、各着信ユーザーのDNS逆引き参照を明示的に無効にします（DNSは一般に遅いため）。
Patrickが指摘するように、nscdは正しいことを行い、正のTTL値を尊重します。はい、それを上書きできます（unboundはこれを簡単に行うことができ、server.cache-min-ttl、同じ理由で1時間を超えて増やすことについての警告があります）。ただし、クエリはおそらくほとんどがrDNSであり、一般にTTLが長くなる傾向があります。
また、maximum number of cached valuesが非常に低いため、トラフィックがほとんどないことをお知らせします。
ユーザーが頻繁に繰り返す場所を気にする場合は、nscdの外部にログを記録し、もう心配しないことをお勧めします。
編集（2013/12 // 09）：nscd -gはdev.gentoo.orgからの統計をホストします（コメントにブロックはありません）：
nscd configuration:
4h 8m 43s server runtime
hosts cache:
yes cache is enabled
no cache is persistent
no cache is shared
422 suggested size
1108744 total data pool size
966632 used data pool size
600 seconds time to live for positive entries
20 seconds time to live for negative entries
67878 cache hits on positive entries
2479 cache hits on negative entries
9464 cache misses on positive entries
4276 cache misses on negative entries
83% cache hit rate
6951 current number of cached values
7641 maximum number of cached values
33 maximum chain length searched
1 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/hosts for changes
少し話題から外れているかもしれませんが、nscdを使用する代わりに、sssdに切り替えることができます（これは後継と見なしています）。
私はそれをSUSE Linux Enterprise Server 11.3（完全にサポートされています）で使用しており、切り替えを行ってよかったです。 nscdよりもはるかに多くのきめ細かい構成オプションがあり、nscdが達成できる機能をはるかに超える機能もあります。
少なくとも一見の価値があると思います： https://fedorahosted.org/sssd/
このパラメーター：
はいキャッシュは共有されます
アプリケーションがnscdのキャッシュをルートすることを許可し、そのようなアクティビティはログに記録されません。これは予想される最も効率的な動作です。
これをNOに設定すると、ヒット率が劇的に上昇しますが、やや遅くなります。
nscdはアップストリームのTTL値を尊重しています。
Google.comのDNSサーバーがgoogle.comのAレコードのTTLは10秒であり、positive-time-to-liveが36000であると言っている場合、レコードは10秒で期限切れになります。