Простое программное решение проблем с блокировками SQL
База данных - HighLoad оптимизация
О блокировках, причинах их возникновения и решениях этой проблемы информации очень много, поэтому просто опишу одно из программных решений, которое реально помогло полностью исключить блокировки по номенклатуре при проведении документов в крупной информационной системе. Метод подходит только для клиент-серверных систем 1С. Протестировано на платформе 1С:Предприятие 8.2 (8.2.19.130), обычные формы.
Решение для случая блокировок по номенклатуре:
1. Добавить новый служебный регистр сведений "БлокировкаПроведенияДокументов". Он не будет содержать данных и необходим только как объект наложения управляемой блокировки. Добавить полные права на этот регистр в общедоступную роль.
2. В начало процедуры "ПриЗаписи" модуля проблемного документа добавить код:
Процедура ПриЗаписи(Отказ)
Если Проведен Тогда
Попытка
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрСведений.БлокировкаПроведенияДокументов");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = ТабличнаяЧастьНоменклатура;
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Номенклатура", "Номенклатура");
Блокировка.Заблокировать();
Исключение
# Если Клиент Тогда
Сообщить(СокрЛП(Ссылка) +":"+ Символы.ПС + " Превышено время ожидания возможности проведения! Повторите попытку проведения.");
# КонецЕсли
Отказ = Истина;
Возврат;
КонецПопытки;
КонецЕсли;
//Исходный текст
//...
КонецПроцедуры
При возникновении блокировок по полям другого типа, необходимо в регистр "БлокировкаПроведенияДокументов" добавить новое измерение соответствующего типа и в процедуре "ПриЗаписи" указать соответствующий источник данных для элемента блокировки.
Всем удачи!
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
HighLoad оптимизация Разработчик 1С 8.3 1С:ERP Управление предприятием 2 Бесплатно (free)
Использование оператора «В» для полей или данных составного типа (например, Регистратор) может приводить к неочевидным проблемам.
10.11.2025 15969 ivanov660 48
HighLoad оптимизация Разработчик 1С:Предприятие 8 1C:ERP Бесплатно (free)
Приведем примеры использования различных в динамических списках и посмотрим, почему это плохо.
18.02.2025 16546 ivanov660 39
HighLoad оптимизация Системный администратор Разработчик 1C:ERP Бесплатно (free)
Не всегда индексирование с дополнительным упорядочиванием полезно.
04.02.2025 15181 ivanov660 21
HighLoad оптимизация Разработчик Россия Бесплатно (free)
А вы знали, что сервер 1С при соединении с базой на сервере PostgreSQL самостоятельно устанавливает некоторые параметры? Это важно знать при настройке сервера и отладке долгих запросов. Предлагаю разобраться.
27.08.2024 10467 soulner 10
HighLoad оптимизация Технологический журнал Системный администратор Разработчик Бесплатно (free)
Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.
24.06.2024 19207 ivanov660 13
HighLoad оптимизация Разработчик 1С:Предприятие 8 Бесплатно (free)
Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.
06.06.2024 25059 Evg-Lylyk 73
HighLoad оптимизация Механизмы платформы 1С Системный администратор Разработчик Стажер 1С:Предприятие 8 Бесплатно (free)
Сравним «Регистры сведений» с «Сервисами интеграции» и узнаем, кто быстрее!
28.03.2024 14696 dsdred 27
HighLoad оптимизация Разработчик 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free)
Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.
13.03.2024 14675 spyke 29
)
По моему там тоже удивлялись такому костылю.
Возможно конечно и толковому, но в статье нет всех исходных данных чтобы это осознать.
Да в принципе можно и не искать а в этом же самом месте поставить блокировку на справочник номенклатуры
И будет то же самое
И будет то же самое
О!
На мой взгляд здесь присутствует некоторый скрытый эффект, который всплывет в будущем при сопровождении системы. Не сразу разработчикам может быть понятно что же там происходит.
Плюс это явно искуственное узкое место в системе. Возможно стоит посмотреть в сторону формирования движений в фоне. А если нужно контролиовать остатки по номенклатуре, то посмотреть в сторону резервирования и использовать этот регистр для блокировки.
Вообщем, решение выглядит как временный костыль :)
Условия работы предприятия на котором это протестировано:
- Круглосуточный режим работы: производство, торговля;
- Размер свернутой рабочей БД - более 400ГБ;
- Средний поток документов движения товаров - более 20 документов в минуту.
- Высокий уровень контроля на уровне программы: обязательный контроль остатков, качества и пр.
- Высокая частота повторений номенклатурных позиций в документах товародвижения;
- Пересечение 3-х высоконагруженных участков:
1. Центр приема заказов - резервирование товаров;
2. Участок производства(уровень автоматизации цехов на базе 1С более 80%) - выпуск продукции, поступление на склад;
3. Участок конвейерной сборки и комплектации на складе(20 АРМ) - перемещение, реализация товаров.
- программные модули товародвижения предельно оптимизированы, отдел программирования 1С - 7 человек.
До внедрения этого "костыля" была подключена система гибких блокировок от Softpoint, без нее программа не работала.
После внедрения "костыля" программа заработала без гибких блокировок.
В свое время когда то давно размышлял о покупке этой системы, но в конце концов перевел базу на управляемые блокировки, включил снапшоты, оптимизировал узкие места и про блокировки забыл.
Если нет понимания причин, нет рассуждения автора то материал который вы предоставили нужен только для галочки, т.к. большая часть читающих сходу не поймет всех нюансов и переключиться на публикации, которые раскрывают суть проблемы.
А насчет решения - сложную систему не всегда можно починить простым методом
Решение в лоб может принести проблему, но затянутую во времени. т.е. это не решение а оттягивание.
Ну талмуты расписывать никто не просит, можно было и просто пару комментариев. Такое ощущение вы не вникали в суть этих блокировок, тыкнули пальцем и попали, а теперь хотите поделиться решением, вместо того чтобы отловить реальную проблему. Как именно ваше решение помогает избежать конфликта блокировок можете сказать ?Накладывает их заранее ? Можете сказать одну из вероятных причин ваших блокировок ? Может не это ваше решение решило проблемы, иногда события просто совпадают, допустим кто-то ошибку исправляет или оптимизирует код, приблизительно в это же время и вы накидали это. Раз вы скрин копировали откуда-то, то возникает вопрос - были взаимоблокировки или блокировки ?
"переключиться на публикации, которые раскрывают суть проблемы". Ну а после этого - добро пожаловать!
Хорошо, что в свое время, когда на заре разбирания с упр. блокировками такое не придумал, а сделал все по "фен-шую".
В сертификации на профа по тех. вопросам есть такое выражение, как "заметание грязи под ковер".
Так вот мне думается, что это подобное решение.
Узкие места в системе никуда не делись, просто добавили некую упреждающую блокировку.
Это решение ВОЗМОЖНО (!) имеет право на существование, когда идет более детальный разбор, а это времянка, но оставлять такое в продакшене….я бы своих порешил )
Поэтому во времена крепостного права ценились крестьянки, которые тратят минимум материала на изнанку и максимум на рисунок изделия. Есть такой шов "козлик". Простите за офф.
ЦУП + ТЖ + профайлер.
Пробовали в демо-режиме PerfMonitor от Софтпоинта - интересная программка, но каких конских денег она стоит, это вообще нечто и эти деньги надо платить каждый год...послали лесом. Это единственное стороннее ПО, которое пробовали ради интереса.
Это решение имеет эффект бомбы замедленного действия, ИМХО. Можно говнокодить и вроде как все хорошо...но нет.
Чисто ИМХО. Я б не стал.
Большинство обходится без них. Я думаю, такие и придумывают простые решения, вроде представленной в публикации.
Чтобы вы делали без ЦУПа, оставшись один-на-один с базой?
Большинство проблем решается визуальным анализом кода.
Но, бывают ситуации, когда визуальный анализ не помогает, для это есть вышеназванные инструменты.
Так вот, что касается недоступности пути....это больше похоже на нежелание разбираться в инструментах.
Кому он недоступен и по каким причинам ?
А они видятся следующие:
1. Просто тупая лень, когда чел ходит на работу протирать штаны и получать ЗП.
2. На предприятии не могут дать доступ к оснастке сервера и все что у тебя есть - это конфигуратор. Такое часто бывает на предприятиях оборонного значения.
3. Программист пока не знает об инструментах. Есть у меня такой знакомый, в глубинке на заводе работает. Я ему скилл прокачал.
Регистр - лишний объект. Блокируйте элементы несущего справочника.
Если исходить из крайне скупого описания в публикации и комментариях, то такое решение вообще не имеет права на существование.
Проблема не решена 100%. Блокировки ушли, если ушли, совершенно по другой причине.
Такой сюрприз может выпить очень много крови из 1С-ов, которые потом будут разбираться с ситуацией, когда система встанет колом.
Ещё раз повторюсь - без описание проблемы крайне сложно оценить решение...
Без обид.
1. Действительно ли проблема на блокировках СУБД?
2. Если действительно на СУБД, то как до этого дело дошло при управляемом режиме?
3. Если проблема не на уровне СУБД, то от чего нельзя было решить имеющимся средствами, без создания "вспомогательного" элемента?
4. Каким вообще образом было выяснено, что всему виной номенклатура?
Причины возникновения проблем с блокировками конкретном частном случае:
1.Необратимое изменение типовой УПП в процессе перехода с 1С V77 на 82, связанное с переносом множества алгоритмов из V7 и серьезной доработкой конфигурации в течение многих лет разными специалистами. Глобальная автоматизация производственных процессов на базе этой конфигурации.
2.Одновременное проведение любых из 7 видов документов по 5 основным регистрам остатков в произвольной последовательности.
3.Высокий поток документов движения товаров - более 20 документов в минуту.
4.Присутствие нескольких номенклатур, присутствующих в большинстве документов - как следствие частые конфликты при попытке изменения итогов регистров.
5.Регистры, в которые записываются движения, имеют большой размер - десятки миллионов строк и более.
Я не считаю непосредственное возникновение блокировок ошибкой. Это вполне нормальное, естественное и необходимое условие корректной записи информации при столь нагруженном режиме работы. Я считаю ошибкой вызванный блокировками непредсказуемый массовый вылет сессий 1С с потерей текущих рабочих данных и необходимостью перезапуска 1С и повторной инициализации автоматизированных рабочих мест.
Почему используется пустой служебный регистр? - потому, что наложить управляемую блокировку на 1 пустой регистр, более оптимально и безопасно, чем накладывать управляемые блокировки на 5 основных регистров хранения данных с миллионами записей.
Почему не используется разделение итогов и режим версионирования MS SQL? - по причине условия обязательного и строгого контроля остатков по сложным алгоритмам.
Большое всем спасибо за попытки анализа и обсуждение, но мне известны абсолютно все тонкости и причины возникновения проблемы в описанной информационной системе.
Без всяких сомнений, данная проблема может быть решена глобальным перестроением алгоритмов работы программы с переводом ее на новую платформу 1С (минимум год на разработку, установку, заполнение данными, переписывание сотни производственных и торговых отчетов, создание и настройку новой схемы обменов - в системе более 40 связанных информационных баз), специалисты по администрированию предложат немало проектов по замене и настройке оборудования. В принципе, можно найти массу решений стоимостью в миллионы или, что более вероятно, в десятки миллионов. Вот только зачем, если проблема решается практически бесплатно за 5 минут с помощью 16 строк абсолютно типового кода?
Т.е. в условиях автора его можно заменить блокировкой одного предопределенного элемента справочника без потери производительности?
Блокировать элементы справочника номенклатура наверное можно как предлагали, но тогда редактировать сам справочник станет затруднительно.
В тему управляемых блокировок может кто знает. Как влияет режим совместимости + версия платформы на производительность: имеется сильно переписанная УТ 8.0 в режиме совместимости 8.2 и платформа 8.3.11. Есть ли смысл увеличивать релиз платформы вместо переработки конфигурации для повышения версии режима совместимости?
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1016138
Создание 06.03.19 10:12
Обновление 06.03.19 10:12
Просмотры 11686
Загрузки 0
Рейтинг
18
Комментарии 38
Код открыт Да
Рубрики HighLoad оптимизация
Кому
Системный администратор
,
Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)