|
Очистка памяти 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) сколько готовы платить за решение проблемы?
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |