У меня проблема с медленным откликом на моем сервере 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"