nscd には「プリロード」という名前の単独のコマンドはありません。キャッシュを先に温めておくには、persistent（再起動後もキャッシュを保持）、reload-count（期限切れ前の再読み込み）、そして起動直後に getent で名前を引いておく、の3つを組み合わせます。この記事では、それぞれの設定方法と確認手順、WordPress サーバーで使うときの注意点を説明します。
nscd が何をキャッシュするのか
nscd（Name Service Cache Daemon）は glibc に付属するデーモンで、名前解決（NSS）の結果をメモリに保持します。対象は主に次のデータベースです。
- passwd / group：ユーザーとグループの情報。LDAP などのディレクトリを使う環境で効果が大きい
- hosts：ホスト名からIPアドレスへの解決（/etc/hosts と DNS）
- services / netgroup：サービス名とポート、ネットグループ
PHP の外部通信や WordPress の更新確認など、アプリケーションが glibc の名前解決を使う場合、nscd が動いていれば2回目以降の問い合わせはキャッシュから返ります。DNS サーバーへの往復が減るため、応答の遅いリゾルバを使っている環境や、同じホストへ大量に接続する処理で効果が出ます。
一方で、最初の1回はキャッシュがありません。再起動直後やキャッシュを消した直後に、外部APIへの接続が一時的に遅くなるのはこのためです。これを避けるのが「プリロード」の目的です。
nscd を使い続けるべきかの確認
ディストリビューションによっては、nscd は非推奨または削除の方向にあり、DNS のキャッシュは systemd-resolved、ユーザー情報のキャッシュは SSSD に任せる構成が案内されています（2026年10月現在）。新しく構築するサーバーでは、まず手元のディストリビューションで nscd が提供・サポートされているかを確認してください。SSSD を使っている環境で nscd の passwd・group キャッシュを有効にすると、二重にキャッシュされて変更の反映が遅れることがあるため、SSSD 側のドキュメントに従って hosts 以外は無効にするのが一般的です。
手順1：現在の状態を確認する
# インストールと稼働の確認
systemctl status nscd
# キャッシュの統計（ヒット率やエントリ数）
sudo nscd -gnscd -g の出力には、データベースごとに有効かどうか、persistent や shared の設定、キャッシュヒット数とミス数が表示されます。プリロードの効果を測るため、作業前の値を控えておきます。設定ファイルは通常 /etc/nscd.conf です。変更前にコピーを取っておきます。
sudo cp -a /etc/nscd.conf /etc/nscd.conf.bak手順2：persistent で再起動後もキャッシュを残す
/etc/nscd.conf で、対象のデータベースに persistent を設定します。以下は hosts の例です。
enable-cache hosts yes
positive-time-to-live hosts 3600
negative-time-to-live hosts 20
suggested-size hosts 211
check-files hosts yes
persistent hosts yes
shared hosts yes
reload-count hosts 5persistent を yes にすると、キャッシュの内容がファイル（多くの環境で /var/db/nscd/ 配下）に保存され、nscd を再起動しても前回の内容から始まります。これが最も手軽なプリロードです。shared を yes にすると、クライアントがキャッシュのメモリ領域を直接参照でき、問い合わせのオーバーヘッドが小さくなります。
check-files を yes にしておくと、/etc/hosts の変更を検知してキャッシュを無効化します。hosts ファイルで一時的に向き先を変えて確認する作業（サーバー移転前の表示確認など）をする場合は、有効のままにしておくと混乱が減ります。
DNS の結果については、DNS のように TTL を返すサービスでは、nscd はその TTL を使い、positive-time-to-live の設定は無視される、と nscd.conf の man ページに説明されています。TTL を短くして切り替えを準備している時期に、nscd が古い値を長く持ち続けることは基本的にありませんが、念のため実際の挙動を nscd -g と次の手順の確認で見ておきます。
手順3：reload-count で期限切れ前に読み直させる
reload-count は、キャッシュの期限が来たときに、エントリを捨てずに再取得する回数です。既定値は 5 で、unlimited も指定できます。よく使われるホスト名は、期限が来るたびに裏で読み直されるため、利用者側では「キャッシュが切れて遅くなる」瞬間が起きにくくなります。
ただし unlimited にすると、使われなくなった名前もずっと再取得され続けます。DNS への問い合わせが増えるほか、エントリがたまってメモリを使います。まずは既定値のまま様子を見て、ヒット率が足りない場合に増やすのが無難です。
手順4：起動直後に getent で名前を引いておく
persistent が使えない環境や、新しいサーバーで最初から温めたい場合は、よく使う名前を起動直後に引いておきます。getent は NSS を通して問い合わせるため、nscd が動いていればその結果がキャッシュに入ります。
#!/bin/sh
# /usr/local/bin/nscd-warm.sh
# よく使う接続先を事前に解決して nscd のキャッシュに入れる
for h in api.wordpress.org downloads.wordpress.org; do
getent ahosts "$h" > /dev/null
done
exit 0sudo chmod 755 /usr/local/bin/nscd-warm.sh接続先のホスト名は、サイトで使っている外部サービス（決済、メール送信API、CDNなど）に合わせて書き換えてください。dig は nscd を経由しないため、温める目的には使えません。
このスクリプトを nscd の起動後に実行させるには、systemd のドロップインを使います。
sudo systemctl edit nscd開いたエディタに次を書きます。
[Service]
ExecStartPost=/usr/local/bin/nscd-warm.sh保存したら反映して、再起動で動作を確かめます。
sudo systemctl daemon-reload
sudo systemctl restart nscd
sudo nscd -gExecStartPost のスクリプトが失敗すると、サービス全体が失敗扱いになることがあります。名前が引けない場合でも nscd 自体は止まらないよう、上の例では結果を捨て、末尾の exit 0 で終了コードを 0 にしています。DNS が一時的に応答しない状況でもキャッシュデーモンが起動できることを優先した書き方です。
手順5：効果を確認する
再起動後に nscd -g を見て、hosts のキャッシュ件数が 0 ではないこと、アプリケーションの通信後にヒット数が増えていることを確認します。WordPress 側では、管理画面の更新確認やサイトヘルスの表示が、再起動直後でも遅くならないかを見ておくと分かりやすいです。
古い値をすぐ捨てたいときは、データベース単位で無効化します。
sudo nscd -i hosts注意点
- アプリケーションが nscd を使うとは限らない：PHP の cURL 拡張は libcurl の名前解決を使います。libcurl が独自のリゾルバ（c-ares など）でビルドされている場合は glibc を通らず、nscd のキャッシュも効きません。
- コンテナ環境：コンテナ内のプロセスはホストの nscd のソケットを見ないのが普通です。コンテナごとに考える必要があります。
- systemd-resolved との重複：両方で hosts をキャッシュすると、どちらの値が古いのか分かりにくくなります。どちらか一方に寄せるのが運用しやすい構成です。
- 本番での変更：設定変更はステージングで試し、元の設定ファイルを残してから本番に反映してください。
まとめ
- nscd に専用のプリロード命令はなく、persistent・reload-count・getent による事前解決の組み合わせで実現します。
- persistent は再起動後もキャッシュを残す最も手軽な方法で、reload-count は期限切れによる遅延を減らします。
- 新規の環境では、起動直後に getent でよく使う接続先を引く処理を systemd のドロップインで追加します。
- 効果は
nscd -gのヒット数で確認し、古い値はnscd -i hostsで消せます。 - ディストリビューションによっては nscd が非推奨のため、systemd-resolved や SSSD との役割分担を先に決めておきます。