трабла с MS SQL
в mssql бывает автоматическая сборка мусора ?
Тормозит его дисковая подсистема.Инсерты в таблицы с индексами?
+1.
вроде если индекс и данные разнести на разные винты(физические работать будет быстрее.
хотя у нас все пишется на зеркало и без проблем тоже в несколько таблиц.
вроде если индекс и данные разнести на разные винты(физические работать будет быстрее.
хотя у нас все пишется на зеркало и без проблем тоже в несколько таблиц.
вроде если индекс и данные разнести на разные винты(физические работать будет быстрее.у автора "xp128 от HP"
это такая балалайка размером в шкаф, для которой традиционные нехитрые методы типа разнесения индексов и данных по разным дискам просто не актуальны
в смысле там нельзя сделать, чтобы тома не пересекались по дискам?
если извратиться то может и можно, но никто так не делает - не нужно
как это не нужно? 
Ну так, I/O и так размазаны по десяткам дисков...
Я в основном работал с оборудованием классом пониже - HP EVA, в документах от Oracle+HP типа Best practices for Oracle 10g and EVA5000 нигде не найдёшь таких вещей как разнесение индексов и данных на разные диски.
P.S. Как там всё устроено в XP - не знаю. С ними не работал. Вроде лицензировано у Hitachi, признанного лидера...
Я в основном работал с оборудованием классом пониже - HP EVA, в документах от Oracle+HP типа Best practices for Oracle 10g and EVA5000 нигде не найдёшь таких вещей как разнесение индексов и данных на разные диски.
P.S. Как там всё устроено в XP - не знаю. С ними не работал. Вроде лицензировано у Hitachi, признанного лидера...
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.Короче, советуют все доступные диски отдавать под один большой рейд и на нём уже выделять место по надобности.
Ну так, I/O и так размазаны по десяткам дисков...Если задача небольшая, то эти десятки дисков будут поделены с десятками других задач, что уже чревато.
это такая балалайка размером в шкаф, для которой традиционные нехитрые методы типа разнесения индексов и данных по разным дискам просто не актуальныРазносить не обязательно. Но если часто происходит разбиение индексов, то MS SQL очень сильно теряет производительность insert'ов. Ещё хуже, если есть неправильные clustered index. Проблему можно попытаться решить, пересоздав индексы с малым значением fill factor.
Спсб. Насчет разнесения индексов итп - реально не актуально 
Шкаф тот еще - 128 винтов, как понятно из названия. Инсерты ведутся в таблицы с индексами, индексы перестраиваются раз в сутки. Попробуем почаще и ff поменьше. Хотя вроде бы они довольно долго перестраиваются... Но это все после праздников Так что можно еще подумать
Шкаф тот еще - 128 винтов, как понятно из названия. Инсерты ведутся в таблицы с индексами, индексы перестраиваются раз в сутки. Попробуем почаще и ff поменьше. Хотя вроде бы они довольно долго перестраиваются... Но это все после праздников Так что можно еще подумать индексы перестраиваются раз в суткиЕсли перестраиваются раз в сутки, то должно быть нормально. Конечно, при том объёме данных, который ты указал.
Для Ms sql server Майкрософт рекомендует разносить данные и индексы на разные диски, чтобы запись шла параллельно и независимо. Рейды, если я правильно себе представляю их работу, скорее должны замедлять операции с произвольным доступом. Вот журнал транзакции имеет смысл разметить на рейд массиве, т.к. там линейная запись.
Рейды, если я правильно себе представляю их работу, скорее должны замедлять операции с произвольным доступом.Почему это? Один винт читает одну часть файла, другой - другую, третий в это время записывает.
ну, я себе это так представляю: чтобы считать файл, который находится на 4-х винтах, надо как минимум дождаться, пока головка каждого винта займет необходимое положение, т.е. средний сик тайм — средний максимальных сик таймов.
вообще, если так много оперативы, то скорее всего проблемы именно с журналами транзакций
Журнал транзакций пишется непрерывно, для каждого изменения делается запись. Причем объем записи в журнал сопоставим с объемом изменений в базе. Буферизация записи в журнал минимальна, выполняется небольшими блоками для оптимизации скорости записи на диск. Поскольку запись в журнал осуществляется последовательно то, когда под журнал отводиться отдельный диск или отдельный рейд, то скорость, понятно, будет высокая. Если на этом диске или рейде сидят другие базы, и соответственно другие журналы транзакции, то скорость заметно падает, примерно как если с одного винта копировать одновременно несколько фильмов и выполнять другие операции.
Можно проверить эту версию, наверно, если последить за значением параметра Log Flush Wait Time для объекта SQLServer:Databases (для твоей базы или total). Мб еще параметр Log Flushes/sec поможет.
Журнал транзакций пишется непрерывно, для каждого изменения делается запись. Причем объем записи в журнал сопоставим с объемом изменений в базе. Буферизация записи в журнал минимальна, выполняется небольшими блоками для оптимизации скорости записи на диск. Поскольку запись в журнал осуществляется последовательно то, когда под журнал отводиться отдельный диск или отдельный рейд, то скорость, понятно, будет высокая. Если на этом диске или рейде сидят другие базы, и соответственно другие журналы транзакции, то скорость заметно падает, примерно как если с одного винта копировать одновременно несколько фильмов и выполнять другие операции.
Можно проверить эту версию, наверно, если последить за значением параметра Log Flush Wait Time для объекта SQLServer:Databases (для твоей базы или total). Мб еще параметр Log Flushes/sec поможет.
ну, я себе это так представляю: чтобы считать файл, который находится на 4-х винтах, надо как минимум дождаться, пока головка каждого винта займет необходимое положение, т.е. средний сик тайм — средний максимальных сик таймов.Зачем это? Считываем с любого из 4-х винтов, головка которого на месте.
из которой юзается дай бог 2.В порядке бреда - а PAE/AWE включены? SQL Server энтерпрайзовый?
Зачем это? Считываем с любого из 4-х винтов, головка которого на месте.а если используется striping или запись без буферизации?
контроллер массива ничего не знает о файлах.
контроллер массива ничего не знает о файлах.Зато ОС и драйверы вполне могут что-то знать.
PAE/AWE включены? SQL Server энтерпрайзовый?Да уж
Бред то оказался не бредом Оба были отключены. У нас просто один админ юниксоид по жизни, а второму на MSsql положить, потому как не его зона ответственности... В общем ночью перезапуск системы Посмотрим что получится...Ну и как оно? Лучше стало?
Оставить комментарий
gsharov
Может кто сталкивался... В общем - есть не такой уж сложный запрос. Инсерт на 300 строк всего. Не хитрый, ниче. Правда в несколько таблиц инсертится (ну т.е. 30 в одну, 30 в другую..) Ну дак вот. Периодически (не всегда, но часто) даже если паралельно работает только один юзверь этот запрос начинает тормозить. Тормозит его дисковая подсистема. Причем, судя по мониторингу дисковой активности, данных пишется мало (в байтах если). Но вот дисковая очередь вырастает до неприличных значений ~200. При этом сама база лежит на файбере (xp128 от HP) где размещается и оракловская база с которой таких проблем вовсе даже нет. Коннектится к массиву (файберу т/е) виндоввый сервак также как и юникс на котором оракл - в смысле аппаратной части. Запрос показать не могу (потому как корп тайна типа, да и я к нему косвенное отношение имею) Но мне отчего то кажется что не в нем дело а в настройке винды/sql. Сервак нормальный для задач которые решает - 4 ксеона + 6 гиг оперативы из которой юзается дай бог 2. Процы тоже не особо загружены (меньше 20% почти всегда). Вот... tempdb тоже на файбере лежит если что... Буду благодарен за любые советы и идеи, поскольку DBA у нас есть только ораклиный, да и тот так себе