vasilis cpr ...(bufreads+lockreqs+bufwrites+seqscans)>0
...
в верхних строчках будет всплывать тормозящий запрос
Странно, как можно по числу запросов на блокировки определять "тормозящий запрос" ? Может сначала определимся, что такое "тормозящий запрос" ?
А как насчет чтений непосредственно с диска, ожиданий блокировок или дидлоков ?

В соседней ветке товарищ захотел оптимизировать запрос именно по этому параметру.

В общем случае ясен пень надо сначала понять, какой параметр надо оптимизировать, а потом соответственно изменить предлагаемый запрос.
а (bufreads+lockreqs+bufwrites+seqscans)>0 появилось, когда я не знал как ограничить выборку первыми N строками, да так и осталось в скрипте ;-)

Евгений Фадеев cprВ соседней ветке товарищ захотел оптимизировать запрос именно по этому параметру.Если Вы про меня, то я не хотел оптимизировать запрос (у меня его нет, был бы - я бы и так оптимизировал, без профайлинга по всемму серверу).
Я хочу найти узкие места в большой и сложной системе, о внутреннем устройстве которой у меня очень поверхностное представление.

ИМХО узкие места ищутся по жалобам юзеров.

Или смотреть операционку. У системного админа (не DBA) есть свои критерии.
Idle CPU какой?
А так узкими местами традиционно могут быть например диски.
iowait надо анализировать, если у вас в ОС есть ожидания чтения с дисков, то это скорее всего узкое место. Т.н. Informix запросил чтение с диска, а система не успевает по причине большого количества обращений к диску по совершенно различным секторам, так что скорость считывания с диска резко деградирует.
и.т.д.

vasilis cprбольшое число запросов на блокировку при малом количестве чтений конечно говорит о том, что чтение происходит из буферного кэша. Но это же означает что вероятнее всего запрос неоптимален. при этом еще должен cpu быть довольно большим.
Странный вывод. Даже очень.

Что именно? что запрос не оптимален? для OLTP скорее всего так и есть. Для OLAP скорее всего нет.

Евгений Фадеев cprИМХО узкие места ищутся по жалобам юзеров.

Или смотреть операционку. У системного админа (не DBA) есть свои критерии.
Idle CPU какой?
А так узкими местами традиционно могут быть например диски.
iowait надо анализировать, если у вас в ОС есть ожидания чтения с дисков, то это скорее всего узкое место. Т.н. Informix запросил чтение с диска, а система не успевает по причине большого количества обращений к диску по совершенно различным секторам, так что скорость считывания с диска резко деградирует.
и.т.д.Видите ли в чем дело: если у меня есть пара-тройка "кривых" запросов или нет пары-тройки жизненно важных индексов, то это легко может давать колоссальную нагрузку на диски, процессор, память и т.п.
Вы предлагаете лечить это разгоном процов, усилением дисковой подсистемы и наращиванием памяти?! Я предпочитаю другие методы.
А по данным низкоуровнего профайлинга (уровня ОС и железа) найти причины узких мест довольно сложно, если вообще возможно...

Первое, если в системе есть проблемы, то это проявляется именно на низком уровне - свопинг, иовэйты, Idle CPU близкий к нулю? ошибки на девайсах и т.д.. Если сисадмин говорит DBA что в системе все ОК, а юзеры жалуются, то тогда смотри в информикс.

То что тюнинг алгоритмов дает эффект намного выше, чем тюниг информикса или увеличение ресурсов вопросов не вызывает, я сам это здесь уже говорил как то.

Не очень понятна постановка вопроса "... если у меня есть ...". Они как правило или есть или их нет (пока нет). Но пока их нет, вы, не понимая природы запросов и характеристик распределения данных в таблицах врядли сможете их предугадать. Простой пример - сиквенс скан к небольшой таблице , плохо это или хорошо может сказать тот, кто может предполагать каким образом таблица будет расти. Если в ней например 100 коротких записей, и она никогда не вырастет - забудьте о ней. и т.д. и т.п....

эээ... а вообще
1 характер БД - OLTP или DSS? от этого много хависит
2 какая платформа? ОС и железо в смысле.

Сам по себе интенсивный ввод-вывод не означает, что это плохо. Может так надо и других вариантов вообще нет. Здесь как раз надо знать характеристики системы. Так например постоянное чтение 40 метров в секунду много или мало? Если читаете с локально FC диска- то нормально, а если с внешнего массива со страйпингом, то наверняка маловато.
И в таком случае разумеется с такого девайса надо уносить все остальное чтобы не мешать.
ИМХО профайлинг Informix обязательно надо соотносить с мониторингом ОС.


Какой всетаки Сан? Какой storage?.

Ввод-вывод говорите? тогда на каких именно чанках можно посмотреть onstat -D.
Посмотрите статистику в течении дня и в короткие периоды при пиковых нагрузках. Дает много пищи для размышлений.

Если смотрите статистику за день, то утром сделайте onstat -z, а вечером смотрите статистику. Если за короткий промежуток времени, то можно
onstat -rz -10 -D
-10 это время в секундах, ставьте скоко нужно.

Потом посмотреть какие таблицы в чанках лежат. Далее зависит от того, что там именно лежит - количество, размеры, количество экстентов, наличие фрагментов, индексы отсоединены или нет, ширина строк тоже немаловажна.

Если можете большие таблицы к которым идут постоянное обращение разнесите на разные девайсы.
Кстати хороший эффект для oltp дает установка признака резидентности для небольших, но постоянно читаемых таблиц, повышает кэширование и снижает ввод-вывод.