Доброго времени суток ALL!

Никак не могу побороть проблему производительности сервера, а именно - низкую скорость чтения данных с диска ;(

Есть одна большая плоская таблица содержащая аналитические данные. Построены индексы (минимум необходимого). Эта таблица находится в отдельном dbSpaces на отдельном физическом носителе.

При обращении к ней скорость чтения данных не превышает 1500-2000 Кб/сек.

По монитору SCSI дисков заметил что скорость доступа к ним (винтам) от процесса dbsrv11 очень редко переваливает за отметку 2000 Кб.

При этом загрузка проца минимальна (2-10% одного ядра). Из других приложений скорость чтения-записи около 30-40 Мб/сек (например прямое чтение в никуда, копирование, тот же транслятор логов работает намного продуктивней с файловой системой).

Под кеширование базе отдано 6 гигов (-cw server option).
(база большая - около 40 гигов)

Что не так? Куда копать?
Какие есть хитрости повышения производительности?

P.S. ParalelQuery советовать включить не надо - почему-то база периодически вылетает с Assertion при достаточной нагрузке.

P.S. Фрагментация файлов базы минимальна. Фрагментация таблиц то же (периодически раз в неделю запускается Reorganize и дефрагментация).

v_smirnov
По монитору SCSI дисков заметил что скорость доступа к ним (винтам) от процесса dbsrv11 очень редко переваливает за отметку 2000 Кб.


Небольшая поправка. при бэкапе (включая бэкап на лету) скорость доступа возрастает до 13-15 мб/сек - значит умеет быстро писать и читать, но не хочет ;(

Уровень изоляции либо ReadUnCommited либо ReadCommited (большего и не надо, т.к. используется AppServer).

авторнасколько интенсивно АСА работает с основным пространством и временными файлами

Вот тут немного подробнее если можно. В стандартных средстваx монитора я что-то этого не нашел.

автормного времени тратиться на составление хэш таблиц или много пишется промежуточных результатов во времянки

Это можно как-то мониторить?

Без сложных запросов не обойтись ... вложил один из примеров плана.
выдает 1 запись, время 1,8 - 2,0 сек. (в основной таблице (по которой условие where по PK) 1,5 млн записей, в остальных до 100 тыс.)

95% запросов оптимизировано до такого состояния - все данные отбираются по PrimaryKey или FK

P.S. Сорь что немного сумбурно, я пока не понимаю куда надо копать для оптимизации ...

"вложил один из примеров плана" - повторная отправка ... в первый раз сорвалось

Если и сейчас не будет файла - то можно взять отсюда:
http://vsmirnov.sang.ru/Sql/

авторчто этот самый AppServer и сгенерил сей запрос

Сер абсолютно прав! ;)
nHibernate ничего не знает про особенности синтаксиса языка ASA 11.

Тем не менее если его переписать на key join и left outer join план запроса не меняется ;((
Тут надо отдать должное оптимизатору - он сам понял что хочет AppServer

Все свойства объекта связаны либо по PK либо по FK. Это дало выигрыш в производительности по сравнению с первоначальным вариантом но все равно этого мало.

to ASCRUS
авторСкачал план, посмотрел ... раскурил :)

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

авторНа фоне большого кол-ва соединяемых таблиц с большим кол-вом записей
хм ... т.е. в данном случае оптимизатор не оценивает условие where и то что кол-в записей будет 1 штука? Вроде он в плане запроса везде пишет что ожидаемое количество строк=1.

Убрал первую часть из запроса (просто select * сделал), убрал inner join - зрительно план не поменялся. Те же "LEFT OUTER JOIN с использованием Sort" и "NESTED LOOPS" - так и должно?

to Ggg_old
автора если вы двадите ккй-нибудь просто запрос к табличке

Спасибо за идею. Исходные данные для теста - таблица около 12 млн записей.
план запроса - "Scan t_dw using index idx_t_dw_dOut"
985890 Row(s) affected
Execution time 25 sec
максимальная скорость доступа к диску ... 2 мб/сек

жаль тут смайлов нет ... эмоциональных. Ушел читать и экспериментировать ...