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

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

ос какая?

1процесс=1ядро по этому и рекомендуют делать и рассчитывать количество рпхостов так чтобы их было по количеству ядер примерно..

а в 8.3 есть настройка количества процессов? если есть то где она?

Смотря какая разрядность 1С

64

теория возникла из банального эксперимента. на простом компе, настроенном как сервер, 1с работает в 3 раза быстрее, чем 2-процессорный  мощный сервер. Другого объяснения не вижу.

Сервер не для скорости делают, а для надежности.

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

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

[для скорости тоже] для скорости нужна тактовая частота CPU, если твой смешной 12 ядерный процессор тикает на жалких 2 Ггц, то его порвёт даже смартафон

Это заблуждение. Один процесс может запускать множество потоков (thread), каждый может выполняться на своём ядре. При этом адресное пространство общее.

для скорости нужны прямые руки а не частота...

+ И кстати, если есть возможность работы на одном РП - то лучше использовать один. В 8.2 при наличии нескольких рпхостов сильно тупит инициализация фоновых заданий.

и частота.

Это же смешно, когда дизельный седельный тягач MAN, мощностью в 5 раз большей, чем жигули, проигрывает жигулям в скорости перевозки 1 кг картошки!!! Где справедливость??! Это ж надо такое сказать..

А есть чем опровергнуть?

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

день сурка какой-то. это не тот же чувак с 2 оптеронами против интел и7?

ну так и есть. Все эти накрученные многоядерные на 90% лохотрон. Чтобы подороже продать. Вешают нам лапшу на уши.

Да блин, этот бред еще и опровергать надо чтоли? Берешь запускаешь обработку в 2х сеансах и смотришь как загрузятся 2 ядра на сервере. Очевидно, IamAlexy спутал узлы NUMA и ядра процессора. В результате, получилась фигня. В разделе ТВКВ вроде была статья Морозова, что rphost нужно размножать по количеству узлов NUMA.

два сеанса <=> два процесса или два сеанса <=> один с двумя тредами?

Два сеанса может наплодить хоть 20 тредов, все это может выполняться в 1 процессе rphost. Что совершенно не требует "количество rphost по количеству ядер"

как происходит появление нового треда, для этого что-то нужно прописывать в программном коде или системны планировщик сам множит треды от балды?

Любой серверный вызов порождает тред, очевидно.

очевидно, что это он ДОЛЖЕН делать, иначе треда просто не будет. Ну и где этот тред останется? В адресном пространстве родного процесса?

Появление треда прописано в платформе, ты ничего явно не создаешь. На клиенте треды могут создаваться из кода через "ПодключитьОбработчикОжидания", на сервере через ФоновыеЗадания.Выполнить, но это косвенное создание треда. Я не понял смысла вопроса. Тред может быть только там, где создан. Тред не может перейти в другое адресное пространство. А потом вызов закончится и треда вообще не будет. Но все треды могут принадлежать одному rphost и загрузить сколько хочешь ядер.

Где настраивется максимальное количество этих потоков в процессе?

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

Для начала надо понимать что такое многозадачность и какая она бывает

А платформа не использует пул потоков? Всегда ли при соединении создаётся поток, а при отключении удаляется? ПодключитьОбработчикОжидания разве не через таймер сделан? Вероятнее всего оконный, а не ядерный.

Так ведь предметом планирования времени процессоров являются потоки, а не процессы, в которых они живут. Проблема с таким распределением может быть только в NUMA-архитектуре, там планировщик может по другому действовать.

Запусти винрар и посмотри, как у процесса "нет доступа в один и тот же квант процессорного времени доступа к нескольким ядрам"

Смотря какая операционка

молись на винду дальше

запусти когда у тебя один рабочий процесс

А при чем тут винда? В линуксе почти то же самое. Правда, там треды это форкнутые процессы, но поведение аналогично.

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

сколько сотен пользователей работало в базе, на старой версии и на 8.3, что конфигурация работала медленно? В 8.3 сделали упор на большое количество пользователей, медленные каналы связи и веб-клиенты, в старых версия не было проблем с этим? А какие варианты ОС рассматриваются? Те что уже не на поддержке должно исключить (< Vista).

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

база файловая, розница 2.1, стоит веб-сервер, пользователей 2 (сеансов 3-4), один подключается через веб, второй локально... локально даже все открывается со скрипом, веб соединение вообще может печать этикетки 5 минут выдавать... мне кажется, что файловая ТиС и УТ даже по сети не так тормозили, как эта... меньше двух пользователей - куда уж меньше... и базу для меньше 5 пользователей советуют файловую... ну вот файловая... я даже если одна подключаюсь локально - медленно все...

для меньше 5 пользователей есть , его же не просто так продают

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

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

ну так что в итоге? я зашел в базу десятью пользователями и у меня в настройках стоит "1 сеанс на процесс" - сколько у меня будет процессов и как они расположатся по ядрам если у меня 10 ядер ?

Создай 10 фоновых заданий одновременно, да посмотри.

можешь подогнать через настройку количества баз/сеансов.. примерно.. то есть если у меня допустим 10 пользователей и 4 ядра и они работают в одной базе - то я делаю настройку - 3 сеанса на процесс..  и каждый четвертый сеанс инициирует новый процесс который падает в наиболее свободное по загрузке ядро на момент создания процесса.

в зависимости от моих настроек они радостно наплодят рпхостов которые займут наиболее свободные ядра.. я собственно про это выше и писал..

и чем лечить? кроме сервера? ни на каком компе не будет это нормально работать? я для примера открыла ут 10.2 и розницу 2.1 рядом, вывела на печать этикетку - в ут посчитала до трех, в рознице до 60-ти примерно...

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

вывод этикетки в 60 секунд это не нормально.. даже для УФ...

Такой разницы не должно быть. Розница развернута без веб-сервера, база находится на сетевом ресурсе?

Немедленно убирай эту убийственную настройку! 1 сеанс на процесс - это жесть просто. "В 64-разрядном сервере "1С:Предприятия" один rphost может полностью использовать и оперативную память, и процессорные ресурсы сервера. Поэтому для 64-разрядного сервера "1С:Предприятия" нормальным следует считать запуск одного рабочего процесса на один сервер."

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

это было для примера. ок. вопрос сугубо практический: 1. у тебя 32битный сервер, один процесс и 2 сеанса. каждый пользователь в сеансе запускает по тяяяяжолому отчету, для упрощения сделаем вид что отчеты старые и не плодят фоновых заданий. сколько ядер будет занято  и соответственно уйдут в максимум по загрузке? 2. вопрос в продолжение к вопросу №2:  эти же два сеанса но в РАЗНЫХ процессах запускают те же отчеты - сколько на этот раз будет занято ядер и в каком случае отчеты сформируются быстрее?

1. 2 ядра 2. 2 ядра. В последнем случае могут быть расходы на маршалинг, вариант №1 быстрее.

вопрос в догонку конечно же про память - отчеты генерятся с количеством строк по 100 000 в каждом и на СКД - что будет с памятью?

странно - с каких версий платформ они стали занимать 2 ядра? можешь показать скрин где видно как один rphost.exe  загрузил 2 ядра?

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

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

Всегда занимали 2 ядра. Запусти и сам смотри. Это твои субъективные впечатления, практика ничего подобного не показывает. 1С официально рекомендует для х64 1 рабочий процесс, на х86 несколько только по причине ограничения памяти на процесс. Для многосокетных систем может быть кривое распределение по ядрам, потому для них есть рекомендация использовать несколько рабочих серверов.

32-разрядный сервер может упираться в лимит по памяти. Это грозит ошибкой "Недостаточно памяти на сервере". В случае, если памяти для отчетов достаточно, они будут формироваться чуть-чуть быстрее, чем на х64 за счет более быстрой адресации памяти.

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

Это о NUMA? Разве система сможет правильно разделить одно адресное пространство процесса на несколько узлов NUMA, каждый со своей памятью, даже если разные потоки будут честно разделены между ядрами?

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

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

по ссылке так и написано

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

не сказал  бы. В 8.2 этот параметр был явным, а по ссылке предлагается завести кучу рабочих процессов кратную числу узлов, если число пользователей известно. 8.3 умеет переносить сеансовые и др. данные в rphost, когда он один? В 8.1 это был веский аргумент не ставить флаг много процессов.

Сеансовые данные в клиент-серверной архитектуре все же находятся в ведении процесса rmngr

Тесты рассчитаны на работу с данными, что немного уводит нас от анализа работы самого rphost (параллельность будет ограничена блокировками sql). Намного проще написать обработку с кодом вида Пока Истина Цикл КонецЦикла.

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

Мне вот сложно в таком стиле вести дискуссию. Кажется очевидным, что следует получать объективные данные. Когда анализу подвергается возможность использования нескольких ядер одним rphost, разумно анализировать именно этот аспект, а не запускать, к примеру, тесты PCMark. Упомянутые тесты показывают производительность записи в базу данных. Процесс записи данных в базу физически выполняется процессом сервера СУБД, а не rphost. Т.е. влияние rphost там будет видно только тогда, когда процесс записи будет достаточно быстрым и перестанет быть узким местом -  то есть не на каждой инсталляции. Т.е. результаты тестов скорее будут примерно одинаковыми, но влияние многопоточности на стороне rphost там может быть минимально. А если нагружать математику без привязки к СУБД, то это отвечает на вопрос загрузки ядер одним процессом rphost совершенно однозначно.

Когда несколько РП - то тормозит инициализация фоновых процессов. Оптимально один рабочий рпхост и один резервный. Плюс наши любимые повторные вызовы и хранилища значений с COM-объектами намного приятнее работают с одним процессом, чем с кучей.

Мне кажется, у вас все в диск упирается. Помониторьте счетичик. Первый шаг - это замена ХДД на быстрый ССД. Второй - вынос темп файлов на отдельный ССД.

спасибо! будем пробовать

все гораздо проще:

Уже устарела, сейчас основные блокировки - это блокировки сервера 1с

64х сервер - замечательно умеет работать по всем ядрам, для него несколько рхостов делать надо только в отдельных и весьма специфических случаях (вроде резервирования нагрузки)

В статье 1С речь не о ядрах, а о NUMA-узлах. , там тормоза на файловой базе через однопоточный веб-сервер.

может и проще, но тут "При появлении тормозов при работе с SQL", а у нас нет sql-сервера именно в данном случае...

если файловая через веб сервер, то: 1: всех пускать через веб (даже локальных и терминальных) 2: если активных пользователей больше 3-х воспользоваться заляпухой, например

Что за хрень эта нума?

Я в том смысле, что для современных процессоров нет никакого смысла учитывать эту самую нуму. Всё равно снаружи они - обычные SMP, с общей памятью. А нюансы кэширования - внутренннее дело ядра.

В настройках MS SQL NUMA может учитываться, хотя это тонкая настройка.

у тебя нет многосокетных серверов?

Это только у меня 1с чаще упирается в дисковые операции, а не количество процессоров и их мощность. Локальный комп с ССД диском сделает нацатипроцесорный сервак, если тестить 1-2 экземпляра 1с. Если их с полсотни запустить то уже буде видна разница

Есть, конечно. И что? Два сокета в режиме SMP. В точности так же как и многоядерный проц.

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

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

все ядра используют один контроллер памяти. Мультисокетные же системы либо содержат несколько контроллеров (они уже давно переехали в процессор) либо вынуждены конкурировать за доступ к 1. Второй случай - чистый smp. Первый - либо smp без аппаратного решения по доступу к чужой памяти и как следствие не позволяющий без специально разработанного софта иметь доступ к чужой, который будет все равно медленный, либо NUMA, в котоом эта задача решена на аппаратном уровне. Тут есть и оборотная сторона - доступ к удаленной памяти может быть не таким медленным, а из-за того, что ОС пытается этого избежать, получаем проблему с rphost, который грузит только один сокет с ближней памятью, остальные простаивают.