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

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

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

Я являюсь автором и тренером курсов по оптимизации и повышению производительности в 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 2016 DEVELOPER. Больше статей можно прочитать здесь.

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

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. kolya_tlt 24 13.06.17 11:00 Сейчас в теме
спасибо, еще раз освежил в памяти
2. orefkov 2074 13.06.17 12:42 Сейчас в теме
Насколько я понял, бОльший упор делается на специфику работы именно MS-SQL?
Очень хотелось бы подобной инфы/сравнения с "честными" СУБД-версионниками - Postgres, Oracle.
Даже sqlite - там и то читатели и писатель никак не мешают друг-другу (в WAL-режиме).
megatrend; +1 Ответить
3. KazanKokos 8 13.06.17 12:50 Сейчас в теме
Начал читать. Очень интересно.
4. orefkov 2074 13.06.17 12:54 Сейчас в теме
Всякие расчеты, проверки и пр. делайте за пределами транзакции

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

Возьмём к примеру контроль остатка на складе или распределение по партиям. Если делать расчёты вне транзакции, то к моменту её выполнения данные об остатках уже могут изменится, делая расчёты неверными. А могут и не изменится. А могут изменится, но не сделать расчёты не верными.
Поэтому есть еще и такой метод выполнения - сначала вне транзакции вычисляется сколько откуда списывать, потом в транзакции делается запись вычисленного и проверка, что ни по складам/партиям не "улетели в минус". Если улетели - отмена транзакции и всё по новой.
tormozit; Stim213; Serg O.; lefthander; brr; +5 Ответить
29. kolya_tlt 24 21.06.17 13:28 Сейчас в теме
(4) понятное дело, что тут надо включить голову. из практики, имеется пример, где в рознице мы проверяли остатки до транзакции и во время. так как ошибка остатков - была самая распространенная среди продавцов розницы.
5. headMade 143 13.06.17 12:56 Сейчас в теме
Объясните пожалуйста зачем включать SNAPSHOT_ISOLATION ?
Ведь 8.3 включает только READ_COMMITTED_SNAPSHOT
Спасибо.
6. lefthander 13.06.17 14:58 Сейчас в теме
Спасибо, приятное дополнение к курсу Ускорение и оптимизация систем на 1С:Предприятие 8.3
7. asved.ru 35 13.06.17 15:00 Сейчас в теме
8. ZLENKO 387 13.06.17 15:20 Сейчас в теме
Хорошая полезная статья. Автору плюс.
9. nvv1970 13.06.17 17:03 Сейчас в теме
переходите на управляемый режим блокировок.

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

Как правило проблемы возникают на старых конфигурациях с автоматическими блокировками и очисткой движений в документах в начале проведения. В 99% проблем именно такие проекты ищут решения своих проблем в подобных статьях. И вроде все правильно сказано в статье, а приложить ее не к чему. И складывается у заказчика впечатление, что заветная зеленая кнопка где-то есть. И объяснить, что кроме оптимизации переписывать нужно код в проведении документов и прочих транзакциях, порой трудно. А заикаться, что внедренный тобой же много лет назад проект на основе типовой конфигурации по сегодняшним меркам не имеет права на жизнь, что "тогда 1с так писала" и на 100-300 юзеров (24/7) эта конфа не рассчитана (а только на 50 редко нажимающих кнопочки бабушек и т.п.), вообще запрещено...
lavash67; LeaNaeD; bajiepka; tormozit; DarkUser; purgin; eeeio; flu; Evil Beaver; Wrols; Serg O.; kote; sansys; +13 Ответить
10. kolya_tlt 24 13.06.17 17:46 Сейчас в теме
(9) напишите статью как перейти и автор сделает ссылку на вашу статейку :)
32. KAV2 04.01.18 06:12 Сейчас в теме
(9)
появятся дедлоки...

А почему должны появиться дедлоки? Ведь переход на управляемый режим (без написания дополнительного кода) не предусматривает автоматическое увеличение уровня изоляции, а значит вероятность появления дедлоков будет как минимум не выше чем при автоматическом режиме.
33. nvv1970 04.01.18 10:00 Сейчас в теме
(32) все верно, вероятность снижается. Я не точно выразился.
В общем случае при наличии дедлоков в "Авто" скорей всего их количество значительно уменьшится или же они исчезнут вообще. Но на практике после адаптации и перевода в "УПР" получал дедлок там, где его не было. Поэтому правильно сказать: "есть ненулевая вероятность, что могут появиться новые дедлоки". Причину и схему дедлока сейчас не вспомню. Помню что дедлок был сложный и это был очень частный случай. Поэтому заморачиваться не стоит. А еще в гибридном (авто+упр) режиме неоднократно ловил "неразрешимый дедлок" между менеджерами блокировок 1с и СУБД. Это вообще жесть. Сначала понял что это именно так, а потом прочитал что такая ситуация на самом деле бывает. После доработки конфы и перевода в УПР проблема исчезла.
Есть мнение, что смешанный режим "Авто+Упр" лучше не использовать вообще. Как человек прошедший на крупном проекте 8.2 через него - соглашусь с этим мнением. Проще сразу на УПР и по ходу дорабатывать. Очень экономит время.
И еще я бы посоветовал сразу не включать rcsi, чтобы минимизировать логические ошибки списаний, контролей и т.п. Конфа должна идеально работать в RC. Добейтесь этого - только потом принимайте решение о rcsi.
11. sank84 14.06.17 05:56 Сейчас в теме
12. iskdv 14.06.17 06:35 Сейчас в теме
"Например, если у вас запрос из-за блокировок выполняется 15 секунд, то после оптимизации он начнет выполняться за 15 миллисекунд." -- т.е. мне покажут как писать правильные запросы? ага "щаз"! мне опишут проблемы, скажут "нельзя просто так взять и оптимизировать"(гы...гы.. с картинкой) и предолжат скачать программу. и все это со мной проделает специалист аж 65 звездами. охренеть
d4rkmesa; scanner1980; AleksKol; prog77; +4 2 Ответить
13. DarkAn 966 14.06.17 09:27 Сейчас в теме
(12)
т.е. мне покажут как писать правильные запросы?
- именно так! Программу никто не предложит скачать. Андрей не нуждается в рекламе. Многие его знают как высококвалифицированного специалиста и лектора. Он ведет курсы на и на сколько я знаю на gilev.ru. То что рассказано в курсе в разы (В РАЗЫ!!!) превосходит, то что показано тут. Тут так - краткая шпаргалка :). (Например методичка второй редакции - 360 страниц)

Я прошел два курса по оптимизации на и не жалею. Там рассказано реально очень многое, на многие вещи начинаешь смотреть совсем по другому. Если раньше накидаешь измерений в регистр - "и так сойдет", теперь раз 20 подумаешь как лучше. Подумаешь, что индексировать, а что нет и еще очень, очень многое :)
andron77777; mmch; alevnev; sansys; +4 Ответить
14. tata_1211 62 14.06.17 10:04 Сейчас в теме
(12) (13) Я полностью согласна с Иваном. Прошла первый курс по оптимизации и очень довольна. Мышление совершенно изменилось при написании кода. Теперь даже когда нужно закрыть задачу быстро, автоматом думаешь не просто над тем, как это сделать правильно, но и сразу писать так, чтобы код не тормозил систему. Периодически и в стандартных конфигурациях приходится переписывать запросы - в итоге полученный результат превосходит ожидания настолько, что даже не верится. Да, в стандартных конфигурациях на обычных формах многие запросы написаны очень давно, и туда обычно никто и не заглядывает при обновлениях - работает, ну пускай и работает.
16. iskdv 14.06.17 11:16 Сейчас в теме
(13) нет, вы не подумайте ничего дурного, я просто восхищен тем как виртуозно "высококвалифицированный специалист и лектор" съезжает с темы анонсированной вначале статьи.
(14) "Мышление совершенно изменилось при написании кода" -- и теперь мы "Периодически и в стандартных конфигурациях переписываем запросы"
17. DarkAn 966 14.06.17 12:05 Сейчас в теме
(16)
съезжает с темы анонсированной вначале статьи.


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


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

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

Как вариант могу сказать следующее - благодаря информации полученной на курсах мне удалось реализовать восстановление последовательности партий в УПП 1.3 (не РАУЗ) с 4,5 часов до 15-20 мин (режим совместимости 8.2). А для получения такого результата типовой функционал поправился "незначительно" в объеме кода, и да еще пришлось полностью переписать 3 типовых запроса. (если интересно - все описано тут http://infostart.ru/public/626117/)
15. Fatov_DI 14.06.17 11:09 Сейчас в теме
Спасибо за статью! Освежили в памяти... Конечно не так "разжевано" как мы все привыкли видеть, но тому кто в теме, думаю будет понятно, остальным придется вычитывать доп. информацию....
18. Painted 34 14.06.17 18:31 Сейчас в теме
регистр расчета – это единственный объект в 1С, который не имеет кластерного индекса.
Есть какая-то причина этого? Почему 1С для регистров расчета делает исключение?
19. Serg O. 190 15.06.17 08:35 Сейчас в теме
Да, очень кратко и доступно... Андрей снова открывает нам глаза...

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

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

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

Автору - Большое Спасибо
20. Serg O. 190 15.06.17 08:55 Сейчас в теме
Параллельность - это очень крутая штука... У меня лично для прайсов "всем" клиентам заточена обработка в 10 потоков... И если раньше 1 прайс выгружался 20-30 сек... То теперь почти в 10 раз быстрее 3-3,5 сек

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

Поэтому в 100 потоков ... Нет смысла делать...
И НЕ Надо доп.ключ на эти самые 100 лицензий...
22. DarkAn 966 15.06.17 09:30 Сейчас в теме
(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 часов, например, ночью. Все зависит от задачи :)
23. Serg O. 190 15.06.17 09:47 Сейчас в теме
(22)
Простая формула в Excel: КоэфКратностиВремени = ОКРУГЛВВЕРХ(КоличествоОперация / КоличествоПотоков; 0)


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

увеличение числа потоков в 2 раза (до 20) - дало прирост всего в 15 мин (8-10%)...
а не в 2 раза...как по этой формуле.
Так что именно "накладные расходы" - при числе потоков более 10 уже очень сильно "взаимотормозят" друг друга...

до 100 не пробовал... на можно как-нить проверю... думаю тогда будет максимум раза в 2-3 быстрее чем сейчас - до 1-2 часов сократится...
когда число клиентов вырастит до 100 тыс... может тогда понадобится такая супер-много-поточность
24. DarkAn 966 15.06.17 11:56 Сейчас в теме
(23)
увеличение числа потоков в 2 раза (до 20) - дало прирост всего в 15 мин (8-10%)...


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


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

Обычно при увеличении в 2 раза (с 1 потока в 2) - прирост обычно 2х.
В вашем случае надо разбираться в чем дело.
* Одинаковые ли прайсы формируются для клиентов (может одному на 100тыс. записей, а остальным на 10 записей. тогда время будет определяться самым медленным потоком)
* может дисковая подсиситема не справляется с записью файлов
* может почта "тупит"
21. Serg O. 190 15.06.17 09:19 Сейчас в теме
Еще одной из причин массовых блокировок - являются всякие там обмены! Обмен с бухгалтерией, с ЗУПом, выгрузка на сайт каждые 5-10 мин... Все они читают план обмена... А каждый документ/обьект туда пишется постоянно... И чтение ждет... И тормозит... И может не успеть выгрузиться даже за 5-10 мин...

Обратные загрузки (запись) из сторонних систем к себе - еще хуже... Например каждое утро бухгалтер грузит платежки из банка....
Там одинаковые движения сплошь и рядом... Плюс пользователи "попадают" на ожидание 20 сек...

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

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

Развели регл.задания на 10-15 мин начало сдвинули и конец установили и сразу стало легче
alex689ru; +1 Ответить
25. axelrich 7 18.06.17 11:09 Сейчас в теме
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)}: Процедура или функция с указанным именем не определена (ПолучитьТаблицуЛоговТЖ)
	ТаблицаЛогов = <<?>>ПолучитьТаблицуЛоговТЖ();
26. Yashazz 3585 19.06.17 14:29 Сейчас в теме
Вопрос к уважаемому гуру: транзакция распространяется на фоновое задание, вызванное из неё? Если я вызываю выполнение фонового задания из обработки проведения, а потом транзакция откатывается, проведение не выполняется, то выполнится ли запись данных (допустим, лога действий) в некий регистр сведений, вызываемая в рамках фонового задания?
28. mickey.1cx 361 21.06.17 10:30 Сейчас в теме
(26) Фоновые задания выполняются в отдельных сеансах и их транзакции являются независимыми по отношению к транзакции модуля проведения. Соответственно, в вашем примере в фоновом задании данные в регистр сведений запишутся не смотря на * основной транзакции. Так же стоит учитывать изолированность данных этих транзакций друг от друга. Мне недавно пришлось разбирать случай, когда при проведении в форме документа в обработке проведения фоновые задания запускались для формирования движений по некоторым регистрам. В одном задании данные набора записей формировались практически сразу запросом по табличной части, во втором был предварительный расчет по другим регистрам. В результате возникали случаи, когда новый документ не успевал зафиксироваться в базе и в первом задании движения не формировались.
27. Yashazz 3585 20.06.17 13:17 Сейчас в теме
То что рассказано в курсе в разы (В РАЗЫ!!!) превосходит, то что показано тут. Тут так - краткая шпаргалка :). (Например методичка второй редакции - 360 страниц)

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

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

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

Хотя, кому-то "Андрей снова открывает нам глаза..." - кому-то и такой материал в откровение)))
30. mmch 123 03.07.17 23:42 Сейчас в теме
На всякий случай... уровень изоляции в 8.2 или с ее совместимостью, сбрасывается после каждого обновления конфигурации, видимо в момент реструктуризации
31. Blackspb 11.12.17 12:55 Сейчас в теме
При чтении – неважно, Запрос.Выполнить() или Константа.Прочитать() – вообще при любом чтении – платформа накладывала управляемую исключительную (Х) блокировку на поле, которое является разделителем данных и параллельность сразу падала.


Если я не ошибаюсь, при наличии разделителей данных, платформа накладывает исключительную блокировку при первом обращении к объектам в рамках рабочего процесса (rphost). Решением данной проблемы может быть принудительная "инициализация" объектов первым запущенным сеансом.
34. user642047_ziborov.roman 07.06.18 11:36 Сейчас в теме
Кто-нибудь знает, по какой причине может зависать наглухо 1С на следующей строке (52)?

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

Это происходит при нажатии кнопки "Протестировать подключение" из формы настроек подключения.
35. starik-2005 2231 02.09.20 17:22 Сейчас в теме
(34)
может зависать наглухо 1С на следующей строке
Кто-то забыл про таймауты, понадеявшись, что подключение будет всегда.

https://www.w3schools.com/asp/prop_conn_commandtimeout.asp
Оставьте свое сообщение

См. также

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

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

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

30.10.2017    30143    MrWonder    42    

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

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

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

07.10.2020    3179    ivanov660    12    

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

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

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

02.10.2020    3763    Nykyanen    16    

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

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

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

14.09.2020    1192    capitan    19    

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

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

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

22.04.2015    41307    Gilev.Vyacheslav    1    

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

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

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

19.08.2020    8651    YPermitin    30    

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

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

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

17.08.2020    474    ivanov660    0    

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

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

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

14.08.2020    10121    dmurk    30    

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

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

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

22.01.2014    67647    yuraos    112    

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

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

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

20.07.2020    2012    Филин    7    

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

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

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

25.06.2020    2895    ivanov660    12    

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

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

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

24.05.2020    7797    DataReducer    22    

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

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

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

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

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

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

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

18.05.2020    2203    Aleksey.Bochkov    4    

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

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

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

06.04.2020    12284    YPermitin    0    

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

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

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

03.04.2020    4770    feva    15    

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

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

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

19.02.2013    54928    Gilev.Vyacheslav    46    

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

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

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

31.03.2020    13508    informa1555    31    

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

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

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

31.03.2020    3207    vasilev2015    9    

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

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

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

20.03.2020    5362    vasilev2015    26    

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

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

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

11.02.2013    30194    gallam99    19    

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

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

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

18.03.2020    7454    kaliuzhnyi    43    

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

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

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

17.02.2020    10242    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    43039    madmpro    32    

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

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

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

23.01.2020    6563    darkdan77    59    

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

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

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

23.01.2020    8173    Kaval88    26    

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

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

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

19.12.2019    12166    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    7806    EugeneSemyonov    11    

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

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

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

14.10.2019    18317    YPermitin    28    

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

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

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

13.09.2019    9216    Repich    5    

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

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

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

10.09.2019    19063    Sloth    24    

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

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

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

09.09.2019    8757    2tvad    17    

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

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

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

19.07.2019    9098    Филин    12    

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

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

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

16.07.2019    10288    fhqhelp    0    

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

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

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

02.07.2019    11573    igordynets    119    

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

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

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

27.06.2019    9977    YPermitin    17    

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

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

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

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

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

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

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

13.06.2019    12852    Repich    117    

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

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

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

13.06.2019    5985    slayer-ekb    10    

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

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

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

11.06.2019    26072    dmurk    146    

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

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

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

28.05.2019    20207    ivanov660    10    

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

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

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

21.05.2019    8089    vasilev2015    21    

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

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

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

20.05.2019    7280    zhichkin    15    

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

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

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

29.04.2019    24106    comol    198    

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

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

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

26.04.2019    14360    kuzyara    13