帶有 WordPress 和 W3TC 的 Apache AWS EC2 小型實例上的 APC 碎片問題

AWS EC2 小型實例、執行 WordPress 和 W3TC 的 Apache 2。一個小時內，我的 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 可能是導致問題的原因，外掛作者似乎同意這一點，但除此之外沒有任何有用的細節。為什麼會導致問題？

我只是暫時使用它並使用 APC 關閉對象記憶體嗎？我沒有什麼可以做的嗎？在不用於對象記憶體的情況下打開它真的有什麼幫助嗎？memcache 可以替代這裡的對象記憶體嗎？最後，也許我不應該太擔心碎片化？

Cached variables: 3562 ( 14.3 MBytes)

這就是導致您的碎片化的原因。GC 正在清理它們，當它們重新生成時，它們很可能被放置在一個新的“切片”中。

您可以嘗試在使用者變數上增加 GC TTL - 但如果您的 APC 使用程式碼手動處理可能是問題的一部分的 TTL。

3500+ vars 對於我所看到的來說相當多（僅記憶體 500 個文件，100MB SHM）；APC 可能無法正確利用。

編輯：

Hits 19195 Misses 13830

Insert Rate 1312.99 cache requests/second<– 這讓我覺得有些東西配置不正確。從技術上講，這告訴我您的記憶體在很大程度上是無效的，因為每秒生成 33% 的記憶體變數。

引用自：https://serverfault.com/questions/375593