Fragmentação do Cache do Servidor APC

Question

Estou executando um site Wordpress com APC e W3TC no CentOS 5.5, que recebe cerca de 10000 pageviews por dia (incluindo ajax e WP-Admin). O servidor é um VPS de baixo nível e tem um máximo de 376MB de RAM.

Recentemente, comecei a receber alguns travamentos no servidor, que agora posso atribuir à APC (desativei por alguns instantes e as falhas pararam).

Depois de reinstalar e olhar os gráficos da APC, vejo que estamos obtendo muita fragmentação, apenas alguns segundos após o lançamento do PHP-FPM. Em alguns casos, 100% de fragmentação pode ocorrer com alguns minutos.

O tamanho do cache atual é de 40 MB e estou um pouco hesitante em aumentar devido ao limite de memória no servidor.

Eu configurei um ttl no cache em 2 horas, mas tenho medo de que seja muito longo considerando a quantidade de fragmentação que está ocorrendo, no entanto, se eu definir um tempo muito curto, ele acabaria com todo o propósito de o cache.

Eu também notei que quando configuro userttl acima de 0, recebo muitos erros quando certas funções require / include / require_once / include_once são chamadas.

Qualquer ajuda seria muito apreciada.

    

Answer 1

Se a sua versão em execução do APC 3.0.6 for sugerida nas instruções de instalação do W3 Total Cache, você provavelmente obterá o potential cache slam avoided errors que preencherá seus registros muito rapidamente.

Desinstale o APC e reconstrua usando a versão 3.1.7 (3.1.9 está estável no momento), que corrige o bug do cache slam e vários outros problemas .

Você também obterá melhores resultados executando o último PHP 5.3.6, cada versão se aprimora na interação com o APC (eles serão completamente integrados quando o PHP 6 for lançado).

Veja também o seu arquivo de configuração e a configuração apc.slam_defense e aumente para 30 ou 40.

Para um aumento de desempenho real, ajuste o apc.stat para 0 e ele remove o processo de verificação de uma nova versão do arquivo. Se você fizer muitas alterações em seu site, elas não serão atualizadas até que o cache expire. (Meus usuários ficam frustrados, então tenho que mantê-lo em 1)

setting apc.slam_defense to 75 would mean that there is a 75% chance that the process will not cache an uncached file. So, the higher the setting the greater the defense against cache slams. Setting this to 0 disables this feature.

Reduza o apc.user_ttl que é o que o W3 Total Cache usa e o material mais dinâmico. Mantenha o apc.ttl alto porque serão seus arquivos principais do WordPress e arquivos de tema que você realmente não muda.

Eu suponho que seu objeto de configuração e cache de cache em W3 para APC. Para o tamanho do seu servidor, eu configuraria o cache de páginas para o disco aprimorado. Lembre-se também que você pode definir o ttl para o material dinâmico no W3.

Aqui está o meu executando um WordPress Multisite muito grande em um servidor dedicado com 12G Ram. Não tenha medo de aumentar o tamanho do cache, mesmo com memória limitada. Você sempre pode voltar para baixo, se necessário. O meu é definido em 512M, mas nunca usa mais do que cerca de 120M.

; configuration for php apc module
extension = apc.so
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 512M
apc.optimization = 0
apc.num_files_hint = 2700
apc.user_entries_hint = 2700
apc.ttl = 7200
apc.user_ttl = 3600
apc.gc_ttl = 600
apc.cache_by_default = 1
apc.slam_defense = 1
apc.use_request_time = 1
apc.mmap_file_mask = /dev/zero
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 = 1
apc.localcache.size = 1350
apc.coredump_unmap = 0
apc.stat_ctime = 0

    

Answer 2

Você tem uma alta "contagem total de cache"? Parece que você precisa aumentar o tamanho do seu apc.shm_size no php.ini para reduzir os itens armazenados em cache sendo removidos do cache. Ainda assim, é decepcionante que isso esteja causando problemas de estabilidade ...