APC estranhas respostas longas

2

Eu tenho problema de resposta lenta no meu servidor debian 6 + nginx + apc 3.1.9 + php-fpm 5.3.10. Meu site é baseado no symfony 1.4.

Minha configuração é VPS com 512MB de RAM, que é quase sempre usada até 250MB. Isso só acontece se eu tiver o APC ligado. Sem o armazenamento em cache da APC, o site tem respostas mais lentas, mas se comporta de maneira estável.

Quando eu ligo o APC, alguns pedidos de cerca de 1/20 se comportam como se esperasse alguns arquivos serem desbloqueados ou algo assim e a resposta é enviada cerca de 5-6s depois. (Respostas comuns sobre as mesmas solicitações são exibidas em cerca de 100 ms) Eu tenho essa configuração do APC:

extension=apc.so

apc.enabled="1"
apc.shm_size="32M"
apc.num_files_hint = 100
apc.ttl="7200"
apc.gc_ttl="600"
apc.cache_by_default="1"
apc.filters = "apc\.php$,apc_clear\.php$"
apc.canonicalize="0"
apc.mmap_file_mask="/tmp/apc-php5.XXXXXX"
apc.enable_cli="0"
apc.max_file_size = 5M
apc.report_autofilter="0"
apc.include_once_override="0"
apc.write_lock="0"

apc.stat="0"

fpm é multithread assim como nginx, então eu ensinei seus arquivos de sessão bloqueados, ok, movi sessões para memcache - website é muito mais rápido (cerca de 50ms em média), mas o comportamento estranho com respostas algumas vezes muito longas permanece. >

Eu estou registrando respostas lentas (o limite é 3s) em fpm e capturo algumas delas:

config_core_compile.yml.php: o 3851 mencionado no segundo log contém apenas o $ path com o caminho válido para o arquivo php existente.

(o primeiro levou cerca de 20 anos!)

[15-Feb-2012 13:39:12]  [pool www] pid 2205
script_filename = /www/www.site.com/current/web/index.php
[0x0000000001d415f0] session_start() /www/www.site.com/releases/20120214220306/cache/frontend/prod/config/config_core_compile.yml.php:3779
[0x0000000001d41410] initialize() /www/www.site.com/releases/20120214220306/cache/frontend/prod/config/config_core_compile.yml.php:1507
[0x0000000001d3f0e0] __construct() /www/www.site.com/releases/20120214220306/cache/frontend/prod/config/config_factories.yml.php:114
[0x0000000001d3ea38] +++ dump failed

[15-Feb-2012 12:39:00]  [pool www] pid 2186
script_filename = /www/www.site.com/current/web/index.php
[0x0000000001b80670] renderFile() /www/www.site.com/releases/20120214220306/cache/frontend/prod/config/config_core_compile.yml.php:3851
[0x0000000001b7f820] renderFile() /www/www.site.com/releases/20120214220306/lib/vendor/symfony/view/sfPartialView.class.php:124
[0x0000000001b7f138] render() /www/www.site.com/releases/20120214220306/lib/vendor/symfony/helper/PartialHelper.php:220
[0x0000000001b7f040] get_partial() /www/www.site.com/releases/20120214220306/lib/vendor/symfony/helper/PartialHelper.php:182
[0x0000000001b7ebe0] include_partial() /www/www.site.com/releases/20120214220306/apps/frontend/modules/hotel/templates/_list_tabs_boxmain.php:8
[0x0000000001b7e770] +++ dump failed

O estranho é que isso acontece apenas às vezes ...

    
por palmic 15.02.2012 / 14:13

1 resposta

4

Encontrei ..

Foi por causa de apc.mmap_file_mask definido como "mmap com backup direto de arquivo", como foi dito documento APC oficial . Como a configuração do servidor é multithread e o apc era armazenado em um arquivo físico, ele era stucking por causa do arquivo bloqueado.

É muito importante configurá-lo na memória compartilhada.

Então agora meu apc.ini é:

apc.gc_ttl="600"
apc.cache_by_default="1"
apc.filters = "apc\.php$,apc_clear\.php$"
apc.canonicalize="0"
apc.mmap_file_mask=/apc.shm.XXXXXX
apc.enable_cli="0"
apc.max_file_size = 5M
apc.report_autofilter="0"
apc.include_once_override="0"

apc.stat="0"
    
por 17.02.2012 / 00:33