Кейс: как мы разрабатывали систему автоматизации анализа ошибок, связанных со скоростью работы 1С

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

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

Бурмистров Андрей рассказывает о создании инструмента по автоматизации анализа неоптимальных запросов в коде 1С. Он поднимает вопрос о предпосылках создания этого инструмента, рассказывает о возникших форс-мажорных ситуациях, с которыми столкнулась команда в процессе разработки, и о том, как они с ними справлялись.

Меня зовут Андрей Бурмистров. Я читаю курс по повышению производительности 1C команды gilev.ru – занимаюсь обучением людей тому, как ускорять 1С и решать проблемы производительности. И сегодня я хочу поделиться с вами опытом создания нашей командой инструмента по автоматическому поиску проблем в коде (в частности, в запросах), с возможностью анализа способов решения этих проблем.

Предпосылки создания инструмента

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

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

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

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

В итоге мы решили автоматизировать анализ запросов в системе.

Вроде бы, все понятно – есть код конфигурации и текст запроса. Берем код, ищем там запросы, выделяем неоптимальные места – ничего сложного.

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

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

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

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

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

Первые трудности

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

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

Также у нас было пожелание, чтобы весь инструмент целиком был написан на коде 1С. Но на 1С это работало очень медленно, поэтому сейчас мы строим дерево запроса, используя возможности Java. Надо отметить, что если бы наш человек, который писал код, не занимался Java, мы бы этот инструмент, наверное, так и не написали до сих пор.

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

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

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

Основные принципы работы инструмента

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

Проактивный подход основан на прогнозных алгоритмах. Это когда у нас есть текст запроса, и мы анализируем этот текст, не выполняя его. Например, мы можем проанализировать программный модуль на 20 000 строк кода и найти по тексту в нем неоптимальные места.

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

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

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

Анализ всей конфигурации для поиска проблем в ней – задача нетривиальная. Представьте, что у вас есть текстовый файл с 20 000 строк программного кода, и вам нужно выбрать оттуда запросы. Как это сделать? Регулярки? Просто найти запросы по ключевым словам? Если мы хотим в будущем научить инструмент находить в коде запросы в цикле и анализировать их, то здесь регулярки нам уже не помогут.

В результате, наш инструмент анализирует программный код и строит из него синтаксическое дерево – разбирает по кускам код в дерево значений.

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

Сначала мы решили реализовать наш инструмент целиком на 1С. Но представьте себе текстовый модуль на 30 000 строк, по которому надо построить синтаксическое дерево – на языке 1С даже на мощном оборудовании это выполнялось очень долго.

Поэтому мы реализовали сервис, который превращает программный модуль в дерево с помощью кода на Java. Это сразу дало ускорение в 14 раз как минимум.

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

Разбор конфигурации – это очень затратная операция.

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

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

Подводные камни, с которыми мы столкнулись

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

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

Если у вас где-нибудь используется подобная конструкция, то от нее лучше избавляться. Даже если обернуть ее в «Попытку-Исключение», она все равно приводит к падению. Видимо, есть какая-то ошибка платформы – когда-то воспроизводится, когда-то нет.

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

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

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

  • Сначала мы большое дерево значений для передачи в сервис сериализовывали с помощью «ЗначениеВСтрокуВнутр» – объем данных получался большой.
  • После этого мы решили сначала помещать дерево значений в хранилище значений, и потом уже для хранилища значений делать «ЗначениеВСтрокуВнутр» – объем данных стал гораздо меньше, чем первый.
  • Есть подозрение, что если мы загрузим дерево значений в XML, потом XML упакуем в хранилище значения, для которого сделаем «ЗначениеВСтрокуВнутр» и этот результат будем передавать, то объем данных будет еще меньше.

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

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

Сначала этот справочник был каких-то необъятных размеров, причем его индексы были гораздо больше, чем сами данные. Нам пришлось перестроить эту структуру. Мы поняли, например, что такие служебные индексы, как «Наименование» и «Код» в нашей ситуации не актуальны, поэтому наименование мы сократили до нуля, чтобы платформа для него индекс не создавала.

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

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

Интересная ситуация получилась с работой интерфейса.

Напомню, мы сделали инструмент, который показывает вам неоптимальные места не просто в запросе, а в коде всей конфигурации. Как видно на слайде, слева отображается некий аналог дерева конфигурации, а справа – место в коде. Но представьте, что программный модуль у вас занимает, допустим, 50 000 строк, и вам при клике с одной стороны нужно моментально и быстро отобразить данные с другой стороны, при этом подсветить, в какой строке проблема. Сначала это было сделано типичным для 1С образом, т. е. с сервера все дерево с данными передавалось на клиент. Это было невыносимо долго. Даже не пять и не десять секунд, а вплоть до минуты. Скорость была очень низкая. Наша ошибка заключалась в том, что все эти тысячи строк дерева человек вряд ли вообще откроет – он посмотрит лишь ограниченное количество строк дерева, а остальные никогда не откроет. Это – «избыточный» переданный объем. После оптимизации дерево рекомендаций стало открываться практически мгновенно.

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

Представьте, что у вас есть 50 000 строк текста, из которого вам нужно сделать HTML-документ – для этого вам нужно перебрать все строки в цикле, и на выходе получить HTML-документ. Самый простой способ – это конкатенация строк, и, если строк относительно мало (допустим, 1 500), то конкатенация работает приемлемо, 3 000 строк – уже обрабатываются примерно половину секунды, а если строк становится больше 5 000, то конкатенацию использовать уже неоптимально.

В 8.3.10 появилась замечательная возможность работы с потоками. Дело в том, что новый объект «Поток данных» работает с памятью немного иначе, чем строки. И поэтому при работе с большими объемами данных (большими объемами строк), как в этом случае, он значительно выигрывает.

На слайде вы можете увидеть, какая получается разница. Когда 45 000 строк, конкатенацию можно не дождаться несколько минут, а потоки работают всего лишь за 15 секунд. Это я к тому, что наверняка у кого-то 1С используется не только для задач автоматизации учета. Может быть, вы на 1С еще какие-то интересные задачи автоматизируете. Есть такой новый объект – можете его использовать, в некоторых случаях он дает очень ощутимый эффект при работе со строками.

Что ускорить не получилось

К сожалению, некоторые моменты в нашем инструменте ускорить не получилось, даже нам с нашим опытом.

Например, это отчет по проблемным местам. Берем конфигурацию, загоняем ее в инструмент, он ее анализирует. В итоге, можно либо интерактивно посмотреть, какие там проблемы, либо сформировать отчет и потом его почитать, отправить по почте руководству. Сам отчет формируется где-то 1% времени, а остальные 99% времени платформа 1С просто сохраняет этот отчет в XLS. Это происходит долго и, к сожалению, повлиять на это нельзя. Если вы планируете формировать и сохранять в Excel какие-то отчеты, где несколько тысяч строк, будьте готовы к тому, что это будет долго.

На слайде показан пример такого отчета по проблемным местам. Видно:

  • объект, в котором есть какая-то проблема;
  • модуль, который эту проблему содержит;
  • строка в этом модуле;
  • сам проблемный текст запроса;
  • и отображается рекомендация, которая позволяет решить эту проблему.

Выполняете рекомендацию, и проблема уходит.

Заключение

Для интереса мы решили прогнать через инструмент несколько типовых конфигураций.

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

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

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

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

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

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. tsukanov 27.08.18 19:06 Сейчас в теме
Поэтому, если вдруг вы на 1С решаете какие-то задачи, не связанные напрямую с учетом, а связанные, например, с обработкой больших объемов текстовых данных – подумайте о других инструментах, не об 1С. Это даст вам ускорение не то что в разы, а на порядки.

В целом так, но зависит от объема на самом деле. Исходный код ERP можно разобрать в AST в пределах 15-20 минут. Это достаточно быстро для многих задач.

Самый простой способ – это конкатенация строк, и, если строк относительно мало (допустим, 1 500), то конкатенация работает приемлемо, 3 000 строк – уже обрабатываются примерно половину секунды, а если строк становится больше 5 000, то конкатенацию использовать уже неоптимально.

Конкатенация - это же СтрСоединить()?
Что-то не верится, что на потоках можно сделать быстрее, чем эта функция )
4. Dem1urg 313 27.08.18 22:22 Сейчас в теме
(1) Конкатенация это
Стр = Стр + КакаяТоСтрока;
Она медленная на больших объемах данных. Иногда очень медленная.
А вот СтрСоединить работает быстрее из-за другого механизма выделения памяти.
5. tsukanov 27.08.18 22:42 Сейчас в теме
(4) Хм, если автор имел ввиду обычную конкатенацию, то вообще непонятно к чему это было сказано. Понятно что ее нельзя использовать. СтрСоединить() доступна с версии 8.3.6 - странно не знать об этом
6. Dem1urg 313 28.08.18 09:28 Сейчас в теме
(5) Я вот не знал до недавнего времени.
10. Gilev.Vyacheslav 1852 28.08.18 17:00 Сейчас в теме
(5) надо делать поправку на время, так доклад был не вчера, а материал готовился еще раньше и тогда у нас долгое время стоял стабильный релиз 8.3.4
с появлением новых возможностей мы перешли на 8.3.10 и уже давно используем СтрСоединить(), но это не самый быстрый способ и используем его только как план Б если отдельный сервер выделенный только под парсинг не будет доступен например в силу аварии
если у нас получилось парсить быстрее чем платформа, то в принципе при желании и разработчики платформы конечно могут в будущих релизах ускорить работу методов парсинга (в том числе за счет многопоточности)

смысл доклада был показать способы решения проблем, проблема может быть любая, тут важнее не загонять себя в шаблонное мышление
надеюсь мне удалось пояснить
11. tsukanov 28.08.18 17:23 Сейчас в теме
(10) Понятно, спасибо. Было бы здорово, если бы вы написали (статью?) о том, как можно сделать быстрее чем СтрСоединить(). Сам пробовал использовать потоки для задач парсинга (казалось ускорит), но со строками все равно получалось быстрее.
18. Gilev.Vyacheslav 1852 29.08.18 17:54 Сейчас в теме
(11) было бы время, мы бы каждый второй оптимизированный запрос статьей описывали, так как доработки типовых каждый раз чем то "новым" удивляют
а свертка резервов через блокировку константы в проведении документов это вообще можно психологический анализ автора конфигурации раскрыть в стиле "что такое ошибка в ДНК"
но увы, за это не платят
будут силы - напишем
иногда некоторые кейсы добавляем в курсы, но все не впихнешь )))
надеюсь на инфостарт следующего года что то приготовим
2. Gilev.Vyacheslav 1852 27.08.18 19:35 Сейчас в теме
текущий вариант http://www.gilev.ru/review/ с выгрузкой конфы, заливкой к нам и обсчетом конфигурации занимается несколько часов, если речь про большие конфигурации типа ERP, если самописные конфы то весь процесс занимает меньше часа
3. genayo 27.08.18 20:32 Сейчас в теме
Пока сама 1С не начнёт применять подобные инструменты при написании типовых - на оптимизаторов будет спрос...
9. Steelvan 28.08.18 15:44 Сейчас в теме
(3) Оставляя неинформативные и бесполезные комментарии в темах с умным содержанием вы поднимаете чувство собственного величия ?
Типа, в умной беседе поучаствовал ?
7. shura_k 28.08.18 09:40 Сейчас в теме
Сразу вопрос - вы проверили типовые конфигурации, в частности Бухгалтерию.
Есть ли в результате проверки комментарии по улучшению производительности закрытия месяца, перепроведению документов в последовательности?
8. Gilev.Vyacheslav 1852 28.08.18 12:57 Сейчас в теме
(7) да, и не только
хотя часто слышим веру в безошибочность типовых
большинство отчетов в типовых построено на СКД, так вот вместо того чтобы наложить отборы на скуле сразу, тянутся избыточные данные на сервер 1С и только там этот отбор накладывается, из-за чего типовые решения получили репутацию жрущих оборудование продуктов
12. zqzq 21 29.08.18 09:31 Сейчас в теме
(8) Не понял по поводу СКД. Она же в запрос подставляет отборы, кроме редких случаев. Можно посмотреть результирующий запрос в консоли СКД.
15. Gilev.Vyacheslav 1852 29.08.18 17:41 Сейчас в теме
(12)
редких случаев
видимо не такие уж и редкие
особенно универсальные отчеты...
сначала куча строк с сервера субд доезжает до сервера 1С где в ОЗУ дальше крутится обсчет и манипуляции, ну и собственно проблема в факте такого "приезда на сервере 1С", т.е. это концептуально не очень красивая идея
конечно у всех решений есть минусы и плюсы
но одно дело когда СКД мы в ларьке запускаем и там это добро, и другое дело в ERP, которая чаще всего сотни пользователей - там это зло

а уж новый поиск по всем колонкам на субд в формах последних типовых (когда номер документа искать нужно только в одной колонке) для меня вообще загадка, мегазло
13. Yashazz 3293 29.08.18 13:12 Сейчас в теме
Когда-то сам для себя написал систему разбора кода и запросов, успешно ею пользуюсь. Скажите, коллеги, а как вы делали (и делали ли вообще) анализ ОписанийОповещений и передачи управления по ним, это ведь уже анализ кода на уровне ИИ?
14. minimajack 63 29.08.18 15:00 Сейчас в теме
(13)
Пока что наш инструмент работает только с запросами, но развивать его можно бесконечно.

я сомневаюсь что есть изменения =)
17. Gilev.Vyacheslav 1852 29.08.18 17:49 Сейчас в теме
(14) уже не только, но анонсируем когда наступит время
16. Gilev.Vyacheslav 1852 29.08.18 17:48 Сейчас в теме
(13) мы продукт продаем за деньги, мы на него потратили несколько лет и n-цать рублей - подробности алгоритма и кода тут не будут
ИИ в нашем продукте нет, выше описано - "экспертная система" со всеми вытекающими из этого определения, думать за человека наш анализ не будет, работает по паттернам, но всё необходимо эксперту для оптимизации кода "найдет"
в процессе анализа проанализированная часть доступна сразу, по окончанию анализа приходит письмо
19. minimajack 63 30.08.18 12:41 Сейчас в теме
(16)
мы на него потратили несколько лет и n-цать рублей - подробности алгоритма и кода тут не будут
ИИ в нашем продукте нет, выше описано - "экспертная система" со всеми вытекающими из этого определения, думать за человека наш анализ не будет, работает по паттернам, но всё необходимо эксперту для оптимизации кода "найдет"
в процессе анализа проанализированная часть доступна сразу, по окончанию анализ

Сообщаете ли вы о найденных "косяках" в 1С ?
Почему не храните модули целиком, а собираете построчно?
Java у вас только для AST-построения, или и для анализа?
20. Gilev.Vyacheslav 1852 30.08.18 15:27 Сейчас в теме
(19) Мы не можем сообщить напрямую в 1С, так как фирма 1С так барикадируется от помощи подписками на ИТС, регистрацией анкет и прочими заградительными мерами. Такая возможность есть у наших клиентов. Как правило такие фирмы как 1С-Рарус, Инталев, Акселот и т.п. через наших клиентов получают информацию. В некоторых случаях ревью кода целиком. Что происходит дальше мы не отслеживаем.

Анализ происходит кодом 1С потому что так удобней обслуживать. Java у нас преимущественно используется когда к базе постгреса в среде линукса надо добраться "снаружи" без "внешних источников". Мы стараемся избегать внешних по отношению к 1С технологий, но не всегда получается. Как мы используем java был доклад на конференции PGconf

Модули хранятся в разных разрезах. Если у вас проанализирована база, то когда вы запускаете наш сервис QueryTj анализа долгих запросов, то туда подтягивается несколько разрезов. Можно увидеть сам модуль в том числе в одном из разрезов. Разумеется если ревью не включен и не собран, то сервис не покажет этот блок. Главный плюс такой комбинации увидеть пересечение теоретического с практической интенсивностью и вкладом замеделния, чтобы выбрать наиболее ценные рекомендации.

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

См. также

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

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

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

30.10.2017    29203    MrWonder    42    

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

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

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

20.07.2020    1589    Филин    6    

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

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

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

25.06.2020    2312    ivanov660    12    

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

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

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

24.05.2020    6595    DataReducer    22    

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

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

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

22.04.2015    40446    Gilev.Vyacheslav    1    

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

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

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

18.05.2020    1880    Aleksey.Bochkov    3    

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

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

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

06.04.2020    10663    YPermitin    0    

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

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

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

03.04.2020    3614    feva    14    

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

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

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

22.01.2014    66887    yuraos    112    

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

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

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

31.03.2020    11850    informa1555    28    

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

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

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

31.03.2020    2985    vasilev2015    9    

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

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

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

20.03.2020    4397    vasilev2015    21    

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

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

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

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

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

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

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

18.03.2020    6513    kaliuzhnyi    43    

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

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

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

17.02.2020    8627    Evil Beaver    13    

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

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

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

19.02.2013    54436    Gilev.Vyacheslav    46    

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

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

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

23.01.2020    6204    darkdan77    59    

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

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

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

23.01.2020    7418    Kaval88    26    

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

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

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

19.12.2019    10561    ivanov660    16    

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

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

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

11.02.2013    29865    gallam99    19    

Весёлые картинки о работе 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    7282    EugeneSemyonov    11    

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

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

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

14.10.2019    17038    YPermitin    28    

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

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

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

13.09.2019    8753    Repich    5    

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

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

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

03.11.2012    42080    madmpro    32    

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

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

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

10.09.2019    18008    Sloth    24    

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

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

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

09.09.2019    8268    2tvad    17    

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

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

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

19.07.2019    8733    Филин    12    

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

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

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

16.07.2019    9506    fhqhelp    0    

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

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

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

02.07.2019    11032    igordynets    119    

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

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

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

27.06.2019    9657    YPermitin    16    

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

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

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

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

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

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

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

13.06.2019    12404    Repich    117    

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

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

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

13.06.2019    5769    slayer-ekb    10    

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

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

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

11.06.2019    23895    dmurk    144    

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

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

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

28.05.2019    18281    ivanov660    9    

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

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

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

21.05.2019    7831    vasilev2015    21    

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

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

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

20.05.2019    7065    zhichkin    15    

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

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

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

29.04.2019    22091    comol    198    

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

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

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

26.04.2019    13990    kuzyara    12    

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С

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

С версии 1С 8.3.14 в платформе появился новый функционал «Копии базы данных». В данной публикации я хочу рассказать, как включить использование данного механизма в платформе 1с и как его использовать для получения отчетов с копии базы данных, которая может быть вынесена на внешний сервер относительно текущей базы данных, а также как использовать систему «Дата акселератор», в которой база данных целиком размещена в оперативной памяти рабочего сервера кластера серверов «1С:Предприятия».

25.04.2019    13608    Elf1k    27    

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С

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

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

18.04.2019    28584    ivanov660    77    

Как разбить базу на файлы и не сойти с ума

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

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    15439    YPermitin    30    

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз

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

В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

18.03.2019    15420    w.r.    23    

Простое программное решение проблем с блокировками SQL

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

Описание одного из способов программного решения проблемы блокировок при проведении документов в клиент-серверной 1С.

06.03.2019    8850    dmitrydemenew    38