Имя: Пароль:
1C
1С v8
Очистка памяти SQL Server
, ,
0 Tester
 
21.06.18
09:40
Всем привет.
Может есть кто знающий по 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 не освобождает занятую им память, хотя данные в ней уже давно не актуальны и надо бы ее освободить?
Как реализовать очистку памяти? Не рестартовать же службу каждую ночь...
1 Tester
 
21.06.18
09:41
2 1c-kind
 
21.06.18
09:42
SQL Server сразу "отжимает" память системы столько, сколько ему необходимо (точнее сколько выделено в настройках).
Так что это вполне штатный режим работы, службу перезагружать не надо.
3 Tester
 
21.06.18
09:46
(2) А как мне узнать, например, что из 350 отжатых ГБ только например 50 содержит актуальные данные, а остальные 300 старые ненужные, которые он, я так понимаю, замещает на нужные при необходимости? И почему тогда явно замедляется работа 1С. Не хватает 350 ГБ выделенной памяти?
4 tabarigen
 
21.06.18
09:47
400Гб база ёмаё..
5 Tester
 
21.06.18
10:29
(4) 20+ узлов в РИБ ну... и пару таблиц есть по пол сотни гигов.
6 Галахад
 
гуру
21.06.18
10:37
Очевидно же, или добавить физической памяти, или уменьшить аппетит SQL.
7 mistеr
 
21.06.18
12:28
(2) Откуда дровишки? Не вводи людей в заблуждение. Как настроишь, так и будет.
8 mistеr
 
21.06.18
12:48
(0) Во-первый SQL Server память освобождает, но не сразу, а через некоторое время.

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

Сколько памяти возьмет 1С, если ей вдруг освободить? Не 350 Гб же.
9 ptiz
 
21.06.18
12:56
(0) Нагрузку на диск смотрели до и после этих расчетов? Возможно, память SQL надо еще ограничить, т.к. её не остается на прочие нужды системы.
10 Tester
 
21.06.18
13:51
(8) (9)
Свободная память остается, за этим следим, даже rphost немного съедает. Основная нагрузка на CPU скуля и память, которую он съедает.
Для теста взял уменьшил лимит до 50 Гб и SQL потихоньку освободил память до 50 ГБ. Потом вернул назад 350 ГБ. Через час уже 80 Гб забрал, хотя расчеты крупные ночью происходят.

В общем делаю вывод, что не нужно пытаться освобождать эти 350 ГБ. Если только для проверки как быстро он назад их заберет и хоть какой-то проверки ее достаточности.
11 Tankur
 
21.06.18
14:05
(5) РИБ звезда? в плане снежинку предлагать?
12 Минона
 
21.06.18
14:08
Если вы попробуете после своей фразы "SQL Server не освобождает занятую им память, хотя данные в ней уже давно не актуальны", ответить на вопрос "Что значит данные не актуальны", да ещё в свете SQL индексов, планов и статистики запросов,
то вот тут вы поймёте, что ответить на это очень сложно.

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

Лучше поищите инфу на тему "Счётчики SQL сервера и их анализ", это будет полезнее.
13 Tankur
 
21.06.18
14:15
вар1. смотреть РИБ, возможно и не нужно так много узлов на одной ЦБ. Попробовать её децентрализовать. создав промежуточные между ЦБ и ПБ.
вар2. Может слишком жадный запрос? убирать излишнюю детализацию, сколько раз видел - вытаскивают по 100 полей в отчет для какого нибудь аналитика, который именно сводно строит по 8 полям, а остальные 90 нужны для расшифровок.
вар3. Если такое количество ВТ нужно держать активными - может подумать чтобы вместо этих ВТ создать новые справочники/регистры?
14 Tankur
 
21.06.18
14:16
Короче это хорошая задачка для эксперта по технологическим вопросам.  )))
15 arsik
 
гуру
21.06.18
14:24
Может у вас, из-за больших изменений после "алгоритма" планы запроса не актуальны. попробуйте после закрытия статистику обновить.
16 KAUTERPER
 
21.06.18
16:11
(0) А зачем вы вообще ожидаете что СГЛ вам чтото будет возращать? Ему выделили память, он ее в какой то момент всю занял. Дальше сам будет разбираться что и как лучше с ней делать.
17 yzimin
 
21.06.18
16:16
Каждый час у себя выполняем произвольный запрос в SQL
DBCC FREESYSTEMCACHE ('all');

Удаляет все неиспользуемые элементы из всех кэшей. Компонент Компонент SQL Server Database Engine заранее автоматически очищает неиспользуемые элементы кэша в фоновом режиме, освобождая память для текущих записей. Однако можно использовать эту команду, чтобы вручную удалить неиспользуемые записи из всех кэшей или из указанного кэша пула регулятора ресурсов.
18 Tankur
 
21.06.18
19:41
(17) Кэш создан чтобы помогать, а не чтобы его руками чистить.
19 mistеr
 
21.06.18
20:24
(15) Скорее всего все проще. Во время тяжелого расчета вытесняются справочники и индексы из кэша, отсюда и "замедление".
20 mistеr
 
21.06.18
20:24
(17) В бубен тоже стучите каждый час?
21 mistеr
 
21.06.18
20:25
(11) Причем здесь РИБ вообще?
22 Tankur
 
21.06.18
20:38
(21) ты сказал в 7 что 20 баз
23 Tankur
 
21.06.18
20:38
планов обмена
24 Tankur
 
21.06.18
20:42
то что я сказал в (13) - во первых для чего нужен такой тяжелый механизм расчета? обычно всегда можно сложный процесс разбить на более простые.
25 болид
 
21.06.18
21:09
До чего же все-таки 1С-ники тупые ...
я просто оставлю это здесь
https://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/
26 mistеr
 
21.06.18
21:14
(25) Вот уж сказанул так сказанул...

Что-то не вижу по ссылке ничего про тупизну 1С-ников.
27 болид
 
21.06.18
21:17
(0) Автор очисти статистику ожиданий перед тем как начинает тормозить
DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);
GO

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

Можешь настроить на сбор по периодам https://www.sqlskills.com/blogs/paul/capturing-wait-statistics-period-time/
29 mistеr
 
21.06.18
21:20
(25) Я бы не стал пользоваться скриптом, который прячет некоторые ожидания и искажает картину.
31 болид
 
21.06.18
21:21
(29) Скрипт Пола искажает и прячет? Можно пруф? А то DBA всего мира им пользуются и не знают
32 mistеr
 
21.06.18
21:24
(31) В скрипт-то загляни.
33 болид
 
21.06.18
21:27
(32) заглянул, что там не так?
37 mistеr
 
21.06.18
21:46
(33)

    WHERE [wait_type] NOT IN ( <73 ожидания> )
38 болид
 
21.06.18
21:50
(37) чувак учи матчасть...это неопасные ожидания
39 болид
 
21.06.18
21:52
Пол же написал:

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.
41 mistеr
 
21.06.18
22:05
(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.
42 болид
 
21.06.18
22:11
(41) это Пол говорит или это твои сочинения о вечном?
43 болид
 
21.06.18
22:13
(41) чота не вижу у него про 20% откуда этот высер?
46 cons74
 
22.06.18
06:48
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()) - только для одной базы).

Это конечно не правильное решение проблемы, но за не имением лучшего, обходимся тем что есть.
47 болид
 
22.06.18
06:51
(46) изменение лимита памяти как раз и сбрасывает проц кэш...найти причину и устранить мозга конечно же нет
50 Адинэснег
 
22.06.18
08:44
(4) страшное тут не то что скуль сожрал 400Г памяти, а в том что 95% ЦП...
по ходу ему её не хватает, бггг
привет погромистам местным передавай
51 ptiz
 
22.06.18
08:59
(50) "95% ЦП..." - вот уж действительно, слона-то я и не приметил :)
(0) Степень параллелизма у вас какая? Поставьте 1.
52 mistеr
 
22.06.18
09:16
(50) (51) И что тут страшного? Если все данные в кэше, запросы идут на ЦП.

И проблема, на которую жалуется ТС, начинается "после этого".
53 Cyberhawk
 
22.06.18
13:55
(52) "что тут страшного?" // Да это сисадминская примета: если в пике нагрузка на какой-нибудь ресурс сервера достигает 80% или выше, то пора увеличивать этот ресурс
54 Cyberhawk
 
22.06.18
13:57
А то когда в пике настанет *опа, тогда уже может поздняк оказаться увеличивать - и будут простои и все такое
55 чегевара
 
22.06.18
14:04
(52) Чушь. Скорей всего нагрузка из-за постоянной перекомпиляции планов или латчей на временных таблицах. Чтобы не гадать, нужна диагностика.
56 чегевара
 
22.06.18
14:05
(0) сколько готовы платить за решение проблемы?