Как определить уровень изоляции запроса?

Публикация № 621599

Администрирование - Производительность и оптимизация (HighLoad)

Блокировки уровень изоляции Profiler Read Committed Serializable конфликт блокировок при выполнении транзакции SQL Server Сервер 1С SET READ_COMMITTED_SNAPSHOT ON SET ALLOW_SNAPSHOT_ISOLATION ON

Как с помощью Profiler определить уровень изоляции запроса и зачем это нужно

Этот вопрос возник у нас на проекте по внедрению ЗУП2.5 с численностью 20000 и максимальным количеством одновременных пользовательских сессий 200.

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

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

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

Представим такую ситуацию – есть два документа «Начисление зарплаты сотрудникам организаций», в которых указан одинаковый налоговый период, а на закладке НДФЛ указаны одинаковые физлица. Гипотетически допустим, что расчет и проведение следуют один за другим в одной транзакции. Рассмотрим случай, когда блокировка вообще отсутствует. Если последовательно запускать расчет и проведение сначала одного, а затем другого документа, то в первом сумма НДФЛ посчитается правильно, а во втором будет равна нулю, т.к. расчетный и фактически начисленный НДФЛ на момент проведения второго документа будут совпадать. Но если обрабатывать эти документы параллельно, то они одновременно начислят НДФЛ, не подозревая о существовании друг друга, и в результате налог удвоится. Но если блокировка настроена верно, то первый документ успеет раньше прочитать и заблокировать данные о фактически начисленном налоге в регистре «НДФЛ расчеты с бюджетом» по сотруднику Пушкину А.С. Из этого запроса будет видно, что фактический налог за январь пока не начислялся и значит надо его рассчитать и выполнить движение по регистру. Блокировка будет отпущена только после завершения записи в регистре. Второй документ, дойдя до запроса чтения фактически начисленного налога будет поставлен системой на ожидание до тех пор, пока первый документ не закончит транзакцию проведения, после чего он прочитает в запросе, что налог уже начислен и поймет, что расчет выполнять не надо. Это необходимая блокировка.

Конечно, этот пример притянут за уши для простоты объяснения. На самом деле логика ЗУП 2.5 такова, что для задвоения НДФЛ пользователям не нужно прикладывать особых усилий. НДФЛ рассчитывается до проведения документа, а при проведении содержимое табличной части просто заносится в регистры без всякой проверки. Пользователям между расчетом и проведением предоставляется возможность посмотреть будущий результат и при необходимости поправить руками. Конечно это большой плюс в пользу гибкости ЗУПа, но предъявляет высокие требования к профессиональному уровню расчетчиков. Поэтому вопрос предотвращения задвоения НДФЛ решается организационным путем или с помощью дополнительных проверочных отчетов. Конечно, в ЗУП2.5 есть регистры, которые рассчитываются и записываются одновременно при проведении документа, например «НДФЛ к зачету», но этот пример пришлось бы дольше объяснять ;).

А теперь представим другую ситуацию. При проведении документа выполняется запрос, который должен отобрать документы, в которых присутствуют сотрудники из этого документа. Но запрос написан так, что сервер SQL вынужден находить нужные документы методом перебора. Для эксперта по технологическим вопросам это означает, что вместо INDEX SEEK выполняется TABLE SCAN, т.е. вместо поиска по таблице индексов происходит последовательный перебор записей в самой таблице. Причем в процессе перебора блокируются все записи, к которым прикоснулся запрос, даже те, в которых отсутствуют искомые сотрудники. И эта блокировка будет действовать до конца завершения проведения документа, что будет препятствовать параллельному проведению документов с другими сотрудниками. Это избыточная блокировка.

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

Теперь немного теории про уровни изоляции на SQL сервере:

  1. В автоматическом режиме в транзакциях используется уровень изоляции SERIALIZABLE. Этот уровень накладывает на таблицы с данными блокировку типа S (запрещает запись и проверяет нет ли в этот момент параллельных записей) до конца транзакции на все данные, которых коснулись запросы, и блокировку типа X (запрещает чтение и запись)  на все данные, по которым произошла запись. На таблицы индексов также до конца транзакции накладываются блокировки типа RangeS в запросах, и RangeX при записи.
  2. В управляемом режиме в транзакциях используется уровень изоляции READ COMMITTED. Этот уровень на записанные данные также устанавливает блокировку типа X до конца транзакции. Но при выполнении запросов на данные накладывает блокировку типа S, а при завершении запроса блокировка снимается не дожидаясь завершения транзакции. На таблицы индексов никаких блокировок не накладывается.
  3. Если база данных переведена в режим READ COMMITTED SNAPSHOT, то в управляемом режиме при чтении данных не накладывается блокировка типа S, есть только блокировка типа X при записи.

Тоже самое чуть более подробно в таблице:

Транзакция

Уровень изоляции

Действие

Блокировка

Вне транзакции

READ UNCOMMITTED

Чтение

-

Управляемая транзакция

READ COMMITTED SNAPSHOT

Чтение

-

Запись

X

READ COMMITTED

Чтение

S (запрос)

Запись

X

Автоматическая транзакция

REPEATABLE READ

Чтение объектов

S

Чтение объектов «Для изменения»

U

Запись объектов

X

SERIALIZABLE

Чтение регистров

S, RangeS

Чтение регистров «Для изменения»

U, RangeU

Запись регистров

X, RangeX

Обычно лечение начинают с понижения уровня изоляции, т.к. это не особо трудозатратно и дает быстрый эффект. Достаточно перевести конфигурацию из «Автоматического» режима управления блокировкой данных в «Управляемый», и транзакции начнут выполняться на уровне изоляции типа READ COMMITTED, вместо SERIALIZABLE или REPEATABLE READ.

Чтобы переключить базу данных в режим READ COMMITTED SNAPSHOT (RCSI) необходимо в «SQL Server Management Studio» в свойствах базы данных установить параметр "Is Read Committed Snapshot On" в значение "True":

В некоторых источниках предлагают установить параметр "Allow Snapshot Isolation" в значение "True", но в этом нет необходимости, т.к. это приведет к включению другого режима изоляции SNAPSHOT, который не поддерживается платформой 1С (На момент написания статьи релиз платформы 8.3.9).

Режим управления блокировкой данных задается для неявных транзакций, которые выполняются при записи или при проведении документов, т.е. внутри  предопределенных процедур типа ПриЗаписи() или ОбработкаПроведения(). Но большинство «тяжелых» вычислений в типовой конфигурации ЗУП2.5 происходит при выполнении команды «Рассчитать». При этом в модуле объекта запускается процедура РассчитатьВсе(), внутри которой неоднократно повторяется конструкция НачатьТранзакцию() …ЗафиксироватьТранзакцию(). Это явно указанные транзакции, внутри которых происходит запись и очистка регистров, выполняются запросы. Нам необходимо убедиться, что при переключении конфигурации в управляемый режим в процедуре «РассчитатьВсе()» явно указанные транзакции также начинают выполняться на уровне READ COMMITTED.

Для этого проведем небольшой эксперимент:

  • Запустим SQL Server Profiler.
  • Запустим «NEW TRACE».
  • Выполним подключение к серверу SQL.
  • В окне «Trace Properties» на закладке «General» выберем «Use the template» = «Blank», а на закладке «Events Selections» раскроем группу «Stored Procedures» и выберем «RPC:Complited». По кнопке «Column Filters» укажем имя базы и длительность выполнения запросов более 1.

  • Кнопку RUN пока нажимать не будем, т.к. нам надо сначала запустить базу данных в режиме отладки и остановить выполнение расчета документа «Начисление зарплаты сотрудникам организаций» перед выполнением самого массивного запроса. Например, это будет команда
    «Результат = Запрос.ВыполнитьПакет();» в функции «ПолучитьДанныеНДФЛПоРегистратору» в общем модуле «ПроведениеРасчетов». Здесь происходит выполнение основного запроса для расчета НДФЛ. Поставим на ней точку останова отладчика и запустим расчет в документе.

  • После того как отладчик остановится, нажмем кнопку RUN в Профайлере.
  • Теперь сделаем один шаг в отладчике кнопкой F11. Когда запрос будет выполнен и отладчик перейдет на следующий шаг, остановим чтение Профайлера кнопкой «Pause Selected Trace».
  • Теперь найдем самый длительный запрос по колонке Duration и внимательно изучим текст запроса. Если при обращении к реальной (а не временной) таблице после слова WITH стоит SERIALIZABLE, то мы имеем дело с автоматическим режимом блокировки. Если ничего не стоит – то с управляемым.

Если в хинте запроса (Hint – это параметр после слова WITH, позволяющий влиять на план выполнения запроса) не указан уровень изоляции, то выполняется уровень изоляции, установленный по умолчанию для текущей SQL-сессии. Определить уровень изоляции, действующий по умолчанию для текущих сессий можно, например, с помощью команды в «SQL Server Management Studio»:

SELECT CASE transaction_isolation_level
WHEN 0 THEN 'Unspecified'
WHEN 1 THEN 'Read Uncommitted'
WHEN 2 THEN 'Read Committed'
WHEN 3 THEN 'Repeatable'
WHEN 4 THEN 'Serializable'
WHEN 5 THEN 'Snapshot' END AS TRANSACTION_ISOLATION_LEVEL
FROM sys.dm_exec_sessions

В управляемом режиме для всех сессий будет указан режим Read Committed.

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

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

Настройка  управляемых блокировок – это тема для отдельной статьи. Вкратце скажу, что программно управляемые блокировки устанавливаются с помощью объекта «БлокировкаДанных». Сами управляемые блокировки работают уже не на уровне SQL сервера, как в случае с автоматическими блокировками, а на уровне сервера 1С. Для определения необходимых и достаточных управляемых блокировок надо понимать логику программы одновременно на уровне бизнес-процессов и на уровне архитектуры таблиц СУБД.

Но на мой взгляд, для таких конфигураций, как ЗУП2.5 вообще нет смысла использовать какие-либо блокировки, лучше использовать проверочные отчеты для выявления нарушения целостности данных - на практике это самый быстрый способ расчета зарплаты. Особенно на крупных предприятиях, где точно есть сотрудники с внутренним совмещением в обособленных подразделениях, а за каждым ОП закреплен отдельный расчетчик, что и является причиной задвоения НДФЛ. Какой бы не был вышколенный персонал, сама идеология конфигурации допускает возможность задвоения НДФЛ. Поэтому лучше не мешать пользователям работать параллельно во время массированных месячных расчетов, а по завершении точечно и быстро исправить небольшой процент ошибок, чем заставлять их сидеть и нервничать в очереди из-за страха допустить хотя бы одну ошибку. В этом проекте мы использовали самописный отчет «Проверка НДФЛ», который отображал сотрудников с некорректным НДФЛ.

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

PS1. По многочисленным просьбам выложен упомянутый самописный отчет "Контроль НДФЛ" в отдельной статье.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. nvv1970 15.05.17 08:20 Сейчас в теме
200 одновременных сеансов и не нужны упр блокировки? Мне кажется такое заявление слишком самонадеянным.
Решение должно работать "нажал и забыл", а не всё сделал и сел все пересчитывать и перепроверять ((
Конечно 200 человек для зуп 2.5, и не только, в авторежиме - это капут. И такое решение - это лучше чем ничего.
Silenser; Dmitri93; matveev.andrey.v; +3 Ответить
2. barelpro 1184 15.05.17 12:43 Сейчас в теме
(1) Ну что тут скажешь, да, в теории мы должны стремиться сделать идеальную систему "нажал и забыл". Но на практике за перфекционизм никто не готов переплачивать.

Плюс к этому повторюсь, из-за идеологии ЗУП2.5 "Рассчитал-поправил-провел" есть неконтролируемый временной лаг между "рассчитал" и "провел". В это время документ находится в непроведенном состоянии и параллельно с ним другой пользователь может рассчитать второй документ с такими же физлицами. А потом оба документа будут проведены без какой-либо проверки. Поэтому какие бы умные управляемые блокировки ты не сделал, нарушение целостности все равно будет. Так что пусть неизбежное будет, но с максимальной скоростью )))
KAV2; METAL; +2 Ответить
3. matveev.andrey.v 47 15.05.17 12:45 Сейчас в теме
(1) полностью согласен, у меня около 100 пользователей и перевод на управляемые был необходимостью
7. barelpro 1184 15.05.17 13:42 Сейчас в теме
(1) (3) Парни, вдруг вы меня не так поняли- фразу "для таких конфигураций, как ЗУП2.5 вообще нет смысла использовать какие-либо блокировки" надо понимать так, что мы переводим конфигурацию в режим управляемых блокировок и не добавляем объект "БлокировкаДанных", т.е. максимально понижаем уровень изоляции на SQL сервере и так и оставляем, не используя управляемые блокировки на Сервере 1С. Чтобы у пользователей была максимальная параллельность. А потом подчищаем проверочными отчетами последствия такой максимальной параллельности.
8. grumagargler 673 15.05.17 14:42 Сейчас в теме
(7) небольшое уточнение: если вы уберете управляемые блокировки совсем, у вас могут возникнуть дедлоки в запросах на получение остатков при проведении документов (если, конечно, таковые имеются в зуп)
9. barelpro 1184 15.05.17 15:14 Сейчас в теме
(8) Да, в ЗУПе при проведении документов есть обращение к остаткам. Но при чтении остатков дэдлоки вряд ли возникнут на RCSI, выполнению запроса может помешать X-блокировка при записи в параллельном документе, сам запрос никому не мешает, т.к. не накладывает блокировок. А вот два документа при записи теоретически могут друг друга ввести в дэдлоки, но только в режиме автоматических блокировок, когда на таблицу индексов регистров накладывается RangeX блокировка. Согласен, RangeX - сущее зло, но его нет в режиме управляемых блокировок!
11. grumagargler 673 15.05.17 16:23 Сейчас в теме
(9) Если вы не будете блокировать (БлокироватьДляИзменения) при записи регистра, у вас получится такой дедлок:
1. Пользователь1 записывает набор данных, остаток с разделителем 1.
2. Пользователь2 записывает набор по тем же измерениям, но с разделителем 2.
3. При контроле остатков (выполнение запроса к вирт.таблице) Пользователь1 будет пытаться считать все записи по этим измерениям (без учета разделителя). И запись с разделителем 2 он прочитать не может, потому что её держит Пользователь2, поэтому Пользователь1 встает в очередь.
4. При контроле остатков Пользователь2 также будет пытаться считать все записи по тем же измерениям, без учета разделителя. Запись с разделителем 1 он прочитать не может (ее держит Пользователь1) и Пользователь2 встает в очередь.
13. nvv1970 15.05.17 16:27 Сейчас в теме
(11) Да. Но лучше ловить дедлоки и иметь возможность работать, чем на несколько часов намертво заблокированную базу. Ну а дедлоки можно и нужно понемногу убирать.
barelpro; +1 Ответить
16. grumagargler 673 15.05.17 18:12 Сейчас в теме
(13)
Да. Но лучше ловить дедлоки и иметь возможность работать, чем на несколько часов намертво заблокированную базу

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

Ну а дедлоки можно и нужно понемногу убирать.

ну так это ровно то, что я и написал выше, организация очереди, а не взаимоблокировка.
matveev.andrey.v; +1 Ответить
18. barelpro 1184 15.05.17 18:37 Сейчас в теме
(11) Согласен, если бы в ЗУПе 2.5 использовалась модная технология "сначала запись в регистр, потом контрольный запрос", тогда и на RCSI можно словить deadlock. Но в ЗУП2.5 старая технология, сначала запрос, потом запись регистра, так что пока живем без deadlock ))
22. Batchir 126 17.05.17 09:13 Сейчас в теме
(18) Отлично)))
При уровне изоляции READ COMMITTED SNAPSHOT "пишущий" не блокирует "читающего". Почему? Потому что "читающий" просматривает версию данных до начала изменения. Получаем следующую картину:

1. Т1 S (Прочитали остаток и = 1)
2. Т1 Х (Списываем остаток становится 0)
3. Т2 S (Прочитали остаток и = 1)
4. Т2 Х (Списываем остаток становится -1)
5. Фиксация транзакций Т1 Т2 (причем тут не важно в какой последовательности будет выполняться п.2 и п.3)

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

Для того что бы система корректно отработала, нужно:

1. Т1 S (Прочитали остаток и = 1) Накладываем упр. блокировку
2. Т2 S (ожидаем) ...
3. Т1 Х (Списываем остаток становится 0)
4 Фиксация транзакций Т1
5. Т2 S (дождались, получили остаток = 0) отвалились или записываем (зависит от логики, которую заложил программист)
6. Фиксация транзакций Т2
uncle_Vasya; +1 Ответить
27. barelpro 1184 17.05.17 11:42 Сейчас в теме
(22) Это все понятно, я ж не спорю, но статья про проект по ЗУП2.5. Ошибка искажения остатков страшна там, где речь идет об оперативном учете товара или денег. Расчет зарплаты и налогов - это бухгалтерский "посмертный" учет. Здесь главное точность, а не скорость. Вот и коллега Uladzimir - со мной согласен, видимо у него тоже был опыт высоконагруженного ЗУПа - лучше дать расчетчикам максимальный зеленый свет, а потом точечно подчистить ошибки. Практика показывает, что таких ошибок действительно очень мало.
28. headMade 143 17.05.17 13:33 Сейчас в теме
(22)
В ЗУПе как правило вся логика строится на предварительной записи данных в регистры т.е. когда бухгалтер нажимает кнопку "Рассчитать" происходит запись в регистр. На основании этих записей производится расчет сумм, которые затем возвращаются в документ.
А в момент проведения документа уже готовые суммы записываются в регистры.

Поэтому наверное такая проблема не совсем актуальна для ЗУПа.
29. Batchir 126 17.05.17 14:56 Сейчас в теме
(28) Как по мне то это выливается в не корректный расчет, дальнейшую перепроверку и перерасчет на большом количестве записей. В не зависимости от конфигурации это грубая ошибка.
Сегодня рассчитали с ошибками ЗП, не заметили и завтра сдали в гос. органы.
Я не работал с высоконагруженным ЗУМом, поэтому конечно это всё ИМХО.
Но к проблеме нужно подходить корректно, если имеем проблему с блокировками на ожиданиях, то нужно решать эту проблему, а не ставить костыль, который позволяет системе некорректно работать.
30. headMade 143 17.05.17 15:22 Сейчас в теме
(29)
нужно решать эту проблему, а не ставить костыль

Абсолютно с этим согласен.

Я просто хотел обратить внимание что
(28)
В ЗУПе как правило вся логика строится на предварительной записи данных в регистры

т.е. момент записи данных в регистр будет установлена управляемая блокировка, поэтому (скорее всего) и логическая ошибка, описанная Вами выше, не всплывет.
4. matveev.andrey.v 47 15.05.17 12:49 Сейчас в теме
Есть еще одно замечание о котором мне кажется надо упомянуть в статье, что бы MS SQL использовала уровень READ COMMITTED SNAPSHOT нужно перевести платформу на 8.3 и убрать режим совместимости. Так указано в книге "Настольная книга 1С Эксперта по технологическим вопросам" стр 38
Прикрепленные файлы:
5. nvv1970 15.05.17 13:09 Сейчас в теме
(4) Совершенно верно.
Боюсь может оказаться, что упрблокировки + совместимость 8.3 - это не то же самое что упрблокировки + совместимость 8.2 + включение снэпшотов в SQL. Я правда не проверял )) В теории, менеджер блокировок 1с может вести себя по-разному.
10. Sergey.Noskov 1168 15.05.17 15:31 Сейчас в теме
(5)
это не то же самое что упрблокировки + совместимость 8.2 + включение снэпшотов в SQL
Это то же самое, единственное отличие, что 8.3 сама включает снепшот
12. nvv1970 15.05.17 16:25 Сейчас в теме
(10) Ну если рассматривать разные поколения платформ 8.2 и 8.3, то разница точно есть. )) И даже в разных версиях 8.3 были изменения...
Но в данном случае мы предполагали, что платформа одна, а "балуемся" только настройками конфы и скуля.
14. Sergey.Noskov 1168 15.05.17 16:56 Сейчас в теме
(12)касаемо включения READ COMMITTED SNAPSHOT это то же самое. Про сравнение 8.2 и 8.3 речи нет.
15. nvv1970 15.05.17 17:16 Сейчас в теме
(14) т.е. поведение платформы в части менеджера блокировок 100% не зависит от совместимости конфигурации? А зависит только от релиза платформы?
17. Sergey.Noskov 1168 15.05.17 18:14 Сейчас в теме
(15) Либо СУБД работает с уровнем изоляции READ COMMITTED SNAPSHOT либо просто READ COMMITTED, что должно измениться в поведении платформы? Просто в первом случае выше требования к правильности наложения упр.блокировок т.к. без оных есть риск прочитать, например, остатки, которые кто-то меняет в параллельной сессии.
matveev.andrey.v; +1 Ответить
6. barelpro 1184 15.05.17 13:36 Сейчас в теме
(4) Ага, мы так и делали. Позже добавлю в статью.
19. nvv1970 16.05.17 09:59 Сейчас в теме
В описанном мною случае, вместо кратковременного ожидания одного пользователя, работа обоих будет парализована.

Ну как сказать... Когда у клиента доходит до того, что пользователи на протяжении часа жмякают, например, проведение и 100% в течении часа получают таймаут, то чем можно помочь? Увеличение времени таймаута (как многие делаю) еще более усугубляет ситуацию. Рестарт сервера? ))) Да, админы так и делают )
А при "просто перевод в упр" влечет за собой исчезновение тысяч! таймаутов и появление десятков дедлоков. А дедлоки по ТЖ диагностируются гораздо легче, чем таймауты.
20. Vladimir Litvinenko 16.05.17 15:36 Сейчас в теме
Устанавливать настройку "Allow Snapshot Isolation" в истину нет необходимости. Сама платформа 8.3 этого не делает и ни 8.2 ни 8.3 не использует этот уровень изоляции. Достаточно ограничиться "Read Commited Snapshot". Уровень изоляции Snapshot ведет себя отлично от Read Commited Snapshot, который нужен нам при работе с 1С.
barelpro; baton_pk; Sergey.Noskov; +3 Ответить
21. headMade 143 16.05.17 18:02 Сейчас в теме
(20)
зачем тогда Гилев предлагает это делать? (snapshot1c)
24. Vladimir Litvinenko 17.05.17 10:22 Сейчас в теме
(21) Подозреваю, что это ретрансляция работающей на практике инструкции, полученной в результате экспериментов или из каких-то источников. Специалисты часто находят работающую инструкцию и применяют ее целиком, не экспериментируя с отдельными частями, так как это затратно по времени и обычно не дает большой практической пользы.

Хотя возможно есть и другие причины. Если есть причина для 1С устанавливать "Allow Snapshot Isolation" в истину, то очень хотелось бы о ней знать. Но и в настольной книге эксперта по тех.платформе написано, что 1С не использует уровень изоляции Snapshot, и платформа 1С 8.3 сама не устанавливает эту опцию. Да коллеги - специалисты по MS SQL подтверждали, что разрешения на Snapshot и на Read Commited Snapshot устанавливаются независимо друг от друга.
25. barelpro 1184 17.05.17 11:25 Сейчас в теме
(24) Кто с этим разберется, тому плюс от меня! )
33. barelpro 1184 17.05.17 23:53 Сейчас в теме
(20) Нашел интересную статью, где говорится, что RCSI и SNAPSHOT это два разных вида уровней изоляции

Получается вот что:
команда "ALT ER DATABASE SET READ_COMMITTED_SNAPSHOT ON" включает уровень изоляции RCSI
а команда "ALT ER DATABASE SET ALLOW_SNAPSHOT_ISOLATION ON" включает уровень изоляции SNAPSHOT

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

Тогда как SNAPSHOT - это полноценная изоляция и пишуших и читающих блокировок между транзакциями. Т.е. полная анархия!!!

Судя по всему, когда конфигурация переведена в управляемый режим блокировок, то 1С-платформа для SQL-сессий устанавливает по умолчанию режим READ COMMITTED, который превращается в READ COMMITTED SNAPSHOT, если включен режим READ_COMMITTED_SNAPSHOT ON

А полноценный SNAPSHOT в 1С-базах не работает, даже если включить режим ALLOW_SNAPSHOT_ISOLATION ON, т.к. как я уже писал в статье команда

"SEL ECT CASE transaction_isolation_level
WHEN 0 THEN 'Unspecified'
WHEN 1 THEN 'Read Uncommitted'
WHEN 2 THEN 'Read Committed'
WHEN 3 THEN 'Repeatable'
WHEN 4 THEN 'Serializable'
WHEN 5 THEN 'Snapshot' END AS TRANSACTION_ISOLATION_LEVEL
FR OM sys.dm_exec_sessions"

возвращает для всех сессий режим Read Committed
Vladimir Litvinenko; +1 Ответить
34. Vladimir Litvinenko 18.05.17 00:48 Сейчас в теме
(33)
Также очень рекомендую два следующих ролика:
Read Committed Snapshot Isolation
Snapshot Isolation

Это лучшее объяснение различий между двумя уровнями изоляции из тех, что встречал в сети. У автора акцент тот еще, но понять можно. А вот иллюстрация на флипчарте - это то, ради чего стоит посмотреть. Обычно различия объясняются на примере параллельно исполняемых запросов в Management Studio. В этих роликах дается понятное объяснение на схемах, и только потом демонстрируются подтверждающие примеры в Студии.
barelpro; +1 Ответить
35. barelpro 1184 18.05.17 12:50 Сейчас в теме
(20) Спасибо за замечание, поправил в статье!
23. Andrefan 17.05.17 09:24 Сейчас в теме
Очень позновательная статья, спасибо. А можете поделиться этим: самописный отчет «Проверка НДФЛ»?
barelpro; +1 Ответить
26. barelpro 1184 17.05.17 11:32 Сейчас в теме
(23) Я как раз думаю его выложить, но он использует вызовы нетиповых процедур из общих модулей, в частности под него была переписана процедура ПроведениеРасчетов.ПолучитьДанныеНДФЛПоРегистратору, а так же много внимания уделено разделителю ОКТМО/КПП. Так что его еще надо причесать, прежде чем выкладывать
31. Dmitri93 7 17.05.17 18:01 Сейчас в теме
А почему внедряли именно ЗУП 2.5, а не 3.1?
32. barelpro 1184 17.05.17 19:15 Сейчас в теме
(31) Цель проекта была внедрить единую систему путем слияния двух баз: допиленный 2.5 и "известное неодинесное решение". Следующим этапом планируется 3.1. Вангую, что в 3.1 тоже придется оптимизировать блокировки )))
36. logarifm 1084 19.05.17 00:18 Сейчас в теме
еще не прочитал. + поставил и таких стотей не бывает мало )
37. dumsik 24 29.05.17 14:02 Сейчас в теме
В статье не точность. На уровне изоляции READ COMMITTED блокировки снимаются после выполнения запроса до окончания транзакции. Для того чтобы блокировки держались до конца транзакции используется уровень изоляции REPEATABLE READ.

Выбор между уровнем изоляции READ COMMITTED или REPEATABLE READ платформа выполняет сама в зависимости от объекта метаданных. Для объектных (все у чего есть ссылка) выбирается READ COMMITTED, для регистров REPEATABLE READ.

Источник "Настольная книга 1с эксперта по технологическим вопросам"
38. barelpro 1184 29.05.17 14:21 Сейчас в теме
(37) Интересно! Назовите номер издания книги и номер страницы, посмотрим
39. barelpro 1184 29.05.17 16:39 Сейчас в теме
(37) Вот что пишет сам Филиппов Женя по поводу первого издания: "Во втором издании скорректированы неточности в теоретической части" http://1c.ru/news/info.jsp?id=20028. Так я ничему не удивляюсь ;)
40. Irwin 354 02.08.17 13:42 Сейчас в теме
У вас стоит режим совместимости в 8.2.13 (если правильно помню). И основные проблемы параллельности при расчете зарплаты в том, что при записи в регистр расчета ОсновныеНачисления происходит сканирование таблицы. Происходит это при расчете фактического периода действия. Получается ситуация, что при расчете в документе до 150 сотрудников параллельность высокая (порядка 200-250 записей в документе). При большем количестве план запроса становится неоптимален - появляется скан, ставятся лишние X-блокировки. При этом появляются взаимоблокировки, таймауты.

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

Про это также есть в статье у Бурмистрова: https://infostart.ru/public/629017/. Раздел "Ошибка платформы – скан индекса регистра расчета".

Варианты решения:
1) попробовать снять режим совместимости (частично переписать конфу), чтобы добавился кластерный индекс на регистр расчета.
2) попробовать самим добавить индекс
3) попробовать документ начисления зарплаты рассчитывать порциями по 150 сотрудников. Можно параллельно, в этом случае может еще и время расчета сократиться.

В любом случае эффект не гарантирован, надо пробовать.
barelpro; +1 Ответить
41. Irwin 354 02.08.17 13:55 Сейчас в теме
В этой же конфе был еще один интересный случай. Есть отчет "Неиспользованные отпуска МСФО", который рассчитывает средний заработок. Создается документ "Увольнение", рассчитывается, результат среднего запоминается. И так для каждого сотрудника. Отчет рассчитывался в разрезе организаций. В самой крупной из них на тот момент было порядка 8 тыс. (могу соврать, не помню уже). Расчет шел порядка 6-7 часов. Иногда прерывался из-за какого-нибудь таймаута. Приходилось заново запускать.

В итоге решили считать в фоне в несколько потоков. При этом каждый поток должен считать не по одному сотруднику, а сразу пачками. В итоге расчет пачками дал прирост скорости в 30%. А 20 фоновых заданий все это дело рассчитывали за 40 минут.

Но самое интересное было, когда первый раз запустили параллельный расчет. Фоновые задания начали друг другу мешать. Каждая пачка рассчитывалась в отдельной транзакции - создавался документа, рассчитывался, все записи удалялись. При чем в ТЖ отслеживались ожидания на управляемых блокировках на регистре расчет "СреднийЗаработок". ТЖ показал, что при записи в регистр данных даже по одному сотруднику устанавливалась исключительная блокировка на всю таблицу. При этом если писать обработкой какие-нибудь записи в регистр - все хорошо, ставятся только необходимые блокировки. Если при расчете документа увольненеия - вся таблица. Оказалось, что если писать в этот регистр набор записей, у которого в записях стоит Активность = Ложь, то ставится исключительная управляемая блокировка на всю таблицу.

Пробовал создать в пустой базе аналогичный регистр и записывать в него - такого поведения добиться не удалось. Что это было - остается загадкой.
barelpro; +1 Ответить
Оставьте свое сообщение

См. также

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    30104    MrWonder    42    

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

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

07.10.2020    3105    ivanov660    12    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

Производительность и оптимизация (HighLoad) v8 ДО Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    3720    Nykyanen    16    

Тест скорости работы мобильной платформы 1С

Мобильная разработка Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

14.09.2020    1177    capitan    19    

Долго открывается конфигуратор Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    41275    Gilev.Vyacheslav    1    

Описание почти всех событий технологического журнала

Технологический журнал v8 Бесплатно (free)

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

19.08.2020    8397    YPermitin    30    

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

Технологический журнал v8 1cv8.cf Бесплатно (free)

Корректируем классификацию ошибок ТЖ в процессе работы для конфигурации мониторинг производительности

17.08.2020    470    ivanov660    0    

SQL для 1С: пишем правильно, красиво, сложно

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Многие программисты боятся работать с Null, считая, что от этих данных в запросах нужно избавляться. О том, как с помощью Null-полей в запросе решать востребованные в учете задачи по выборке данных, на конференции Infostart Event 2019 Inception рассказал ведущий разработчик ГК WiseAdvice Дмитрий Дудин.

14.08.2020    10023    dmurk    30    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    67615    yuraos    112    

Нестандартные блокировки при работе с OLAP-нагрузкой

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    2005    Филин    7    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

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

25.06.2020    2882    ivanov660    12    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

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

24.05.2020    7752    DataReducer    22    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

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

21.06.2013    55431    Антон Ширяев    117    

[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

18.05.2020    2187    Aleksey.Bochkov    4    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    12212    YPermitin    0    

Оптимизация запросов 1С посредством индексации временных таблиц. Миф? Тестируем, смотрим, считаем

Производительность и оптимизация (HighLoad) Практика программирования v8 Бесплатно (free)

Появилось свободное время, решил проверить на работе индексацию таблиц. Решил поделиться с Вами результатами исследования. Давайте порассуждаем на эту тему? Часто ли вы пользуетесь индексацией в запросах? Платформа 8.3.16.1224

03.04.2020    4721    feva    15    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    54917    Gilev.Vyacheslav    46    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    13450    informa1555    31    

Многострочный контекст событий

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

31.03.2020    3205    vasilev2015    9    

Анализ взаимоблокировок

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

20.03.2020    5343    vasilev2015    26    

Параллельные вычисления в 1С 8 Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    30176    gallam99    19    

Многопоточность

Практика программирования Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

18.03.2020    7417    kaliuzhnyi    43    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    10183    Evil Beaver    13    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    42897    madmpro    32    

Оптимизатор запросов. Вторая часть

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

23.01.2020    6557    darkdan77    59    

Улучшаем производительность 1С. Рекомендации

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

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

23.01.2020    8145    Kaval88    26    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    12093    ivanov660    16    

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    7791    EugeneSemyonov    11    

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

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    18260    YPermitin    28    

Мониторинг высоконагруженной системы

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    9204    Repich    5    

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Администрирование данных 1С Zabbix v8 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    19009    Sloth    24    

Хранение файлов - как уменьшить размер базы данных

Чистка базы Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 Россия Бесплатно (free)

Хранение файлов в базе 1С можно оптимизировать для уменьшения размера хранимых данных.

09.09.2019    8728    2tvad    17    

Неочевидные проблемы производительности: важность системного подхода при анализе

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

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

19.07.2019    9087    Филин    12    

Ловля блокировок на связке "Microsoft SQL server - 1С"

Производительность и оптимизация (HighLoad) v8 v8::blocking Бесплатно (free)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    10264    fhqhelp    0    

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным

Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка v8 Бесплатно (free)

В этой статье приведен пример неочевидной "оптимизации" запроса, которая противоречит всем правилам, описанным в книгах для подготовки к сертификации "1С:Эксперт по технологическим вопросам", а также преподаваемым на курсах подготовки экспертов.

02.07.2019    11552    igordynets    119    

Ускорение чтения правил обмена в УПП 1.3 в 20 раз!

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

27.06.2019    9963    YPermitin    17    

Хотите снизить нагрузку на процессор сервера в 2 раза?

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

27.06.2019    9962    Дмитрий74Чел    6    

Непридуманные истории по оптимизации. История 1

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    12843    Repich    117    

Оптимизация: неэффективные запросы

Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

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

13.06.2019    5983    slayer-ekb    10    

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Практика программирования Производительность и оптимизация (HighLoad) v8 v8::Запросы Бесплатно (free)

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    25971    dmurk    146    

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    20130    ivanov660    10    

Не думать о секундах свысока...

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    8083    vasilev2015    21    

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

Производительность и оптимизация (HighLoad) v8 v8::blocking 1cv8.cf Россия Бесплатно (free)

Данная публикация освещает одну из альтернативных стратегий блокирования данных на уровне MS SQL Server, которая недоступна средствами 1С, но может быть весьма полезной. Разбирается практический пример.

20.05.2019    7271    zhichkin    15    

Как работают управляемые блокировки

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

29.04.2019    24024    comol    198    

Странное потребление места на диске С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    14350    kuzyara    13