Sua configuração mostra que apc.max_file_size está definido como 16 bytes . Portanto, nenhum arquivo com mais de 16 bytes (e TODOS eles são!) Será armazenado em cache. Eu iria redefinir isso para o padrão de 1M .
Meu objetivo é implementar o APC para cache opcode para um site de produção do drupal 6. Eu até agora testei APC com vários arquivos php com e sem incluir outros arquivos php com include_once.
Também tentei ajustar os valores de apc.ini para shm_size, apc.include_once_override e apc.stat. Reiniciou o apache toda vez.
Resultando em apc.php não mostrando nenhuma alteração em nenhum valor. (exceto, claro, os valores alterados do apc.ini são mostrados como deveriam)
Toda vez que eu atualizo a página de teste apc.php, a hora de início é redefinida como a hora atual mostrando o tempo de atividade 0 minutos.
apc.php -testpage mostra:
General Cache InformationAPC Version 3.1.9
PHP Version 5.2.10
APC Host xxxx.xx.xx
Server Software Apache/2.2.3 (CentOS)
Shared Memory 1 Segment(s) with 128.0 MBytes
(mmap memory, pthread mutex Locks locking)
Start Time 2011/07/26 11:53:56
Uptime 0 minutes
File Upload Support 1
Cached Files 0 ( 0.0 Bytes)
Hits 1
Misses 1
Request Rate (hits, misses) 2.00 cache requests/second
Hit Rate 1.00 cache requests/second
Miss Rate 1.00 cache requests/second
Insert Rate 0.00 cache requests/second
Cache full count 0
Cached Variables 0 ( 0.0 Bytes)
Hits 0
Misses 0
Request Rate (hits, misses) 0.00 cache requests/second
Hit Rate 0.00 cache requests/second
Miss Rate 0.00 cache requests/second
Insert Rate 0.00 cache requests/second
Cache full count 0
apc.cache_by_default 1
apc.canonicalize 1
apc.coredump_unmap 0
apc.enable_cli 0
apc.enabled 1
apc.file_md5 0
apc.file_update_protection 2
apc.filters
apc.gc_ttl 3600
apc.include_once_override 0
apc.lazy_classes 0
apc.lazy_functions 0
apc.max_file_size 16
apc.mmap_file_mask /tmp/apcphp5.095eRm
apc.num_files_hint 1024
apc.preload_path
apc.report_autofilter 0
apc.rfc1867 0
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 128M
apc.slam_defense 0
apc.stat 0
apc.stat_ctime 0
apc.ttl 7200
apc.use_request_time 1
apc.user_entries_hint 4096
apc.user_ttl 7200
apc.write_lock 1
Host Status Diagrams:
Free: 128.0 MBytes (100.0%) Hits: 1 (50.0%)
Used: 20.3 KBytes (0.0%) Misses: 1 (50.0%)
Detailed Memory Usage and Fragmentation:
Fragmentation: 0%
phpinfo mostra:
Server API CGI/FastCGI
APC:
Version 3.1.9
APC Debugging Enabled
MMAP Support Enabled
MMAP File Mask /tmp/apcphp5.JkKDk7
Locking type pthread mutex Locks
Serialization Support php
Revision $Revision: 308812 $
Build Date Jul 21 2011 14:31:12
Eu segui estas etapas para descobrir se as configurações do suexec impediriam o armazenamento em cache: link
[root@host /]# ps -ef|grep lsphp
root 20402 17833 0 11:21 pts/0 00:00:00 grep lsphp
[root@host /]# ps -waux
root 17833 0.0 0.1 5004 1484 pts/0 S 10:39 0:00 bash
.. indica que não há lsphp em execução no host
também li o seguinte artigo e comentários, concluindo que no meu caso o problema não é o suexec como o usuário apache é o proprietário do processo httpd link
também o comando suexec não é reconhecido quando registrado e executado como root @ host
Também estou quase confiante de que não há nenhum cPanel em execução no host para verificar se uma configuração lá redefiniria o processo de cache em execução em algum intervalo
Isso me deixa com poucas pistas para onde ir. Eu tentei definir (com chown e chgrp) apache como o proprietário do arquivo apc.php e alguns arquivos php de teste, resultando em 500 erro de servidor.
Existe uma maneira de verificar se as permissões do arquivo impedem que o apc continue em execução? Sou muito grato por qualquer sugestão ou ajuda.
Sua configuração mostra que apc.max_file_size está definido como 16 bytes . Portanto, nenhum arquivo com mais de 16 bytes (e TODOS eles são!) Será armazenado em cache. Eu iria redefinir isso para o padrão de 1M .
Você tem o SELinux habilitado nesse host? Verifique isso com getenforce . Se devolver Enforcing , está ativado.
Caso esteja habilitado e você não precise dele, tente temporariamente (até a próxima reinicialização, por exemplo) desativá-lo com setenforce 0 . Se isso resolver seu problema e você precisar desativar permanentemente o SELinux, modifique o arquivo /etc/selinux/config e defina-o como desativado. Alternativamente, você pode tentar modificar o SELinux para ser mais permissivo, mas isso é outro tópico e nós retornaremos a isso se isto realmente fosse por causa do SELinux. : -)
EDIT: OK, o SELinux foi desativado.
Você vê /tmp/apcphp5.JkKDk7 arquivos elegantes aparecendo em / tmp?
Eu tive o mesmo problema. Foi um problema de tmp. A configuração de mmap_file_mask para / dev / zero conseguiu o armazenamento em cache. Detalhes postados em drupal.org com o mesmo nome de usuário.
Definir permissões no tmp não ajuda se não estiver montado com as permissões corretas.
No caso de alguém achar isso à procura de um problema semelhante, talvez seja necessário verificar apc.enable_opcode_cache = 1 :
"Na ramificação de desenvolvimento (3.1.5dev), uma opção foi introduzida para desabilitar o cache opcode (apc.enable_opcode_cache = 0), que permite usar o Zend OPcache e o APC estritamente para dados do usuário." -Remi Blog
Tags cache apache-2.2 php5 centos5