Сервер забирает всю свободную память #406427

Стоит win server 2008, sql server 2008, сервер предприятия 8.1 - всё х64. Железо 8 процессоров, 7 гб ОЗУ У сервера предприятия запущен 1 рабочий процесс. "крутится" две базы УПП по 770 Мб - одна рабочая max 4 пользователя, другая тестовая копия для разработки, где только один пользователь. На этом сервере запускаются max 3 терминальных сессии, одна из которых моя. 1. Постоянно при работе процесс sqlserver забирает себе всю имеющуюся память Пользователи работают неактивно (15-20 документов в день), из последнего пример: поставил разворачиваться в тестовую базу бекап, процесс sql разрастается до 4-5 гигов, съедая всю свободную ОЗУ в связи с чем всё начинает "тупить", у процессора заргруженность max 20%. 2. Вчера под вечер сижу в тестовой базе, в консоли отлаживаю запрос (наипростейший, к остаткам в регистре), больше даже смотрю на результат выполнения. Разрастается процесс rphost до 6,5 Гб, отнимая память у всех процессов. Кое-как убил его через диспетчер задач. В чём могут быть причины такой жадности к ОЗУ?

Переходи на клюшки, там это реализовано!

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

свойства сервера, закладка мемори

вчера уже поставили ограничение sql'ю

у нас скуль съедает 30 гб оперативы

Зачем убил-то? Сервер бы перезапустил.

+ то есть не установи этого ограничения, он будет постоянно забирать, сколько захочет? поэтому больше интеерсует второй вопрос.

что некорректного в убивании процесса? не одно и тоже, если бы я перезапустил серевер предприятия?

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

так индексировать можно чуть ли не бесконечно, что sql честно и делает. В общем, для него такое поведение совершенно нормально. Если ресурсы сервера нужны еще дял чего-то - просто ограничьте sql'ю память

скоро под каждого буха и манагера будут ставить отдельный терминальный сервер и клиентскую машину не хуже чем 24-проца

> УПП - 15-20 документов в день. В акуе. И от железа для 15 документов тоже. > В чём могут быть причины такой жадности к ОЗУ? Ответ в

, начало деятельности, лицензий закуплено на 30 пользователей, которые с лета начнут активную работу. Терминальный доступ сейчас открыт для временных удаленщиков-бухгалтеров.

УПП 20 документов в день, базы 770 метров - на 8-процессорной машине с 7Г мозгов... офигеть...

повторюсь, sql'ю память уже ограничили, сейчас с ним всё ок. Основным остается вопрос о внезапном вчерашнем разрастании rphost'a.

Разнеси SQL и сервер предприятия...

"sql'ю память уже ограничили" - нда... Может, стоит позвать специалиста?

Об стену... И переходи на семерку.

что непрофессионального было высказано?

Спасибо и на том

дело не только в ограничении памяти скула. Скул вообще штука не простая. Я недавно тоже в это ввязался. Пока пару книг не асилил, толку не стало. Могу дать пару советов: рыба - модель базы ставь в симпл (тогда лог расти не будет) - автошринк - шринк базы вечером по заданию - ежеденевная архивация средствами скула и внимательное чтение логов на утро удочка - читай книжки по скулу, или найми спец. админа SQL. без этого не взлетит

"- модель базы ставь в симпл (тогда лог расти не будет)"  У них проблема не в разрастании лога. Хотя рекомендация, безусловно, полезная. Сам так всегда делаю.

Так наверное в момент разрастания запрос был не совсем простейший, а написанный с ошибкой, приводящей к декартовому соединению Хозрасчетного с самим собой или что-то в этом духе? ^^ Сиквель-то с бесконечными выборками справляется (не вылетает), а вот 1Ска дохнет, отжирая всю память

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

ща понасоветуют симпл :)

А зачем вести полный журнал транзакций, если никогда его не использовать? У многих ли возникает реальная необходимость "откатывать" базу на произвольный момент времени?

с архивированием всё хорошо, работа пока не активня, так что возможности восстановления на момент времени не требуется

Чего сложного в запросе? В результате запроса 139 строк ВЫБРАТЬ        ОстаткиИОбороты.Контрагент КАК Контрагент,        ОстаткиИОбороты.ДокументРасчетовСКонтрагентом КАК ДокДвижения,        ОстаткиИОбороты.Сделка КАК Заказ,        ОстаткиИОбороты.СуммаРеглКонечныйОстаток КАК СуммаРеглОстаток,        Город.Значение КАК Город,        Регион.Значение КАК Регион,        ОстаткиИОбороты.Сделка.Ответственный КАК Менеджер,        ОстаткиИОбороты.СуммаРеглРасход КАК Платежи    ИЗ        РегистрНакопления.ВзаиморасчетыСКонтрагентамиПоДокументамРасчетов.ОстаткиИОбороты КАК ОстаткиИОбороты            ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЗначенияСвойствОбъектов КАК Город            ПО ОстаткиИОбороты.Контрагент = Город.Объект            ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЗначенияСвойствОбъектов КАК Регион            ПО ОстаткиИОбороты.Контрагент = Регион.Объект    ГДЕ        Город.Свойство = &Город        И Регион.Свойство = &Регион    УПОРЯДОЧИТЬ ПО                ОстаткиИОбороты.ДокументРасчетовСКонтрагентом.Дата        ИТОГИ        СУММА(СуммаРеглОстаток),        СУММА(Платежи),        МАКСИМУМ(Город),        МАКСИМУМ(Регион),        МАКСИМУМ(Менеджер)    ПО        Контрагент

Надо посмотреть еще настройки венды, скл и рейда. Недавно в одной конторе сменил рейд5 на рейд1 - ускорение бэкап/ресторе в 5 раз, транзакций - в 10 раз, разносил рабочие базы и tempdb по каналам разным. Т.е.: 1. криворукий сисадмин. 2. судя по разрастанию сервера приложений - что то и в конфе "не так".

Чё то запрос не нравится. Я бы сделал вложенный запрос, где выбрал из регистра и сгруппировал по контрагенту, документу расчетов, сделке, менеджеру, а потом уже по сгруппированным данным лез бы в регистры сведений доставать свойства контрагента.

автошринк включи или сам базу режь периодически.

>>ОстаткиИОбороты.Сделка.Ответственный КАК Менеджер И тип реквизита Сделка - любой документ из БД? :)

- Вам чё, памяти жалко? (с) MS

Да им просто заняться нечем...

Да, опасный запросец :( 1. В верно сказали, в этом случае идет объединение с таблиц всех документов, которые могут быть в Сделка. Как правило, это очень опасно и тяжело по времени/объему :( 2. Надеюсь, индексация по всем полям, которые сравниваются и отбираются, стоит? типа Контрагент, Свойство, Объект? 3. Нафига в Итогах МАКСИМУМ(Город), МАКСИМУМ(Регион), МАКСИМУМ(Менеджер) ? 4. Неужели выборка ИЗ ВТ_ОстаткиОбороты нельзя ограничить по каким-то данным? Типа интервал дат, по контрагентам и т.д. Я бы лично еще протестил вариант с первоначальной выборкой контрагентов из РС ЗначенияСвойствОБъект (при условии его индексированности и не таком большом количесте записей, как в регистре накопления) по ограничивающим условиям, а уж потом левым присоединением выборки из регистра накопления. ЗЫ что еще забыл? настройки скуль пока пропускаем :)