Классика.... проблема что брать... 1С8х64, корпа нет и не будет (т.е. на РП до 8 ИБ и до 128 сеансов)...
Условный выбор 12 ядер по 3,6 или 18 ядер по 2,4... ядра реальные а не те что с гиперком...
Что брать-то?

(0) То что не КОРП, не значит что ядер не надо. 1С вполне норм параллелит фоновые задания, они каждое на своем потоке выполняется, т.е. на современных платформах и конфигах ядра уже рулят и 1С не однопоточное приложение. А если еще учесть, что даже формирование отчетов происходит в отдельных фоновых заданиях, то больше ядер лучше. У первого варианта частота в полтора раза выше, у второго ядер в полтора раза больше. :) Баз и пользователей суммарно сколько предполагается?

В качестве примера. У нас для разработки два сервера. У первого 4 ядра 8 потоков, но быстрых 4.1ГГц базовая частота, в диспетчере задач показывает 4.4ГГц. У второго 6 ядер 12 потоков, но медленных 2.2ГГц. Так вот обновление ЕРП на втором, в части когда уже в режиме предприятия выполняются фоновые обработки, происходит просто в разы быстрее.

Уточнение. По первому все так и он чисто железный, а вот второй это виртуальная машина и там показывает 12 процессоров, возможно там ядра все 12 физические, без потоков, но это виртуалка. Скуль у них один на двоих.

бери 12 по 3.6
когда много потоков быстрые ядра между ними попрыгают пусть и с некоторыми накладными потерями все выполнится.
а когда будет длительная задача висеть тупить то тебе будет фиолетово что у тебя 24 или 224 ядра, если хочется чтобы она вместо 3х часов отработала хотя бы за 2.

(4) Тогда это зависит от количества пользователей дающих длительные задачи. Если будет тупить у 10-ка процентов, а остальные будут работать - это одно, а если тупить будет у всех = это совсем другое.

и да
2,4 Ггц
https://ark.intel.com/content/www/ru/ru/ark/products/27438/intel-pentium-4-processor-2-40-ghz-512k-cache-533-mhz-fsb.html
исполнилось 20 лет

"прошлый век, чугунное литье" (с)

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

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

(1) баз пяток, в самой крупной сеансов около сотки, всего сеансов пара сотен

(2) ядра они разные... конвейер, прогнозирование кэшь 2,3 уровня... в (0) про одинаковые по сути ядра - разная только тактовая

(0) 8 ядер с гипером по 5

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

опыт показывает что тактовая приоритетней. Но еще зависит от кол-ва одновременно работающих пользователей. Если их >=300 то 12 ядер будет мало

(13) на прошлой работе на 18 физических ядер 1К+ сеансов 1С-ДО корп. было каждый день... никто не жаловался... но не 2,4

Обычно частота важнее.

(0) В таком вариант однозначно частота. Даже если КОРП будет - частота все равно рулит больше ядер. Т.к. частота ускоряет всегда и уменьшает вероятность блокировок, а ядра - только иногда могут ускорить. При этом более медленные ядра увеличивают время блокировок, т.к. простоев.

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

(3) Я сравниваю 8 ядер по 4,7 против 28 ядер по 2,9 - и то тестовый не всегда медленнее (обычно быстрее). Только когда есть задания, которые могут задействовать больше 12 ядер без взаимоблокировок. А более 12 потоков вообще нет смысла ставить в большинстве случаев - иногда даже медленнее получается, чем с 8-12 потоками из-за блокировок. В обоих случаях SQL стоит на той же машине, где и сервер предприятия, т.е. работает через shared memory в обоих случаях.

(0) 1С8х64, корпа нет и не будет (т.е. на РП до 8 ИБ и до 128 сеансов)...
Условный выбор 12 ядер по 3,6 или 18 ядер по 2,4..

в курсе, что сервер ПРОФ видит только 12 ядер, а что бы больше, то нужно КОРП?

(19) часть ядер утилизирует сиквел/постгри

(16) ничто так не минимизирует ибыточные блокирвоки как отсутствие трэша в коде, имхо

(17) Возможно, но ЕРП я обновляю только на втором сервере и он проходит все процедуры быстрее. Как пример: на первом от 40 минут до часа, на втором то же самое от 15 минут до 20 минут. Разница от двух до трех раз. При этом сама база развернута на одном и том же скулевом сервере.

(0)
1. sql там-же будет?
2. сколько одновременных сеансов (пользователь*баз) будет?
3. сколько памяти планируется выделить под 1с и под SQL?

(23) 1.скорее всего. Но возможно это будет постгри (рамы ему нужно меньше)
2.пока наверное речь про порядка пары сотен.
3.всего 128Gb, видимо 5 - ОС, 80-90 СУБД, остальное - для 1С.

(24) тогда бери более быстрые, у тебя рхостов будет не более 10, по этому параллелизм всех ядер использоваться будет только SQL, что не так страшно.

(25) эээ современные рпхосты они многопоточные
так что нет смысла держать их больше пары штук

(26)+ исключая случай когда сервер 1С 32 битный ))

(26) надёжность выше если внутри 1 РП соединения только с 1 ИБ

(26) В идеале на каждую базу как минимум один свой rphost.

(24) Конфигурация какая будет крутиться? Если типовые УТ 11 или ERP на несколько сотен активных, то, возможно, стоит задуматься про сервер на 2 проца и ОЗУ побольше.

(29) такая настройка требует лицензии корп

(30) пока упп, возможно туда-же съедет ДО корп... теоретически ЕРП но не в этом году уже

(32) если в планах ЕРП - бери где ядер больше, там запросы укуренные, для SQL это будет большим плюсом....

(33) эт хорошо что тебя Дмитрий не слышит... он бы тебе сказал всё что гон думает про тех у кого MaxParralileze <> 1

(21) Если бы кодом всё решалось - вопрос про частоту или ядра не стоял бы.

(22) У меня обновление 50/50 (от обновления зависит - где-то продакшн быстрее, где-то тестовый), а вот, например, при закрытии месяца в 90% случаев быстрее тестовый сервер. Причем доходит до смешного: уменьшаешь количество потоков для закрытия месяца в продакшене - и месяц начинает закрываться быстрее. И остальные пользователи меньше жалуются на тормоза. Несмотря на то, что бОльшую часть времени там блокировки вообще не влияют, т.к. запись только в конце идет. Похоже что синхронизация потоков и накладные расходы жрут больше полезной нагрузки.

(31) Не обязательно. Можно кучу агентов наплодить на разных портах. Тогда каждая база на своем порту.

С 1с однозначно

(36) какой ты затейник, впрочем бывает атк делаю но чаще если 2 версии платформы на 1 сервер ... а ещё можно каждой каждому сервису свой менеджер.... но это не комильфо тоже

(38) Это как подводная лодка: если, допустим, кто-то подвесил менеджер кластера - курит бамбук только 1 база. Перезапуск агента - тоже раздельный. Кроме того, можно настройками маршрутизаторов ограничить доступ к базам.

для 1С

(0) уже давно разбирали это...
что в сервере под 1с. важна тактовая частота...
Но это не значит что можно взять 1 ядро с частотой 4 ггц.... и это будет лучше чем. 12 ядер с частотой 3.5Ггц...
все должно быть в меру

(41) вся ветка по сути о этом... где та грань разумности - вот вопрос...

(42) На сколько я помню была хорошая статья где то 20 или 21 года, там было штук 10 разных систем собранно (по ядрам и частоте и тд). и с разными количество пользователей. И результаты производительности. Ссылки нет надо в яндексе искать.
от туда можно примерно прикинуть для себя где эта грань исходя из результатов.

Так же вроде была инфа о "минимальном".. что хоть ты сделаешь 40 ядер..но если в них частота 1.5Ггц (я образно).. то это будет хуже чем 12 ядер с 2.5Ггц. опять же нужно гуглить могу ошибаться. давно не читал ибо сервер купили в 20 году

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

Однозначно!

исходя из той статьи и этого теста можно легко понять к чему стремится..

Сейчас есть высокоэффективные и энергесберегающие, нужно смотреть соотношение

(47) Энергосберегающие не так на самом деле важно.. 90% фирм снимают офисы где в аренду уже включен интернет и электричество по фикс цене. Мы платим где то 200к в месяц за офисы и все равно сколько там компов у нас и серверов и сколько они едят энергию

(48) Купишь энергосберегающие вместо энергоэффективных и офигеешь ;-)

частоты нужны только для математики. Для разработчика не на сях важнее ядра. Загляни в список процессов, у тебя там стопицот процессов, конкурирующих за ядра. И частота тут не помощник, потому что переключение контекста съедает производительность. А для ноута так вообще частоты смерть, тк жрут батарейку, что свинья помои (

(48) Ты сейчас с арендодателем общаешься, он в другую сторону воюет.

(44) сервер типа под заказ везти должны... пощупать-бы дали оба - не было-бы вопросов

(47) энергосбережение лесом!

(50) речь про продактовый сервер

(44) 67 попугаев на мсскл, 50 без настройки не высокопроизводительных ядрах

(50) Причем тут разработчик ? сервер в первую очередь 1с покупают для людей.. что бы этим 100+ пользователей не ныли что у них долго себестоимость считается и отчеты формируются

(50) Контекст переключается в любом случае - что 1 ядро, что 500. Только вот при 500 ядрах надо все данные проверять в кеше какого ядра они лежат, и если ядро вдруг сменилось - надо их перетаскивать через L3 или ОЗУ.

+(57) При этом именно этот резурс (L3/ОЗУ) становится узким местом, и чем больше ядер - тем сильнее это узкое место влияет.

Очевидно же. )

При совокупно одинаковой производительности

(58) кстати, да и даже прогнозирование тут лишь немного помошник