web-dev-qa-db-ja.com

WordPressおよびW3TCを使用するApacheAWS EC2 SmallインスタンスでのAPCフラグメンテーションの問題

AWS EC2 Smallインスタンス、Apache2が実行中WordPressおよびW3TC。1時間以内に、APCの断片化が100％に達します。

私のAPC設定は次のとおりです。

apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 100M
apc.optimization = 0
apc.num_files_hint = 512
apc.user_entries_hint = 1024
apc.ttl = 7200
apc.user_ttl = 7200
apc.gc_ttl = 3600
apc.cache_by_default = 1
apc.use_request_time = 1
apc.filters = "apc\.php$"
apc.mmap_file_mask = "/tmp/apc.XXXXXX"
apc.slam_defense = 0
apc.file_update_protection = 2
apc.enable_cli = 0
apc.max_file_size = 2M
apc.stat = 1
apc.write_lock = 1
apc.report_autofilter = 0
apc.include_once_override = 0
apc.rfc1867 = 0
apc.rfc1867_prefix = "upload_"
apc.rfc1867_name = "APC_UPLOAD_PROGRESS"
apc.rfc1867_freq = 0
apc.localcache = 0
apc.localcache.size = 256M
apc.coredump_unmap = 0
apc.stat_ctime = 0
apc.canonicalize = 1
apc.lazy_functions = 0
apc.lazy_classes = 0
/etc/php.d/apc.ini

より多くのうんちがあります ここに見られます 。

主に ここ から設定をクリブしました。 shmは、いくつかの観察の後で、このような高い値から削り取られることを意図していましたが、明らかに、このような大きな値は十分に高くさえありません。

同様の質問/回答を見つけました ここ 。私はいくつかの仮想ホストをセットアップしていますが、それらはまったく触れられていません。ユーザーをWPの管理パネルにログインさせると事態は悪化しますが、それは確かに主な原因ではありません。質問者はそれが判明したことを示唆しているようです W3TCはおそらくproblem 、プラグインの作者は同意しているようですが、それ以上の役立つ詳細はありません。なぜ問題が発生するのですか？

今のところそれを取り、APCでオブジェクトキャッシュをオフにしますか？私にできることはありませんか？オブジェクトのキャッシュに使用せずにオンにすると、実際に何か役に立ちますか？ memcacheは、ここでのオブジェクトキャッシュの代わりに使用できますか？最後に、断片化についてそれほど心配する必要はないのでしょうか。

apache-2.2amazon-ec2wordpressmemcachealternative-php-cache
3
two7s_clash

Cached variables: 3562 ( 14.3 MBytes)

これが断片化の原因です。 GCはそれらをクリーンアップしており、再生時に新しい「スライス」に配置される可能性があります。

ユーザー変数でGC TTLを上げることを試みることができますが、APC使用法のコードが、問題の一部である可能性のあるTTLを手動で処理している場合。

3500以上の変数は私が見ているものにはかなりのものです（キャッシュされたファイルは500ファイルのみ、100MB SHM）。 APCが正しく活用されていない可能性があります。

編集：

Hits 19195Misses 13830

Insert Rate 1312.99 cache requests/second <-これにより、何かが正しく構成されていないと思います。技術的には、これは、キャッシュされた変数の33％が毎秒生成されるため、キャッシュはほとんど効果がないことを示しています。

4
thinice