SQL выжирает все процессорное время, как решить проблему - Страница 2 - DAX: Администрирование

Sergik · 28.03.2006, 09:41

to vadik

А двумя строчками выше приведеной цитаты: % загр проц - 97

Так что одно лежит, другое висит.

Пусть человек попробует, ничего страшного в этом нет. Тем более если они планируют добавить новую стойку.

**Vadik** · 28.03.2006, 09:58

Цитата:

Сообщение от serge kotov

Так что одно лежит, другое висит

Зато как висит (с) оптимист

Цитата:

Пусть человек попробует, ничего страшного в этом нет. Тем более если они планируют добавить новую стойку

Да пусть попробует, конечно. Правда, в серебряную пулю верю чем дальше, тем меньше. Старею, наверное

**sergeypp** · 28.03.2006, 10:08

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

Еще заметил одну вещь.. Счетчик очереди чтения попеременно, то близок у нулю (с пиками), то взлетает вверх и не падает, с чем это связано еще не разобрался - в обоих случаях, блокировок вроде нет, кол-во пользователей одинаковое. Загрузка проца то же около 70%. Есть ли еще каки-нить счетчики, с помощью которых можно определить, чем вызвана такая активность??

я отключил автообновление статистики (делаю ночью планом), увеличил интервал сохранение контр точек до 15 минут. Выделил 6гиг статически и запретил своп. так что система по сравнению с тем что было - чувствует себя лучше, правда иногда загрузка взлетает под 100 %. Так же появляются лавинообразные блокировки (я создал другую тему по этому поводу). Cahe Hit Ratio под 100 %
могу прислать файл мониторинга за последние 5 дней

Sergik · 28.03.2006, 13:29

Цитата:

Сообщение от sp16RUS

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

Еще заметил одну вещь.. Счетчик очереди чтения попеременно, то близок у нулю (с пиками), то взлетает вверх и не падает...

ИМХО с точки зрения производительности стойку нужно сконфигурировать полностью на один логический раздел (конечно не забываем о хотсвапе), не разделяя на более мелкие. Дело в том, что чем больше винчестеров в RAID, тем более быстро он работает. Как уже говорили ранее предпочтителен RAID10 (0+1).

Раскидывать БД на логические файлы нужно в случае нескольких дисковых массивов. Оптимальность определяется опытным путем. Разбиваете, тестируете, видите, что в среднем нагрузка на каком то логическом файле чрезмерная, выносите оттуда еще таблицы. Снова тестируете, пока в среднем не сравняется. У нас, например, наиболее требовательная была SalesLine.

То что счетчик по чтению скачет это нормально. Так всегда бывает. Продолжительные пики бывают например когда запускается расчет каких-нибудь аналитических отчетов особенно по длительным периодам.

**sergeypp** · 28.03.2006, 13:48

Цитата:

Есть ли еще какие - нить рекомендации на этот случай. так же интересны уже существующие варианты распределения таблиц по лог. файлам.

а по этому вопросу есть что нить?. Что бы с чего то начать.