Линукс Блог » Баги

Yii CFileCache Performance Issue [Solved] – Проблема с резким ростом нагрузки при использовании CFileCache во фреймворке Yii

admin — Tue, 21 Jun 2011 20:31:37 +0000

Итак, похоже, найдена еще одна супер-тупая недокументированная фича класса 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 и обнаружил, упомянутый выше, собрщик мусора с рекурсией. Завтра утром станет понятно, насколько точны мои расчеты и насколько эффективным оказалось решение проблемы.

Проблема с OpenSSH – “Protocol major versions differ: 2 vs. 1″

admin — Sat, 16 Apr 2011 08:46:04 +0000

При попытке установить беспарольное соединение между 2-мя серверами на ubuntu (8.04 vs 9.*), выскочила такая ошибка:

Protocol major versions differ: 2 vs. 1
lost connection

и соединение, ясень пень, сразу же разрывается. Что бы все-таки законектиться можно добавить ключ “-1″ на машине отправителе (отправитель – это система на 9й убунте с 5м openssh-ем на борту, получатель – система на 8й убунте с 4.7 openssh), другими словами, можно сделать так:
ssh -1 source_file user@remote:remote_file
но при этом мои rsa ключи, сгенерированные для других серверов, для этой пары не работали.
Начал гуглить и откапал решение. Оказывается, 1ая версия протокола ssh использует другие ключи, а именно rsa1.
Для их генерирования используем команду

ssh-keygen -t rsa1

Ключик получился немного непривычным на вид, но отличия еще в том, что создаются файлы с непривычными названиями:
identity и identity.pub.
По аналогии, точнее, по привычке, перенес identity.pub на сервер-приемник, добавил в конец /home/$user/.ssh/authorized_keys и … получилось!

Надеюсь, по заголовку поста кто-то найдет эту страницу и она ему поможет.

UPDATE:
что бы rsync использовал 1й протокол, все-таки оказалось нужным раскомментировать строку
Protocol 2,1
в /etc/ssh/ssh_config
теперь ssh клиент сам определяет, когда нужно использовать 1ую версию протокола, а когда вторую.

Короче, проехали – работает.

Пофиксил проблемы с SMTP при регистрации на блоге

admin — Sun, 03 Jan 2010 13:37:57 +0000

Так увлёкся прикручиванием OpenID авторизации к блогу, что не заметил, как smtp сервер перестал отсылать посетителям логин/пароль после регистрации обычным способом (без ОпенАйди).

Спасибо Сергею за своевременное извещение!

Кстати, мне сейчас намного больше нравится авторизация через friendconnect от Гугла. С ней логиниться можно с реквизитами своего Twitter, GMail или Yahoo аккаунта.