LiveMan,

Понятно. Там нет "лишних" и "как попало" созданных индексов. Есть только те, котрые можно использовать в единственном варианте к запросу... или не использовать совсем. То есть по большей части, для меня фича - бесполезна.

А вот расширенная диагностика оказалась крайне полезной: 100% слоулог по причине InnoDb_IO_r_wait - оно составляет 99% времени выполнения запроса и может "висеть" до 10-15сек! При том, что команда dd if=/dev/zero of=/каталог_базы/test.txt bs=16384 count=1024, равно как и обратные команды в /dev/null и команды промеж пары таких файлов - кажут скорость копирования от 200 до 800 метров в сек (16М за 0.02сек)...

... что-то "не так" с диском? или с Перконой таки?

krevedko13,

Да, мне это известно, но тем не менее, даже в плохих ситуациях dd копирование из файла в файл кажет не хуже 115 метров в сек. Как можно "ожидать" чтения данных, объемом полтора метра по 10секунд?

Arhat109,

ладно полтора метра... запрос количества столбцов - COUNT(*) из инф.схемы может провисеть ... 5-10сек на этом же ожидании!

Arhat109,

?!? ничё не понял ?!? после прогона несколько раз dd с разным размером файлов по разделу raid с базами ... слоу лог - писаться перестал ваще и нагрузка на сервак вернулась в штатный диапазон... прос...ся чтоли? Как это? :)

tanglir,

похоже какой-то косяк со стыковкой с ФС. Теперь, в 2-хсекндный слоулог попадают только реально медленные запросы... там "лучше" мне придумать не удалось... там на самом деле надо сканировать по 20млн. записей...

Да, соглашусь не настолько оно "барахло"... система диагностики - очень даже на уровне. Но ресурсов в целом явно жрет больше.

miksoft,

увы, уже не посмотришь. Оно пашет. Не шустро как ожидалось, но без особой дури.

netwind,

Пока ещё нет. Админ - занят... пашет Перкона 5.5. Вроде - с утра (как прогнал dd) - ещё ровно. Мониторинг показывает, что тупление с io-wait - пропало, скорости запросов заметно подросли, но в целом итогового "приросту" - не заметно. Да, очень качественно начал заполняться кеш запросов... прям сказка. А наличие хорошей отчетности - позволяет за этим следить. В slow-log - пока попадают только реально проблемные запросы... по ним улучшение - явное:

Запрос по поиску "дочек" на структуре дерева со списком дочек в корневом узле (не надо так делать! Руки не доходят переделать :) ) в виде перечисления идентов через запятую в текстовом поле "мои_детки" - на выборке из 240тыс. записей, дерева в 4 этажа, в среднем по три дочки отдается за 10-12сек, вместо 30-40сек. как было ранее. При этом отчет слоулога показывает, что вся выборка (просмотр около 240тыс. записей) берет и индексы и данные из кеша InnoDb, время тратится только на выделение дочек из текстовых строк списку... фантастика.

Не, отчетность - явно класс. Я пожалуй ишо поиграюсь (пока админ занят)... :)

Arhat109,

но, в среднем по больнице - работает медленнее явно. Примерно процентов на 15 точно и жрет - больше зараза. :(

netwind,

нет, не в этом дело. "ДО" прогона команды dd - в слоулог валились вполне рядовые запросы и даже чисто служебные с временем исполнения в 3-15сек. Нагрузка на процы сервера была просто невероятная. При этом, "в среднем по больнице" сервер слегка притормаживал... до 2-х раз. Кеш запросов - практически не рос...

... сейчас их там нет, нагрузка на процы - штатная, время исполнения "несколько хуже" но "без фанатизма"... 10-20% по штатным запросам.

dd гонял сначала на 16.7метров, но потом сообразил что "маловато будет" и прогнал "туда-обратно" 17 гектар... и всё встало ровно. Кроме мыслей (черных) в сторону кеша ФС - других пока нет.

netwind,

вы где увидели "идею", да ещё и "классную"? Покажите, а то не заметил. Ежели вчё я описал результат и только. Причина - так и осталась не выясненной, где идея?

Возиться и ставить мониторинг, изучать в научных целях проблемы Перконы или 5.5 - некому и некогда. Как только админ освободится - откатимся на 5.1, вы это считаете "классной идеей"?

krevedko13,

он стоит у админа. Это его плюшка... мне она нафига? :)

Да, кстати. Нашлась причина. Перед каждым таким просадом появляется старый запрос из крона, который катает времянку 2гектара на диск... всё оказалось просто. Я про него - не знал... убираю ужо.

На последнего. Закончилось всё возвратом к MySql 5.1.
Как итог:
Нагрузка на процы вернулась к прежним значениям, в кеше Мускуля снова 90к+ запросов, апач - падать перестал. На Перконе было 3 падения апача за 4 суток работы. Причину никто не выяснял - уже было "пофиг"... Да, ещё, на Перконе был глюк со вставкой в пустую таблицу 37.5млн записей выбранных селектом сгруппировкой... Мускуль - вставил "всё ровно" и даже быстрее, чем у Перконы произошел глюк на 2.5млн-ной записи.

Тему можно закрывать. Мускуль 5.1. - рулит дальше. :)