Итак, похоже, найдена еще одна супер-тупая недокументированная фича класса CFileCache в моём “любимом” фреймворке Yii. Страницы некоторых “действий” (actions) кешируются целиков в файлах на ФС с помощью CFileCache.
Суть проблемы в том, что, по прошествии суток после начала работы нашего “facebook-проекта” на новом движке, начала по экспоненте расти нагрузка. На решение проблемы было убито более суток… Должен отметить, попутно разобрался с рядом мелочей, которые давно доставляли мне неприятности, в частности, с отсутствием на сервере нормальной системы мониторинга (отсетапил себе nagios).
Так вот, дело в том, что в классе CFileCache есть protected метод flushValues, вызывающий “уборщик мусора” $this->gc(false);
который (какая гениальная идея!) проходится рекурсивно по директориям и удаляет файлы, время действия кеша для которых истекло. Учитывая 10-20 запросов в секунду, которые создает мне googlebot и другие обитатели сети, количество файлов в каждой папке, даже при 3-уровневом файловом кеше, зашкаливает и в этот момент сервер уходит в глубокий коматоз. То, что причина не в mysql, было понятно почти сразу – mysql жрет кучу ресурсов, даже после memcached, но нагрузку основную я ощущал именно на диске, потому как переставали выполняться любые команды, даже такие как date, uptime, не говоря уже о ls и df 😉 А mysql-базы находятся на другом диске с raw разделе и в этот момент сам mysql не показывал ни одного нового запроса по show processlist. Стало ясно, что проблема где-то в апаче, а точнее – в софте, так как от предыдущей версии софта, текущая версия отличалась лишь использованием yii… И жесткая нагрузка диска давала намёк на то, что трабла как раз в механизме кеширования. 2й раз полез в исходники CFileCache и обнаружил, упомянутый выше, собрщик мусора с рекурсией. Завтра утром станет понятно, насколько точны мои расчеты и насколько эффективным оказалось решение проблемы.