Захвачено субд 1с что это

Захвачено субд 1с что это

Частые вопросы по производительности «1С:Документооборота»

Приведем ответы на частые вопросы, связанные с производительностью «1С:Документооборота».

Вопрос 1

Есть ли в «1С:Документообороте» оценка производительности?

В «1С:Документообороте» версии КОРП и ДГУ есть встроенная оценка производительности. Рекомендуется включить ее перед началом работы пользователей в программе: Настройка и администрирование — Настройка программы — Общие настройки — Выполнять замеры производительности.

После этого программа автоматически будет замерять время выполнения ключевых операций: создание документа, запуск процесса, открытие и создание файла, выполнение задачи и другие. Эталонное время ключевых операций приведено здесь. На основе полученных данных удобно вовремя обнаружить снижение производительности программы и провести первичный анализ.

Чтобы увидеть средние показатели за определенный период, выполните команду Время выполнения ключевых операций в меню раздела Настройка и администрирование.

Анализ и контроль производительности можно также вести по методике APDEX — команда Оценка производительности в меню раздела Настройка и администрирование.

Вопрос 2

С чего начать проверку при замедлении работы программы?

При замедлении работы программы рекомендуется проверить формат журнала регистрации. Также эту проверку рекомендуется проводить после обновления платформы «1С:Предприятия» на версию 8.3.7 или после создания информационной базы с нуля.

Вопрос 3

Что делать, если у рядовых пользователей ключевые операции выполняются более 15 секунд? По прошествии этого времени операции выполняются без ошибок. При входе в программу под Администратором задержек нет. Все рекомендованные настройки СУБД и сервера «1С:Предприятие» выполнены.

Во-первых, проверьте версию конфигурации. Если установлена версия 1.4.xx, необходимо перейти на версию 2.0, куда включено много доработок по быстродействию.

Если проблема воспроизводится не в 100% случаев:

Вопрос 4

Что делать, если зафиксированы периодические замедления работы, например, раз в минуту?

Проверьте версию конфигурации. Если это версия 2.0.9 — 2.0.13 включительно, то обновитесь на более свежую или отключите автоматическую проверку контрагентов по ЕГРН (Настройка и администрирование — Настройки программы — Контрагенты — Автоматически проверять контрагентов по ЕГРН).

Вопрос 5

Что делать, если операция длится более 20 секунд, после чего выдает ошибку «Превышено максимальное время ожидания предоставления блокировки»? Как правило, ошибка проявляется у всех пользователей.

Анализ проблем производительности по динамике мониторинга RAS 1C

Мы опишем результаты наблюдений и выводы по состоянию производительности системы через мониторинг RAS 1C основанный на наших наблюдениях и мнении/советах коллег по цеху. Наиболее показательны изменения для больших баз по количеству работающих пользователей на одном кластере. Иначе требуется проводить агрегирование показателей таких как очередь какого-нибудь свойства, если на сервере много кластеров или на реальном много виртуальных машин для общей оценки сервера.

Также на поведение параметров контролируемой целевой базы 1С будет оказывать влияние версия платформы, окружение, конфигурация и это также нужно будет учесть при сравнении. Однако, динамика и характер поведения должны быть похожи. Мы выполняли анализ на версиях 8.3.14, 8.3.15, 8.3.16 и конфигурации ERP 2.4.

I) Свойства процессов

Номер строки (по порядку)

Содержит объем виртуальной памяти,
занимаемой рабочим процессом,
в килобай тах.

Средняя за последние 5 минут доступная
производительность. Определяется по времени
реакции рабочего процесса на эталонный
запрос. В соответствии с доступной
производительностью кластер серверов
принимает решение о распределении
клиентов между рабочими процессами.

Количество соединений рабочего
процесса с пользовательскими
приложениями.

Показывает среднее время обслуживания
рабочим процессом одного клиентского
обращения. Оно складывается из:
значений свойств AvgServerCallTime,
AvgDBCallTime, AvgLockCallTime,
AvgBackCallTime.

Параметр состояния процессов avg-call-time

Параметр avg-call-time – позволяет увидеть проблемы загрузки хоста, если один из них находится под нагрузкой

Вот так выглядит график средней нагрузки

В этот момент было запущено тяжелое задание по пересчету регистра. Всем тем, кто-попадал на этот процесс было «плохо».

Если же все процессы показывают рост нагрузки, то скорее всего проблема возникла у менеджера, и он перестал корректно разруливать ситуацию.

Можно поставить оповещение о изменении данной ситуации, нормальное среднее значение должно быть значительно менее 1. При значениях от 1 до 2-3 возможны проблемы. При значениях более 7-10 можно считать, что мы потеряли пациента.

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

Вот так выглядит показатель среднее avg-call-time при проблемах на сервере.

Вот так выглядит нагрузка на процессор в этот момент:

Количество процессов

Изменение количества процессов, также график позволяющий определить проблемы. Резкий рост или превышение некоторого установившегося количества, также является критерием того что у нас происходят какие-то проблемы.

Вот так меняется количество процессов при аварии:

Показатель расхода памяти

Показатели расхода памяти особенно проявляются с увеличением количества процессов. Рост памяти выше доступных в системе приведет к остановке служб. На графике ниже можно проследить рост потребления после запуска нового процесса.

Показатель производительность

Вот так выглядит падение производительности по показателю доступная производительность:

II) Свойства соединений

Содержит номер соединения.

Номер строки (по порядку)

Показатель соединений session-number

Если следить за связью между процессами и сеансами пользователей, то можно легко определить нормальные и не нормальные показатели для состояния системы. Об использовании нейронных сетей для определения критичных аномалий, о которых рассказывал на конференции я буду рассказывать позже (сейчас есть решаемые технические проблемы, которые не позволяют их использовать массово без сторонних приложений и с функционалом из коробки – банально не хватает времени).

Как только количество соединений между процессами и сеансами в единицу времени превышает некоторый порог, то стоит трубить о проблемах. На рисунке ниже показана ситуация аварии, в момент пика службы 1С перестали обслуживать и произошел самостоятельный перезапуск всех процессов с дальнейшим падением менеджера кластера. Он настолько ушел в себя, что не отпустил кэш и пришлось его удалять вручную.

Для хорошо нагруженной системы обычно такой показатель колеблется в районе 30-40 соединений в единицу.

Вот так показатель количество строк при падении производительности с полным зависанием служб.

Рекомендуемые агрегируемые функции:

III) Свойства сеансов

Номер строки (по порядку)

время вызова (текущее)

Содержит интервал времени в
миллисекундах, прошедший с
момента начала обращения,
в случае, если сеанс выполняет
обращение к серверу 1С:Предприятия.
Иначе – 0.

время вызова (текущее)

время вызова (текущее)

Е сли в момент получение списка соединений информационной базы методом
GetInfoBaseConnections данное соединение
выполняло обращение к серверу баз данных,
то свойство содержит время в секундах,
в течение которого выполняется данное
обращение к серверу баз данных.
В противном случае – 0.

процессорное время (текущее)

Процессорное время текущее

процессорное время (текущее)

Как уже ранее рассказывал, то стоит следить сразу несколькими параметрами

Свойство duration-current

Показатель duration-current (время вызова (текущее)) показывает обслуживание пользователя процессом. Если же количество пользователей со значением этого параметра (отличным от 0 в каждый момент времени) растет, то сервисы 1с не успевают обслуживать, кто-то запустил что-то тяжелое и в итоге может привести к серьезному снижению производительности. Обычно значения, превышающие 60 штук (зависит от конкретной обслуживаемой системы) повод задуматься о том, что начинаются проблемы.

Предполагаем в данном случае отследить пользователя по табличной части «Данные» смотри ниже. Далее связаться с ним и обсудить решение проблемы. Возможно приложение зависло и его достаточно удалить, и система придет в норму, или попросить пользователя не запускать тяжелых задач. А возможно проблема производительности какой-либо формы или обработки и требуется ее оптимизация и рефакторинг.

Рекомендуем использовать следующие агрегирующие функции:

Свойство db-proc-took

Показатель db-proc-took (захвачено СУБД) характеризует обращение процесса к СУБД. Если количество таких обращений растет в единицу времени, то это говорит о том, что СУБД не успевает обслуживать запросы 1С. Такое поведение может возникать во время блокировок – когда один пользователь захватил популярный регистр, а все другие начинают его ждать. Недостаточной производительности самого сервера СУБД. Наличия большого количества неоптимальных запросов. Наличия операций, которые не рекомендуется запускать в момент высокой нагрузки пользователей – удаление помеченных, пересчет регистров и т.п.

Разбор проблем можно выполнять в соответствии с рекомендациями выше. А также возможно проверить настройку и работу сервисных заданий на сервере СУБД – обновление статистики, или другие настройки.

Рекомендуем использовать следующие агрегирующие функции:

Показатель cpu-time-current

Данный показатель обычно необходимо смотреть с duration-current. Если он значительно большой, то это говорит о том, что пользователь действительно запустил что-то существенно сжигающее мощность сервера и стоит связаться с пользователем, ограничить или удалить соединение.

Совместный анализ и учет свойств duration-current и db-proc-took

Если захват и время текущее больше нормы, то видно, что пользователь нагрузил сервер. А чем нагрузил можно узнать из журнала действий пользователя по номеру сеанса или ТЖ (удалив сеанс пользователя мы сгенерируем ошибку).

На графике ниже видно, что выполняются ресурсоемкие операции (фоновые задания) с постобработкой данных на сервере 1С (захвачено СУБД менее времени вызова (текущее)). Показатели время вызова и потребления процессора высокие. Но пока не превышена критическая отметка и уровень тревоги «желтый»

Если же у вас среднее состояние каждый день показывает высокую нагрузку, то скорее всего следует обновить ваши ресурсные мощности.

Количество пользователей

Количество пользователей обычно гладкий и равномерный график без резких скачков. Следить необходимо за резким изменением его поведения или резкими изменениями изменения количества спящих пользователей. На рисунке ниже видна аномалия после аварии служб 1С, в результате были выбиты практически все пользователи.

IV) Настройка обработки ситуации по комбинации показателей

Таблица настройки для реакции по комбинациям показателей выглядит следующим образом:

Анализ и устранение взаимоблокировок

Для понимания взаимоблокировок необходимо знать, что такое блокировка и ожидание на блокировке. Подробная информация по этой теме содержится в статье базы знаний «Блокировки данных в 1С:Предприятии 8». Рекомендуется предварительно ознакомиться с этим материалом для лучшего понимания текста настоящей статьи.

В случае взаимоблокировки двух сессий конфликт заключается в том, что сессия 1 ожидает снятия блокировки, установленной сессией 2, в то время как сессия 2, в свою очередь, ожидает снятия блокировки, установленной сессией 1. Ни одна из сессий не может ни продолжить свою работу (из-за ожидания), ни снять свою блокировку для того, чтобы дать конкурирующей сессии продолжить работу.

Такой конфликт не может быть разрешен без участия внешних (по отношению к обеим сессиям) механизмов. Подобные механизмы реализованы во всех СУБД, используемых «1С:Предприятием», а также в самом сервере «1С:Предприятия» (для обнаружения неразрешимых конфликтов управляемых блокировок). Будем называть эти механизмы «менеджерами взаимоблокировок».

Менеджер взаимоблокировок работает следующим образом:

Следует учитывать, что во взаимоблокировках могут участвовать несколько (более двух) сессий «1С:Предприятия». Причем одна и та же причина может приводить к возникновению разных (по конфигурации и по сложности) взаимоблокировок с различным количеством участников и блокировок между ними. Поэтому при анализе большого количества взаимоблокировок в системе всегда имеет смысл начинать с самых простых взаимоблокировок – с минимальным количеством участников и с самыми простыми схемами. Высока вероятность того, что, устранив одну простую взаимоблокировку вы одновременно устраните несколько других – в том числе более сложные.

Другой важной особенностью взаимоблокировок является тот факт, что взаимоблокировка почти всегда «распределена» по нескольким различным строкам кода конфигурации. При этом на начальном этапе анализа пользователю известна только одна строка кода. Это может быть, например, последняя строка, выполненная «жертвой» перед тем, как ее транзакция была отменена менеджером взаимоблокировок (эта строка доступна в информации об ошибке) или строка кода конфигурации, которую выдал ЦУП в дереве аналитической информации.

При этом причина взаимоблокировки (ошибка, приводящая к ее возникновению) может находиться совсем в другом месте исходного кода. Это создает определенные трудности при анализе и устранении взаимоблокировок.

Известны следующие типичные причины возникновения взаимоблокировок в системах на платформе «1С:Предприятие 8»:

В настоящей статье будут рассмотрены особенности возникновения этих видов взаимоблокировок, объяснены причины, по которым они возникают, и даны рекомендации по анализу и устранению этих причин.

Следует заметить, что взаимоблокировки не всегда поддаются анализу в том случае, если нам известна только одна строка кода – та, в которой было получено сообщение об ошибке взаимоблокировки. Как правило, для анализа взаимоблокировки необходимо использовать подробную информацию, предоставляемую «Центром управления производительностью». Однако для понимания информации ЦУП необходимо знать основные схемы взаимоблокировок и причины, по которым они возникают. Поэтому рекомендуется сначала освоить материал следующих четырех разделов, а затем, если понадобится, переходить к анализу информации, предоставляемой ЦУП.

Текущая версия ЦУП показывает схемы взаимоблокировок только в том случае, если исследуемая информационная база работает с использованием MS SQL Server 2005.

Повышение уровня блокировки ресурса в рамках одной транзакции

Общие сведения

Повышение уровня блокировки в рамках одной транзакции является наиболее распространенной причиной возникновения взаимоблокировок.

Схема возникновения взаимоблокировки такова. Две конкурирующие транзакции (Т1 и Т2) читают один и тот же ресурс – Р1. При этом устанавливаются разделяемые блокировки на этот ресурс. Разделяемые блокировки от конкурирующих транзакций могут существовать одновременно, поэтому к моменту времени t1 обе транзакции успешно установили свои блокировки и продолжают работу.

Затем транзакция Т1 изменяет ресурс Р1 и пытается его записать. При этом устанавливается эксклюзивная блокировка на этот ресурс. Однако эта блокировка не может быть установлена одновременно с разделяемой блокировкой от транзакции Т2, поэтому она устанавливается в состояние ожидания. Транзакция Т1 прекращает работу и ждет, пока будет снята разделяемая блокировка, установленная транзакцией Т2.

Транзакция Т2, в свою очередь, хочет записать ресурс Р1, для чего также предпринимает попытку заблокировать его в эксклюзивном режиме. Однако это невозможно, так как существует уже установленная транзакцией Т1 разделяемая блокировка на этот ресурс. Транзакция Т2 также прекращает работу и ждет, пока будет снята разделяемая блокировка, установленная транзакцией Т1.

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

Причина возникновения взаимоблокировки данного вида – повышение уровня изоляции заблокированного ресурса в рамках одной транзакции. Транзакции сначала блокировали ресурс при помощи разделяемой блокировки, а затем повышали уровень блокировки до эксклюзивного.

Применительно к данному случаю перед чтением ресурса необходимо было заблокировать его в эксклюзивном режиме. Тогда картина изменилась бы следующим образом:

В данном случае обе транзакции, перед тем как читать ресурс Р1, устанавливают на него эксклюзивную блокировку. Одна из транзакций (Т1) успевает сделать это первой. К моменту времени t1 ресурс Р1 оказывается заблокированным в эксклюзивном режиме и транзакция Т2, которая не может установить свою блокировку, становится в ожидание на блокировке.

Особенности взаимоблокировок данного вида

Взаимоблокировки данного вида достаточно просты для анализа. При разработке (или доработке) системы следует всегда использовать сформулированное выше правило: блокировка в транзакции должна изначально осуществляться с максимально необходимым уровнем изоляции. Это позволит полностью исключить возникновение таких взаимоблокировок в системе.

Типичной ошибкой в коде конфигурации, которая может приводить к возникновению взаимоблокировок данного вида, является неблокирующее чтение и последующая запись в рамках одной транзакции:

Для возникновения взаимоблокировки данного вида необходимо одновременное выполнение следующих условий:

Автоматический режим. Чтение без опции «ДЛЯ ИЗМЕНЕНИЯ» и последующая запись в рамках одной транзакции

Рассмотрим следующий пример.

Обратите внимание на то, что проведение документа выполняется в неявной транзакции, которая автоматически открывается «1С:Предприятием». Таким образом, весь текст обработчика проведения будет выполнен в рамках одной транзакции.

При выполнении запроса, описанного в данной функции, происходит чтение остатков регистра накопления «ТоварыНаСкладах». При этом автоматически устанавливается разделяемая блокировка остатков списываемых товаров. Эта блокировка не позволит конкурирующей транзакции изменить остатки по данным товарам, но позволит ей считать остатки. То есть чтение является неблокирующим.

В этой функции выполняется запись регистра накопления «ТоварыНаСкладах». В том случае, если остатки по товару реально изменились, при записи будет автоматически установлена эксклюзивная блокировка на остатки по данному товару. То есть произойдет повышение уровня изоляции ресурса в рамках одной транзакции.

Если несколько пользователей системы будут одновременно списывать одинаковые товары с одних и тех же складов, это может привести к возникновению взаимоблокировки.

Для того чтобы избежать возникновения взаимоблокировки, необходимо сделать чтение остатков блокирующим. Для этого используется опция «ДЛЯ ИЗМЕНЕНИЯ».

Необходимо изменить функцию «ПроверитьОстатки» следующим образом:

Автоматический режим. Чтение в объектной технике и последующая запись

Предположим, что в коде конфигурации определена следующая процедура

В транзакции считывается элемент справочника «Контрагенты». Чтение реализовано в объектной технике. При выполнении этой строки кода «1С:Предприятие» выполнит запрос к базе данных, который автоматически установит разделяемую блокировку для данного контрагента.

Затем в этой же транзакции реквизиты контрагента изменяются, и объект записывается в информационную базу. Перед записью будет автоматически установлена эксклюзивная блокировка для данного контрагента, то есть произойдет повышение уровня изоляции ресурса. В том случае если эта операция будет выполняться несколькими пользователями одновременно, возможно возникновение взаимоблокировок.

В этом случае процедура будет выглядеть следующим образом:

Управляемый режим. Чтение без установки блокировки (либо с установкой разделяемой блокировки) и последующая запись

Если в примере 1 перевести конфигурацию в управляемый режим блокировки данных в транзакции, то опция «ДЛЯ ИЗМЕНЕНИЯ» будет игнорирована «1С:Предприятием», и необходимой эксклюзивной блокировки перед чтением остатков не произойдет. Кроме того, разделяемая блокировка, которая автоматически установится на уровне СУБД, будет снята после завершения выполнения запроса (то есть до конца транзакции). Такая ситуация может привести к нарушению бизнес-логики системы.

Обратите внимание на то, что взаимоблокировки в данном случае не произошло. Вместо этого была нарушена бизнес-логика системы (списаны товары, отсутствующие на складе), что по серьезности последствий намного хуже, чем взаимоблокировка.

Источником этой проблемы является низкий уровень изоляции транзакции на уровне СУБД. Разделяемые блокировки, которые были автоматически установлены в момент чтения остатков, снялись непосредственно после выполнения запроса и остались незащищенными (то есть незаблокированными) до конца транзакции. Отсюда следует необходимость установить такую блокировку, которая бы защищала итоги до окончания транзакции. Для решения таких задач предназначены явные управляемые блокировки, устанавливаемые из кода конфигурации.

Подробная информация о том, как работать с управляемыми блокировками, содержится в данной статье базы знаний.

Для данного примера измененный текст функции должен быть следующим:

Обратите внимание на то, что для блокировки выбран режим «Исключительный». Это сделано в соответствии со сформулированным выше правилом: необходимо изначально устанавливать блокировку с наивысшим требуемым уровнем изоляции ресурсов.

Если в данном случае установить режим блокировки «Разделяемый», то при одновременной работе нескольких пользователей возможно возникновение взаимоблокировки на уровне «1С:Предприятия».

Захват ресурсов в разном порядке

Общие сведения

Захват ресурсов в разном порядке является второй наиболее распространенной причиной возникновения взаимоблокировок.

В отличие от взаимоблокировки, возникающей при повышении уровня изоляции ресурса в рамках одной транзакции, данная блокировка возникает не на одном ресурсе, а минимум на двух (или более).

Схема возникновения взаимоблокировки для двух ресурсов такова. В начале две конкурирующие транзакции (Т1 и Т2) захватывают два разных ресурса – Р1 и Р2. Устанавливаемые при этом блокировки не мешают друг другу (так как заблокированы разные ресурсы), поэтому к моменту времени t1 обе транзакции успешно блокируют ресурсы и продолжают работу.

Затем транзакция Т1 пытается заблокировать ресурс Р2. Однако это невозможно, поскольку он уже заблокирован транзакцией Т1. В свою очередь, транзакция Т2 пытается заблокировать ресурс Р2, но это также невозможно, поскольку он уже захвачен транзакцией Т1.

Возникает взаимоблокировка: обе транзакции находятся в режиме ожидания и не могут ни продолжить работу, ни освободить заблокированные ими ресурсы.

В данном примере все блокировки установлены в эксклюзивном режиме, однако это не является необходимым условием. Если бы первая пара блокировок была разделяемой, а вторая – эксклюзивной (или наоборот), то взаимоблокировка также возникла бы. Из-за этого взаимоблокировку из-за разного порядка захвата ресурсов иногда можно спутать со взаимоблокировкой из-за повышения уровня изоляции ресурса.

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

При блокировании ресурсов в одинаковом порядке картина изменится следующим образом:

В этом случае транзакция Т1 успевает первой заблокировать ресурс Р1. Транзакция Т2 пытается установить аналогичную блокировку, но не может этого сделать и становится в ожидание на блокировке.

Транзакция Т1 продолжает работу, выполняет все необходимые действия (при этом, в частности, захватывает ресурс Р2) и завершается. После завершения транзакции все установленные ей блокировки автоматически снимаются и транзакция Т2 продолжает работу. Ей также никто не мешает, и она успешно выполняет все необходимые действия, включая установку блокировок на ресурсы.

Особенности взаимоблокировок данного вида

Взаимоблокировки первого вида (возникающие по причине повышения уровня изоляции ресурса в транзакции) обычно проявляются при одновременной работе однотипных транзакций. Взаимоблокировки второго вида (возникающие из-за разного порядка захвата ресурсов в транзакции), как правило, проявляются при выполнении пользователями разных действий. Например, первый пользователь может вводить документ «РеализацияТоваров», а второй – «ПоступлениеТоваров».

Эта особенность делает взаимоблокировки данного вида неудобными для анализа на уровне кода. Если нам известна только строка кода, на которой жертва взаимоблокировки получила сообщение об ошибке, то мы не имеем следующей необходимой информации:

Как правило, для анализа взаимоблокировок данного вида необходимо использовать информацию, предоставляемую «Центром управления производительностью».

Изначально разрабатывать приложение таким образом, чтобы в нем всегда использовался одинаковый порядок захвата ресурсов, – достаточно сложная организационная и техническая задача. Как правило, такие взаимоблокировки приходится анализировать и устранять по факту их возникновения во время многопользовательского нагрузочного тестирования либо при работе реальных пользователей системы.

Типичные причины возникновения взаимоблокировок данного вида таковы:

Захват ресурсов без учета порядка

При разработке кода конфигурации необходимо обеспечить правильную работу приложения в рамках одной транзакции. Это понятная и разрешимая задача. Однако взаимоблокировка данного вида возникает при конкурентной работе разных транзакций. Для того чтобы исключить потенциальную возможность таких взаимоблокировок, необходимо было бы анализировать код всех имеющихся в системе транзакций на предмет одинакового порядка захвата ресурсов. Для сложных конфигураций такая задача может оказаться невыполнимой.

Однако можно сформулировать несколько несложных правил, выполнение которых позволит значительно снизить риск возникновения взаимоблокировок данного вида:

Предположим, что в конфигурации определены два вида документов: «РеализацияТоваров» и «ПоступлениеТоваров». Документы записывают движения в два регистра накопления: «ТоварыНаСкладах» и «ТоварыОрганизаций». При этом движения заполняются и записываются в явном виде в обработчиках проведения документов.

При написании этого кода разработчики не учли порядок захвата ресурсов, в результате чего движения записываются в разном порядке. Например, в документе «РеализацияТоваровУслуг»:

Для того чтобы избежать этих взаимоблокировок, можно отказаться от записи движений в явном виде. В этом случае движения будут записываться платформой, которая будет делать это гарантированно в одинаковом порядке.

Другое решение – обеспечить одинаковый порядок записи движений организационными мерами. Например, подготовить проектный документ, который описывает рекомендуемый порядок захвата ресурсов и обеспечить выполнение этих рекомендаций всеми программистами системы.

Обратите внимание на то, что ресурсы захватываются (блокируются) не только при записи движений. Полный перечень операций, при которых происходит захват ресурсов:

Захват ресурсов в разном порядке в соответствии с требованиями алгоритмов обработки данных

Алгоритмы обработки информации могут требовать строго определенного порядка захвата ресурсов, и для разных алгоритмов этот порядок может быть различным. В этом случае задача может оказаться неразрешимой либо потребовать серьезного пересмотра структур данных и алгоритмов.

Возможна ситуация, при которой такой порядок записи движений, как в предыдущем примере, применен осознанно в связи с тем, что таков алгоритм обработки информации. Например, документ «РеализацияТоваров» должен сначала записать регистр «ТоварыНаСкладах», затем при помощи запросов к этому и другим регистрам произвести некоторые вычисления и только потом – на основании результатов этих вычислений – сформировать и записать движения регистра «ТоварыОрганизаций». В свою очередь, документ «ПоступлениеТоваров» может, наоборот, вычислять данные для регистра «ТоварыНаСкладах» на основании данных регистра «ТоварыОрганизаций».

Например, при работе в автоматическом режиме мы можем выполнить запрос с опцией «ДЛЯ ИЗМЕНЕНИЯ» к виртуальной таблице остатков регистра «ТоварыОрганизаций» в обработчике проведения документа «РеализацияТоваров». В качестве условия в этот запрос следует передать набор значений измерений, который будет изменяться в этой транзакции (то есть выборку из табличной части документа). В этом случае последовательность установки блокировок будет такая же, как в документе «ПоступлениеТоваров»: сначала будет блокироваться регистр «ТоварыОрганизаций», а затем «ТоварыНаСкладах». Взаимоблокировка при этом будет исключена.

При работе в управляемом режиме вместо запроса с опцией «ДЛЯ ИЗМЕНЕНИЯ» следует прописать в коде обработчика проведения явную блокировку пространства «РегистрНакопления.ТоварыОрганизаций» по соответствующему набору значений измерений.

Непредсказуемый порядок захвата ресурсов в СУБД при выполнении сложных запросов

При выполнении сложных запросов, включающих соединение нескольких таблиц, не всегда можно точно предсказать, в каком порядке эти таблицы будут обрабатываться СУБД. Этот порядок будет зависеть от выбора плана запроса, а план, в свою очередь, от множества непредсказуемых факторов – распределения данных по индексам, размеров таблиц, нагрузки на систему и т. д.

Иначе говоря, возможны такие ситуации, когда СУБД будет устанавливать блокировки при выполнении одного и того же запроса к нескольким ресурсам в разном порядке. При этом также возможно возникновение взаимоблокировок. Для устранения таких взаимоблокировок необходимо также установить искусственные блокировки на ресурсы в предопределенном порядке.

Неоптимальная работа запроса

При неоптимальной работе запроса блокируются избыточные ресурсы, что может значительно увеличить вероятность возникновения взаимоблокировок. Если взаимоблокировка возникла при выполнении прикладного запроса, следует провести анализ и оптимизацию его текста в соответствии с рекомендациями, данными в статье «Типичные причины неоптимальной работы запросов и методы оптимизации».

Ошибка блокировок при работе внутренних механизмов MS SQL Server

Известны случаи возникновения взаимоблокировок при работе внутренних механизмов MS SQL Server. О возникновении таких взаимоблокировок говорят следующие сообщения об ошибках:

Обычно для возникновения взаимоблокировки необходимо участие четырех и более запросов (по два в двух конкурирующих транзакциях). Однако при выполнении некоторых запросов MS SQL Server может самостоятельно повышать уровень изоляции заблокированных ресурсов, что иногда также приводит к возникновению взаимоблокировки. В этом случае возможна взаимоблокировка, в которой участвуют всего два запроса от двух конкурирующих транзакций. Для возникновения такой взаимоблокировки необходимо одновременное выполнение следующих условий:

Соответственно, для устранения такой взаимоблокировки необходимо исключить любое из трех условий:

Анализ взаимоблокировок при помощи ЦУП

Как уже было отмечено выше, взаимоблокировки не всегда поддаются анализу на основании одной строки кода – той, в которой было получено сообщение об ошибке взаимоблокировки. Если исследуемая база работает с использованием MS SQL Server 2005, то есть возможность получить детальную информацию по взаимоблокировке с помощью Центра управления производительностью.

ЦУП пытается автоматически ранжировать взаимоблокировки по сложности, показывая на верхних позициях в списках более простые случаи. Однако оценить сложность взаимоблокировки возможно не всегда. Не стоит тратить много времени, пытаясь разобраться в сложной для понимания взаимоблокировке. Следует выбрать из списка более простой и понятный вам случай.

Для получения информации по взаимоблокировке необходимо выполнить следующую последовательность действий:

1. Настроить права доступа и подключиться к исследуемой информационной базе в режиме мониторинга (см. руководство по использованию ЦУП).

2. Добавить показатель «Анализ взаимоблокировок» в список показателей ЦУП.

3. Включить запись этого показателя.

Внимание!
При включении записи аналитических показателей может наблюдаться падение производительности в исследуемой информационной базе.

4. Воспроизвести взаимоблокировку в исследуемой информационной базе либо дождаться, пока взаимоблокировка возникнет во время работы пользователей. О возникновении взаимоблокировки можно судить по значениям показателя «Количество взаимоблокировок».

Внимание!
После включения записи аналитического показателя ЦУП начинает сбор информации примерно через 1 минуту. Необходимо выдержать паузу между включением записи показателя и воспроизведением взаимоблокировки.

5. Выключить запись показателя «Анализ взаимоблокировок». После выключения записи ЦУП начнет разбор и анализ собранной информации. Этот процесс может занять длительное время.

6. Остановить работу сценария «мониторинг» и подключиться к исследуемой базе в режиме просмотра. При необходимости выбрать интервал времени, на котором наблюдалась интересующая вас взаимоблокировка.

7. Нажать кнопку «Анализ».

8. В форме анализа проблем производительности выбрать закладку «Код конфигурации», раскрыть первую вершину дерева и двойным щелчком открыть форму анализа взаимоблокировок:

9. Будет открыта форма списка взаимоблокировок, в которых участвует выбранный источник проблем – строка кода конфигурации. Группы взаимоблокировок объединяют одинаковые (по схеме) взаимоблокировки, произошедшие в разное время. Поскольку в системе может наблюдаться множество различных взаимоблокировок, следует проанализировать каждую группу. Из группы следует выбирать наиболее простую взаимоблокировку.

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

10. Провести анализ схемы взаимоблокировки и причин ее возникновения.

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

Далее приведены примеры анализа взаимоблокировок двух основных видов:

Примеры получены на измененной конфигурации УПП при помощи теста «Продажи» и доступны для самостоятельного изучения в демонстрационной базе ЦУП.

Повышение уровня блокировки ресурса в рамках одной транзакции

Рассмотрим пример взаимоблокировки, возникшей в результате повышения уровня блокировки ресурса в рамках одной транзакции:

Во взаимоблокировке участвуют два процесса (транзакции):

Для каждого процесса показана хронология событий, которая привела к возникновению взаимоблокировки.

Вначале оба процесса выполняют запросы, в результате которых успешно устанавливаются две блокировки:

Затем оба процесса пытаются выполнить два других запроса, но при установке блокировок возникает взаимное ожидание, то есть взаимоблокировка:

В этой взаимоблокировке можно видеть следующие характерные признаки взаимоблокировок данного вида (возникающих по причине повышения уровня блокировки ресурса):

1. Во взаимоблокировке участвует один ресурс – регистр накопления «ТоварыВРезервеНаСкладах»:

2. Процессы являются однотипными, то есть выполняются одинаковые прикладные действия и, соответственно, работает один и тот же код конфигурации:

Откроем конфигурацию исследуемой базы и проанализируем запрос, который исполняется в строке 506 модуля набора записей регистра накопления «ТоварыКПередачеСоСкладов». При этом нас будет интересовать только обращение к заблокированному ресурсу – регистру «ТоварыВРезервеНаСкладах».

Ниже приведен сокращенный текст процедуры КонтрольСвободныхОстатков_Реализация(), из которой вызывается интересующий нас запрос.

При выполнении данного запроса идет чтение остатков регистра ТоварыВРезервеНаСкладах. При этом будет установлена разделяемая блокировка, так как опция «ДЛЯ ИЗМЕНЕНИЯ» применена только к регистру «ТоварыКПередачеСоСкладов».

Затем проанализируем код, который исполняется во второй интересующей нас строке: модуль набора записей регистра накопления «ТоварыВРезервеНаСкладах», строка 395. Нас по-прежнему будут интересовать только обращения к регистру «ТоварыВРезервеНаСкладах».

При выполнении этого запроса также производится чтение остатков регистра «ТоварыВРезервеНаСкладах», но они читаются с опцией «ДЛЯ ИЗМЕНЕНИЯ», то есть при этом будет установлена эксклюзивная блокировка.

Таким образом, регистр «ТоварыВРезервеНаСкладах» блокируется в рамках одной транзакции сначала разделяемой блокировкой, а затем эксклюзивной. Это и является причиной возникновения данной взаимоблокировки.

Для исправления этой ошибки необходимо изначально заблокировать остатки регистра «ТоварыВРезервеНаСкладах» с максимальным необходимым уровнем изоляции, то есть с опцией «ДЛЯ ИЗМЕНЕНИЯ». При этом код процедуры изменится следующим образом:

Захват ресурсов в разном порядке

Рассмотрим пример взаимоблокировки, возникшей в результате захвата ресурсов в разном порядке:

В этой взаимоблокировке можно видеть следующие характерные признаки взаимоблокировок данного вида (возникающие по причине захвата ресурсов в разном порядке):

1. Во взаимоблокировке участвуют несколько (в данном случае два) ресурсов. При этом они захватываются в разном порядке.

2. Процессы являются разнотипными, то есть выполняются разные прикладные действия и, соответственно, разный код конфигурации.

Рассмотрим действия, которые выполняют эти два процесса, и блокировки, которые при этом устанавливаются.

1. Действия и блокировки процесса 1:

1.1. Процесс 1 выполняет запрос контроля остатков в строке 506 модуля набора записей регистра накопления «ТоварыКПередачеСоСкладов». Рассмотрим фрагменты кода процедуры «КонтрольСвободныхОстатков_Реализация», обращая внимание только на обращения к таблице «ТоварыНаСкладах.Остатки».

В результате выполнения этого запроса успешно устанавливается разделяемая блокировка на остатки регистра «ТоварыНаСкладах».

При двойном клике на первой блокировке процесса 1 откроется форма подробной информации о блокировке. Эта форма, в частности, содержит ссылку на выполнение интересующего нас запроса:

Открыв форму выполнения запроса, мы увидим полный стек вызовов кода конфигурации. Из этого стека становится понятно что интересующий нас запрос выполнялся при проведении документа «РеализацияТоваровУслуг» (в коде тестовой обработки соответствующая переменная имеет имя «Реализация»).

1.2. Следующее действие, выполненное процессом 1, имеет этот же стек вызова, но он заканчивается на строке «Реализация.Записать».

Это означает, что оба действия были выполнены в результате проведения одного документа «РеализацияТоваровУслуг», но первое действие было вызвано в явном виде из кода конфигурации, а второе – выполнено автоматически платформой.

Посмотрим, какой SQL-запрос был сгенерирован платформой при выполнении этого действия.

Это обновление таблицы остатков регистра накопления «ТоварыКПередачеОрганизаций». При выполнении этого действия была установлена эксклюзивная блокировка на таблицу остатков этого регистра. Однако эта блокировка находится в режиме ожидания, так как имеется несовместимая с ней блокировка процесса 2.

2. Действия и блокировки процесса 2:

Процесс 2 выполняет одно-единственное действие – запись и проведение документа «РасходныйОрдер». Оба действия, имеющие отношение к взаимоблокировке, выполняются платформой автоматически при проведении документа.

2.1. Первое действие: обновление остатков регистра накопления «ТоварыКПередачеОрганизаций»:

В результате этого действия устанавливается эксклюзивная блокировка на соответствующие остатки регистра «ТоварыКПередачеОрганизаций». Именно эта блокировка мешает процессу 1 установить аналогичную блокировку при выполнении действия 1.2.

2.2. Второе действие: обновление остатков регистра накопления «ТоварыНаСкладах»:

В результате этого действия устанавливается эксклюзивная блокировка на соответствующие остатки регистра «ТоварыНаСкладах». Однако в системе уже имеется несовместимая блокировка на эти же записи регистра, которая была установлена процессом 1 при выполнении действия 1.1. По этой причине блокировка процесса 2 устанавливается в режиме ожидания.

Итак, процесс 1 ожидает окончания транзакции процесса 2, в то время как процесс 2 ожидает окончания транзакции процесса 1. Получаем взаимоблокировку по причине захвата ресурсов в разном порядке. Процесс 1 захватил сначала регистр накопления «ТоварыНаСкладах», а затем регистр «ТоварыКПередачеОрганизаций». Процесс 2 захватил эти же регистры, но в обратном порядке.

Все запросы, попавшие во взаимоблокировку, выполняются при автоматической записи движений по регистрам при проведении документа. Проблема в том, что в документе «РеализацияТоваровУслуг» при записи движений в регистр «ТоварыКПередачеСоСкладов» захватывается таблица остатков регистра «ТоварыНаСкладах». Именно это является причиной взаимоблокировки, однако обойтись без чтения этой таблицы, очевидно, нельзя, поскольку это часть алгоритма обработки данных.

Можно было бы попробовать изменить порядок записи движений в документе «РасходныйОрдер», прописав в обработчике проведения этого документа следующий код:

Таким образом мы избавились бы от рассматриваемой взаимоблокировки, но создали бы опасность возникновения других взаимоблокировок. Для полной уверенности в их отсутствии нам пришлось бы проанализировать весь код конфигурации в поисках транзакций, которые записывают движения по этим двум регистрам, и везде произвести запись в явном виде и в нужном порядке. Кроме того, пришлось бы принимать организационные меры для того, чтобы разработчики впредь всегда записывали движения по этим регистрам только в явном виде и только в заданном порядке.

Поэтому в данном случае рекомендуется другой способ устранения взаимоблокировки – установка искусственной блокировки. Поскольку процесс 2 (проведение документа «РасходныйОрдер») выполняет захват ресурсов автоматически, будем считать именно этот порядок правильным. Процесс 1 («РеализацияТоваровУслуг») захватывает ресурсы в неправильном порядке – сначала блокируется регистр «ТоварыНаСкладах», затем – «ТоварыКПередачеОрганизаций». Именно этот порядок должен быть изменен.

Для этого следует выполнить запрос с опцией «ДЛЯ ИЗМЕНЕНИЯ» к таблице остатков регистра «ТоварыКПередачеОрганизаций». Этот запрос должен быть выполнен перед запросом в строке 506 модуля набора записей регистра «ТоварыКПередачеСоСкладов». Условия запроса должны быть такими, чтобы считать (и, соответственно, заблокировать) все остатки, которые будут изменены при записи набора записей в действии 1.2.

Существует еще один вариант устранения этой взаимоблокировки. Блокировки, устанавливаемые процессом 1 (документ «РеализаяТоваровУслуг»), возникают только при работе в автоматическом режиме. Характерным признаком таких блокировок является значение поля режим = «Range…»:

Эти блокировки полностью исчезают при переходе в управляемый режим блокировки данных в транзакции. То есть данная взаимоблокировка будет невозможна при работе в управляемом режиме.

От экспертов «1С‑Рарус»: Настраиваем «Закрытие месяца» в 1С:ERP с 500 000 первичных документов ежемесячно. Часть III

Цикл статей об оптимизации «Закрытия месяца» в 1С:ERP

Вашему вниманию предлагается третья часть из цикла статей по оптимизации расчета операции «Закрытие месяца» в 1С:ERP.

Давайте для начала вспомним о чем мы говорили в двух предыдущих частях:

• В первой части мы подробно рассмотрели процесс отладки расчета себестоимости и подкрепили практическими кейсами полученные знания. В том числе, снабдив читателя приемами отладки в высоконагруженных продуктивных системах.
  Выявляем причины долгого «Закрытия месяца» в 1С:ERP и ускоряем выполнение операции. Часть I.
• Во второй части мы продолжили применять наши знания на практических примерах, в том числе поговорив о случае, когда операция и вовсе не доходит до своего завершения.
  Расследование и оптимизация расчета операции «Закрытие месяца» в 1С:ERP. Часть II.

В данной статье рассмотрим практический случай, который затронет ранее не освещенные темы, а также покажет нестандартный подход к решению задачи.

1С:ERP для производства муки и хлебобулочных изделий

Сегодня речь пойдет о крупном холдинге основным направлением деятельности которого является производство муки и хлебобулочных изделий. В состав предприятия входит мельница, а также несколько хлебозаводов. На предприятии проходил проект по внедрению ERP системы. 1 января 2021 года был произведен торжественный запуск.

Особенностью учета данного предприятия является объем первичных документов. В базу данных ежемесячно вносится порядка 500 000 документов, из них 210 000 – 240 000 документов реализации. Режим работы предприятия 24*7, доступность информационной системы 24*7, работа пользователей в системе ведется непрерывно.

Перед нами была поставлена задача добится стабильного и максимально быстрого закрытия месяца.

Какие сервера нужны для 1С с 500 000 первичных документов в месяц

Сервер СУБД

• Microsoft SQL Server Enterprise: Core-based Licensing (64-bit) 15.0.4153.1.
• Оперативная память: 169 ГБ.
• Процессор: 3.1 ГГц, 24 ядра.

1С

• Платформа: 8.3.17.
• ERP: 2.5.5.82.

Серверы кластера 1С

• Оперативная память: 169 ГБ.
• Процессор: 3.1 ГГц, 24 ядра.
• 3 рабочих сервера, 1 центральный.
  Сервера имеют одинаковую аппаратную составляющую:
  • Оперативная память: 48 ГБ.
  • Процессор: 3.1 ГГц, 24 ядра.

  Сервер СУБД и сервера приложения развернуты в облаке. Прирост базы данных за год 800 ГБ.

  Выполняем требование «Стабильное закрытие месяца»

  Отметим, что 1 января 2021 года система вышла в опытную эксплуатацию, был выполнен запуск системы «с нуля» и проблемы решались по мере их появления.

  Ошибка при расчете себестоимости

  Первой проблемой с которой пришлось столкнуться, это постоянные падения на этапе «Расчет себестоимости». Стоить заметить, что этот этап выполняется не только в случае, когда есть производственные акты. В нашем случае их не было.

  При запуске процедуры закрытия месяца первоначально выполнялся этап «Актуализация движений взаиморасчетов», этап завершался штатно и мы переходили к расчету себестоимости, который в определенный момент времени завершался без объяснения причин, единственное описание ошибки, которую удалось получить, это была ошибка в консоли фоновых заданий «Аварийно завершился процесс фонового задания». Протокол расчета себестоимости мы тоже не получали. В версии 2.5.5.82 еще не было режима отладки расчета, который мы разбирали в первой части нашего повествования Выявляем причины долгого «Закрытия месяца» в 1С:ERP и ускоряем выполнение операции. Часть I. Забегая вперед скажем, что длительности этапа расчета себестоимости, которую мы получили после первого удачного расчета составила 22 часа 31 минута. Такая длительность не позволяла определить проблему путем прохода расчета в отладке, падение задания расчета происходило в непредсказуемый момент времени.

  Когда речь идет о непрерывном цикле работ, поиск причин в продуктивном контуре становится делом почти невозможным, так как с одной стороны, операция закрытия создает сильную нагрузку, а с другой — очень сложно или даже почти невозможно найти окно с минимальной нагрузкой, чтобы оперативная работа не мешала исследованию операции закрытия. Поэтому был организован тестовый контур. И проверка расчета на копии базы в тестовом контуре дала позитивный результат.

  Расчет смог завершиться, что внушило оптимизм и дало возможность сделать первый вывод: дело скорее всего в серверной части. Начинаем собирать материал в продуктивном контуре. Запускаем расчет на рабочей базе и наблюдаем за журналом регистрации в надежде увидеть причину без большого и сложного анализа логов технологического журнала. При выполнении расчета себестоимости в журнале регистрации фиксируются события, по которым можно определить, на каком этапе расчета мы находимся.

  После анализа журнала регистрации были сделаны выводы:

  1. до момента падения, расчет выполнялся штатно;
  2. падения происходило на разных этапах расчета себестоимости.

  Детальности этой информации к сожалению не хватило, чтобы локализовать место проблематики.

  Собираем данные в технологический журнал

  На серверах приложения был настроен технологический журнал. А так же был настроен сбор данных Performance Monitor.

  

  При анализе Performance Monitor мы увидели следующую картину:

  

  В момент падения расчета себестоимости на сервере приложения доступная оперативная память имела минимальные значения.

  Имея более точный временной интервал падения , мы обратились к технологическому журналу, в самих файлах технологического журнала подсказку мы найти не смогли, однако проанализировав время записи последних файлов логов в рамках одного rphost, мы пришли к выводу, что вместе с падением расчета перезапускался рабочий процесс, на котором выполнялся расчет себестоимости.

  Перезапуск рабочих процессов

  Соединив вместе информацию полученную из Performance Monitor и технологического журнала мы пришли к выводу, что происходит завершение рабочего процесса сервером 1С:Предприятия вследствие превышения допустимого объема памяти.

  Подробнее про перезапуск рабочих процессов при превышении лимита памяти можно прочитать в статьях:

  .
  • Значительное потребление памяти процессами кластера на сервере приложений (https://its.1c.ru/db/metod8dev/content/5815/hdoc).

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

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

  Изолируем расчет себестоимости на отдельном сервере

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

  Для выполнения изоляции расчета себестоимости на отдельном сервере мы применили механизм требований назначения функциональности.

  Определившись с механизмом, мы пошли творить:

  1. Был выбран сервер 1С:Предприятия из состава кластера, который планировалось выделить для целей расчета себестоимости.
  2. Были выполнены настройки требований назначений функциональности.

  На первом этапе были сделаны следующие настройки:

  

  Требованием под номером 18 мы указали, что использование сервера недоступно, кроме требований 12, 13 и 14. Для корректной работы требований необходимо правильно выстраивать последовательность требований, если мы укажем требование «Для всех не назначать» самым первым, то дальнейшие требования будут проигнорированы.

  Поскольку расчет себестоимости выполняется в фоновом задании была использована конструкция BackgroundJob.CommonModule. . , которая используется для указания конкретного фонового задания, запущенного из встроенного языка.

  Далее нам потребовалось определить все методы, которые запускаются при расчете себестоимости. Мы использовали консоль фоновых заданий, был запущен расчет в копии, после чего по истории выполнения заданий, были определены методы, которые запускаются, как отдельные фоновые задания, в момент расчета себестоимости.

  Потребовалось создать отдельную настройку на каждый метод:

  1. РасчетСебестоимостиПрикладныеАлгоритмы.ЗаписатьДвиженияПоРегиструФоновымЗаданием.
  2. РасчетСебестоимостиПрикладныеАлгоритмы.РассчитатьПартииВФоне.
  3. ЗакрытиеМесяцаСервер.ВыполнитьРасчетЭтаповВФоновомЗадании.

  После настройки целевого сервера, необходимо выполнить настройку на всех остальных серверах в кластере. Необходимо указать, что фоновые задания, которые мы вынесли на отдельный сервер не должны выполняться на других на серверах.

  

  После выполненных настроек мы смогли выйти на «более-менее» стабильный расчет себестоимости.

  Рационализируем использование отдельного сервера под расчет себестоимости

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

  Для более рационального использования ресурсов сервера было принято решение перенести часть выполняемых роботов на данный сервер. Мы определили список фоновых заданий с предсказуемым потреблением ресурсов. Для определения списка мы проанализировали исполняемый код фоновых заданий. Были выбраны задания, в которых нет объемных выборок данных, произвольных периодов, прогнозируемо исполняемый код. Далее мы постепенно выносили их на сервер к расчету себестоимости, отслеживая потребление памяти. После окончания формирования списка заданий настройки требований назначений приобрели следующий вид:

  

  Из важных моментов, которые мы подчеркнули в процессе эксплуатации хочется отметить:

  1. Требование под номером 1. Данное требование запрещает формирование любых отчетов на данном сервере, это было сделано вследствие того, что отчет является непредсказуемым по потребляемым ресурсам.
  2. Требование под номером 16. Конструкция BackgroundJob.CommonModule должна «в теории» отправлять на данный сервер все фоновые задания, запущенные из кода, однако, как мы выяснили, в нашем случае данная конструкция не работает.
  3. Требование под номером 4. Данное требование запрещает отправлять на данный сервер поиск в списке. Поиск в списке должен выполняться на том же сервере, на котором работает пользователь, иначе мы получим сильную задержку, при передаче данных и поиск будет тормозить.
  4. Не забываем настроить на других серверах в кластере требования назначения функциональности, запрещающие выполнения заданий, которые мы выделили на отдельный сервер.

  Так образом мы одержали победу в сражении, но не в войне…

  Повторное появление аварийного завершения расчета себестоимости после 2-х месяцев эксплуатации

  После настройки требований назначений функциональности мы добились достаточно стабильного расчета себестоимости, что позволило нам отвлечься на другие задачи, однако через некоторое время, около 2-х месяцев, мы снова начали получать аварийное завершение процесса расчета.

  Когда плановый перезапуск рабочих процессов может быть вреден

  В памяти еще были свежи воспоминания и по протоптанной дорожке мы пошли проверять потребление ресурсов сервера, на котором выполняется расчет, однако никаких проблем с памятью обнаружено не было. Потребление памяти было стабильным.

  

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

  Решение было найдено после анализа списка рабочих процессов, а конкретно параметра «Время запуска». Было обнаружено, что рабочие процессы с разных серверов имеют одинаковое время запуска, это побудило нас проверить, не является ли данная картина результатом настроек кластера.

  

  И такая настройка была найдена. Ей оказался интервал перезапуска рабочих процессов, было установлено значение 86400 секунд, что соответствует 24 часам. Интервал перезапуска — отвечает за частоту перезапуска рабочих процессов кластера. Существует распространенная практика, установки интервала перезапуска рабочих процессов, это помогает в борьбе с повышенным расходом памяти на сервере 1С:Предприятия. В нашем случае такой проблемы не наблюдалось, однако привычка настраивать перезапуск рабочих процессов уже сформировалась.

  Данный метод борьбы за общую производительности в целом неплох и часто помогает, однако он имеет очень существенный минус. Минусом данного метода является то, что при перезапуске рабочего процесса в новый rphost переезжает только клиентское соединение. Серверные вызовы и фоновые задания не умеют переезжать и завершаются вместе со старым процессом через время указанное в настройке «Проблемные процессы завершать через», в нашем случае 300 секунд.

  Несмотря на заданный интервал перезапуск рабочих процессов все же является событием случайным, а случайности нам не нужны, по этой причине было принято решение установить параметр «Интервал перезапуска» в значение 0. Значение 0, является значением по умолчанию для консоли кластера, оно говорит о том, что перезапуск рабочих процессов по определенному интервалу выполняться не будет.

  

  Итак мы одержали очередную победу в войне за стабильность…

  Ошибки конфликтов блокировок и замедление работы ERP у пользователей

  В процессе эксплуатации системы, периодически возникала ситуация, при которой работа в системе резко замедлялась, практически при любых действиях пользователей возникала ошибка конфликта блокировок.

  Поиск причин начали с консоли кластера и колонки «Захвачено СУБД».

  В колонке «Захвачено СУБД» отображается длительность захвата соединения с базой данных текущим сеансом с момента захвата по текущий момент. Отображается только если соединение с захвачено сеансом.

  Проверяем время захвата соединений с СУБД

  Принцип метода, которым мы пользовались кратко описан в статье «Частые вопросы по производительности „1С:Документооборота“» (https://v8.1c.ru/metod/article/chastye-voprosy-po-proizvoditelnosti-1s-dokumentooborota.htm) однако мы пошли немного дальше, чем описано в данной статье.

  Маленький «лайфхак» который был подсказан коллегами, это назначить служебных пользователей фоновым заданиям, пользователи именуются таким образом, чтобы можно было выполнить идентификацию фонового задания. Данное решение позволяет существенно ускорить идентификацию проблемных процессов, без сбора технологического журнала и его последующего анализа.

  

  В итоге анализа консоли кластера было обнаружено, что в момент возникновения проблем с производительностью и массовых блокировок регламентное задание «Отражение документов в регламентированном учете» начинало захватывать соединение с базой данных, признаком этого были значения в колонке «Захвачено СУБД» в районе 3000–4000 секунд. Принудительное завершение задания восстанавливало работоспособность базы, что убедило нас в необходимости присмотреться поближе к отражению в регламентированном учете.

  Разбираем задание «Отражения документов в регламентированном учете»

  Необходимо было разобрать алгоритм работы отражения в регламентированном учете.

  Разбор механизма отражения документов в регламентированном учете выполнялся экспертами ранее на страницах нашей рубрики в статье «От экспертов „1С-Рарус“: Расследование и оптимизация расчета операции „Закрытие месяца“ в 1С:ERP. Часть II».

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

  Задание отражения начинается с процедуры ОтразитьВсеРегламент, взглянув на нее внимательно мы обнаружили в ней вызов 3-х функций:

  1. УчетНДСУП.ВыполнитьФормированиеДвиженийПоНДС(КонецМесяца(ТекущаяДата)).
  2. РеглУчетПроведениеСервер.ОбновитьДанныеЗависимыхРегистров().
  3. РеглУчетПроведениеСервер.ОтразитьВсе(КонецДня(ТекущаяДата)).

  

  Для более точной идентификации проблемы, мы разделили описанные выше процедуры на 3 отдельных задания и начали наблюдать. В результате, используя консоль кластера, мы выяснили, что соединение с базой данных держит функция РеглУчетПроведениеСервер.ОтразитьВсе(КонецДня(ТекущаяДата)).

  Выполнив анализ исполняемого кода мы обнаружили, что в самом начале процедуры инициализируется менеджер временных таблиц, а закрывается он только в конце данной процедуры. Вход в процедуру ОтразитьВсе осуществляется в начале выполнения отражения документов в регламентированном учете, завершается процедура только после отражения всех документов.

  То есть создаваемый в начале процедуры менеджер временных таблиц существует все время выполнения отражения и учитывая, что временные таблицы будут существовать в памяти компьютера до закрытия менеджера временных таблиц (автоматически или принудительно методом Закрыть()) или до исполнения запроса, связанного с этим менеджером, уничтожающего временную таблицу с помощью конструкции УНИЧТОЖИТЬ, мы решили, что именно данный менеджер временных таблиц удерживает соединение с СУБД.

  

  Связав воедино информацию из консоли кластера о длительном соединении и наличии менеджера временных таблиц, который остается открытым все время работы задания по отражению документов, мы решили отследить использование менеджера временных таблиц далее по коду отражения и избавиться от постоянного соединения, путем закрытия и пересоздания менеджера ВТ.

  В ходе отладки и анализа кода мы проследили путь созданного менеджера временных таблиц до процедуры ОтразитьДокументыПакетно. В данной процедуре выполняется выборка 1000 документов из очереди к отражению и передача их в процедуру ВыполнитьОтражение. Мы приняли решение закрывать менежер ВТ и пересоздавать его заново для каждой порции документов.

  Данное решение было принято по причине того, что в месяц в системе выполняется отражение 500 тысяч документов в том числе за один сеанс работы данного фонового задания и существование менеджера временных таблиц в пределах отражения такого количества документов признано нами потенциально опасным.

  

  После выполненной доработки отражение в регламентированном учете проблем не доставляло.

  Ускоряем расчет «Закрытия месяца» в ERP

  Когда мы смогли добиться стабильного расчета на первый план вышла проблема длительности.

  В нашем случае закрытие могло выполняться от 12 до 30, а в последствии и 40 часов.

  В первую очередь мы определили длительность основных этапов закрытия:

  1. Актуализация движений документов по данным взаиморасчетов.
     Время выполнения порядка 3–4 часов.
  2. Расчет себестоимости.
     Время выполнения от 8 до 30 часов.
  3. Отражение документов в регламентированном учете.
     Время выполнения до 6 часов.

  Как ускорить «Расчет себестоимости»?

  Работу мы начали с этапа «Расчет себестоимости». Такое решение было принято исходя из опыта борьбы за стабильности системы, чем дольше выполняется операция, тем больше шансов получить исключительную ситуацию.

  Решив проблему нестабильного расчета себестоимости, мы смогли получить протокол расчета себестоимости, в котором достаточно информации, для определения этапов расчета, имеющих наибольшую длительность.

  Как читать протокол расчета себестоимости мы рассказывали в первой части нашего цикла «Выявляем причины долгого „Закрытия месяца“ в 1С:ERP и ускоряем выполнение операции. Часть I».

  Разброс времени расчета себестоимости достаточно велик и этому есть объяснения. Давайте сравним топ длительных операций расчета апреля 2021 года зафиксированных в протоколе.

  Первоначальный расчет длительностью: 19 ч. 55 мин. 53,941 сек.

  

  Повторный расчет длительностью: 9 ч. 28 мин. 16,163 сек.

  

  Как можно заметить основная разница в этапе №88. Партионный учет: ЗаписатьСформированныеДвижения. При первичном расчете месяца мы фиксируем движения по всем документам, введенным за месяц, а при повторных расчетах только для измененных с момента предыдущего расчета.

  Что делать с «Заполнением партий»?

  Наше расследование мы начали с этапа ЗаполнениеПартийВРегистреСебестоимостьТоваров.

  В результате анализа было выявлено, что в ходе построения цепочек для расчета партий получатся 2 таблицы, каждая по 277 млн. записей, которые обрабатываются не очень быстро. Результаты анализа вместе с протоколом были переданы на линию консультации фирмы «1С». После анализа наших данных была признана проблема и зафиксирована ошибка. Проблемой в нашем случае являлось большое количество корректировок реализаций, которые создавали излишние связи.

  

  По причине наличия планов на обновление системы до версии 2.5.7 от работ по самостоятельной переделке заполнения партий было решено отказаться и ждать исправления от фирмы «1С», в расчете получить их в целевой версии при обновлении.

  Оптимизируем «Запись сформированных движений»

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

  Для возврата к оптимизации записи движений появился хороший повод. В сентябре 2021 года первоначальный расчет длился: 30 ч. 53 мин. 12,091 сек., запись движений при этом заняла почти половину данного времени.

  

  К проблемам добавилось резкое увеличение времени выполнения регламентов обслуживания базы. Ночной регламент, включающий в себя перестроение индексов и обновление статистики стал выполняться до 8 часов.

  Увеличение времени расчета себестоимости и выполнения ночного регламента повлекло за собой наложение этапа записи движений на ночной регламент обслуживания, вследствие чего различные этапы расчета себестоимости заканчивались конфликтом блокировок. Типичная картина в протоколе расчета:

  

  Проверяем скорость работы дисковой подсистемы

  Первоначально виноватой во всех грехах была назначена дисковая подсистема, в силу определенных обстоятельств собрать счетчики на сервере СУБД являлось проблемой, в связи с чем пришло искать косвенные подтверждения.

  Выполнив несложный скрипт на сервере СУБД.

  

  Мы получили среднее время чтения файла базы данных порядка 45, а записи 20 миллисекунд.

  В связи с тем, что физически увеличить скорость дисков возможности не было, по причине того, что сервера развернуты в облаке и уже имеют максимально возможные по производительности диски, было принято решение провести анализ насколько параллельная нагрузка от роботов в базе влияет на скорость чтения/записи.

  Для проведения эксперимента был развернут тестовый стенд, соответствующий конфигурации рабочих серверов, была развернута свежая база.

  После подготовки тестовой среды был выполнен расчет месяца и был получен крайне удивительный результат, повторный расчет месяца занял всего 3,5 часа.

  

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

  

  Было назначено расследование, в результате которого, мы выяснили, что на тестовом стенде на сервере СУБД был включен параметр параллелизма SQL (параметр max degree of parallelism) в значении 12, на рабочем сервере СУДБ данный параметр установлен в значение 1.

  О примерах работы с этим параметром SQL max degree of parallelism мы уже говорили во второй части нашего цикла «От экспертов „1С-Рарус“: Расследование и оптимизация расчета операции „Закрытие месяца“ в 1С:ERP. Часть II».

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

  

  Дополнительно были произведены тестовые расчеты полного месяца с включенным параллелизмом, результат и тут порадовал, мы получали существенную прибавку к скорости расчета.

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

  Далее была предпринята попытка установки параллелизма на продуктивном сервере СУБД, которая не привела к успеху, задержки на ожидании параллелизма перекрывали эффект от его использования. От этой идеи отказались.

  Была обнаружена следующая картина:

  

  В период с 6 часов утра, когда в базе начинается активная работа, нагрузка на CPU существенно возрастает. Для дальнейшего анализа был использован монитор активности SQL сервера, который показал постоянное наличие ожидающих задач в очереди.

  На основании всех полученных данных, мы пришли к выводу, что серверу СУБД не хватает процессорного ресурса.

  Были выполнены следующие изменения:

  1. С сервера СУБД с самой «тяжелой» базой были вынесены все остальные базы на отдельный сервер СУБД.
  2. Количество процессоров увеличено с 24 до 32.
  3. Оперативная память увеличена с 169 до 262 ГБ.

  В результате выполненных изменений производительность базы улучшилась. Скрипт выполнения ночного регламента был изменен, для операции перестроение индексов и обновление статистики был использован параметр max degree of parallelism равный 0, передаваемый непосредственно в исполняемую функцию. Значение параметра max degree of parallelism 0 означает, что SQL сервер сам выбирает значение данного параметра для выполнения функции. В результат ночное обслуживание базы стало выполняться от 2-х до 3,5 часов.

  

  Показатели работы дисковой подсистемы так же улучшились.

  

  Распараллеливаем «Запись сформированных движений» в 1С:ERP

  Поработав над сервером СУБД настала очередь и ERP. Имея хороший запас производительности сервера было принято решение распараллеливать запись движений насколько это возможно. Были установлены следующие настройки операций закрытия месяца.

  

  На первом этапе параметр «Ожидать окончания записи предыдущей порции этого же регистра» был установлен в значении «Да», однако прироста в скорости мы не получили, количество заданий записи движений оставалось небольшим, до 5 фоновых заданий, после этого было принято решение установить параметр «Ожидать окончания записи предыдущей порции этого же регистра» в значение «Нет».

  Вместе с тем, для избежания потери данных в случае конфликта блокировок была выполнена доработка процедуры ЗаписатьНаборЗаписей модуля РасчетСебестоимостиПрикладныеАлгоритмы. Был реализован бесконечный цикл записи с паузой в 1 минуту, в случае получения ошибки конфликта блокировок.

  Важно отметить, что использование бесконечных циклов является опасным приемом и может привести к нестабильной работы системы. В нашем случае мы посчитали риск оправданным, поскольку за системой всегда «приглядывает» служба технической поддержки. Применять данные решения в системах, которые предполагается эксплуатировать в формате тиражных решений, без постоянной технической поддержки мы настоятельно не рекомендуем.

  

  В итоге проделанной работы при полном расчете декабря мы получили длительность этапа записи движений в: 1 ч. 59 мин. 25,485 сек., общее время расчета себестоимости декабря 16 часов.

  

  Планы по дальнейшей оптимизации «Закрытия месяца» в 1C:ERP

  Мы все еще продолжаем работы по ускорению закрытия месяца. В планах на ближайшее будущее оптимизация функции ВернутьДокументыКОтражению, по методу, описанному во второй части нашего цикла (От экспертов «1С-Рарус»: Расследование и оптимизация расчета операции «Закрытие месяца» в 1С:ERP. Часть II).

  Это позволит нам получить ускорение сразу в 2-х местах:

  1. Этап расчета себестоимости ЗарегистрироватьКОтражениюВРегламентированномУчете.
  2. Операция «Актуализация движений документов по данным взаиморасчетов», поскольку функция ВернутьДокументыКОтражению вызывается по окончании этой операции и занимает продолжительное количество времени.

  Также в планах уменьшить значение параметра закрытия «Максимальное количество движений, записываемое одним фоновым заданием» поскольку он напрямую влияет на количество заданий записи движений. При установленном значении по умолчанию 100000 мы имеем 31 задание для записи регистров «Себестоимости» и «Выручки и себестоимости» и всего 5 для записи регистра «Прочие активы и пассивы».

  

  Итоги третьей части цикла экспертных статей про оптимизацию «Закрытия месяца»

  Время подводить итоги третьей части нашего путешествия по лабиринту ERP.

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

  Во-вторых, показали насколько важным и мощным инструментом является настройка сервера 1С:Предприятие. Как одни настройки помогают решать проблемы, а другие создавать их.

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

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

  Мы хотим поблагодарить читателей, за интерес, проявляемый к данной теме. Мы планируем продолжить цикл данных статей, в которых будем раскрывать «профессиональные секреты», знакомить вас с новыми возможностями ERP по отладке, рассказывать вам про сложные и интересные случаи из нашей практики.

  1с захвачено субд в чем измеряется

  

  Ошибка с tempdb

  Tempdb
  Privet. U menya ustanovlen SQL Server 6.5. Pri poiske v pole tipa (text) , vidaetsya oshibka.

  Ошибка SQL запроса , в базе работает, а через IBQuery в Delphi ошибка
  В Combobox загружены имена организаций. Нужно выполнить запрос на вывод всех полей таблицы.

  Настройка 1С и MS SQL. Оптимизация работы 1C. Настройка сервера MS SQL

  Настройки кластера отвечают за настройки всех серверов, принадлежащих настраиваемому кластеру. Кластер — это работа нескольких физических или виртуальных серверов, работающих с одними и теми же информационными базами.

  • Интервал перезапуска — отвечает за частоту перезапуска рабочих процессов кластера. Этот параметр необходимо выставлять при круглосуточной работы сервера. Рекомендуется частоту перезапуска связывать с технологическим циклом информационных баз кластера. Обычно это каждые 24 часа (86400 сек). Как известно, рабочие процессы серверов 1С обрабатывают и хранят рабочие данные.
  • Автоматический перезапуск был разработан в платформе «для минимизации отрицательных последствий фрагментации и утечки памяти в рабочих процессах». На ИТС есть даже информация о том, как организовать перезапуск рабочих процессов по другим параметрам (объем памяти, занимаемые ресурсы и т.п.).
  • Допустимый объем памяти — защищает сервера 1С от перерасхода памяти. При превышении процессом этого объема в интервале превышения допустимого объема, процесс перезапускается. Можно рассчитать, как максимальный размер памяти, занимаемый процессами «rphost» в периоды пиковой нагрузки серверов. Также стоит установить небольшой интервал превышения допустимого объема.
  • Допустимое отклонение количества ошибок сервера. Платформа рассчитывает среднее количество ошибок сервера по отношению к числу обращений к серверу в течение 5 минут. Если это отношение превысит допустимое, то рабочий процесс считается «проблемным», и может быть завершен системой, если установлен флаг «Принудительно завершать проблемные процессы».
  • Выключенные процессы останавливать через. При превышении допустимого объема памяти, рабочий процесс не завершается сразу, а становится «выключенным», чтобы было время «перенести» рабочие данные без потери на новый запущенный рабочий процесс. Если указан этот параметр, то «выключенный» процесс в любом случае завершится по истечении этого времени. Если наблюдаются «зависшие» рабочие процессы в работе сервера 1С, то можно стоит этот параметр на 2-5 минут.

  Эти настройки устанавливаются для каждого сервера 1С индивидуально.

  • Максимальный объем памяти рабочих процессов — это объем совокупной памяти, которую могут занимать рабочие процессы (rphost) на текущем кластере. Если параметр установлен в «0», то занимает 80% оперативной памяти сервера. «-1» — без ограничений. Когда на одном сервере работают СУБД и сервер 1С, им нужно делить между собой оперативную память. Если в процессе эксплуатации обнаружится, что серверу СУБД не хватает памяти, то можно ограничить память, выделяемую серверу 1С с помощью этого параметра. Если СУБД и 1С разделены по серверам, то имеет смысл рассчитать этого параметр по формуле:
    «Max объем» = «Общая оперативная память» — «Оперативная память ОС»;
    «Оперативная память ОС» рассчитывается по принципу 1 Гб на каждые 16 Гб оперативной памяти сервера
  • Безопасный расход памяти за один вызов. В общем случае, отдельные вызовы не должны занимать всю оперативную память, выделенную рабочему процессу. Если параметр установлен в «0», то объем безопасного расхода будет равен 5 % от «Максимального объема памяти рабочих процессов». «-1» — без ограничения, что крайне не рекомендуется. В большинстве случаев этот параметр лучше оставлять «0».
  • С помощью параметров «Количество ИБ на процесс» и «Количество соединений на процесс» можно управлять распределением работы сервера 1С по рабочим процессам. Например, запускать под каждую информационную базу отдельный «rphost», чтобы в случае «падений» процесса, отключались только пользователи одной базы. Эти параметры стоит подбирать индивидуально под каждую конфигурацию сервера.

  Рекомендации по настройке СУБД MS SQL

  Ограничение на использование оперативной памяти сервером СУБД — У сервера СУБД MS SQL есть одна замечательная особенность — он любит загружать базы, с которыми ведется активная работа в оперативную память полностью. Если его не ограничивать, то он заберет себе всю оперативную память, какую только сможет.

  • Если сервер 1С установлен вместе с Microsoft SQL Server, то верхний порог памяти необходимо уменьшить на величину, достаточную для работы сервера 1С.
  • Если на сервере работает только СУБД, то для СУБД по формуле:
    «Память СУБД» = «Общая оперативная память» — «Оперативная память ОС»;
  • Shared memory — об этом параметре известно много, но до сих пор встречается, что про него забывают. Выставляем в «1», если сервер 1С и СУБД работают на одном физическом или виртуальном сервере.
  • Max degree of parallelism — определяет, сколько процессоров используется при выполнении одного запроса. СУБД распараллеливается получение данных при выполнении сложных запросов на несколько потоков. Для 1С рекомендуется устанавливать в «1», то есть одним потоком.
  • Авторасширение файлов БД — определяем шаг в МБ, с которым «расширяется» файл базы данных. Если шаг будет маленький, то при активном росте БД, частые расширения приведут к дополнительной нагрузке на дисковую систему. Лучше установить в 500 — 1000 МБ.
  • Реиндексация и дефрагментация индексов — рекомендуется делать дефрагментацию/реиндексацию хотя бы раз в неделю. Реиндексация блокирует таблицы, поэтому лучше запускать в нерабочее время или периоды минимальной нагрузки. Нет смысла делать дефрагментацию после перестроения индекса (реиндексации). По рекомендации Microsoft дефрагментацию делают в том случае, если фрагментация индекса не превышает 30 %. Если выше, рекомендуется сделать реиндексацию.
  • Обновление статистики — рекомендуется обновлять статистику хотя бы 1 раз в день. Статистика отвечает за производительность выполнения запросов.
  • План электропитания — в настройках электропитания операционной системы установить на высокую производительность.

  Включить возможность мгновенной инициализации файлов (Database instant file initialization)

  Это позволяет ускорить работу таких операций как:

  Создание базы данных.

  Добавление файлов, журналов или данных в существующую базу данных.

  Увеличение размера существующего файла (включая операции автоувеличения).

  Восстановление базы данных или файловой группы.

  Для включения настройки:

  Откроть Local Security Policy (secpol.msc).

  Локальные политики — Назначение прав пользователей

  Выполнение задач по обслуживанию томов

  «Добавить» пользователя или группу и добавить сюда пользователя, под которым запущен сервер MS SQL Server

  Включить «Блокировка страниц в памяти» (Lock pages in memory)

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

  Пуск — Выполнить — gpedit.msc.

  Конфигурация компьютера — Конфигурация Windows

  Настройки безопасности и Локальные политики

  Назначение прав пользователя

  «Блокировка страниц в памяти»

  В диалоговом окне Параметр локальной безопасности — блокировка страниц в памяти выбрать «Добавить» пользователя или группу

  В диалоговом окне Выбор: пользователи, учетные записи служб или группы добавьте ту учетную запись, под которой запускается служба MS SQL Server

  Чтобы изменения вступили в силу, перезагрузите сервер.

  Отключить механизм DFSS для дисков

  Механизм Dynamic Fair Share Scheduling отвечает за балансировку и распределение аппаратных ресурсов между пользователями. Иногда его работа может негативно сказываться на производительности 1С. Чтобы отключить его только для дисков, нужно

  • Найти в реестре ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk
  • Установить значение параметра EnableFairShare в 0

  Отключить сжатие данных для каталогов, в которых лежат файлы базы

  При включенном сжатии ОС будет пытаться дополнительно обрабатывать файлы при модификации, что замедлит сам процесс записи, но сэкономит место.

  Чтобы отключить сжатие файлов в каталоге, необходимо

  • Открыть свойства каталога
  • На закладке Общие нажать — Другие
  • Снять флаг «Сжимать» содержимое для экономии места на диске

  Установить параметр «Максимальная степень параллелизма» (Max degree of parallelism) в значение 1

  Данный параметр определяет, во сколько потоков может выполняться один запрос. По умолчанию параметр равен 0, это означает, что сервер сам подбирает число потоков. Для баз с характерной для 1С нагрузкой рекомендуется поставить данный параметр в значение 1, т.к. в большинстве случаев это положительно скажется на работе запросов

  • Запустить Management Studio и подключиться к нужному серверу
  • Свойства сервера — Дополнительно
  • Установить значение параметра равное единице

  Ограничить максимальный объем памяти сервера MS SQL Server

  Необходимо ограничить максимальный объем памяти, потребляемый MS SQL Server, особенно это критично, если роли сервера 1С и сервера СУБД совмещены. Максимальный объем памяти, рекомендуемый для MS SQL Server, можно рассчитать по следующей формуле:

  Память для MS SQL Server = Память всего — Память для ОС — Память для сервера 1С

  Например, на сервере установлено 64 ГБ оперативной памяти, необходимо понять, сколько памяти выделить серверу СУБД, чтобы хватило серверу 1С.

  Для нормальной работы ОС в большинстве случаев более чем достаточно 4 ГБ, обычно — 2-3 ГБ.

  Чтобы определить, сколько памяти требуется серверу 1С, необходимо посмотреть, сколько памяти занимают процессы кластера серверов в разгар рабочего дня. Этими процессами являются ragent, rmngr и rphost, подробно данные процессы рассматриваются в разделе, который посвящен кластеру серверов. Снимать данные нужно именно в период пиковой рабочей активности, когда в базе работает максимальное количество пользователей. Получив эти данные, необходимо прибавить к ним 1 ГБ — на случай запуска в 1С «тяжелых» операций.

  Чтобы установить максимальный объем памяти, используемый MS SQL Server, необходимо

  • Запустить Management Studio и подключиться к нужному серверу
  • Свойства сервера, Память
  • Указать значение параметра Максимальный размер памяти сервера

  Включить флаг «Поддерживать» приоритет SQL Server (Boost SQL Server priority)

  Данный флаг позволяет повысить приоритет процесса MS SQL Server над другими процессами.

  Имеет смысл включать флаг только в том случае, если на компьютере с сервером СУБД не установлен сервер 1С

  Для установки флага:

  • Запустить Management Studio и подключиться к нужному серверу
  • Свойства сервера — Процессоры
  • Включить флаг «Поддерживать приоритет SQL Server (Boost SQL Server priority)» и Ок.

  Установить размер авто увеличения файлов базы данных

  Автоувеличение позволяет указать величину, на которую будет увеличен размер файла базы данных, когда он будет заполнен. Если поставить слишком маленький размер авторасширения, тогда файл будет слишком часто расширяться, на что будет уходить время. Рекомендуется установить значение от 512 МБ до 5 ГБ.

  Для установки размера авторасширения необходимо:

  • Запустить Management Studio и подключиться к нужному серверу
  • Свойства нужной базы — Файлы
  • Напротив каждого файла в колонке Автоувеличение поставить необходимое значение

  Данная настройка будет действовать только для выбранной базы. Если нужно, чтобы такая настройка действовала для всех баз, нужно выполнить эти же действия для служебной базы model. После этого все вновь созданные базы будет иметь те же настройки, что и база model

  Разнести файлы данных mdf и файлы логов ldf на разные физические диски

  В этом случае работа с файлами может идти не последовательно, а практически параллельно, что повышает скорость работы дисковых операций. Лучше всего для этих целей подходят диски SSD.

  Для переноса файлов:

  • Запустить Management Studio и подключиться к нужному серверу
  • Открыть свойства нужной базы — Файлы
  • Запомнить (записать) имена и расположение файлов
  • Отсоединить базу.
  • Поставить флаг Удалить соединения и нажать Ок
  • Открыть Проводник и переместить файл данных и файл журнала на нужные носители
  • В Management Studio открыть контекстное меню сервера и «Присоединить базу».
  • Нажать кнопку Добавить и указать файл mdf с нового диска
  • В нижнем окне сведения о базе данных в строке с файлом лога нужно указать новый путь к файлу журнала транзакций и нажать Ок

  Вынести файлы базы TempDB на отдельный диск

  Служебная база данных TempDB используется всеми базами сервера для хранения, промежуточных расчетов, временных таблиц, версий строк при использовании RCSI и многих других вещей. Обычно обращений к этой базе очень много, и если она будет лежать на медленных дисках, это может замедлить работу системы.

  Рекомендуется хранить базу TempDB на отдельном диске для повышения производительности работы системы

  Для переноса базы TempDB на отдельный диск:

  • Запустить Management Studio и подключиться к нужному серверу
  • выполнить скрипт

  ALTER DATABASE tempdb

  MODIFY FILE (NAME = tempdev, FILENAME = ‘Новый_Диск:\Новый_Каталог\tempdb.mdf’)

  ALTER DATABASE tempdb

  MODIFY FILE (NAME = templog, FILENAME = ‘Новый_Диск:\Новый_Каталог\templog.ldf’)

  • Перезапустить MS SQL Server

  Включить Shared Memory, если сервер 1С расположен на том же компьютере, что и сервер СУБД

  Протокол Shared Memory позволит общаться приложениям через оперативную память, а не через протокол TCP/IP.

  Для включения Shared Memory необходимо

  • Запустить диспетчер конфигурации SQL Server
  • Зайти в SQL Native Client — Клиентские протоколы — Общая память — Включено
  • Поставить значение Да и нажать Ок

  Протокол Именованные каналы нужно выключить аналогичным образом.

  Когда все настройки выполнены, необходимо перезапустить службу MS SQL Server

  Похожие публикации:

  1. Как изменить файловую систему диска в linux
  2. Как сделать батник на выключение компьютера
  3. Как узнать в каком режиме работает оперативная память
  4. Как узнать заблокирован ли сайт на компьютере