TG Telegram Group & Channel
Прусаков Никита про 1С | United States America (US)
Create: Update:

«Интересный вопрос: как обстоят дела с многопоточностью в 1С? Давайте попробуем в этом разобраться.

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

Допустим у меня есть сервер с одним процессором у которого 6 ядер. В кластере работает одна база, и все настройки стоят по умолчанию, я имею ввиду параметры рабочих процессов (кол-во ИБ на процесс: 8, кол-во соединений на процесс: 256). Как вы думаете, если я запущу 6 фоновых заданий в которых будет выполняться цикл эмулирующий загрузку процессора, будут ли все 6 ядер загружены или будет загружено только одно ядро? Примем допущение, что на этом сервере больше никто и ничего не работает.

Правильно, будут загружены все ядра процессора. Но такая ситуация будет происходить, если все эти процессоры находятся в одном NUMA узле. NUMA - это архитектура , при которой некоторое количество логических процессоров объединены в группу, и общаются между собой через общую память. Такое взаимодействие между ядрами внутри numa-узла самое быстрое. Отсюда и название Non-Uniform Memory Access (неравномерный доступ к памяти).

Таким образом, если один rphost стартовал в одном numa-узле, то использовать ли ядра другого numa-узла будет решать сама ОС. ОС при обработке поступающего запроса, может отказаться выбирать свободные процессоры, из-за того что используют другой сегмент выделенной памяти. Почем так? Потому, что полноценная поддержка NUMA в 1с пока не реализована.

Выдержка из технологических вопросов крупных внедрений:

На многопроцессорных системах на одном сервере должно работать больше одного процесса rphost.

Следует иметь в виду, что поддержка NUMA в кластере серверов "1С:Предприятия" полноценно пока не реализована.

Сервер 1С не управляет распределением ресурсов по NUMA узлам, полностью полагаясь в этом на операционную систему, что не всегда даёт оптимальный результат.


И тут можно наблюдать картину, когда часть ядер на сервере 1С загружена под 100%, а часть простаивает. В этой ситуации как раз помогут параметры рабочих процессов: количество ИБ на процесс, и количество соединений на процесс, которые позволяют регулировать количество rphost-оф.

При этом нельзя забывать про ограничение платформы уровня ПРОФ, все эти возможности по настройке, такие как: количество ИБ на процесс, режим распределения нагрузки, безопасный расход памяти за один вызов, а также использование более 12 ядер на сервере 1С доступны только в платформе уровня КОРП.

«Интересный вопрос: как обстоят дела с многопоточностью в 1С? Давайте попробуем в этом разобраться.

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

Допустим у меня есть сервер с одним процессором у которого 6 ядер. В кластере работает одна база, и все настройки стоят по умолчанию, я имею ввиду параметры рабочих процессов (кол-во ИБ на процесс: 8, кол-во соединений на процесс: 256). Как вы думаете, если я запущу 6 фоновых заданий в которых будет выполняться цикл эмулирующий загрузку процессора, будут ли все 6 ядер загружены или будет загружено только одно ядро? Примем допущение, что на этом сервере больше никто и ничего не работает.

Правильно, будут загружены все ядра процессора. Но такая ситуация будет происходить, если все эти процессоры находятся в одном NUMA узле. NUMA - это архитектура , при которой некоторое количество логических процессоров объединены в группу, и общаются между собой через общую память. Такое взаимодействие между ядрами внутри numa-узла самое быстрое. Отсюда и название Non-Uniform Memory Access (неравномерный доступ к памяти).

Таким образом, если один rphost стартовал в одном numa-узле, то использовать ли ядра другого numa-узла будет решать сама ОС. ОС при обработке поступающего запроса, может отказаться выбирать свободные процессоры, из-за того что используют другой сегмент выделенной памяти. Почем так? Потому, что полноценная поддержка NUMA в 1с пока не реализована.

Выдержка из технологических вопросов крупных внедрений:

На многопроцессорных системах на одном сервере должно работать больше одного процесса rphost.

Следует иметь в виду, что поддержка NUMA в кластере серверов "1С:Предприятия" полноценно пока не реализована.

Сервер 1С не управляет распределением ресурсов по NUMA узлам, полностью полагаясь в этом на операционную систему, что не всегда даёт оптимальный результат.


И тут можно наблюдать картину, когда часть ядер на сервере 1С загружена под 100%, а часть простаивает. В этой ситуации как раз помогут параметры рабочих процессов: количество ИБ на процесс, и количество соединений на процесс, которые позволяют регулировать количество rphost-оф.

При этом нельзя забывать про ограничение платформы уровня ПРОФ, все эти возможности по настройке, такие как: количество ИБ на процесс, режим распределения нагрузки, безопасный расход памяти за один вызов, а также использование более 12 ядер на сервере 1С доступны только в платформе уровня КОРП.
👍17🔥1


>>Click here to continue<<

Прусаков Никита про 1С






Share with your best friend
VIEW MORE

United States America Popular Telegram Group (US)