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

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

Yii Framework не работает с БД без PDO

admin — Sat, 16 Apr 2011 09:34:40 +0000

В контексте масштабирования нового сайта на дополнительные 2 сервера столкнулся с очередными проблемами, теперь Yii отказывался работать с mysql без установки PDO.
Просто не забудьте поставить

sudo apt-get install php-pear [если он у вас еще не установлен, конечно]

sudo pecl install pdo
sudo pecl install pdo_mysql

ну и, для сборки, мне еще понадобились хедеры клиента мускула:

sudo apt-get install libmysqlclient15-dev

Всё, правка кронтаба и в путь – выжирать новые мегабиты на webazilla-e.

‘Lost connection to MySQL server at ‘reading authorization packet’, system error: 0′

admin — Tue, 18 May 2010 11:55:04 +0000

Если у вас возникает такая ошибка
'Lost connection to MySQL server at 'reading authorization packet', system error: 0'
при попытке соединиться с mysqld, знайте – проблема с сетью
В моём случае суппорт corenetworks.net оказался умнее меня.. Ребята заметили, что последние дни мои 10мб/сек забиты на 100%, с чем и было связано возникновение это ошибки. После подключения сервера в 100мб порту всё решилось.

Очередной баг в MySQL

admin — Fri, 25 Dec 2009 17:34:32 +0000

Еще одну прелестную новость подарил сегодняшний день.
В одной из хранимых процедур, после переезда на новый сервер запрос работал невероятно медленно. Космически медленно. Вместо тысяч insert/replace в секунду – один insert за 2-3 минуты. Начал копаться в show innodb status и обнаружил, что каждое текстовое значение принудительно конвертировалось в utf8
SELECT id INTO @vI FROM project.table1 WHERE project.table1.word = NAME_CONST('vD',_utf8'by word here' COLLATE 'utf8_general_ci') LIMIT 1;
Решить проблему удалось с 1й попытки – в начале процедуры поставил
SET NAMES ‘cp1251′ COLLATE ‘cp1251_general_ci’;
и объявил переменную как
DECLARE vD VARCHAR(67) CHARSET CP1251;
Как потом оказалось – достаточно было лишь объявить переменную.
Не сложно, но почему сама по себе операция сравнения project.table1.word с NAME_CONST(‘vD’,_utf8′by word here’ COLLATE ‘utf8_general_ci’)
занимала столько времени.
Чушь какая-то.

dbForge Studio – мой выбор. И пару слов о MySQL

admin — Wed, 09 Dec 2009 19:31:02 +0000

В новом проекте всё завязано на базе. Очень большие объемы информации нуждаются в тщательной проектировке и отладке. Впервые возникла необходимость в средстве визуальной проектировки БД. Выбор сделал в пользу dbForge Studio и, думаю, оказался прав. Софт писали люди, которые определенно им будут пользуются сами. Очень качественный продукт, всё продумано, стандартная привязка клавиш. Никаких сюрпризов – сел и начал работать. Руки сами знаю, что и где спрятано. Что особенно понравилось, так это отладка хранимых процедур, да и само создание процедур реализовано очень удобно. Короче – супер!

Часть 2 или “программист растёт вместе с объемами его баз данных”.
Когда объем записей увеличивается в 10 тысяч раз – программисту приходится расти и самому. Уже давно не позиционирую себя как программера, но все-таки всю серверную часть пишу самостоятельно из соображений дальнейшей поддержки софта, да и вообще – это удобно, безопасно и держит в тонусе. Продвинулся за последние 2 недели в вопросах кодировок (особенно китайских GBK, big5)..
Обнаружил не очень-то хорошо документированную необходимость указывать у формальных параметров хранимой процедуры CHARSET UTF8 после, к примеру, VARCHAR(255), иначе в базу данные попадают, проходя через процедуру, в виде знаков вопроса. Вроде всё, движемся дальше…