Всем привет.
Может есть кто знающий по MS SQL Server'у 2012?
В общем база 1С около 400 ГБ. SQL Server и Сервер 1С на одной машине с 400 ГБ ОЗУ. В 1С используется сложный алгоритм расчета, основанный на запросах с хранением большого количества временных таблиц (уничтожение ненужных реализовано). В итоге выделенная SQL Server'у память в 358400 ГБ ([url=https://radikal.ru][img]https://a.radikal.ru/a31/1806/4a/4df88ac009db.png[/img][/url]) быстро выедается ([url=https://radikal.ru][img]https://a.radikal.ru/a07/1806/20/71b94396f2c4.png[/img][/url]
).
После этого 1С начинает работать медленнее, хотя расчет уже прошел и надо бы освободить память.
Хотелось бы задать вопросы следующие плана.
Почему SQL Server не освобождает занятую им память, хотя данные в ней уже давно не актуальны и надо бы ее освободить?
Как реализовать очистку памяти? Не рестартовать же службу каждую ночь...

Ссылки:
https://a.radikal.ru/a31/1806/4a/4df88ac009db.png
https://a.radikal.ru/a07/1806/20/71b94396f2c4.png

SQL Server сразу "отжимает" память системы столько, сколько ему необходимо (точнее сколько выделено в настройках).
Так что это вполне штатный режим работы, службу перезагружать не надо.

(2) А как мне узнать, например, что из 350 отжатых ГБ только например 50 содержит актуальные данные, а остальные 300 старые ненужные, которые он, я так понимаю, замещает на нужные при необходимости? И почему тогда явно замедляется работа 1С. Не хватает 350 ГБ выделенной памяти?

400Гб база ёмаё..

(4) 20+ узлов в РИБ ну... и пару таблиц есть по пол сотни гигов.

Очевидно же, или добавить физической памяти, или уменьшить аппетит SQL.

(2) Откуда дровишки? Не вводи людей в заблуждение. Как настроишь, так и будет.

(0) Во-первый SQL Server память освобождает, но не сразу, а через некоторое время.

Во-вторых, нужно выяснить, из-за чего "1С начинает работать медленнее". Может быть, совсем не из-за нехватки памяти.

Сколько памяти возьмет 1С, если ей вдруг освободить? Не 350 Гб же.

(0) Нагрузку на диск смотрели до и после этих расчетов? Возможно, память SQL надо еще ограничить, т.к. её не остается на прочие нужды системы.

(8) (9)
Свободная память остается, за этим следим, даже rphost немного съедает. Основная нагрузка на CPU скуля и память, которую он съедает.
Для теста взял уменьшил лимит до 50 Гб и SQL потихоньку освободил память до 50 ГБ. Потом вернул назад 350 ГБ. Через час уже 80 Гб забрал, хотя расчеты крупные ночью происходят.

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

(5) РИБ звезда? в плане снежинку предлагать?

Если вы попробуете после своей фразы "SQL Server не освобождает занятую им память, хотя данные в ней уже давно не актуальны", ответить на вопрос "Что значит данные не актуальны", да ещё в свете SQL индексов, планов и статистики запросов,
то вот тут вы поймёте, что ответить на это очень сложно.

Так что оставьте SQL как есть.

Лучше поищите инфу на тему "Счётчики SQL сервера и их анализ", это будет полезнее.

вар1. смотреть РИБ, возможно и не нужно так много узлов на одной ЦБ. Попробовать её децентрализовать. создав промежуточные между ЦБ и ПБ.
вар2. Может слишком жадный запрос? убирать излишнюю детализацию, сколько раз видел - вытаскивают по 100 полей в отчет для какого нибудь аналитика, который именно сводно строит по 8 полям, а остальные 90 нужны для расшифровок.
вар3. Если такое количество ВТ нужно держать активными - может подумать чтобы вместо этих ВТ создать новые справочники/регистры?

Короче это хорошая задачка для эксперта по технологическим вопросам.  )))

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

(0) А зачем вы вообще ожидаете что СГЛ вам чтото будет возращать? Ему выделили память, он ее в какой то момент всю занял. Дальше сам будет разбираться что и как лучше с ней делать.

Каждый час у себя выполняем произвольный запрос в SQL
DBCC FREESYSTEMCACHE ('all');

Удаляет все неиспользуемые элементы из всех кэшей. Компонент Компонент SQL Server Database Engine заранее автоматически очищает неиспользуемые элементы кэша в фоновом режиме, освобождая память для текущих записей. Однако можно использовать эту команду, чтобы вручную удалить неиспользуемые записи из всех кэшей или из указанного кэша пула регулятора ресурсов.

(17) Кэш создан чтобы помогать, а не чтобы его руками чистить.

(15) Скорее всего все проще. Во время тяжелого расчета вытесняются справочники и индексы из кэша, отсюда и "замедление".

(17) В бубен тоже стучите каждый час?

(11) Причем здесь РИБ вообще?

(21) ты сказал в 7 что 20 баз

планов обмена

то что я сказал в (13) - во первых для чего нужен такой тяжелый механизм расчета? обычно всегда можно сложный процесс разбить на более простые.

До чего же все-таки 1С-ники тупые ...
я просто оставлю это здесь
https://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/

(25) Вот уж сказанул так сказанул...

Что-то не вижу по ссылке ничего про тупизну 1С-ников.

(0) Автор очисти статистику ожиданий перед тем как начинает тормозить
DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);
GO

А потом запускай скрипт в (25)

Можешь настроить на сбор по периодам https://www.sqlskills.com/blogs/paul/capturing-wait-statistics-period-time/

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

(29) Скрипт Пола искажает и прячет? Можно пруф? А то DBA всего мира им пользуются и не знают

(31) В скрипт-то загляни.

(32) заглянул, что там не так?

(33)

    WHERE [wait_type] NOT IN ( <73 ожидания> )

(37) чувак учи матчасть...это неопасные ожидания

Пол же написал:

These wait types are almost 100% never a problem and so they are
        -- filtered out to avoid them skewing the results. Click on the URL
        -- for more information.

(39) So what do I do if one day one of these suddenly become a problem and take 20% of total time? I won't even see that. Instead, I'll see skewed results.

(41) это Пол говорит или это твои сочинения о вечном?

(41) чота не вижу у него про 20% откуда этот высер?

Tester, у нас были проблемы "внезапно начало тупить" или "конфликт блокировок на любом документе". Помогало уменьшить потом увеличить лимит памяти sql. Позже прописали в план обслуживания (раз в сутки, утром):

EXEC sys.sp_configure N'show advanced options', N'1'  RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'max server memory (MB)', N'5000'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure N'show advanced options', N'0'  RECONFIGURE WITH OVERRIDE
GO

Т.е. 2 задания, в одном (условно) 5000, во втором (через 5 минут) обратно на 358400.

Такой же эффект (для описанных проблем) дает очистка процедурного кеша сервера dbcc freeproccache (а лучше аналог DBCC FLUSHPROCINDB (DB_ID()) - только для одной базы).

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

(46) изменение лимита памяти как раз и сбрасывает проц кэш...найти причину и устранить мозга конечно же нет

(4) страшное тут не то что скуль сожрал 400Г памяти, а в том что 95% ЦП...
по ходу ему её не хватает, бггг
привет погромистам местным передавай

(50) "95% ЦП..." - вот уж действительно, слона-то я и не приметил :)
(0) Степень параллелизма у вас какая? Поставьте 1.

(50) (51) И что тут страшного? Если все данные в кэше, запросы идут на ЦП.

И проблема, на которую жалуется ТС, начинается "после этого".

(52) "что тут страшного?" // Да это сисадминская примета: если в пике нагрузка на какой-нибудь ресурс сервера достигает 80% или выше, то пора увеличивать этот ресурс

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

(52) Чушь. Скорей всего нагрузка из-за постоянной перекомпиляции планов или латчей на временных таблицах. Чтобы не гадать, нужна диагностика.

(0) сколько готовы платить за решение проблемы?