Назад | Перейти на главную страницу

Странные длинные ответы APC

У меня проблема с медленным откликом на моем сервере debian 6 + nginx + apc 3.1.9 + php-fpm 5.3.10. Мой сайт основан на Symfony 1.4.

Моя установка - VPS с оперативной памятью 512 МБ, которая почти всегда используется до 250 МБ. Это происходит, только если у меня включен APC. Без кеширования APC сайт откликается медленнее, но ведет себя стабильно.

Когда я включаю APC, некоторые запросы 1/20 ведут себя так, как будто они ждут разблокировки некоторых файлов или чего-то подобного, и ответ отправляется через 5-6 секунд. (Общие ответы на одни и те же запросы обслуживаются примерно за 100 мс) У меня есть эта настройка 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 является многопоточным, как и nginx, поэтому я научил его заблокированные файлы сеансов, хорошо, перенес сеансы в кеш-память - веб-сайт работает намного быстрее (в среднем около 50 мс), но странное поведение с иногда очень длинными ответами остается.

Я регистрирую медленные ответы (порог 3 с) в fpm и ловлю некоторые из них:

config_core_compile.yml.php: 3851, упомянутый во втором журнале, содержит только требуемый путь $ с действительным путем к существующему файлу php.

(первый занял около 20 с!)

[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

Странно то, что бывает только иногда ...

Нашел ..

Это было из-за того, что apc.mmap_file_mask был установлен в "прямую файловую поддержку mmap", как сказано официальный документ APC. Поскольку настройка сервера многопоточная и apc хранился в физическом файле, он завис из-за заблокированного файла.

Очень важно поместить его в общую память.

Итак, теперь мой 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"