Итак подвожу итоги :)

Основная проблема второго сервера все таки в 5-рейде... как ни крути, а для БД это не лучшее решение... Усугубляет дело отсутствие батарейки и как следствие выключенный режим Write-Back.

Смею предположить, что если б это был какой нить 10-рейд с 6 дисками... то сервер бы "скушал" такой объем IO без всяких проблем.

АнатоЛой
Не вижу даже 50% прямой зависимости между величиной показателя seqscans и прочими проблемами. Я как раз и приводил такой пример с большим количеством seqscan'ов и SELECT FIRST 1. Если считать что подобных "приколов" нет, и все seqscan нужно умножать на
"seqscannedtable".nrows - увидим совсем другую картину...

Если бы на обоих сервера во всех таблицах количество записей было пропорционально, и функциональность бы использовалась пропорционально, и период, за который собрана статистика, и ...

Ну представьте на минутку, что на втором сервере проблема выглядит следующим образом:
1. в deals_tq - 7 млн записей, в отличие от сервера 1
2. часть "непроблемных seqscan" была по deals_tq - и поскольку на 1-ом сервере 0 записей, а на втором 7 млн, получаем, что для получения 250 млн pagereads на втором достаточно запустить запрос c seqscan аж 35 раз (раз в 5 мин в течение рабочего дня или раз в 15 мин в течение суток - за это время из буферов записи этой таблицы уже успевают вытесниться)
3. В результате активного чтения с диска (SECSCAN deals_tq) возрастает время работы других запросов. Ожидания блокировок начинают превышать lock time (приводит к откатам транзакций и возрастанию нагрузки на диски)
4. Общая производительность системы немного падает
5. В программном коде из-за использования "SET LOCK MODE TO WAIT;" падение производительности приводит к более длительному ожиданию, что в свою очередь приводит к выявлению сервером deadlocks, последующей генерацией жертвами-сессиями exception и последующими откатами транзакций, что начинает загонять сервер в глухой угол.

(Всё это на фоне мрачного RAID 5 с WriteThru - слово-то какое )
Апокалипсис...


П.С.: Берёте в сценаристы? :)


Тут АнатоЛой соверенно прав. На уровне БД была включена логика проведения бухгалтерских проводок... огромный потом IO в таблице deals_tq ... генерация IOs была мощнейшая... затык в дисках, LOCK, ROLLBACK и диски были завалены операциями отката...

В итоге вечером я отключил ненужный функционал и сервер вздохнул :) Блокировки редко проскакивают .. сервер стал "пошустрее работать".

Так же принято решение купить таки батарейку и включить Write-Back, благо не такие большие деньги.


Вот свежая картина :)


Уровень IOs упал почти в 10 раз :) Проблемки с локами наблюдаются небольшие, но я думаю они локализуются после покупки батарейки +большая свобода действий с моей стороны на уровне БД
поможет делу :)

Спасибо всем кто принимал участие... Помогли :)
Отдельное спасибо: Журавлев Денис,onstat- ,svat2 ,АнатоЛой за разбор полетов :)

З.Ы. тему можно закрыть.