Должно давать использовать не более 12 ядер. Где посмотреть сколько ядер использует сейчас один rphost?

Одно.

(0) Этот вопрос надо задать вашему сис-админу, заодно его проф пригодность протестируете :)

(0) 1С сервер с лицензией ПРОФ сам ограничит количество ядер, с вашей стороны ничего делать не нужно.

короче никто не знает походу. Вот фейл в масштабах страны )

Процесс rphost однопоточный. Соответственно, использовать несколько ядер он не может. Тебе в (1) ответили уже

(5) с фига ли?

Начиная с 10.09.2019 пользователям ранее выпущенных лицензий (как ПРОФ, так и КОРП) станет недоступна расширенная функциональность уровня КОРП. Также начнут действовать ограничения использования лицензий при превышении 500 сеансов пользователей или использовании более 12 ядер процессора.

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

(5) "Процесс rphost однопоточный. "
Совершенно точно нет. Но на самом деле интересно, как ограничивают использование 13 и последующими ядрами. Если привязк процесса к ядрам делается, то это можно увидеть утилитами, да и так будет видно, что лишния ядра будут незаняты. Можно в принципе проверить, запустить много сеансов, в каждом по бесконечному циклу, и будет видно..

(8) "Если привязк процесса к ядрам делается, то это можно увидеть утилитами,"

И не только увидеть :-)

(8) вот и адекватные люди подтягиваются ))

"то это можно увидеть утилитами" какими? Имя, сестра, имя!

Альтернативные варианты тестирования по нагрузке могут быть только если на сервере ничего кроме 1С (никаких SQL и пр) и всего один rphost (один, сервер, кластер и т.д.)

а насчет древнего баяна седых 1с-ников про однопоточность - хоть бы инструкцию посмотрели
https://its.1c.eu/db/metod8dev#content:4136:hdoc
Современный сервер х64 прекрасно обходится без всякого шаманства )

(9) Вы имеете ввиду https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setprocessaffinitymask ?

(11) у тебя на многоядерной системе загрузка процессора процессом rphost была когда-нибудь выше, чем примерно 100/количество ядер?

(13) http://catalog.mista.ru/public/173394/

(12) Имеем. Но в 1С вполне себе спецы сидят, которым не стоит для своего процесса сделать сплайсинг где -нибудь на уровне nt или zw.

которым не стоит-> которым ничего не стоит

(15) Сплайсинг в коммерческой разработке зло, я бы периодически проверял GetProcessAffinityMask и если он неверный, то включится цветомузыка )

(0) ты сможешь запустить только 12 рабочих процессов кластера

(18) нет

(19) что нет ?

(20) ограничение на 12 ядер никак не связано с количеством рпхостов

(17) Иногда бывают случаи, когда не зло. И это даже антивиры не карают, в отличие от какого нибудь CreateRemoteThread()

Ну,также никто не мешает сказать процессу,что в системе одно ядро,когда их 64.

(23) Процессу вообще пофиг относительно ядер, для него есть потоки исполнения и всё. Ядрами процессора занимается ядро ОС. И какому ядру достанется выполнять очередной квант очередного потока - это решает операционная система в зависимости от кучи условий, включая в том числе "affinity mask", то есть привязка процесса к конкретным ядрам. То есть, процесс может при старте установить эту привязку и ядро ОС будет учитывать такое "пожелание".

(0) Одно ядро занимает rphost.
Другое дело что этих rphost можно создать несколько, это задается в консоле 1с-сервер.

(25) а разве в ПРОФ версии этим можно управлять - количеством рпхостов?

(26) Не смотрел, раньше можно было, думаю сейчас до 12 можно поставить. Но на вопрос (0) я ответил, что 1.

(25) Откуда вы это берете? Это категорически не так.

(13) dka80 - смешной вы человек. Насчет многоядерности - вам и инструкцию от вендора дали и сам автор многопоточного теста сказал. А вы все свое не аргументированное "нет" лепите.

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

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

Например, если устранить узкие места в дисковой подсистеме, и взять многопоточный тест Fragster'a, то график производительности будет расти до количества ядер, а потом рост прекратится.

У вас просто узких мест в системе полно и нагрузка слабенькая, вот и не растет утилизация процессора rphost'ами

В общем раз уж никто не ответил про сабж, значит нет возможности посмотреть в принципе.

(29) // Конечно если запустить перепроведение допустим, то этот сеанс 1С будет занимать одно ядро.

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

(30) "Если на сервере, то в условиях версии ПРОФ эти сеансы будут сидеть в одном процессе rphost и в один момент времени никак не сможет занимать более одного ядра."
Категорически неверная информация

(29) может ты ещё мне будешь рассказывать сколько ядер способен один РП заюзать?

(30) не совсме так, даже совсем не обязательно... но 1 РП - 1 ядро.

(29) если ты не заметил, то сообщение (14) идет после сообщения (13). И да, после сообщения (14) я ничего не писал

(31) Ну так укажи категорически в чем не верная. Если число сеансов будет более 128, тогда я соглашусь, что у них есть вероятность попасть в разные rphost - но это не категорически. А вот способность rphost занимать одномоментно только одно ядро - это категорически.

(26) Конечно - через кол-во соединений на процесс

(30) "сеансы будут сидеть в одном процессе rphost и в один момент времени никак не сможет занимать более одного ядра" // Конечно же смогут, нити одного и того же процесса ОС по разным ядрам прекрасно раскидываются

(35) "способность rphost занимать одномоментно только одно ядро - это категорически" // Запусти закрытие месяца в ЕРП в кластере, где один рпхост. Нагрузит фоновыми все ядра.

(35) "А вот способность rphost занимать одномоментно только одно ядро - это категорически."
Нет, rphost может занимать много ядер. Он многопоточный. Каждый серверный вызов создает поток.

(33) От тебя точно такого не ожидал)

Откуда вы эту дичь тащите про одноядерность rphost ?

Вас Псаки покусала штоле?

"Не учатся ничему некоторые и учиться не хотят. Кина американского насмотрелись или крышу срывает от жадности? Ты ему про аномалии, он тебе про хабар. Ни о чем думать не хотят кроме бабок. Пока кишки по веткам не разбросает."

Народ вы чего? Посмотрите как у вас работает сервер. Неужели сложно посмотреть? Я сейчас в отпуске с дома пишу, проверить нет возможности. В августе на сервере с 24 ядрами 15 платформа использовала только 12 ядер до тех пор пока не обновил аппаратные лицензии на бесплатные программные. При этом использовались только первые 12 ядер (0-11). Замечу, никто не запрещал переназначит некоторым процессам привязку к ядрам с 12 по 23.

(40) не мешай челов троллить. Делов-то прочитать книжку умную или статью, но проще ведь задать вопрос

есть ключи железные и машина с 8 ядрами
юзеров 25 чел

1с выводит окно предупреждении, что нельзя пользоваться
убираю дубли юзеров в сеанса и всё работает


это что за хрень?

(46) Вроде до 10 пользователей сервер 1С работает как под КОРП. Сделано в угоду разработчикам франчей.

Все возможности системы (доступные под лицензией КОРП) доступны в том случае, если к каждой информационной базе кластера серверов «1С:Предприятие» подключено одновременно не более 10 клиентских сеансов. И серверная и все клиентские лицензии в этом случае могут быть уровня ПРОФ. При подключении хотя бы к одной из баз кластера серверов 11-го сеанса, этот сеанс получит ошибку, если в кластере серверов используются возможности, доступные под лицензией КОРП, а лицензий КОРП недостаточно.
https://its.1c.ru/db/v8315doc#bookmark:adm:TI000000971

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

(49) это в самой сути Венды. К 1с это не относится

(50) так я понимаю, что внутри нее. Да и не только винды, но и другие, кто на интелл/амд

(48) ох ты-ж блин! Прикольно!!! Получается у нас на сервере разработки остался КОРП!

(51) скорее даже и не только на х86

вот что мне дало гугленье

Есть теория, что сервер 1с 8.3 использует только 1 ядро процессора. Так ли это?

Все те же лица участники в дискуссии

И это получается наиболее интересное изложение на возникший вопрос.

Ну и вот это тоже

Технологические вопросы крупных внедрений
13.05.2016

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

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

Поэтому при работе на многопроцессорных системах (все современные многопроцессорные системы Intel и AMD имеют NUMA архитектуру), в зависимости от характера нагрузки, может наблюдаться неравномерная загрузка процессоров/ядер. В некоторых случаях может оказаться загружена только какая-то часть доступных ядер CPU, при этом другая часть будет простаивать. В таких случаях рекомендуется использовать лимит числа соединений на рабочий процесс, установленный из расчета:

ЧислоСоединенийНаПроцесс = РасчетноеМаксимальноеКоличествоСоединений/КоличествоNUMAНод.

При этом все равно возможна ситуация при которой будет перегружена только какая-то часть CPU (это можно можно увидеть в диспетчере задач 100% длительная 100% нагрузка на некоторые CPU при том, что остальные свободны). В таком случае лимит соединений на процесс следует уменьшать из расчета:

ЧислоСоединенийНаПроцесс = РасчетноеМаксимальноеКоличествоСоединений/(КоличествоNUMAНод * Коэффициент),

где коэффициент равен 2, и увеличивать его на 1 при каждой подстройке при наблюдении небалансированной нагрузки на NUMA нодах.
https://its.1c.ru/db/metod8dev#content:5903:hdoc

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

(54) там есть пост в котором обоснование есть почему на 1Сх86 нужно столько РП сколько потребуется, а на Х64 - хватит и 1

(55) и да, этот так... https://kb.1c.ru/articleView.jsp?id=89

+ (58) но больше одного отчасти из-за неполноценной NUMA, отчасти что-бы если что с 1 РП - сеансы перекинулись на другой.

(55) (58) (59) Вы в курсе, что такое NUMA ?

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

(61) Ну вот я и думаю, что товарищи путают многоядерность с многопроцессорностью.

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

(44) А ты нам расскажешь как ты это определил?

(60) нуууу, у нас 2 двупроцессорных сервера(для 1с) и нас это касается напрямую.

(46) Реально, 1С блокирует всех? :)

(58) Доступ запрещен, не у всех есть. Так что возможно вы общаетесь сами собой...
Скопируй хоть текст :)

(63) Больше похоже, что отличие КОРП от ПРОФ только виртуальное, и ограничено специально, что бы срубить деньжат. "Жадные один есники" :)

(62) Под "товарищами" подразумевай, пожалуйста, первоисточники копипасты.

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

(69) Статья написана во времена, когда смысл и разница этих терминов вполне ощущаемая была, а именно оверхед на синхронизацию разных ЦП по сравнению с синхронизацией разных ядер внутри одного ЦП.
Отсюда и такие рекомендации.

+(70) Поэтому нити (потоки, треды) рпхоста скорее всего точно привязываются к одному ЦП (по крайней мере стартуют с таким пожеланием), но никак не к одному ядру.

(70) в АМД Zen даже три разных веса таких коммуникаций, а не два, всё актуально

(71) Понятие "процессор" для шедулера ОС вообще не важен, если он не является узлом NUMA. Если является, то шедулер _старается_ выделять кванты потоку исполнения на том же процессоре, на котором он выполнялся в прошлый раз. Но это не обязательно. В случае же привязки процесса к конкретным ядрам шедулер будет использовать эту директиву, _исключая_ из рассмотрения все прочие ядра.

(73) "Понятие "процессор" для шедулера ОС вообще не важен, если он не является узлом NUMA" // Это понятно. Мы как раз про те хосты, где больше одного ЦП.
"Если является, то шедулер _старается_" // Ну, Я про это и толкую, используя слово "пожелание".
"случае же привязки процесса к конкретным ядрам шедулер будет использовать эту директиву" // Ну т.е. изъявляемое желание привязки к ЦП не гарантируется, а к ядрам гарантируется?

(74) "Ну т.е. изъявляемое желание привязки к ЦП не гарантируется, а к ядрам гарантируется?"
Как бы да. Выбор процессора с точки зрения шедулера - задача оптимизации, а вот привязка процесса к ядру - жесткая директива. Жесткой же привязки именно к процессору не существует, по крайней мере в винде (но можно привязать ко всем ядрам одного процессора).

(67) текст примерно тот-же что в (55)