трабла с MS SQL

gsharov

Может кто сталкивался... В общем - есть не такой уж сложный запрос. Инсерт на 300 строк всего. Не хитрый, ниче. Правда в несколько таблиц инсертится (ну т.е. 30 в одну, 30 в другую..) Ну дак вот. Периодически (не всегда, но часто) даже если паралельно работает только один юзверь этот запрос начинает тормозить. Тормозит его дисковая подсистема. Причем, судя по мониторингу дисковой активности, данных пишется мало (в байтах если). Но вот дисковая очередь вырастает до неприличных значений ~200. При этом сама база лежит на файбере (xp128 от HP) где размещается и оракловская база с которой таких проблем вовсе даже нет. Коннектится к массиву (файберу т/е) виндоввый сервак также как и юникс на котором оракл - в смысле аппаратной части. Запрос показать не могу (потому как корп тайна типа, да и я к нему косвенное отношение имею) Но мне отчего то кажется что не в нем дело а в настройке винды/sql. Сервак нормальный для задач которые решает - 4 ксеона + 6 гиг оперативы из которой юзается дай бог 2. Процы тоже не особо загружены (меньше 20% почти всегда). Вот... tempdb тоже на файбере лежит если что... Буду благодарен за любые советы и идеи, поскольку DBA у нас есть только ораклиный, да и тот так себе

Andr163

в mssql бывает автоматическая сборка мусора ?

kokoc88

Тормозит его дисковая подсистема.
Инсерты в таблицы с индексами?

laki

+1.
вроде если индекс и данные разнести на разные винты(физические работать будет быстрее.
хотя у нас все пишется на зеркало и без проблем тоже в несколько таблиц.

ava3443

вроде если индекс и данные разнести на разные винты(физические работать будет быстрее.
у автора "xp128 от HP"
это такая балалайка размером в шкаф, для которой традиционные нехитрые методы типа разнесения индексов и данных по разным дискам просто не актуальны

Marinavo_0507

в смысле там нельзя сделать, чтобы тома не пересекались по дискам?

ava3443

если извратиться то может и можно, но никто так не делает - не нужно

Marinavo_0507

как это не нужно?

ava3443

Ну так, I/O и так размазаны по десяткам дисков...
Я в основном работал с оборудованием классом пониже - HP EVA, в документах от Oracle+HP типа Best practices for Oracle 10g and EVA5000 нигде не найдёшь таких вещей как разнесение индексов и данных на разные диски.
P.S. Как там всё устроено в XP - не знаю. С ними не работал. Вроде лицензировано у Hitachi, признанного лидера...

ava3443

For most Oracle jobs, not much difference was seen in workload performance with different disk group layouts. However, there was a noticeable difference in performance for EVA functions. This was noticed when more disk groups were used. This is because of the way the EVA stripes data across all disks in each disk group. Having a single disk group allows for striping across more spindles thereby reducing the possibility of data access conflicts.
Короче, советуют все доступные диски отдавать под один большой рейд и на нём уже выделять место по надобности.

Marinavo_0507

Ну так, I/O и так размазаны по десяткам дисков...
Если задача небольшая, то эти десятки дисков будут поделены с десятками других задач, что уже чревато.

kokoc88

это такая балалайка размером в шкаф, для которой традиционные нехитрые методы типа разнесения индексов и данных по разным дискам просто не актуальны
Разносить не обязательно. Но если часто происходит разбиение индексов, то MS SQL очень сильно теряет производительность insert'ов. Ещё хуже, если есть неправильные clustered index. Проблему можно попытаться решить, пересоздав индексы с малым значением fill factor.

gsharov

Спсб. Насчет разнесения индексов итп - реально не актуально Шкаф тот еще - 128 винтов, как понятно из названия. Инсерты ведутся в таблицы с индексами, индексы перестраиваются раз в сутки. Попробуем почаще и ff поменьше. Хотя вроде бы они довольно долго перестраиваются... Но это все после праздников Так что можно еще подумать

kokoc88

индексы перестраиваются раз в сутки
Если перестраиваются раз в сутки, то должно быть нормально. Конечно, при том объёме данных, который ты указал.

bastii

Для Ms sql server Майкрософт рекомендует разносить данные и индексы на разные диски, чтобы запись шла параллельно и независимо. Рейды, если я правильно себе представляю их работу, скорее должны замедлять операции с произвольным доступом. Вот журнал транзакции имеет смысл разметить на рейд массиве, т.к. там линейная запись.

kokoc88

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

bastii

ну, я себе это так представляю: чтобы считать файл, который находится на 4-х винтах, надо как минимум дождаться, пока головка каждого винта займет необходимое положение, т.е. средний сик тайм — средний максимальных сик таймов.

bastii

вообще, если так много оперативы, то скорее всего проблемы именно с журналами транзакций
Журнал транзакций пишется непрерывно, для каждого изменения делается запись. Причем объем записи в журнал сопоставим с объемом изменений в базе. Буферизация записи в журнал минимальна, выполняется небольшими блоками для оптимизации скорости записи на диск. Поскольку запись в журнал осуществляется последовательно то, когда под журнал отводиться отдельный диск или отдельный рейд, то скорость, понятно, будет высокая. Если на этом диске или рейде сидят другие базы, и соответственно другие журналы транзакции, то скорость заметно падает, примерно как если с одного винта копировать одновременно несколько фильмов и выполнять другие операции.
Можно проверить эту версию, наверно, если последить за значением параметра Log Flush Wait Time для объекта SQLServer:Databases (для твоей базы или total). Мб еще параметр Log Flushes/sec поможет.

kokoc88

ну, я себе это так представляю: чтобы считать файл, который находится на 4-х винтах, надо как минимум дождаться, пока головка каждого винта займет необходимое положение, т.е. средний сик тайм — средний максимальных сик таймов.
Зачем это? Считываем с любого из 4-х винтов, головка которого на месте.

family

из которой юзается дай бог 2.
В порядке бреда - а PAE/AWE включены? SQL Server энтерпрайзовый?

bastii

Зачем это? Считываем с любого из 4-х винтов, головка которого на месте.
а если используется striping или запись без буферизации?

family

контроллер массива ничего не знает о файлах.

kokoc88

контроллер массива ничего не знает о файлах.
Зато ОС и драйверы вполне могут что-то знать.

gsharov

PAE/AWE включены? SQL Server энтерпрайзовый?
Да уж Бред то оказался не бредом Оба были отключены. У нас просто один админ юниксоид по жизни, а второму на MSsql положить, потому как не его зона ответственности... В общем ночью перезапуск системы Посмотрим что получится...

family

Ну и как оно? Лучше стало?
Оставить комментарий
Имя или ник:
Комментарий: