Коллеги, проконсультируйте в следующей проблеме:
Входные данные
Платформа 1С:Предприятие 8.3 (8.3.11.2954)
ОС Windows Server 2016
СУБД MS SQL 2016
Сервер 1С и СУБД на ходяться на одной машине
Наблюдается рост tempdb, как лучше проанализировать причину роста tempdb(к примеру какие события выбрать в Profiler) ?
Или из за чего может наблюдаться рост tempdb?
Сейчас установил ограничение по размеру tempdb , во избежание проблем.
Важная деталь размер tempdb не меняется, когда пользователи в базах не работают.
Входные данные
Платформа 1С:Предприятие 8.3 (8.3.11.2954)
ОС Windows Server 2016
СУБД MS SQL 2016
Сервер 1С и СУБД на ходяться на одной машине
Наблюдается рост tempdb, как лучше проанализировать причину роста tempdb(к примеру какие события выбрать в Profiler) ?
Или из за чего может наблюдаться рост tempdb?
Сейчас установил ограничение по размеру tempdb , во избежание проблем.
Важная деталь размер tempdb не меняется, когда пользователи в базах не работают.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) как-то написал сложный запрос и место на диске закончилось, файлик вырос до 90 гигов)) Пришлось шринкать!
Посмотрите что за доработки были и оптимизируйте запросы.
Еще как вариант обновление БД было. Но файлик вырос потом должен сдуваться, если сервер на рестарт агентов поставили.
Посмотрите что за доработки были и оптимизируйте запросы.
Еще как вариант обновление БД было. Но файлик вырос потом должен сдуваться, если сервер на рестарт агентов поставили.
(3)Скорее всего это не запросы. Перевел все базы в автономный режим (т.е. базы 1С вообще никаких операций не выполняют), перезапустил SQL , размер tempdb не поменялся, хотя по идее он по идее должен вернуться к минимальному значению. Или в любом случае нужно выполнять DBCC SHRINKDATABASE ?
(14)Всё верно.
Саму проблему предлагаю разделить на 2 части:
1. Как заставить ms sql уменьшать размер tempdb
2. Выяснить причину роста tempdb
По п.1 - создайте регл. задание, которое будет делать шринк tempdb с указанием начального размера и запускайте его раз в 15 минут + указать предельный объём temdb (это у вас уже сделано)
по п. 2 - основная причина это временные таблицы и сортировки, это нормальное поведение ms sql при работе с 1С, так как 1С очень любит временные таблицы как у казали коллеги в комментариях. На kb.1c.ru есть статья "Методика выявления транзакций, приводящих к значительному потреблению tempdb" почитайте, примените на практики советы разработчиков 1С и скорее всего выясните причину. Но не факт что удастся от неё избавиться)
Саму проблему предлагаю разделить на 2 части:
1. Как заставить ms sql уменьшать размер tempdb
2. Выяснить причину роста tempdb
По п.1 - создайте регл. задание, которое будет делать шринк tempdb с указанием начального размера и запускайте его раз в 15 минут + указать предельный объём temdb (это у вас уже сделано)
по п. 2 - основная причина это временные таблицы и сортировки, это нормальное поведение ms sql при работе с 1С, так как 1С очень любит временные таблицы как у казали коллеги в комментариях. На kb.1c.ru есть статья "Методика выявления транзакций, приводящих к значительному потреблению tempdb" почитайте, примените на практики советы разработчиков 1С и скорее всего выясните причину. Но не факт что удастся от неё избавиться)
(1)Происходят частые падения сессий sql в которых делаются временные таблицы, таблицы остаются не удаленными. После перезагрузки сервера база не сжимается, сервер видит что она не пустая и пропускает пересоздание. Нужно про анализировать саму базу и по ней вычислить виновника раздувания.
При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы.
Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п.
Вы ни от каких проблем не избавились. Получите ошибку в 1с - не возможно увеличить tempdb, во время работы.
Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п.
Сейчас установил ограничение по размеру tempdb , во избежание проблем.
Вы ни от каких проблем не избавились. Получите ошибку в 1с - не возможно увеличить tempdb, во время работы.
Причиной увеличения размера базы данных TEMPDB, как правило, является невозможность автоматической очистки журнала транзакций и повторного использования свободного пространства в базе данных TEMPDB из-за наличия активных транзакций, использующих объекты этой базы данных. Основные причины, вызывающие длительную блокировку работы этих механизмов базы данных TEMPDB, заключаются в следующем:
"Большие" транзакции, использующие TEMPDB, выполнение которых занимает большой промежуток времени.
Сетевые ошибки, из-за которых Microsoft SQL Server не получает уведомление о потере сетевого подключения. Если клиентская рабочая станция зависает, перезагружается, или будет выключена во время исполнения определяемой пользователем транзакции, то Microsoft SQL Server будет считать, что клиент продолжает работу, и выполняющаяся клиентская транзакция будет по-прежнему активна. Время обнаружения подобной ситуации зависит от настроек параметров сетевого протокола, используемого Windows . Например, при использовании протокола TCP/IP это время составляет 2 часа.
Если для завершения активных транзакций не хватает места в базе данных, Microsoft SQL Server автоматически увеличивает размер TEMPDB на величину, заданную в параметрах этой базы данных (по умолчанию - 10% от текущего размера).
"Большие" транзакции, использующие TEMPDB, выполнение которых занимает большой промежуток времени.
Сетевые ошибки, из-за которых Microsoft SQL Server не получает уведомление о потере сетевого подключения. Если клиентская рабочая станция зависает, перезагружается, или будет выключена во время исполнения определяемой пользователем транзакции, то Microsoft SQL Server будет считать, что клиент продолжает работу, и выполняющаяся клиентская транзакция будет по-прежнему активна. Время обнаружения подобной ситуации зависит от настроек параметров сетевого протокола, используемого Windows . Например, при использовании протокола TCP/IP это время составляет 2 часа.
Если для завершения активных транзакций не хватает места в базе данных, Microsoft SQL Server автоматически увеличивает размер TEMPDB на величину, заданную в параметрах этой базы данных (по умолчанию - 10% от текущего размера).
Со стороны 1с можно настроить технологический журнал (в яндексе инструкция)
Ниже, данный конфигурационный файл добавляет все операции, длительность которых превышает 10 секунд. Это может оказаться полезным для обнаружения действий пользователей, которые выполнялись длительное время, с целью, например, их последующей оптимизации. Длительность событий выражается в сотнях микросекунд.
(в файле первый символ не должен быть пробелом)
Ниже, данный конфигурационный файл добавляет все операции, длительность которых превышает 10 секунд. Это может оказаться полезным для обнаружения действий пользователей, которые выполнялись длительное время, с целью, например, их последующей оптимизации. Длительность событий выражается в сотнях микросекунд.
(в файле первый символ не должен быть пробелом)
| Код |
|---|
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="false"/>
<log location="C:\v8\logs" history="168">
<event>
<eq property="name" value="admin"/>
<gt property="duration" value="100000"/>
</event>
<event>
<eq property="name" value="conn"/>
<gt property="duration" value="100000"/>
</event>
<event>
<eq property="name" value="excp"/>
<gt property="duration" value="100000"/>
</event>
<event>
<eq property="name" value="proc"/>
<gt property="duration" value="100000"/>
</event>
<event>
<eq property="name" value="qerr"/>
<gt property="duration" value="100000"/>
</event>
<event>
<eq property="name" value="scom"/>
<gt property="duration" value="100000"/>
</event>
<property name="all"/>
</log>
</config>
Показать полностью |
(0) есть смысл в регулярные технологические окна после остановки сервера 1С делать очистку сеансовых данных и рестартовать службу скуля,
а если кроме баз данных 1С есть внешние обращения, то ограничить таймаут на скуле
EXEC sys.sp_configure N'remote query timeout (s)', N'60'
GO
RECONFIGURE WITH OVERRIDE
GO
а если кроме баз данных 1С есть внешние обращения, то ограничить таймаут на скуле
EXEC sys.sp_configure N'remote query timeout (s)', N'60'
GO
RECONFIGURE WITH OVERRIDE
GO
(17) мы умышленно сбрасываем статистику каждые 12 часов в ноль, чтобы:
1. различать ночные и дневные нагрузки
2. не накапливать искажения от каких то разовых пиков
3. иметь возможность расследовать актуальные проблемы
мы например при этом храним историю статистик "по типам ожиданий" в отдельной таблице, так видны факты изменений и улучшений или наоборот ухудшений
кроме того, недействующие индексы по информации системных представлений - вещь неоднозначная - если этот индекс создан платформой, а не вручную то стоит 10 раз подумать прежде чем его отключать или т.п., а если индекс создан вручную, то и так за ним надо следить в первые дни вручную, отслеживая его "востребованность" и эффект от его создания
1. различать ночные и дневные нагрузки
2. не накапливать искажения от каких то разовых пиков
3. иметь возможность расследовать актуальные проблемы
мы например при этом храним историю статистик "по типам ожиданий" в отдельной таблице, так видны факты изменений и улучшений или наоборот ухудшений
кроме того, недействующие индексы по информации системных представлений - вещь неоднозначная - если этот индекс создан платформой, а не вручную то стоит 10 раз подумать прежде чем его отключать или т.п., а если индекс создан вручную, то и так за ним надо следить в первые дни вручную, отслеживая его "востребованность" и эффект от его создания
(18)
(18)
стоит 10 раз подумать прежде чем его отключать или т.п.
Да? Вы меня пугаете ((.
(18)
индекс создан вручную, то и так за ним надо следить в первые дни вручную
Есть индексы, которые работают только во время расчета зарплаты, например, у регистра "Графики работы по видам времени". Соответственно, стараюсь дождаться хотя бы месяц, чтобы оценить их эффективность.
(21) ну если вы знаете что индекс спроектирован под разовую операцию происходящую 1 раз в длительный цикл, ну так вы можете регламентом отключать после использования в день Х и включать перед следующим таким днем - так вы снизите избыточную запись
и что вам мешает посмотреть период с расчетом зарплаты...
и что вам мешает посмотреть период с расчетом зарплаты...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот