Узкие места

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

1. Константы. До версии 8.2.14 узким местом была таблица констант целиком. Все значения констант, определенных в конфигурации, хранились в одной таблице. Начиная с версии 8.2.14 на каждую константу имеется собственная таблица, если не используется режим совместимости. Это позволяет записывать разные константы параллельно, но обычно проблема ошибочно написанного кода кроется как раз не в этом, а в том, что такой код пытается менять одну и ту же константу в разных сеансах, чего и новая структура делать тоже не позволяет. Назначение констант – хранить условно постоянные (очень редко изменяемые) данные, что следует из их названия. Общая рекомендация: не использовать константы для хранения данных, которые меняются чаще, чем раз в полгода, и никогда не использовать их для хранения быстро меняющихся данных (например, счетчиков). Причины ошибок блокировок, возникающих при неправильном использовании констант, диагностируются обычно очень просто: контекст кода, содержащий Константы.<имя>.Установить(...), будет виден в технологическом журнале, если настроить этот журнал, как указано в разделе .

2. Граница регистрации последовательности. Данные каждой последовательности хранятся в двух таблицах:

• таблица записей регистрации документов в последовательности,
• таблица границ последовательности.

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

Таблица 3.11.2. Блокировка данных при работе с последовательностями

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

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

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

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

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

3. Выгрузка сообщений обмена. Если для объекта (речь об объекте метаданных, например, Справочник.Номенклатура (целиком!)) включена регистрация изменений для обмена, к нему добавляется еще одна таблица: таблица регистрации изменений. Эта таблица всегда одна на каждый прикладной объект, для которого возможна регистрация изменений, вне зависимости от количества планов обмена, а также от того факта, имеем мы дело с распределенной базой или нет.

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

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

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

В завершение еще один очень важный момент. И у загрузки, и у выгрузки обычно (в типовых решениях – обязательно) есть параметр «Количество элементов в транзакции». Если речь не идет о совсем простых случаях, не рекомендуется ставить значение этого параметра равным 0, то есть вся выгрузка, как и вся загрузка, совершенно точно не должна проходить в одной транзакции. Значение этого параметра подбирается опытным путем, на практике нормально себя зарекомендовали значения от 1 до 100.

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

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

5. Набор записей регистра бухгалтерии. Если говорить только о записи в регистр бухгалтерии, следует отметить, что при прочих равных условиях скорость и параллельность записи в регистр бухгалтерии гораздо ниже, чем в регистры накопления. Например, при использовании бухгалтерского регистра работа по расчетам с покупателями возможна по одной организации только последовательная: есть всего два счета – 62.01 и 62.02, и вся запись идет в них.

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

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

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

Про нюансы перепроведения документов, связанные с разделением итогов, см. в разделе 3.9.

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

Нюансы работы, когда для регистра накопления разрешено и включено разделение итогов, полностью совпадают с аналогичными нюансами для регистра бухгалтерии, описанными выше, исключая наличие счета в регистрах накопления: разделитель перестанет увеличивать параллельность, если идет чтение остатков. Чтобы не получить взаимоблокировку, необходимо пользоваться свойством БлокироватьДляИзменения.

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

Отправить