11

私はかなり長い間これで遊んできましたが、何をすべきかについて少し途方に暮れています。PHP 5.2.5 を搭載した CentOs 5 で APC 3.1.3p1 を使用しています。APC は、オペコード キャッシュとユーザー キャッシュの両方として機能します。ほとんどの場合、このサーバーは、APC キャッシュ サポート用の CacheRouter モジュールを使用して Drupal 6 サイトを実行します。私はしばらくの間 APC 3.0.19 を実行していましたが、時折 Apache がロックアップする原因となっていたため (そのバージョンの APC で文書化されたバグ)、3.1.3p1 を使用しているのはそのためです。

512 MB のメモリ (mmap) を持つように APC を構成しました。

症状は少し断続的ですが、空のキャッシュから開始すると、一般的に次のように表示されます。

  • ユーザー キャッシュはかなりゆっくりといっぱいになります。最初の挿入レートは 20,000 挿入/秒程度ですが、ユーザー キャッシュは数百、次に数千のエントリしか報告せず、非常にゆっくりと成長します。これは write_locking がオンになっていることに起因する可能性がありますが、目前の問題を解決する上で重要な場合に備えて言及したいだけです。数時間後、約 30k エントリの平衡に達します。

  • 断片化は早期に始まり、急速に成長します。おそらく 10 時間ほどで、通常は 100% の断片化になります。

  • 全体的な (オペコード + ユーザー) キャッシュの使用量は、約 240MB で安定しています。そのレベルを超えることはほとんどありません。1 日ほどすると、ユーザー キャッシュ キャッシュ フル カウント (UCCFC) が増加し始めます。

これを書いている時点で、私の UCCFC は 62358 で、APC が 280MB の空き容量を報告しているにもかかわらず、増加しています。私は 7200 の user_ttl を持っていますが、それを 0 または他の量に設定して遊んだこともあり、問題にはほとんどまたはまったく影響しません。

問題は断片化に関係していると思われます。現在、私のサーバーは「断片化: 100.00% (24740 個のフラグメントで 280.0 MB のうち 280.0 MB)」と報告しており、APC が報告している空き容量はたま​​たま 280 MB です。偶然だと思います。残念ながら、ドキュメントやその他の場所で、APC の世界で「断片化」が本当に何を意味するのかを示す貴重な情報を見つけましたが、それを回避するためにできることはほとんどないようです。

誰でもこの問題に光を当てることができますか?

4

2 に答える 2

23

APCは、次の式を使用して断片化の割合を計算します。

(total_size_of_free_blocks_lt_5M / total_size_of_all_free_blocks) * 100

*フラグメント化されたものとして5M未満のブロックのみをカウントすることに注意してください。

私はあなたの特定のケースを平易な英語に翻訳します：

フラグメンテーション：100.00％（24740フラグメントの280.0Mバイトのうち280.0Mバイト）

これは、無料のブロックの280Mのうち、すべてが5M未満であることを意味します。空き領域をフラグメントの数で割ると、これは平均フラグメントサイズが約11.6Kに相当することがわかります。

つまり、使用可能なすべてのブロックよりも大きいアイテムを保存しようとすると、そのアイテムは収まらず、apc.user_ttl 構成設定に基づいて2つのいずれかが発生します。TTLが0に設定されている場合、ユーザーキャッシュ全体がフラッシュされ、アイテムが挿入されます。TTLが0より大きい値に設定されている場合、期限切れのエントリがフラッシュされ、アイテムが挿入されます。どちらの場合も、キャッシュのフルカウントが増加します。あなたの場合と同じくらいこの増分があることは、あなたがそれを間違っているかもしれないという指標です。

これは、時間の経過とともに断片化がキャッシュに何を行っているかを簡単に視覚化したものです。これは単純な32バイトのキャッシュサイズを表し、各ブロックは1Bです。

[--------------------------------]（空から開始）
[A -------------------------------]（1B保存）
[ABB -----------------------------]（2B保存）
[ABBCCCC -------------------------]（4B保存）
...（時間が経過する）
[A--CCCC-EEE--GGGGGG-III--KKKLLLL]

したがってM、サイズ4Bのアイテムを保存する場合、使用可能な最大のブロックは2Bであるため、保存できません。これにより、キャッシュのフルカウントの増分がトリガーされ、上記で詳細に説明したuser_ttlに基づいて完全または部分的なフラッシュがトリガーされます。

今の質問は：あなたの場合、これは悪いですか？

そうかもしれないと思います。100％キャッシュの断片化は、それ自体は悪いことではありません。実行中の本番サーバーでそれを確認することは珍しくありません。ただし、それだけの空き容量で100％で表示されることは、何かが間違っている可能性があることを示しています。

  • キャッシュが多すぎる可能性があります。キャッシュがあるからといって、すべてをキャッシュに入れる必要があるわけではありません。
  • （エントリの）TTLが短すぎるとキャッシュしている可能性があります。TTLが低いということは、解放されていないブロックがより頻繁に解放されていることを意味します。
  • 保存しようとしている非常に大きなアイテムがいくつかある可能性もあります。100％の断片化では、5Mを超えるアイテムは適合しないことが保証されます。平均空きブロックサイズが11.6Kの場合、サイズが11.6Kを超えると、特定のアイテムが収まらない可能性が高くなります。

ユーザーキャッシュをサイズで並べ替えて、最大のエントリとそのTTLを確認することをお勧めします。多分それらは増やすことができますか？

アプリケーションと使用パターンに深く関わっていない限り、正確な診断を行うことは実際には不可能ですが、これらの情報はすべて、正しい方向に進むはずです。それが問題ではない可能性は十分にあり、APCに静かに仕事をさせることができます。

于 2010-08-07T00:23:28.193 に答える
0

http://pecl.php.net/bugs/bug.php?id=13146そこで続行するか、新しいバグ レポートを開く必要があると思います。

于 2010-08-06T04:57:56.037 に答える