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

11.02.13

База данных - HighLoad оптимизация

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

Технология параллельных вычислений для 1С 8.2

 

Введение

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

Что такое технология параллельных вычислений?

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

      Как видно из рис.1 (см. ниже), из приложения последовательно передаются запросы для параллельного выполнения на сервере БД. После получения выборок запросов данные передаются в приложение и могут дальше обрабатываться.

 Основные сложности применения технологии параллельных вычислений:

- Оценить возможность применения параллельных вычислений для запросов.

- Сложность адаптации и внедрения в прикладное решение.

      В своем решении мы попытались нивелировать сложности насколько это возможно для уменьшения трудозатрат при внедрении .

В чем секрет ускорения?

    Часто заблуждением является тот факт, что при покупке многопроцессорного сервера или работы с многопоточной программой все операции пользователя информационной системы распараллеливаются. Если мы говорим о конкретном сеансе пользователя с последовательным выполнением конкретного функционала приложения – то даже на многоядерном сервере не используется более одного процессора (не берем возможность распараллеливания запроса средствами MS SQL – это немного другая специфика). Таким образом, увеличение аппаратных ресурсов серверов приводит к увеличению скорости совокупной многопользовательской работы, но не увеличению линейной скорости отдельного пользователя.

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

Для каких ситуаций применимы параллельные вычисления?

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

- Запросы для параллельного выполнения должны быть полностью независимы друг от друга.  Под этим понимается следующее: возвращаемые данные одного запросы не влияют на формирование текста другого.

- Нельзя/очень осторожно использовать параллельные вычисления в транзакции.

Несколько основных рисков:

  1. Запрос из параллельной сессии не видит измененные в транзакции данные (кроме запросов с грязным чтением).
  2. Запрос может накладывать блокировки на уровне MS SQL.
  3. Необходимость связывания с транзакцией основной сессии пользователя.

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

- Реализована только для OleDB (ADO, Native) – MS SQL систем.

- Запрос для распараллеливания возвращает только одну выборку (recordset). Для систем 1С 8 – запрос может состоять из последовательности запросов (например, создание виртуальных таблиц, заполнение и прочее), запрос программы на произвольном языке (Delphi, C++ … ) состоит из одной конструкции и одной выборки.

Таким образом, наиболее реальная область применения в 1С 8 –распараллеливание запросов 1С при формировании больших отчетов и обработок. В других системах на других языках  – на усмотрение программиста/архитектора.

 Как проверить на практике (технология внедрения в информационную систему)?

    Подробнее о технологии внедрения можно почитать: http://softpoint.ru/article_id4224.htm

 


 

См. также

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    2335    spyke    25    

38

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7345    148    ZAOSTG    66    

95

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5760    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8573    ivanov660    6    

75

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    4998    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

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

11.10.2023    15954    skovpin_sa    14    

97

Как эффективно настроить autovacuum в Postgres для 1С

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

Кто не любит убирать мусор? Думаю, практически все, а вот в Postgres это обязательный ритуал для эффективной работы. Как эффективно настроить уборку за 1С в Postgres, можно прочитать в этой статье и еще раз задуматься о бесплатности Postgres.

05.08.2023    4971    1CUnlimited    5    

51
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. p1l1gr1m 11.02.13 12:28 Сейчас в теме
Все же самое главное не описано - как именно работает ваша компонента? Неплохо было бы написать хотя бы общий обзор технологии.
2. gallam99 237 11.02.13 12:37 Сейчас в теме
(1) Там приложена схема, лучше нее боюсь ничего не расскажет.
Кратко:
Код 1С можно прочитать самостоятельно, там все понятно.
На первом шаге мы передаем все запросы 1С, которые необходимо выполнить параллельно, дальше в отдельном потоке с отдельным спид они выполняются.

На втором шаге ждем выборок от запросов 1С и их обрабатываем дальше по алгоритму.

Реализована на OLEDB (поэтому это обязательное требование).
Могу ответить на конкретный вопрос!?
3. kapustinag 12.02.13 01:46 Сейчас в теме
Интересно. Но вроде бы очень тяжело настраивать, нет? Каждый запрос по кирпичикам разложить, а запросов в отчетах/обработках 1С-ных немало. Кстати, а как влияет тот факт, что к запросам, в явном виде присутствующим в коде обработки, перед передачей на MS SQL добавляются запросы для фильтрации по правам доступа?

То есть в результате на сервер может прийти не совсем то, что ожидалось, и что с таким трудом на независимые запросы поделили.
4. kapustinag 12.02.13 01:49 Сейчас в теме
Или имеются в виду только запросы к внешним не-1Сным базам? Тогда согласен, без трудноучитываемого влияния ограничений в 1С-ных ролях вполне можно эти запросы построить как нужно для параллельного выполнения.
5. gallam99 237 12.02.13 09:28 Сейчас в теме
- По поводу запросов для фильтров, должно все работать.
Параллеляться штатные запросы 1С.

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

И если более широко рассмотреть, то основная сложность параллельных вычислений - адаптировать последовательный код к ним и их правильно применить (не только к задачам 1С)
6. ValeriVP 1301 12.02.13 11:02 Сейчас в теме
А зачем нужна компонента? Если надо руками разделить запрос 1С на параллельно исполняемые подзапросы, то почему бы не использовать просто фоновые задания?
for_sale; TSSV; +2 Ответить
7. gallam99 237 12.02.13 11:15 Сейчас в теме
Основное преимущество компоненты в том, что адаптация к параллельным вычислениям осуществляется в тексте отчета, оно более простое (пример распараллеливания запросов 1С дан), будет более производительным, чем фоновые задачи и потреблять меньше ресурсов.
И еще ... предполагается, что вы не разделяете запрос 1С, а ищете несколько запросов 1С, которые можно выполнить параллельно и с помощью технологии реализуете это. Найти их можно, например, через отладчик 1С - получаете информацию из отладчика, почему отчет медленно выполняется - например, 30 раз выполняется запрос 1С, но с различными параметрами - это уже предпосылка для их паралелльного выполнения.
8. ValeriVP 1301 12.02.13 11:34 Сейчас в теме
(7)Прокоментируйте пожалуйста: "будет более производительным, чем фоновые задачи и потреблять меньше ресурсов."
Почему?
Также: "предполагается, что вы не разделяете запрос 1С, а ищете несколько запросов 1С, которые можно выполнить параллельно..." - можете привести хотябы один пример?

Из моей практики - запросы в цикле с разным набором параметров - это методическая ошибка. Гораздо более вероятная ситуация исполнения запроса в цикле - это случай, когда каждый следующий запрос использует результаты предыдущего (ну не можем мы написать сразу один запрос по каким-то причинам). А это распараллелить нельзя.
18. vasyak319 150 20.03.15 15:18 Сейчас в теме
(7)
30 раз выполняется запрос 1С, но с различными параметрами - это уже предпосылка для их паралелльного выполнения


Это предпосылка для отрубания рук, которые такое напейсали. Я с 1С с прошлого века работаю, но не могу вспомнить ни одной задачи, для решения которой действительно было бы нужно параллельно выполнить несколько запросов. Причём решения такие я видел много раз, но в 100% случаев это было следствием рукожопости программиста и всё ускорялось в десятки, а то и сотни раз простенькой оптимизацией наиболее вопиющих кусков кода.
for_sale; FractonKireyev; +2 Ответить
9. gallam99 237 12.02.13 12:00 Сейчас в теме
Комментирую - производительней = будет работать быстрее, так как распараллеливаются уже запросы SQL на этапе отправки к серверу MS SQL. В фоновых заданиях вы распределяете запросы в структурах 1С, а это неизбежная потеря времени и ресурсов.

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

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

Мы использовали у себя технологию следующим образом: в отчете клиента написаны запросы 1С к различным регистрам, немного переписали отчет для выполнения их последовательно (с обработкой выборки в другой части отчета) и адаптировали к параллельному выполнению. Затраты с нашей стороны: 1 чел/день, эффект - скорость выполнения отчета в 3 раза. При этом не было глубокого погружения в логику отчета - что в данной ситуации является преимуществом на мой взгляд.
10. ValeriVP 1301 12.02.13 12:25 Сейчас в теме
В фоновых заданиях вы распределяете запросы в структурах 1С, а это неизбежная потеря времени и ресурсов.

Правильно ли я понимаю, что речь идет о потере времени на трансляцию запроса 1С в запрос SQL?
В этом случае - это бред. Это время пренебрежительно мало.

у клиента 100 различных отчетов не устраивающих по производительности

В этом случае надо менять железо, т.к. фактически это означает - все отчеты.

если количество строк в отчете 10000
- если это не считая текстов запросов, то это очень сложный отчет. Велика вероятность наличия запросов которые можно распараллеливать, если они конечно не в цикле. Годный пример.

Таким образом, есть пример когда имеет смысл распараллелить запросы, однако нет обоснования, зачем надо использовать для этого какую-то компоненту.
11. gallam99 237 12.02.13 13:26 Сейчас в теме
(10)
"Правильно ли я понимаю, что речь идет о потере времени на трансляцию запроса 1С в запрос SQL?
В этом случае - это бред. Это время пренебрежительно мало. " - мы проводили сравнения, а Вы? Оно не пренебрежительно мало)))

"В этом случае надо менять железо, т.к. фактически это означает - все отчеты. " - не правильно (кстати типовая ошибка), надо понять почему медленно отрабатывает, менять железо только если узкое место в железе (и то при оптимальных запросах).
Для больших компаний и больших БД - параллелизм бывает единственным вариантом ускорения минимальными трудозатратами.

"Таким образом, есть пример когда имеет смысл распараллелить запросы, однако нет обоснования, зачем надо использовать для этого какую-то компоненту." - как бы Вам пояснить, чтобы понятно было.
Всегда для решения каких-то задач требуется инструментарий. Инструментов бывает несколько, каждый программист тестирует и выбирает для себя что лучше использовать. Мы занимаемся созданием подобных инструментов (на рынке немного компаний которые это делают) и предоставляем Вам, в данном случае бесплатно.
Если Вы пока с чем-то не сталкивались в решении проблем производительности (в частности распараллеливанием), это не значит что не столкнетесь в будущем. Мы лично применяли все доступные технологии на рынке и успешно для больших компаний.
12. ValeriVP 1301 12.02.13 14:04 Сейчас в теме
Оно не пренебрежительно мало

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


не правильно (кстати типовая ошибка)

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

Мне непонятно, почему имеет смысл использовать какую-то проприетарную библиотеку для задач, которые вполне решаются средствами 1С.
Вместе с тем, я сталкивался с проблемами производительности, часть из которых решалась в сотрудничестве с SoftPoint.
Однако в данном случае, на мой взгляд интересна только идея, а реализация неправильная - избыточная и не универсальная. Например, как быть при использовании не MS SQL?
13. ValeriVP 1301 12.02.13 14:09 Сейчас в теме
и еще - правильно ли я вас понял, что ваша компонента транслирует запросы 1С в запросы SQL на порядок быстрее? а как на счет RLS?
14. gallam99 237 12.02.13 15:53 Сейчас в теме
А какая сложность с RLS?
Про универсальность "избыточная и не универсальная" - смотря с какой стороны посмотреть: а если не 1С, но MS SQL? В чем не универсальность? 1С - одна из систем с MS SQL, но список этим не ограничивается. Вместо написания потоков и прочего вам дана возможность в последовательном коде любого приложения выполнять параллельно запросы (Хранимые процедуры), да что угодно.

Про %, тут нельзя сказать однозначно для всех случаев. Но можете провести эксперимент:
Запустите в цикле большое количество фоновых задач (в которой выполните запрос) и сделайте замер, и напишите приложение (на любом языке, например, С++) - в котором создаете поток с выполнением запроса SQL и уничтожаете такое же количество раз (как в примере в фоновыми заданиями). Посмотрите разницу и потребление ресурсов.

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

Надеюсь я ответил на ваши вопросы
15. OBEH 13.02.13 05:17 Сейчас в теме
На прямую к данной теме мое сообщение не относится. Но так, для примера.
Несколько лет назад по совету одного продвинутого программера использовал его dll для ускорения отчетов.
Кое как разобрался с механизмом и все такое. В общем, был немало удивлен, когда скорость отчетов, реально, увеличилась в 10 раз. Конфигурация была не моя и переделывать написанное не было желания, а этот механизм решал проблему неплохо.
Через некоторое время звонит бухгалтер и говорит, что "ни фига, скорость стала прежняя". Приезжаю, тестирую. Скорость в 10 раз выше. Ничего не понимаю. Потом догадался запустить параллельно с другого компа. Действительно, скорость упала до прежнего. Выяснилось, что при обращении к ресурсу(в данном случае, к базе) Windows 2003 "снимает" кэширование считываемых данных в оперативной памяти. Так что, мнимая "многозадачность" Windows 2003, декларируемая мелкомягкими, оказалась на поверку декларацией.
16. vec435 15 13.02.13 08:51 Сейчас в теме
немного не понял: если в пакетном запросе идет последовательное получение временных таблиц и данные одной таблицы есть источник для другой то как распараллелить?
17. gallam99 237 13.02.13 09:03 Сейчас в теме
В данном решении можно параллелить только "независимые" запросы 1С.
Оставьте свое сообщение