Isso pode não ser uma novidade, mas você já testou isso com algo diferente daquela instância do wordpress? Alguma chance de você realmente ter apenas ~ 32MB de conteúdo cahceable?
Estou configurando o APC (v 3.1.9) em uma instalação de alto tráfego do WordPress no CentOS 6.0 de 64 bits.
Eu descobri muitas das peculiaridades da APC, mas algo ainda não está certo. Não importa quais configurações eu mude, o APC nunca armazena mais de 32MB. Eu estou tentando bater até 256 MB. 32MB é uma quantidade padrão para apc.shm_size, então estou imaginando se ele está preso de alguma forma.
Eu corri o seguinte
echo '2147483648' > /proc/sys/kernel/shmmax
para aumentar a memória compartilhada do meu sistema para 2G (metade da minha caixa 4G). Então corri
ipcs -lm
que retorna
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 2097152
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1
Também fez uma alteração em
/etc/sysctl.conf
depois correu
sysctl -p
para fazer as configurações ficarem no servidor. Rebooted, também, para uma boa medida.
Nas minhas configurações de APC, tenho o mmap ativado (o que acontece por padrão nas versões recentes do APC). php.ini se parece com:
apc.stat=0
apc.shm_size="256M"
apc.max_file_size="10M"
apc.mmap_file_mask="/tmp/apc.XXXXXX"
apc.ttl="7200"
Estou ciente de que o modo mmap irá ignorar as referências a apc.shm_segments, então deixei com o padrão 1.
phpinfo () indica o seguinte sobre APC:
Version 3.1.9
APC Debugging Disabled
MMAP Support Enabled
MMAP File Mask /tmp/apc.bPS7rB
Locking type pthread mutex Locks
Serialization Support php
Revision $Revision: 308812 $
Build Date Oct 11 2011 22:55:02
Directive Local Value
apc.cache_by_default On
apc.canonicalize O
apc.coredump_unmap Off
apc.enable_cli Off
apc.enabled On On
apc.file_md5 Off
apc.file_update_protection 2
apc.filters no value
apc.gc_ttl 3600
apc.include_once_override Off
apc.lazy_classes Off
apc.lazy_functions Off
apc.max_file_size 10M
apc.mmap_file_mask /tmp/apc.bPS7rB
apc.num_files_hint 1000
apc.preload_path no value
apc.report_autofilter Off
apc.rfc1867 Off
apc.rfc1867_freq 0
apc.rfc1867_name APC_UPLOAD_PROGRESS
apc.rfc1867_prefix upload_
apc.rfc1867_ttl 3600
apc.serializer default
apc.shm_segments 1
apc.shm_size 256M
apc.slam_defense On
apc.stat Off
apc.stat_ctime Off
apc.ttl 7200
apc.use_request_time On
apc.user_entries_hint 4096
apc.user_ttl 0
apc.write_lock On
apc.php revela o gráfico a seguir, não importa quanto tempo o servidor seja executado (o tamanho do cache flutua e fica abaixo de 32 MB.
Ver imagem link
Você pode ver que o cache está tentando alocar 256MB, mas a parte marrom da torta continua sendo reciclada em 32MB. Isso é confirmado como atualização da página apc.php mostra as contagens de arquivos armazenados em cache que se movem para cima e para baixo (indicando que o cache não está mantendo todos os seus arquivos).
Alguém tem uma idéia de como fazer com que o APC use mais de 32 MB para o tamanho do cache?
** Observe que o comportamento idêntico ocorre para o eaccelerator, o xcache e o APC. Eu leio aqui:
esse suEXEC pode causar esse problema.
Seu problema real é a reinicialização freqüente do Apache que está impedindo que a APC crie o cache. Eu não comento o tamanho da memória para o wordpress. Você está usando o cPanel? Ele tem um recurso de rotação de log que, antes da rotação do log, reinicia o Apache, embora seja uma reinicialização normal, mas limpa todo o cache do APC. Você pode aumentar o limite de rotação de log ou ver por que ele atinge o limite tão rapidamente. Talvez você possa ativar o Piped Log na configuração do Apache (no cPanel).
Este link lhe dirá como você pode fazer as duas coisas.
tente aumentar
apc.shm_segments 1
veja o que acontece
A APC só armazenará em cache o código que está sendo usado ativamente - quando houver bastante memória, a única coisa que removerá o código do cache é o TTL.
Aumentar o TTL aumentará a ocupação.
Tags php cache apache-2.2