Адекватный параллелизм в 1С
Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1) Все достаточно тривиально - механизм фоновых заданий. Например, у вас в выборке 1000 элементов. Разбейте выборку на 2 порции по 500 и распараллельте через запуск 2х фоновых заданий. Потом соберите результат, если нужно в точке ожидания. Принцип, отдалено похожий на map reduce.
(1)
(2)
Это по сути горизонтальное маштабирование вычислений, мы на нем серьезные объемы обрабатываем , но 1С к сожалению и для него имеет четкие ограничения платформы см тут
Но у Вас как понимаю из цитата и 1С и MS SQL на одном сервере
"
а это уже искажает картину
MS SQL подддерживает правильную работу c Numa node а 1С о них не знает и полагается на ОС. Это легко может привести к тому что процессы 1С и MS SQL пересекутся по ядрам и узкие места могут появлятся в любых местах
поэтому если уж играться с параллелизмом на уровне запросов то строго на выделенном сервере для СУБД , так он хотябы правильно отработает по Numa node
(2)
Это по сути горизонтальное маштабирование вычислений, мы на нем серьезные объемы обрабатываем , но 1С к сожалению и для него имеет четкие ограничения платформы см тут
Но у Вас как понимаю из цитата и 1С и MS SQL на одном сервере
"
При условии, что и 1С, и СУБД крутятся на одном сервере, начинается определенная борьба за ресурс. Если используется Windows – он как-то
сможет разрулить ситуацию, но если Linux – не знаю, насколько гибко это работает.
"
сможет разрулить ситуацию, но если Linux – не знаю, насколько гибко это работает.
а это уже искажает картину
MS SQL подддерживает правильную работу c Numa node а 1С о них не знает и полагается на ОС. Это легко может привести к тому что процессы 1С и MS SQL пересекутся по ядрам и узкие места могут появлятся в любых местах
поэтому если уж играться с параллелизмом на уровне запросов то строго на выделенном сервере для СУБД , так он хотябы правильно отработает по Numa node
Cost = M * N * Log(N)
Согласно этой формуле, чем больше работников, тем задачу по сортировке выполнить проще.
Согласно этой формуле, чем больше работников, тем задачу по сортировке выполнить проще.
А количество работников в этой формуле - это N или M? В любом случае, формула показывает линейный рост cost от количества работников.
ЗЫ: некоторые из читающих знают арифметику (я, например, хоть у меня и три класса церковно-приходской).
Чтобы быть более-менее уверенным, что у нас выполнится и будет с этого какой-то профит, лучше по возможности применять алгоритмы обработки в учетной системе. Это топорно, но чем проще, тем лучше.
Если вы все-таки включили параллелизм и надеетесь, что у вас все будет хорошо, вы должны быть уверены в том, что в вашей учетной системе хотя бы 90% запросов адекватные – что у вас все нормально со статистикой, что у вас хватает ядер, что ваши подрядчики написали запросы хорошо. Тогда во включении параллелизма есть смысл.
Если вы все-таки включили параллелизм и надеетесь, что у вас все будет хорошо, вы должны быть уверены в том, что в вашей учетной системе хотя бы 90% запросов адекватные – что у вас все нормально со статистикой, что у вас хватает ядер, что ваши подрядчики написали запросы хорошо. Тогда во включении параллелизма есть смысл.
Что из этой публикации можно почерпнуть?
1. Нормально пишите алгоритмы и запросы самой 1С. Замечательный совет)
2. Параллелизм и прочие жуткие ужасы СУБД лучше не трогать, а если трогать, то как 1С сказала, т.е. ставить 1 и отойти в сторонку, иначе хз что будет. Тоже прям открытие века)
Вывод? Полезность очень так себе. Ни о чём статья. Хороша только упоминанием моментов, которые при расследовании узких мест могут пригодиться. И всё...