実行時設定

php.ini の設定により動作が変化します。

大半のインストール環境では、APCu はデフォルトの設定で問題ありません。 しかし、本格的なユーザーは以下のパラメータのチューニングを考慮すべきです。

APCuを設定するには、ひとつ決断が必要です。 どれくらいのメモリをAPCuに割り当てるのかということです。 この値を制御するのは apc.shm_size です。 以下のこれに関するセクションを注意深く読んで下さい。

サーバーがいったん起動したら、 拡張モジュールにバンドルされている apc.php スクリプトをドキュメントルートのどこかにコピーし、ブラウザから見てみましょう。 apcu の内部動作を詳細に分析した情報が見られるからです。 gd が有効になっている場合、面白いグラフも見られるでしょう。

apcu が動作している場合、(左側の) Cache full count の数が、キャッシュの容量が一杯になり、 メモリを開放するためにエントリを強制的に掃除しなければならなかった回数を示しています。 強制的に掃除している間、apc.ttl が指定されている場合、 APCu はまず期限切れのエントリを削除しようとします。 つまり、TTL が期限切れになったか、 TTL が設定されずに apc.ttl 秒間アクセスがないエントリです。 apc.ttl が指定されていないか、 期限切れのエントリを削除しても十分な容量を確保できない場合、 APCu はキャッシュ全体を削除してしまいます。

強制的に掃除しなければならなかった回数は、 上手に設定されているキャッシュであれば最小にすべきです。 キャッシュが頻繁に一杯になり、強制的に開放される場合、 スクリプトのパフォーマンスに悪影響が出てしまいます。 この数値を最小にする一番簡単な方法は、APCu により多くのメモリを割り当てることです。

APCu が mmap (メモリマッピング) のサポートを有効にしてコンパイルされている場合、 APCu はメモリセグメントをひとつしか使いません。 一方で、SHM (SysV共有メモリ) を有効にしてビルドした場合は、複数のメモリセグメントを使います。 SHM は /proc/sys/kernel/shmmax で最大値を持っていますが、MMAP にはそれがありません。 一般的には、MMAP のサポートを有効にすることをおすすめします。 なぜなら、MMAPはWebサーバーが再起動したときのメモリの再要求の速度が速く、 全体として起動時のメモリ割り当ての負荷が減るからです。

以下に設定ディレクティブに関する 簡単な説明を示します。

apc.enabled bool

APC を無効にする場合、apc.enabled を0に設定できます。 これはAPCがPHPに静的にコンパイルされている場合に役に立ちます。 なぜなら、これ以外にAPCを無効にする方法がないからです。 (DSO としてコンパイルされている場合、 php.ini の extension の行をコメントアウトすれば済みます)

apc.shm_segments int

コンパイラキャッシュに割り当てる共有メモリセグメントの数。 APC の共有メモリが不足したが、apc.shm_size にシステムが許可できるできるだけ高い値を設定している場合、 この値を増やすことでAPCがメモリ不足になることを避けられるかもしれません。

apc.shm_size string

個別の共有メモリセグメントのサイズ。 このFAQ で説明している短縮記法を使います。 デフォルトでは、システムによって(ほとんどのBSD系)は、 共有メモリセグメントのサイズの限界値がとても小さい場合があります。

apc.entries_hint int

異なる値を保存する数のおおよその"ヒント"。 わからない場合はゼロを設定して下さい。

apc.ttl int

ここで指定された秒数アクセスされていない場合、 TTL を明示的に指定しないキャッシュエントリが期限切れとみなされます。 こうすることで、キャッシュを挿入している間や、すべてのキャッシュを削除する前に、 そうした期限切れのエントリを都合よく削除できます。 こうした削除は場当たり的に行われるため、 apc.ttl 秒より古いデータであっても まだ読み取れてしまうことがあり得るので注意してください。 この設定は、TTLが明示的に指定されたキャッシュエントリに対しては意味がありません。

apc.gc_ttl int

キャッシュエントリがガベージコレクションのリストに残っても良い秒数。 この値はキャッシュされたソースファイルを実行中にWebサーバーが死んだ場合のフェイルセーフを提供します。 つまり、このソースファイルが変更された場合、 古いバージョンに割り当てられたメモリはTTLに達するまで絶対に要求されないからです。 この機能を無効にするにはゼロを設定して下さい。

apc.mmap_file_mask string

--enable-mmap を使ってPHPをコンパイルした場合に、 mmapされたメモリ領域をファイルベースか共有メモリベースにするかを決めるために、 mmapモジュールに渡すmktempスタイルのファイルマスク。 ファイルベースのmmapの場合、 /tmp/apc.XXXXXX のように設定します (X はちょうど6つにして下さい)。 POSIXスタイルの shm_open/mmap を使う場合、 .shm をマスクのどこかに含めて下さい。 e.g. /apc.shm.XXXXXX。 匿名のmmapされたメモリを使うために kernel の /dev/zero インターフェイスを使う場合、 この値に /dev/zero も設定できます。

apc.slam_defense bool

とても負荷が高いサーバーでは、いつサーバーを起動したり、 変更したりしても、同じファイルを同時にキャッシュしようとする 多くのプロセスの競合が発生します。 apc.slam_defense の値を 1 に設定すると、確率的な仕組みを使うことで、 複数のプロセスが同時に同じファイルをキャッシュするのを防ぐのを助けます。 同じキーが短期間に異なるプロセスからキャッシュされようとすると、 現在のプロセスがキャッシュをスラム化させるのを防ぐため、 キャッシュをスキップします。

apc.enable_cli int

この設定はほとんどの場合、テストかデバッグに使います。 これを設定すると、CLI版PHPでAPCが有効になります。 通常の状態では、CLI リクエストのたびにAPCキャッシュを生成し、 収集し、破棄するのは望ましくありません。しかし、テストシナリオによっては、 CLI版のPHPでAPCを簡単に有効に出来た方が便利な場合があります。

apc.serializer string

APCにサードパーティーのシリアライザを使わせる場合に使います。

apc.coredump_unmap bool

SIGSEGV のようなシグナルのシグナルハンドラをAPCで有効にします。 ハンドラでは、シグナルを受け取ったときにコアファイルに書き込みます。 これらのシグナルを受け取った場合、 APC はコアファイルから除外するために共有メモリセグメントをアンマップしようとします。 この設定は致命的なシグナルを受け取ったり、 APCの共有メモリセグメントの数を大きく設定している場合に、 システムの安定性を向上させる可能性があります。

警告

この機能は潜在的に危険です。 致命的なシグナルハンドラで共有メモリセグメントをアンマップすると、 致命的なエラーが発生したときの動作が未定義になる可能性があるからです。

注意:

kernel によっては、コアダンプファイルを生成するときに 様々なタイプの共有メモリを無視する機能を提供するものがあります。 こうしたkernelの実装は、 Apache scoreboard のような重要な共有メモリセグメントも無視するかもしれません。

apc.preload_path string

オプション。キャッシュデータを起動時に読み込むディレクトリのパスを設定します。

apc.use_request_time bool

TTL に SAPI リクエストの開始時刻を使います。