Вопросы разработки, анализа производительности и оптимизации приложений 1С под управлением СУБД ORACLE

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

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

Я являюсь сотрудником Комсомольского-на-Амуре филиала компании «Сухой». Наше предприятие производит боевую авиационную технику и комплектующие для гражданской авиационной техники. В статье я вам расскажу про свой опыт работы со связкой 1С и СУБД ORACLE.

Почему именно Oracle?

Находясь здесь, я для себя извлек один небольшой урок – такое сочетание, как Oracle и 1С, встречается нечасто. Это – действительно редкость. И первое, что я хотел бы объяснить, – почему именно Oracle, и как так получилось, что такая достаточно редкая СУБД используется на нашем предприятии.

Во-первых, наше предприятие достаточно давно использует в своей практике Oracle.

  • Начиная с 2000 года, у нас стартовал проект по внедрению ERP-системы на базе системы BAAN версии 4.
  • В рамках этого проекта у нас появились люди с особыми компетенциями, которые хорошо знают, как администрировать эту систему.

Кроме того, Oracle у нас себя хорошо зарекомендовала:

  • Она позволяет обеспечивать бесперебойную работу сервиса высокой доступности в режиме 24*7.
  • А также она обеспечивает высокое быстродействие обработки больших массивов данных.

Характеристика нашей системы

Первоначальные характеристики нашей системы:

Конфигурация сервера для 1С:

  • Сервер 1С у нас располагается на виртуальном сервере под управлением операционной системы Windows;
  • Оперативная память порядка 192 Gb.

Версия конфигурации – УПП, релиз 1.3;

Версия платформы 8.3.6 с поддержкой 8.2;

Что касается конфигурации сервера СУБД:

  • Сервер физический, состоит из двух узлов;
  • Работает под операционной системой Oracle Linux 6.7;
  • Оперативная память на каждом узле 1Тб. Как видите, ресурсов под сервер СУБД выделено гораздо больше, чем под сервер 1С.

Версия СУБД Oracle 12c;

Объем данных информационной базы более 1Тб.

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

  • Верхняя строчка – это основная таблица регистра накопления, содержит более 400 миллионов записей;
  • Последняя строка этого топа содержит чуть менее 100 миллионов записей. Система достаточно тяжелая, в нашей базе присутствует большой массив данных.

Можно также обратить внимание на прирост данных.

Основные проблемы, связанные с обеспечением быстродействия и масштабируемости в системах 1С в связке с Oracle

Итак, что с этим делать? Послушав своих коллег, которые рассказывали про проблемы, связанные с SQL-сервером, я порадовался, потому что большая часть этих проблем оказывается вне поля моего зрения:

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

Так что же остается актуальным в нашей ситуации?

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

Давайте поочередно посмотрим, как мы решаем эти проблемы.

 

Наш подход к разработке с учетом ориентации на Oracle

Что делать, когда возникают какие-то проблемные ситуации, которые необходимо исследовать или анализировать? За те два года, что я работаю с системой 1С, у нас в коллективе выработалась определенная методика проведения анализа и оптимизации быстродействия. Из чего она состоит?

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

Следующий этап –  более детальный анализ выявленных запросов в консоли запросов. На этом этапе запросы анализируются на языке 1С.

Третий шаг – это получение текста запросов SQL, его разбор и первичный анализ:

  • Поиск узких мест;
  • Оценка производительности;
  • Замеры производительности;
  • Включение технологического журнала;
  • Извлечение «оракловых» запросов, которые генерирует 1С.

Все это производится посредством:

  1. Технологического журнала;
  2. А также с помощью средств администрирования Oracle – таких программ, как:
  • SQL*plus – это консольная утилита, которая позволяет администратору базы данных выполнять все свои обязанности. Это достаточно удобная система, ей регулярно пользуются;
  • Отдельная бесплатная утилита SQL developer, которую распространяет Oracle;
  • Платная PL/SQL Developer.

На четвертом шаге производится непосредственно анализ SQL:

  • Получение плана;
  • Разбор этого плана;
  • Оценка его стоимости.

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

И последний шаг – это уже оптимизация. Мы пришли к каким-то выводам, нашли способ решения на стороне языка 1С и переписали запрос.

 

Использование методики проведения анализа и оптимизации запросов с использованием технологического журнала 1С и средств администрирования СУБД на примере отчета «Матрица грейдов»

Давайте теперь на примере рассмотрим, как это все может работать.

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

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

Этот отчет должен строиться таким образом:

Источником для него является регистр сведений «Результаты»:

  • Подразделения и должности выбираются из реквизитов;
  • Шкалы являются измерением;
  • А оценки – это один из ресурсов.

Теперь давайте посмотрим пошаговый алгоритм исполнения этого отчета.

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

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

Давайте последовательно рассмотрим каждый из этих запросов.

Первый запрос – это поиск документов по проекту оценки.

  • Пользователь вводит в качестве условия некий проект, в рамках которого он хочет построить отчет.
  • И запрос, обращаясь к документу «ПланированиеИКонтроль», выбирает перечень ссылок на документы, относящихся к выбранному проекту (все документы, которые участвовали в этой оценке).

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

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

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

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

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

Вот, собственно, то, как работает этот отчет в своем первозданном виде.

Какие «узкие места», по моему мнению, присутствуют в этом отчете?

Во-первых, многократная выборка данных. Мы с вами это видели:

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

Это – первое «узкое» место.

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

Итак, что можно сделать с этим отчетом?

Вариантов немного, они все на поверхности.

Мы можем в одном запросе сразу выбрать все нужные нам поля:

  • Должности;
  • Подразделения;
  • Шкалы;
  • Оценки по этим шкалам.

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

Что можно сделать в такой ситуации?

Количество шкал можно определить сразу на первом шаге. Как видно на слайде:

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

На втором шаге из временной таблицы формируется запрос. Причем его текст не просто написан руками, а на основе этого количества шкал в цикле производится так называемая склейка посредством конструкции «ВЫБОР» – мы объединяем несколько шкал и склеиваем эту строчку.

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

На слайде вы видите алгоритм после преобразования.

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

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

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

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

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

А во втором варианте отчета мы можем отметить, что быстродействие этапа «Построение и вывод» от возрастания количества обрабатываемых данных изменилось незначительно.

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

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

  • Это запрос №5 из первого варианта, который выбирает данные из регистра;
  • И запрос №1, который выбирает те же самые данные.

Итак, два запроса, которые друг от друга практически ничем не отличаются, за исключением того, что во втором запросе появились:

Обращение через точку –  Рез.Шкала.Наименование;

И создание временной таблицы – ПОМЕСТИТЬ ВТРезультат.

 

Как понять, почему, казалось бы, такие небольшие отличия запроса приводят к настолько неоптимальному результату?

Для этого можно проанализировать SQL-запросы, которые генерирует 1С и отправляет в Oracle. Тексты этих запросов были получены путем включения технологического журнала.

В чем существенное различие этих двух вариантов практически одинакового запроса?

Во втором варианте у нас появляется левое соединение к таблице справочника.

Причем, это не просто левое соединение, мы потом в процессе группировки ищем по полю «Наименование» максимум;

И еще здесь в группировке используется какая-то непонятная конструкция: то, что вы видите через точку, – это обращение к так называемой «хранимой процедуре» (в MS SQL – это хранимая процедура, а в Oracle – это просто процедура).

Чтобы понять, как эти действия влияют на сам запрос, обратимся к плану запроса. Вот он перед вами. Этот план запроса был сгенерирован в среде PL/SQL Developer. Он состоит из колонок:

  • Операция (Operation);
  • Имя объекта, к которому происходит обращение (Name);
  • Количество данных, которые выбираются – прогнозируемое количество строк (Rows);
  • Прогнозируемое количество  данных (Bytes);
  • И так называемая стоимость (Cost). Стоимость – это такая универсальная прогнозная величина, которая позволяет оценить запрос в условных единицах времени одноблочного чтения.

Итак, ориентируемся на эту стоимость.

Смотрим план первого запроса:

  • На первом шаге производится полное сканирование таблицы регистра;
  • На втором шаге происходит группировка;
  • И суммарная стоимость самого запроса – мы видим 30436.

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

Во-первых, у нас уже два полных сканирования:

  • Таблица индекса;
  • Таблица справочника. Здесь можно отметить, что полное сканирование справочника дает несущественную нагрузку – всего 11, справочник очень маленький.

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

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

Мы это сделали.

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

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

Его «Запрос 1» работает практически так же, как и «Запрос 5» из первого варианта

При этом этап «Построение и вывод» для третьего варианта работает очень быстро.

 

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

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

Для этого мы можем поставить в свойствах реквизита «Проект» значение использования «Индексировать».

Как видите, в структуре нашего регистра появился новый индекс.

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

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

 

Принципы разработки программного обеспечения базы данных с учетом особенностей 1С

 

 

 

Что следует сказать про те результаты, которых мы добились.

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

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

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

 

Противодействие замедлению в связи с приростом данных. Применение секционирования

Еще один момент, про который я хотел сказать, – это «противодействие» замедлению.

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

Мы на этот счет долго думали и решили, что помочь нам в этом может такая вещь, заложенная в Oracle, как секционирование.

Что это такое? Секционирование – это  изменение параметров хранения данных в таблицах на физическом уровне базы данных таким образом, что таблицы или индексы делятся на какие-то отдельные физические части, и СУБД уже при анализе запросов (при предоставлении данных) оперирует только какой-то одной маленькой частью, нежели всей таблицей.

У секционирования есть свои преимущества – они описаны на слайде.

Также есть разные виды секционирования.

Для нас идеальным вариантом секционирования является разбиение таблиц по диапазонам периода.

 

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

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

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

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

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

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. kiruha 384 07.09.17 10:57 Сейчас в теме
А не подскажете итоговые параметры работы пользователей - сколько выполняются реальные отчеты, сколько занимает проведение, и что делаете с рег. бухгалтерии( справляется ли такой объект) ?
2. SaschaL 07.09.17 11:01 Сейчас в теме
(0) а нет у вас случайно параметров производительности до оптимизации и после. Было бы очень интересно взглянуть.
Оставьте свое сообщение

См. также

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

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

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

30.10.2017    28661    0    MrWonder    42    

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

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

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

25.06.2020    1644    0    ivanov660    12    

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

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

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

24.05.2020    5812    0    DataReducer    22    

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

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

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

18.05.2020    1572    0    Aleksey.Bochkov    3    

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

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

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

22.04.2015    39953    0    Gilev.Vyacheslav    1    

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

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

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

06.04.2020    9831    0    YPermitin    0    

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

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

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

03.04.2020    3139    0    feva    14    

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

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

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

31.03.2020    10971    0    informa1555    21    

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

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

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

22.01.2014    66349    0    yuraos    112    

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

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

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

31.03.2020    2708    0    vasilev2015    9    

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

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

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

20.03.2020    3961    0    vasilev2015    21    

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

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

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

18.03.2020    5982    0    kaliuzhnyi    43    

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

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

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

21.06.2013    53133    0    Антон Ширяев    116    

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

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

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

17.02.2020    7914    0    Evil Beaver    13    

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

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

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

23.01.2020    5768    0    darkdan77    59    

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

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

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

19.02.2013    53804    0    Gilev.Vyacheslav    46    

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

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

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

23.01.2020    7050    0    Kaval88    26    

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

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

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

19.12.2019    9780    0    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    6841    0    EugeneSemyonov    11    

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

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

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

11.02.2013    29558    0    gallam99    19    

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

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

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

14.10.2019    16246    0    YPermitin    28    

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

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

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

13.09.2019    8409    0    Repich    5    

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

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

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

10.09.2019    17300    0    Sloth    24    

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

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

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

03.11.2012    41760    0    madmpro    32    

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

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

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

09.09.2019    7882    0    2tvad    17    

Анализ производительности APDEX

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

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

31.08.2019    9695    2    YPermitin    7    

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

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

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

19.07.2019    8394    0    Филин    12    

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

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

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

16.07.2019    9009    0    fhqhelp    0    

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

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

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

02.07.2019    10503    0    igordynets    119    

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

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

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

27.06.2019    9260    0    YPermitin    16    

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

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

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

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

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

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

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

13.06.2019    12029    0    Repich    117    

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

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

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

13.06.2019    5550    0    slayer-ekb    10    

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

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

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

11.06.2019    22679    0    dmurk    144    

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

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

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

28.05.2019    17559    0    ivanov660    9    

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

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

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

21.05.2019    7546    0    vasilev2015    21    

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

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

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

20.05.2019    6777    0    zhichkin    15    

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

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

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

29.04.2019    21061    0    comol    198    

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

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

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

26.04.2019    13657    0    kuzyara    12    

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

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

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

25.04.2019    12997    0    Elf1k    27    

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

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

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

18.04.2019    27518    0    ivanov660    77    

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

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

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

06.04.2019    14895    0    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    14916    0    w.r.    23    

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

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

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

06.03.2019    8576    0    dmitrydemenew    38