» Утечка памяти на Microsoft SQL 2008 R2

В общем имеется терминал-сервер на базе Windows Server 2008 R2 Enterprise и все работало отлично, пока не появилась жесткая необходимость перевести 1С 8.3 в формат SQL. Установил MS SQL 2008 R2 в самом дефалтном конфиге. На серваке 32Gb оперативки. Как только компьютер включаешь/перезагружаешь все что на нем задействовано съедает около 3.5Gb оперативки. Но уже через сутки (даже если никто не работал) съедается еще ~2Gb. В течении недели съедается вся свободная оперативка и комп приходится перезагружать, чтобы опять все началось с начала. Никакие особые настройки на сервере не делались, все по умолчанию. Может кто знает, решение? Наверняка, это какой-нибудь штатный косячок.

Скорей всего поглащает оперативу SQL сервер, если ему жестко не выставить , посмотри в процессах

Arhimeddd
В процессах ничего такого нету, поэтому я все-таки грешу на криворукость разработчков, как вариант:
https://support.microsoft.com/ru-ru/kb/2778088

Diabolik
Я бы рекомендовал все таки провести диагностику сервера и определить точно что именно течет. Может быть причина не только в SQL.
Можно начать с RamMAP и посмотреть несколько дней за памятью. Посмотрите вот эту статью Преодолевая ограничения Windows: выгружаемый и невыгружаемый пулы в частности ближе к концу статьи Отслеживание утечек пула это если если вы определите с помощью RamMAP что невыгружаемый пул системы слишком разросся.
Посмотрите еще A memory leak in nonpaged pool memory occurs in Windows Server 2008 R2

Скулю нужно жёстко задать ограничение по потреблению памяти в настройках, как написал Arhimedddp. В настройках по умолчанию - без ограничений.
Если раньше всё работало, то вряд ли утечка памяти вылезла после установки SQL. Ну размер non-paged пул можно в диспетчере задач глянуть конечно. А сколько отжирает SQL так и не написал...

ну какая утечка - скуль сожрет все что есть, если есть необходимость в ограничении его аппетитов, то это настраивается

Andrey_Verkhoglyadov
До установки SQL утечки небыло. А больше ничего не изменилось.

Да не утечка же это. В свойствах сервера выставляется объем памяти. Если его не ограничить он закеширует со временем вообще всё. Хоть всю базу и логи. Выставьте сколько надо.

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

Diabolik
Та не. Ставишь ему 32 гига, он 32 и заберёт через некоторое время. Ну при большой базе. И всего ему хватит, это же кэш, всегда можно скинуть. Естественно на это требуется чуть больше времени.
Естественно при таком конфиге он может зажать систему. Вообще прочтите что-нибудь по проектированию СУБД. А именно памяти. Там чистое быстродействие и его критичность.
Он может вообще без кэша жить, только диск будет изнасилован, и работать тормозно.
Посмотрите размер базы, прикиньте ее рост, и задайте %50, только и про систему не забыть. Например сколько отъедает терминальная сессия и сколько их. Плюс всякие обязательные процессы.
В общем, либо оставлять как есть, либо потужиться с калькулятором, и посмотреть.

Diabolik
Ты только вдумайся в слова: это не утечка - это MS SQL сервер так работает. Он кеширует базу в оперативку. Если база большая - он всю память и сожрет. Ничего плохого в этом нет, но идеально, если оперативки больше, чем весит база, тогда все очень шустро

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

В свойствах системы , дополнительные параметры, дополнительно, параметры, дополнительно. Выбираешь оптимизировать работу программ и перегружаешься.

З.Ы. будь готов, что упадет скорость работы с базой. Но для работы в терминале этот режим чуть ли не обязательно

Paromshick
На серваке 2 процессора и 32 Гб оперативки. Основная база 1С 8.3, весит 30 с лишним гигабайт. SQL и пришлось подымать только потому, что в обычный формат уже просто не влезало. Проще говоря база огромная + 2 бухгалтерии и 2 кадровых баз. Все это в терминале на 20 пользователей.

tankistua
Цитата:

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

Она при всем желании не влезет в оперативку.

Народ, так где все это смотреть? Где и как выставляется ограничения? Как проверить этот параметр:
Код: select [Memory Used KB] = (pages_allocated_count * page_size_in_bytes)/1024 from sys.dm_os_memory_objects where type = 'MEMOBJ_RESOURCE'