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, поэтому я научил его заблокированные файлы сеансов, хорошо, переместил сеансы в memcache - сайт работает намного быстрее (в среднем около 50 мс), но странное поведение с иногда очень длинными ответами сохраняется.
Iam регистрирует медленные ответы (порог 3 с) в fpm и ловит некоторые из них:
config_core_compile.yml.php: 3851, упомянутый во втором журнале, содержит только $path с допустимым путем к существующему файлу 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
Странно, что это случается только иногда...
1 ответ
Нашел это..
Это произошло из-за того, что 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"