Ускорение в 100 раз. Решаем проблему блокировок

Я являюсь автором и тренером курсов по оптимизации и повышению производительности в 1С. Большинство людей приходят ко мне на обучение, желая разобраться со своими проблемами, и я очень часто слышу от них: «эти блокировки замучили, достали, жизни нет, что делать – не знаем. Технологический журнал включали, галочки ставили, форумы читали – ничего не помогает».
Я уверен, что эта тема актуальна для многих из вас, поэтому в статье, не вдаваясь глубоко в подробности, я хочу вам дать некоторые конкретные рекомендации, которые вы сможете применить у себя и сразу получить ощутимый эффект. Например, если у вас запрос из-за блокировок выполняется 15 секунд, то после оптимизации он начнет выполняться за 15 миллисекунд. Это обычная практика, никакой фантастики – все это можно сделать.

Какие бывают блокировки в 1С?

 

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

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

Я думаю, вы прекрасно знаете, что в 1С есть два режима блокировок: автоматический и управляемый.

  • В автоматическом режиме все просто:
    • При любом чтении ставится S-блокировка.
    • А при любой записи ставится X-блокировка – причем, блокировки есть только на сервере СУБД, 1С никаких блокировок не ставит.
  • Гораздо больше интересен управляемый режим. Его главная особенность в том, что в 8.2 и в 8.3 блокировки работают по-разному.
    • Например, в 8.2 у вас любое чтение будет ставить S-блокировку. Причем, чтение – это не просто Запрос.Выполнить(), но и Ссылка.Реквизит, Ссылка.ПолучитьОбъект() и т.д. 
    • А в 8.3 без режима совместимости уже блокировок на чтение не будет. Таким образом, 8.3 безусловно выигрывает в плане параллельности работы.
    • Ну а дальше начинается самое интересное – например, для конструкции НаборЗаписей.Прочитать() в управляемом режиме 8.2 у вас будет S-блокировка на сервере СУБД (это естественно). Но кроме этого также будет разделяемая блокировка на сервере 1С, причем это проявляется и в 8.2, и в 8.3. И главная проблема в том, что эта разделяемая блокировка у вас будет длиться до конца транзакции – пока транзакция не закончится, данные будут блокированы.
      Поэтому рекомендация номер один – если набор записей вам нужен только для чтения, лучше использовать запрос, а не объектную модель. Тогда вы ничего блокировать не будете, а если и будете, то ненадолго.
    • Естественно, при любом изменении данных (запись, проведение, удаление) будет ставиться исключительная блокировка на сервере 1С и эксклюзивная на сервере СУБД.

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

 

Длительность блокировок в управляемом режиме

Самое главное при работе с блокировками – это помнить, что любая управляемая блокировка всегда будет держаться до конца транзакции, поэтому важно минимизировать ее длительность.

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

Что касается конструкции Запрос.Выполнить(), то если это 8.2, блокировка будет сниматься сразу после выполнения запроса, а если это 8.3 (либо в вашей СУБД MS SQL включен режим Read Committed Snapshot Isolation), тогда блокировки вообще не будет. Поэтому если у вас 8.2 или 8.3 в режиме совместимости с 8.2, я вам всячески рекомендую включить режим Read Committed Snapshot Isolation – у вас в любом случае повысится параллельность работы.

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

 

Наиболее частые причины блокировок

Запрос со сканом

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

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

Выключить режим совместимости? Правильнее сказать – перекреститься, создать копию, недельку потестировать и потом выключить, потому что если вы сразу выключите, у вас могут случиться «веселые выходные», а может быть не только выходные.

Еще один вариант – это включить режим версионирования для MS SQL Server. Сразу оговорюсь, что описанная ситуация возможна только в СУБД-блокировочнике, потому что если у вас СУБД-версионник, там этой ситуации быть не может. А если вы включаете Read Committed Snapshot Isolation, тогда у вас MS SQL начинает работать почти как версионник. И ваш запрос не будет блокировать строки.

В 1С нет «волшебной таблетки», но включение режима Read Committed Snapshot Isolation – ближайший аналог этой «волшебной таблетки». Вы минимальными действиями сразу резко сможете снизить количество ожиданий в вашей базе. Для этого вам всего лишь нужно выполнить несколько строк приведенным на скриншоте скриптом в MS SQL сервере, и вы сразу получите очень хорошее повышение параллельности работы. Конечно, это имеет смысл только для управляемого режима блокировок в конфигурации 1С. Для автоматического режима включать на сервере СУБД режим RCSI смысла нет.

 

Отсутствие режима разделения регистров

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

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

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

 

Перемещение границы последовательности при проведении

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

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

Длительные транзакции

Старайтесь делать максимально короткие транзакции:

  • Выносите всякие проверки и расчеты за пределы транзакции – любую запись, любое наложение блокировок надо делать в самом конце.
  • Ни в коем случае никаких диалоговых окон в транзакции делать не нужно, особенно, если используется толстый клиент. Мы сталкивались с такими случаями, что у бухгалтера при проведении документа выскакивало диалоговое окно с кнопками «Да» и «Нет». И пока она решит, что нажать, пока с кем-нибудь посоветуется, пока кому-то позвонит – у нее это окно будет висеть, и все это время транзакция будет активна, и, соответственно блокировка тоже будет активна – ее время будет очень долгим. Так делать не нужно.
  • Как можно еще ускорить время транзакции? Можно ускорить код, который там выполняется. Ускорить запросы, если вы это умеете делать. Это сразу даст резкий прирост производительности.
  • Еще один вариант – это ускорить запись в регистры. Как? Можно программным путем, а можно аппаратным. Например, если вы купили нормальные SSD-диски, то скорость записи у вас естественно вырастет – даже запросы станут выполняться быстрее. И, соответственно, время транзакции также уменьшится. Это не значит, что одним апгрейдом дисков можно решить проблему блокировок, но хотя бы можно сгладить этот эффект – он будет уже не так заметен.

 

Эскалация в многопоточном режиме

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

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

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

Когда обычно в 1С возникает эскалация? Чаще всего это какая-то тяжелая операция – закрытие месяца, расчет себестоимости и пр. – когда у вас в одной гигантской транзакции начинает проводиться много документов, блокируется вся таблица и в это время никто работать не может – параллельность падает. Такие операции необходимо учитывать отдельно и проводить их в нерабочее время, потому что в параллельном режиме вы их обработать не сможете.

Ошибка платформы – блокировка при использовании разделителя области данных

В платформе есть несколько ошибок, которые приводят к излишним ожиданиям на блокировке. Например, есть ошибка, которая меня очень удивила. Ситуация следующая – мы собрали данные об ожиданиях и увидели, что строка Запрос.Выполнить() накладывает управляемую исключительную блокировку, чего в принципе быть не может и не должно. Когда мы это увидели, мы подумали, что инструмент «сбоит». Еще раз загрузили данные. Все перепроверили. Действительно, накладывает. Оказалось, что такая ошибка появилась в платформе 8.3.6. При чтении – неважно, Запрос.Выполнить() или Константа.Прочитать() – вообще при любом чтении – платформа накладывала управляемую исключительную (Х) блокировку на поле, которое является разделителем данных и параллельность сразу падала. Причем, блокировка была именно исключительной.

Вот такая платформенная ошибка.

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

Ошибка платформы – скан индекса регистра расчета

Также мы часто сталкиваемся с ошибками платформы по работе с регистром расчета. С точки зрения производительности у него вообще проблем очень много, потому что регистр расчета – это единственный объект в 1С, который не имеет кластерного индекса. Поэтому, когда вы записываете в регистр расчета несколько сотен строк (если строк мало, то эта ошибка не воспроизводится), или чистите там движения (записываете туда пустой набор движений) – будет производиться скан индекса таблицы регистра расчета. А поскольку это запрос платформенный, вы его поправить никак не сможете, и, так как это – удаление (накладывается X блокировка), то включение режима Read Committed Snapshot тоже никак не меняет ситуацию.

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

Еще одна проблема регистра расчета проявляется при чтении и заключается в том, что платформенный запрос, который читает данные из регистра расчета, тоже сканирует индекс. Но здесь уже помогает именно включение либо Read Committed Snapshot, либо, если у вас 8.3, вы можете убрать режим совместимости с 8.2, тогда этой проблемы у вас уже не будет.

Ошибка платформы – невозможность параллельной записи в периодический независимый регистр сведений

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

Рекомендации

Какие можно дать рекомендации?

  • Во-первых, переходите на управляемый режим блокировок. Я думаю, это довольно очевидно, потому что если у вас используется автоматический режим, вы можете даже не удивляться вопросам «Почему у нас параллельность работы маленькая, почему много блокировок?»  Сначала перейдите на управляемый режим, и, если после этого у вас проблемы останутся, тогда уже можно будет дальше разбираться.
  • Когда перевели конфигурацию в управляемый режим блокировок, обязательно должен быть включен режим СУБД Read Committed Snapshot Isolation. Это прямо Must Have –сразу будет резкий прирост по параллельности работы.
  • Используйте разделитель итогов для регистров. Там, где нет контроля остатков, обязательно нужно включить, чтобы не было ожиданий.
  • И НаборЗаписей.Прочитать() – старайтесь вообще для чтения не использовать, потому что при этом будет наложена управляемая блокировка, которая будет «висеть» до конца транзакции. Зачем вам это нужно? Читайте данные запросом, и блокировок тогда вообще не будет, если у вас 8.3 без режима совместимости или включен режим Read Committed Snapshot.
  • По поводу границы последовательности – тоже постарайтесь принять по умолчанию, что границу двигать только регламентным заданием в нерабочее время. При проведении не двигать.
  • Большие транзакции делить на несколько. Чем проводить миллион документов в одной транзакции, лучше сделать мелкие транзакции по 100 документов, по 1000 документов – еще лучше, если в многопоточном режиме. Это будет более стабильно.
  • Всякие расчеты, проверки и пр. делайте за пределами транзакции. Время транзакции должно быть минимальным, как можно меньше.

Пример решения проблемы блокировок

Как еще можно избавиться от излишних ожиданий?

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

Как этого можно избежать? Можно при загрузке документы создавать, но не проводить, а потом написать механизм, который, например, реализует это дальнейшее проведение в многопоточном режиме, где каждый поток будет проводить документы по своему складу. Разнести, таким образом, эти процессы во времени: первый поток проводит документы по одному складу, второй поток – по второму складу и т.д. Тогда проблема будет решена.

Блокировки и оборудование

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

Как влияет на оборудование оптимизация блокировок? Например, вы с автоматического режима перешли на управляемый, или взяли и включили Read Committed Snapshot. Пока система ждет, она оборудование не использует и оно у вас в этом случае простаивает. А как только у вас система заработала на полную мощность, ожиданий нет, у вас сразу идет резкий прирост, резкая нагрузка на оборудование. И, в зависимости от того, в каком состоянии оно у вас на данный момент находится, это может быть критично. Например, если сервер у вас был загружен на 80%, а вы еще и блокировки свои устранили, он вообще может «лечь». Это обязательно нужно учитывать.

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

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

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

Это обработка «Текущие блокировки MS SQL Server и 1С» – она показывает вам, кто заблокировал, что заблокировал, какие конкретно данные именно в терминах 1С. Я эту обработку недавно выложил на Инфостарт – можете ее скачать, посмотреть.

Здесь – открываете, заполняете настройки.

Если хотите увидеть блокировки 1С, включаете флаг «Отображать блокировки 1С» — у вас в течение одной минуты должен включиться технологический журнал. И после этого, когда минута прошла – вы сможете увидеть, какие именно блокировки у вас наложены в базе данных на текущий момент(например, в момент, когда вы встанете на точке останова после строки Движения.Записать() и пытаетесь провести два документа, которые пересекаются по данным – и в первом и во втором документе используется один и тот же товар).

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

Как эту ситуацию отображает обработка? Она показывает, что пользователь Петров заблокирован пользователем Администратор. И при этом вы можете увидеть, что именно заблокировал Администратор и что именно заблокировал Петров.

Нежирным шрифтом показаны блокировки СУБД – можно увидеть, в какой таблице, в каком индексе, какой состав индекса, какой статус блокировки («установлена» или «ожидание»).

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

Жирным шрифтом отображаются блокировки 1С – также можно поглядеть, что именно было заблокировано.

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

***************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 DEVELOPER. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.

34 Comments

  1. kolya_tlt

    спасибо, еще раз освежил в памяти

    Reply
  2. orefkov

    Насколько я понял, бОльший упор делается на специфику работы именно MS-SQL?

    Очень хотелось бы подобной инфы/сравнения с «честными» СУБД-версионниками — Postgres, Oracle.

    Даже sqlite — там и то читатели и писатель никак не мешают друг-другу (в WAL-режиме).

    Reply
  3. KazanKokos

    Начал читать. Очень интересно.

    Reply
  4. orefkov
    Всякие расчеты, проверки и пр. делайте за пределами транзакции

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

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

    А если уж выносить такие расчёты за транзакцию, то в её конце надо проверять, что расчёты остались верными.

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

    Поэтому есть еще и такой метод выполнения — сначала вне транзакции вычисляется сколько откуда списывать, потом в транзакции делается запись вычисленного и проверка, что ни по складам/партиям не «улетели в минус». Если улетели — отмена транзакции и всё по новой.

    Reply
  5. headMade

    Объясните пожалуйста зачем включать SNAPSHOT_ISOLATION ?

    Ведь 8.3 включает только READ_COMMITTED_SNAPSHOT

    Спасибо.

    Reply
  6. lefthander

    Спасибо, приятное дополнение к курсу Ускорение и оптимизация систем на 1С:Предприятие 8.3

    Reply
  7. asved.ru

    Картинка — пять баллов!

    Reply
  8. ZLENKO

    Хорошая полезная статья. Автору плюс.

    Reply
  9. nvv1970
    переходите на управляемый режим блокировок.

    Вот меня пугает такое пожелание… Что значит «переходите»? Ща все попереключают конфигурации с авто на упр… И что? И все?

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

    Как правило проблемы возникают на старых конфигурациях с автоматическими блокировками и очисткой движений в документах в начале проведения. В 99% проблем именно такие проекты ищут решения своих проблем в подобных статьях. И вроде все правильно сказано в статье, а приложить ее не к чему. И складывается у заказчика впечатление, что заветная зеленая кнопка где-то есть. И объяснить, что кроме оптимизации переписывать нужно код в проведении документов и прочих транзакциях, порой трудно. А заикаться, что внедренный тобой же много лет назад проект на основе типовой конфигурации по сегодняшним меркам не имеет права на жизнь, что «тогда 1с так писала» и на 100-300 юзеров (24/7) эта конфа не рассчитана (а только на 50 редко нажимающих кнопочки бабушек и т.п.), вообще запрещено…

    Reply
  10. kolya_tlt

    (9) напишите статью как перейти и автор сделает ссылку на вашу статейку 🙂

    Reply
  11. sank84

    Спасибо за статью!

    Reply
  12. iskdv

    «Например, если у вас запрос из-за блокировок выполняется 15 секунд, то после оптимизации он начнет выполняться за 15 миллисекунд.» — т.е. мне покажут как писать правильные запросы? ага «щаз»! мне опишут проблемы, скажут «нельзя просто так взять и оптимизировать»(гы…гы.. с картинкой) и предолжат скачать программу. и все это со мной проделает специалист аж 65 звездами. охренеть

    Reply
  13. DarkAn

    (12)

    т.е. мне покажут как писать правильные запросы?

    именно так! Программу никто не предложит скачать. Андрей не нуждается в рекламе. Многие его знают как высококвалифицированного специалиста и лектора. Он ведет курсы на и на сколько я знаю на gilev.ru. То что рассказано в курсе в разы (В РАЗЫ!!!) превосходит, то что показано тут. Тут так — краткая шпаргалка :). (Например методичка второй редакции — 360 страниц)

    Я прошел два курса по оптимизации на и не жалею. Там рассказано реально очень многое, на многие вещи начинаешь смотреть совсем по другому. Если раньше накидаешь измерений в регистр — «и так сойдет», теперь раз 20 подумаешь как лучше. Подумаешь, что индексировать, а что нет и еще очень, очень многое 🙂

    Reply
  14. tata_1211

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

    Reply
  15. Fatov_DI

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

    Reply
  16. iskdv

    (13) нет, вы не подумайте ничего дурного, я просто восхищен тем как виртуозно «высококвалифицированный специалист и лектор» съезжает с темы анонсированной вначале статьи.

    (14) «Мышление совершенно изменилось при написании кода» — и теперь мы «Периодически и в стандартных конфигурациях переписываем запросы»

    Reply
  17. DarkAn

    (16)

    съезжает с темы анонсированной вначале статьи.

    Не совсем понял о чем речь? Андрей достаточно нюансов рассказал, что может являться проблемой при работе с базой и даже частично подсказал как их решать. На курсах, он показывает все проблемы в действии, и объясняет способы их устранения.

    (16)

    и теперь мы «Периодически и в стандартных конфигурациях переписываем запросы»

    В этом вообще нет ни чего зазорного. Если вы привыкли работать на типовых, в базах где сидит 10 пользователей и 100 документов в месяц — да можно остаться и при типовом функционале. А если у пользователей 300+ и надо думать как все ускорить, то тут приходиться идти на компромиссы, либо чуток сложнее обновлять (и то не всегда — старые запросы 1С не правит уже очень давно и скорее всего не поправит) или заставлять пользователей постоянно видеть сообщение о невозможности захвата таблицы — блокировка.

    Как вариант могу сказать следующее — благодаря информации полученной на курсах мне удалось реализовать восстановление последовательности партий в УПП 1.3 (не РАУЗ) с 4,5 часов до 15-20 мин (режим совместимости 8.2). А для получения такого результата типовой функционал поправился «незначительно» в объеме кода, и да еще пришлось полностью переписать 3 типовых запроса. (если интересно — все описано тут http://infostart.ru/public/626117/)

    Reply
  18. Painted
    регистр расчета – это единственный объект в 1С, который не имеет кластерного индекса.

    Есть какая-то причина этого? Почему 1С для регистров расчета делает исключение?

    Reply
  19. Serg O.

    Да, очень кратко и доступно… Андрей снова открывает нам глаза…

    Очевидные вроде вещи, и вроде все об этом знают… Но на практике не знают Как это устроено и как этим пользоваться…

    Статья заставит некоторых копать глубже… Profiller SQL и тех.журнал покопать… Gilev.ru инструменты подключить наконец то… А не ныть…

    Про другие БД — их менее 10-15% по России в 2016 году было…

    Так что знать про SQL Server «настоящему» 1с-нику нужно обязательно

    Автору — Большое Спасибо

    Reply
  20. Serg O.

    Параллельность — это очень крутая штука… У меня лично для прайсов «всем» клиентам заточена обработка в 10 потоков… И если раньше 1 прайс выгружался 20-30 сек… То теперь почти в 10 раз быстрее 3-3,5 сек

    Единственный минус фоновых обработок — ключ лицензии отжирается… Иеще… Рост нелинейный… Что 10 что 20 потоков… Более 12x у меня не получилось

    Поэтому в 100 потоков … Нет смысла делать…

    И НЕ Надо доп.ключ на эти самые 100 лицензий…

    Reply
  21. Serg O.

    Еще одной из причин массовых блокировок — являются всякие там обмены! Обмен с бухгалтерией, с ЗУПом, выгрузка на сайт каждые 5-10 мин… Все они читают план обмена… А каждый документ/обьект туда пишется постоянно… И чтение ждет… И тормозит… И может не успеть выгрузиться даже за 5-10 мин…

    Обратные загрузки (запись) из сторонних систем к себе — еще хуже… Например каждое утро бухгалтер грузит платежки из банка….

    Там одинаковые движения сплошь и рядом… Плюс пользователи «попадают» на ожидание 20 сек…

    Регламентные задания надо расписание прописывать аккуратно… Лучше нарисовать… С учетом продолжительности каждого задания…

    У нас так попадало на 11-00 сразу 4 тяжелых задания одновременно… И все пользователи зависали на 20 и более сек… Неудовольствие 1 раз в день, а говорят потом, что это постоянно программа висит…

    Развели регл.задания на 10-15 мин начало сдвинули и конец установили и сразу стало легче

    Reply
  22. DarkAn

    (20)

    Единственный минус фоновых обработок — ключ лицензии отжирается… Иеще… Рост нелинейный… Что 10 что 20 потоков… Более 12x у меня не получилось

    Поэтому в 100 потоков … Нет смысла делать…

    Тут есть пара нюансов 🙂

    Просто, для получения ощутимого результата с большим количеством потоков их надо уже добавлять не по 1,2, а по 10, 100 и т.д связано с «хвостами», например, есть 40 операций, каждая выполняется по 1сек, в 1 поток выполнение займет 40 сек, в 2 потока — 20 сек, в 3 потока — 14 сек, при этом 2 из 3 потоков справятся со своей частью за 13 сек, и останется еще одна задача (13*3 = 39; 40-39=1) и этой одной задачей будет занят 1 поток он и продлит выполнение на 1 сек. Если продолжить, то на 8-9 (дельта 2) потоках выполнение займет 5 сек, на 10-13 (дельта 4) потоках — 4 сек, на 14-19 (дельта 6) — 3 сек, на 20-39 (дельта 20) — 2 сек. на 40-inf (дельта inf) — 1 сек. Ну это утрировано — не учитывая накладные на распараллеливание.

    Простая формула в Excel: КоэфКратностиВремени = ОКРУГЛВВЕРХ(КоличествоОперация / КоличествоПотоков; 0)

    (20)

    НЕ Надо доп.ключ на эти самые 100 лицензий…

    Иногда потратить 100 лицензий на 1 час выгоднее, чем 1 лицензию держать 100 часов, например, ночью. Все зависит от задачи 🙂

    Reply
  23. Serg O.

    (22)

    Простая формула в Excel: КоэфКратностиВремени = ОКРУГЛВВЕРХ(КоличествоОперация / КоличествоПотоков; 0)

    вот так как раз и не получается… у меня прайсы клиентов независимые друг от друга… (т.к. чтение х чтение — не блокируется) и 4000 клиентов в 10 потоков выгружаются ночью естественно примерно за 3 часа… т.е. можем до 8 — 10 тыс. спокойно выгружать… за ночь

    увеличение числа потоков в 2 раза (до 20) — дало прирост всего в 15 мин (8-10%)…

    а не в 2 раза…как по этой формуле.

    Так что именно «накладные расходы» — при числе потоков более 10 уже очень сильно «взаимотормозят» друг друга…

    до 100 не пробовал… на можно как-нить проверю… думаю тогда будет максимум раза в 2-3 быстрее чем сейчас — до 1-2 часов сократится…

    когда число клиентов вырастит до 100 тыс… может тогда понадобится такая супер-много-поточность

    Reply
  24. DarkAn

    (23)

    увеличение числа потоков в 2 раза (до 20) — дало прирост всего в 15 мин (8-10%)…

    Я писал формулу для простого варианта — когда время КАЖДОЙ операции одинаково.

    (23)

    увеличение числа потоков в 2 раза (до 20) — дало прирост всего в 15 мин (8-10%)…

    Обычно при увеличении в 2 раза (с 1 потока в 2) — прирост обычно 2х.

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

    * Одинаковые ли прайсы формируются для клиентов (может одному на 100тыс. записей, а остальным на 10 записей. тогда время будет определяться самым медленным потоком)

    * может дисковая подсиситема не справляется с записью файлов

    * может почта «тупит»

    Reply
  25. axelrich

    8.3.10.2252 Выдало такую ошибку:

    {ВнешняяОбработка.Блокировки_MS_SQL_Server_1С.МодульОбъекта(1033,12)}: Процедура или функция с указанным именем не определена (ПолучитьТаблицуДанныхПоСтрокеSQL)
    Возврат <<?>>ПолучитьТаблицуДанныхПоСтрокеSQL(СтруктураПараметров);
    {ВнешняяОбработка.Блокировки_MS_SQL_Server_1С.МодульОбъекта(1035,12)}: Процедура или функция с указанным именем не определена (ПолучитьТаблицуДанныхПоСтраницеSQL)
    Возврат <<?>>ПолучитьТаблицуДанныхПоСтраницеSQL(СтруктураПараметров);
    {ВнешняяОбработка.Блокировки_MS_SQL_Server_1С.МодульОбъекта(1603,17)}: Процедура или функция с указанным именем не определена (ПолучитьТаблицуЛоговТЖ)
    ТаблицаЛогов = <<?>>ПолучитьТаблицуЛоговТЖ();
    Reply
  26. Yashazz

    Вопрос к уважаемому гуру: транзакция распространяется на фоновое задание, вызванное из неё? Если я вызываю выполнение фонового задания из обработки проведения, а потом транзакция откатывается, проведение не выполняется, то выполнится ли запись данных (допустим, лога действий) в некий регистр сведений, вызываемая в рамках фонового задания?

    Reply
  27. Yashazz
    То что рассказано в курсе в разы (В РАЗЫ!!!) превосходит, то что показано тут. Тут так — краткая шпаргалка :). (Например методичка второй редакции — 360 страниц)

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

    Если человек действительно хочет поделиться знаниями, то он нормальную статью делает или ссылку на книгу выкладывает. А не вот такую мини-презентацию того, что уже на ИС другие писали, что в общедоступных книгах есть, итд. Стоит начать задавать конкретные вопросы — и в ответ от уважаемых гуру будет тишина, потому что они «выше этого» и «в рекламе не нуждаются». Ага.

    «Поскольку у регистра расчета нет кластерного индекса (там есть только некластерный), пришлось этот некластерный индекс деактивировать и создать аналогичный, но кластерный»

    Подробности в студию) Это вы скуль напрямую мутили, лицензионное соглашение 1С нарушали?

    Хотя, кому-то «Андрей снова открывает нам глаза…» — кому-то и такой материал в откровение)))

    Reply
  28. mickey.1cx

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

    Reply
  29. kolya_tlt

    (4) понятное дело, что тут надо включить голову. из практики, имеется пример, где в рознице мы проверяли остатки до транзакции и во время. так как ошибка остатков — была самая распространенная среди продавцов розницы.

    Reply
  30. mmch

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

    Reply
  31. Blackspb
    При чтении – неважно, Запрос.Выполнить() или Константа.Прочитать() – вообще при любом чтении – платформа накладывала управляемую исключительную (Х) блокировку на поле, которое является разделителем данных и параллельность сразу падала.

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

    Reply
  32. KAV2

    (9)

    появятся дедлоки…

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

    Reply
  33. nvv1970

    (32) все верно, вероятность снижается. Я не точно выразился.

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

    Есть мнение, что смешанный режим «Авто+Упр» лучше не использовать вообще. Как человек прошедший на крупном проекте 8.2 через него — соглашусь с этим мнением. Проще сразу на УПР и по ходу дорабатывать. Очень экономит время.

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

    Reply
  34. user642047_ziborov.roman

    Кто-нибудь знает, по какой причине может зависать наглухо 1С на следующей строке (52)?

    Соединение = Новый COMОбъект(«ADODB.Connection»)

    Это происходит при нажатии кнопки «Протестировать подключение» из формы настроек подключения.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *