Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 8 общая

Очистка памяти SQL Server

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

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

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

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

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

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

Удаляет все неиспользуемые элементы из всех кэшей. Компонент Компонент SQL Server Database Engine заранее автоматически очищает неиспользуемые элементы кэша в фоновом режиме, освобождая память для текущих записей. Однако можно использовать эту команду, чтобы вручную удалить неиспользуемые записи из всех кэшей или из указанного кэша пула регулятора ресурсов.
   Tankur
 
18 - 21.06.18 - 19:41
(17) Кэш создан чтобы помогать, а не чтобы его руками чистить.
   mistеr
 
19 - 21.06.18 - 20:24
(15) Скорее всего все проще. Во время тяжелого расчета вытесняются справочники и индексы из кэша, отсюда и "замедление".
   mistеr
 
20 - 21.06.18 - 20:24
(17) В бубен тоже стучите каждый час?
   mistеr
 
21 - 21.06.18 - 20:25
(11) Причем здесь РИБ вообще?
   Tankur
 
22 - 21.06.18 - 20:38
(21) ты сказал в 7 что 20 баз
   Tankur
 
23 - 21.06.18 - 20:38
планов обмена
   Tankur
 
24 - 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/
   mistеr
 
26 - 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/
   mistеr
 
29 - 21.06.18 - 21:20
(25) Я бы не стал пользоваться скриптом, который прячет некоторые ожидания и искажает картину.
   болид
 
31 - 21.06.18 - 21:21
(29) Скрипт Пола искажает и прячет? Можно пруф? А то DBA всего мира им пользуются и не знают
   mistеr
 
32 - 21.06.18 - 21:24
(31) В скрипт-то загляни.
   болид
 
33 - 21.06.18 - 21:27
(32) заглянул, что там не так?
 
 
   mistеr
 
37 - 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.
   mistеr
 
41 - 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% откуда этот высер?
   cons74
 
46 - 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% ЦП...
по ходу ему её не хватает, бггг
привет погромистам местным передавай
   ptiz
 
51 - 22.06.18 - 08:59
(50) "95% ЦП..." - вот уж действительно, слона-то я и не приметил :)
(0) Степень параллелизма у вас какая? Поставьте 1.
   mistеr
 
52 - 22.06.18 - 09:16
(50) (51) И что тут страшного? Если все данные в кэше, запросы идут на ЦП.

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует