Предисловие или предпосылки к статье

В очередной раз ко мне обратился коллега из одного франчайзи 1С с просьбой развернуть Postgres + 1C двух разных версий на одном сервере. Сие ему было необходимо для безболезненного перевода некой компании "Х" с существующего в компании рабочей версии 1С на свежую. Так скажем есть новый боевой сервер, на котором нет ничего кроме Windows 2022 Standart и надо все вышеописанное на нем развернуть.

Я с радостью согласился так как в наше непростое время любая дополнительная денежка за счастье.

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

О системе
О системе

Как мы видим тактовая частота процессора оставляет желать лучшего. Так как 1С дюже любит 2 вещи: тактовую частоту в формате чем больше тем лучше (условные 3.0 ГГц как ориентир) и быстрые жесткие диски.

Тут сразу стало понятно, что не взлетим. Установленный 1С + Postgres и тест уважаемого тов. Гилева ожидаемо показал грусть и печаль.

Стартовый результат
Стартовый результат

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

Собственно эта ситуация с точностью описана на сайте Гилева и сразу было указано "бутылочное горлышко" в виде процессора.

Конфигурация сервера как ее видит тест Гилева
Конфигурация сервера как ее видит тест Гилева

Естественно, заказчики возмутились и начались, так знакомые многим, качели. "Нет это не в железе проблемы", "это программный тест - значит и проблемы программные" ну и так далее. Для сравнения я отправил результат теста с одной из виртуалок Selectel.

Результат теста виртуалки
Результат теста виртуалки
ТТХ виртуального сервера
ТТХ виртуального сервера

Тут собственно нечего сравнивать. 32 ядра и 64 Гб оперативки на "железе" показывают 8 единиц, а 4 ядра и 16 Гб почти 30.

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

Для начала просто скопировал с одного диска на другой три мешка мелких файлов - сразу увидел скорость в районе 220 МБ/c плюс она еще и падала периодами до 30 Мб/с. Выяснилось что диски собраны в RAID 5. Ок. Парни, сделайте хотя бы RAID 1, а лучше RAID 10. Пересобрали - скорость копирования выросла в 8 раз до 1,5 ГБ/с - отлично, но тест Гилева стал показывать не 8 единиц, а 9. Что ситуацию в корне не улучшило.

Решение


В процессе подпрыгивания вокруг сервера в тщетной, как мне казалось, попытке заставить хоть как то работать с приемлемой скоростью - обратил внимание что сервер даже под нагрузкой теста в диспетчере задач - показывает тактовую частоту скачущей в вилке 0,9 ГГц -1,9 ГГц, а!, подумал я - энергоэффективность и прочие "зеленые" приколы. Включил максимальную производительность, но видимого эффекта оно не возымело. Ну ок. Нет, так нет. Надо править в BIOS. Поскольку физического доступа не было - решил как доп запрос отправить позже, когда появится хоть какое-то решение. Параллельно полез на сайт Intel посмотреть какие процессоры можно воткнуть в сокет сервера дабы улучшить ситуацию. Там взгляд зацепился за слово "Маштабируемый" или "Scalable" в описании "Масштабируемый процессор Intel® Xeon®". Далее мысль пошла в сторону того а что именно в процессоре маштабировать то можно. Какое то время гугления привело меня на сайт https://en.wikichip.org/wiki/intel/xeon_silver/4216 где английским по белому была представлена табличка зависимости тактовой частоты от количества ядер

Информация о ядрах с сайта Wikichip.org
Информация о ядрах с сайта Wikichip.org

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

Так вот далее родилось ТЗ для заказчика - в BIOS отключить все что связано с энергоэффективностью, отключить Hyper-Threading (что было в рекомендациях на сайте Гилева) ну и уменьшить количество ядер до 8 (что судя по табличке из интернетов, представленной выше, должно было дать 2,9 ГГц) Буду до конца честным - я в такую магию не особо верил - но тут уже ситуация в формате - поможет - отлично, не поможет - сорян. Без нужной тактовой частоты вся эта конструкция никуда с 1С не полетит.

Результат меня порадовал и удивил.

Результат после уменьшения количества ядер до 8
Результат после уменьшения количества ядер до 8

Комментарии (46)


  1. ivankudryavtsev
    24.11.2022 10:39
    +1

    Ну так все равно, при всех активных ядрах турбо-частота может до 2.7GHz взлетать. Мне кажется, что выигрыш стал достигаться за счет отключения плавающей частоты ядра и большего кэша на одно ядро при уменьшении их количества за счет (а) отключения HT, (б) отключения части ядер. В итоге эффективность работы с кэшем (L2, L3) возросла, степень его блокировки уменьшилась и все улучшилось. Однако, не то чтобы прям сильно улучшилось, как я вижу.

    Кстати, известный факт для маршрутизаторов на Linux рекомендовалось (раньше, особенно с NAT-ом): отключить HT, отключить часть ядер, отключить плавающую частоту ядра. А еще это делали какие-то люди в высокочастотном трейдинге.

    Есть предположение что в сервере RAM может быть косячно скомплектована. Посмотрите через тесты памяти пропускную способность RAM и Latency. Я встречал ситуацию, правда один раз, когда из супового набора плашек получилось собрать очень-очень медленную RAM с дикими задержками доступа. При этом сервер работал как ни в чем не бывало, но все сказочно тупило.

    Не похоже, что вы докопались до первопричины проблемы.


    1. DeathRAMCC
      24.11.2022 11:58

      По моему опыту, с 8ю единицами теста - даже база бухгалтерии объемом в 2 гига еле шаволится. Да и рост в 300% вполне себе результат. На серверах где 30 +- единиц гарантированно работают 25-30 человек вольготно. Многое зависит ещё от объема базы, но это уже решения и железо для крупных заказчиков и там вообще другие развлечения.

      И память и жёсткие показывали отличную скорость, сейчас по памяти не воспроизведу результат, доступа к этому серверу уже нет. Проект мной сдан. Дальше там 1Сники развлекаются.


      1. ivankudryavtsev
        24.11.2022 12:04
        +1

        Ну вы же сами сказали, что 4 ядра Selectel-а вас переехали, а это CPU гипервизора с кучей переключения контекста между VM. А у вас аж монопольный CPU с 32 ядрами, 64 потоками. Выглядит что 3х кратный рост (300%, конечно, звучат внушительнее) не очень-то.


        1. DeathRAMCC
          24.11.2022 12:14

          4 ядра selectel были для подтверждению заказчику важности частоты процессора в работе 1С.

          В этом то и боль специфики 1С. По всем параметрам более крутой сервер но с низкой тактовой частотой будет работать хуже чем условный ноутбук на мобильном проце с тактовой частотой 3.5 ГГц.

          ЗЫ все ж таки 16 ядер в процессоре на железе. 32 это HT от Интел)))


  1. starik-2005
    24.11.2022 10:39
    +3

    У меня на ноутбуке с процем I5-8250U Гилев на серверной кажет 30, при том проц имеет "базовую" частоту 1,6ГГц. ЧЯДНТ?

    В файловой вообще 80, кстати.

    ИМХО, Вы из приличного многоядерного сервера сделали клиенту аналог моего ноутбука - те же 8 потоков )))

    ЗЫ: Ну и память. Если вставить в серверный комп с процем, у которого стопиццот каналов памяти всего две планки, то угадайте, сколько каналов памяти будет использовать процессор?


    1. DeathRAMCC
      24.11.2022 11:49
      +1

      Ну к физической конфигурации сервера - вопросы не ко мне. Что заказчик выбрал и купил - то и оживлял.

      Как связаны 8 потоков и 8 ядер, я не понял.


    1. DeathRAMCC
      24.11.2022 12:03

      Кстати довольно частая картина. Заказчик раньше работал на простом компе с условным i7 десктопном где был развернут сервер 1С. Потом админ выпросил денег на нормальный сервер, но не учел тактовую частоту и результат, описанный мной выше, будет повторен.

      На новом сервере база еле работает. А на домашнем компе летает.


      1. S0LDER
        25.11.2022 10:19

        Недавно на работе обновил сервер под 1с, взял самый топ на тот моент i9 9900K, и intel ssd Optane 900P в RAID1, как же все стало летать в сравнении с замученым xeonom даже не помню уже модель..)) некоторые обработки стали выполнялся за 2 минуты в место 30 минут)) сейчас правда все уже забыли как плохо было раньше и просто работают))


        1. starik-2005
          25.11.2022 11:36

          У меня на прошлой работе я долго пинал народ, чтобы купили уж если и не сервер новый навороченный, то хотя бы комп приличный для сервера. В итоге купили райзен 5 2600Х, NVME, память DDR4 ECC-3200CL22. В итоге у нас чел, который билдил релизы, т.е. фактически основное время его работы - это медитация на прогресс-бар сравнения и объединения (до 3-х часов для приличной большой конфы уровня ЕРП), внезапно стал жаловаться, что если раньше он успевал в столовку сходить, вокруг здания пройтись и все такое прочее, то теперь он в окно не успевал взглянуть. Т.е. скорость ожидания окна сравнения/объединения выросла в овер дофига раз (ну с часа минимум до минуты максимум). Старые сервера - это какие-то древние ксеоны с рейдами и всем таким прочим еще на старых дисках с минимальными йопсами, на которых крутились в основном файловые базы разрабов.

          А частота - да, она важна. Но если бы все дело было только в частоте, то 2.1ГГц, даже работая в 2 всего раза медленнее, чем 4,2ГГц, не давали бы разницу на порядок. В действительности все еще хуже, ибо проц в режиме высокой производительности, нагрузка на котором не перемещается между NUMAX и NUMAY и частота активного ядра которого удерживается выше стока, будет выигрывать у систем, в которых несколько сокетов, между которыми непрерывно передается рабочая нагрузка, даже если они настроены на высокую производительность. При том в системах, где сокетов больше одного, и память (физическая планка) привязана к соответствующему каналу физического сокета, и если на него вдруг переехала задача с ядра другого сокета, то и к памяти сильно дольше доступ будет осуществляться. Ну и лесенка изменения частот - с ней так же все, как с китайским рейтингом: потерять легко, обратно до турбобустовых частот догнать долго. Ну и латентность серверных ядер обычно выше, поэтому и шаг изменения частоты там больше. В итоге сервера работают в основном на околостоковых частотах, разгоняясь только при наличии устойчивой нагрузки на конкретном ядре. Поэтому правильные энтерпрайзные не 1С-ные перцы даже просто вынося нагрузку по обслуживанию сети на какие-нить отдельные ядра, только этим уже повышают производительность, исключая прерывания от процессов обслуживания. Была тут статья об этом - ищите.


    1. nikweter
      24.11.2022 16:33

      У вас на постгрес?


    1. rubikon
      24.11.2022 17:23

      ssd + filebase?


  1. echo10
    24.11.2022 10:50

    1. Удалось ли точно выявить "зеленый" параметр, который привел к увеличению частоты? Был ли такой параметр один или несколько? Какой был прирост от выключения каждого зеленого параметра?

    2. Какой RAID был выбран всё-таки для тестов? Raid1, Raid10 или что-то еще? Какой тип и модель дисков стояли в сервере?

    3. У вас был физический сервер или виртуалка? В нем стоял один процессор или два? Слово DELL как бы намекает на физический, но все же?

    4. Где именно и какой настройкой вы уменьшили кол-во ядер до восьми?

    5. Какой был конфиг у Postgress?



    1. DeathRAMCC
      24.11.2022 11:43

      1. К увеличению привел не зелёный параметр, а отключение половины ядер. Что привело к увеличению частоты оставшихся.

      2. RAID10. SSD Intel DC S4500 960 Гб.

      3. Физический

      4. В BIOS. Не я - а владельцы сервера. У меня физического доступа не было.

      5. Вопрос не понял если честно. 13й постгрес с конфигурацией настроенной согласно рекомендациям 1с.


      1. SensR9
        24.11.2022 12:05
        -4

        1. очень интересно, в каком месте RAID10 стал быстрее RAID5, как в статье написано? он никогда не был и не может быть быстрее. намного надёжнее? да. но не быстрее. не может такого быть, что raid5 в 8 раз медленнее.

          1. idrac в следующий раз просите ????

          2. лицензирование ms, в отличие от 1с, никто не проверяет на практике, так что делать на кактусе БД - сомнительное удовольствие


        1. DeathRAMCC
          24.11.2022 12:07

          Есть вариант что вместе с заменой raid поменяли диски. Я ж физические манипуляции производимые с сервером не мог контролировать.

          Про лицензионность - есть требование заказчика. Мне то, что на сиквеле, что слонах, в целом все равно на чем разводить базу


        1. ivankudryavtsev
          24.11.2022 13:16
          +2

          С чего бы. R5 без батарейки будет всегда медленнее R10, особенно на random io.


        1. sYB-Tyumen
          24.11.2022 13:46

          На запись RAID10 быстрее. У RAID 10 penalty = 2, у RAID5 = 4. То есть чисто на запись, без чтения, RAID10 будет в два раза быстрее, чем RAID5 при том же количестве дисков для СХД.


        1. Klim4War
          24.11.2022 14:10

          1. Давайте посмотрим на то, какой «штраф на запись» есть у популярных типов RAID: RAID 1 — 2; RAID 5 — 4; RAID 6 — 6; RAID 10 — 2.
            В 8 не может, но в 2 да.


          1. VVizard
            25.11.2022 10:28

            Если вы ставите PG под Windows (а по косвенным признкам видно что дело было под Windows) то там может быть вообще что угодно.


        1. NoOne
          24.11.2022 19:45

          Raid penalty


  1. panvartan
    24.11.2022 11:17
    +2

    На Linux будет еще плюс 30-50% попугаев, если для вас это важно. Но не забывайте, что не важно на сколько быстры ваши потоки, если их не хватает. Все-таки на сервере не один человек работает.


  1. Mayurifag
    24.11.2022 11:47
    +2

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

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


    1. ivankudryavtsev
      24.11.2022 11:57

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


  1. atd
    24.11.2022 12:18

    в BIOS отключить все что связано с энергоэффективностью, отключить Hyper-Threading

    Попросите ещё найти настройку "Dell controlled turbo" и включить её. Не кардинально, но на сколько-то процентов ещё может повысить скорость.


    1. DeathRAMCC
      24.11.2022 12:56

      Спасибо за совет. Сделаю.


  1. Cruz_Castillo
    24.11.2022 12:38

    1. Standard.

    2. Боевой сервер с именем WIN-*******? За гранью...


    1. DeathRAMCC
      24.11.2022 12:39

      Очепятка

      С чего вы решили что боевой? Тестовый. Потом был переименован конечно.


      1. Canti
        24.11.2022 14:04

        Простите за глупый вопрос, совершенно не в теме, а что не так с названием WIN-******


        1. DeathRAMCC
          24.11.2022 14:05

          Как минимум охренеешь в названиях баз вводить. Но ничего связанного с надёжностью, скоростью, безопасностью и тэдэ нету. Исключительно про удобство использования имхо.


      1. vitektm
        24.11.2022 18:25

        Главное не делать это на MS SQL на боевом :)


  1. 13werwolf13
    24.11.2022 13:00
    +8

    стандартный же набор действий для 1С сервера:
    1) выкидываем винду, ставим centos/debian
    2) ставим постгресПРО для 1С (доступ к репам высылают бесплатно по запросу
    3) в бивисе/ефи выключаем HT и всё что связано с оптимизацией энергопотребления
    4) проц стараемся подбирать такой чтобы была максимальная производительность на ядро а не 100500 ядер

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


    1. DeathRAMCC
      24.11.2022 13:09
      +2

      Согласен по всем пунктам. Это прямо правильный рецепт.

      Но!! есть требования заказчика и слушать чужое мнение, особенно если оно кардинально отличается от собственного, умеют очень немногие из них, к сожалению. Поэтому часто имеет что имеем(


    1. nikweter
      24.11.2022 16:36
      +1

      1с любит совать в темп tables огромное количество данных. А а пазгресс выполняет ставку в темп tables в один поток на одном ядре. Так что легко словить ситуацию когда один insert в темп выполняется десятки часов. И количество ядер тут совершенно не поможет, а вот частота ядра очень даже.


      1. VVizard
        25.11.2022 10:30

        Спасибо за инфу, привык что MS SQL использует все до чего дотянется, а с PG только недавно...


  1. Fragster
    24.11.2022 15:05

    тест Гилева стал показывать не 8 единиц, а 9. Что ситуацию в корне не улучшило.

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

    Верхняя часть практически всегда была завязана на частоту процессора. А то, что винда не умеет нормально поднимать частоту при "рваных" нагрузках и нужно устанавливать профиль "высокая производительность" - давно известно и описано во всех мануалах по настройке и обслуживанию 1с + sql. Сам видел разницу в три (!!!) раза на проде между "оптимальная" и "высокая". И не в попугаях, а в реальных операциях (например отчеты с RLS, работа динамических списков с тем же RLS, формирование всяких XML и прочем).


    1. DeathRAMCC
      24.11.2022 17:04

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

      По нижней части теста получалось что-то фантастически хорошее типа 200 пользователей. Но база размером в 30 ГБ еле работала у одного, не говоря уж о 10.


      1. Fragster
        24.11.2022 18:04

        Установленный профиль высокая производительность, в данном конкретном случае, в винде

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

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

        Есть еще https://fragster.ru/performanceTest который делает примерно то же самое, что верхняя часть гилевского теста (по качеству попугаев), но многопоточно.


        1. DeathRAMCC
          24.11.2022 18:09

          Спасибо за наводку на тест, попробую.

          А вот интерпретация нижней части теста Гилева - отличное. Мне как то не приходило в голову связать верхнюю и нижнюю части в таком контексте.


          1. Fragster
            24.11.2022 18:25

            Уточню про интерпретацию: она актуальна, если упирается не в проц, а во что-то другое - например в диск (разница между рейдами сразу бы это показала, да и величина прироста файлов БД тоже влияет на самом деле некисло) или в сеть между сервером СУБД и 1с (тут ооооочень сильно влияет латентность сети, даже для локалки была разница между подключением через хаб или напрямую, но может упираться и в ширину канала)


        1. VVizard
          25.11.2022 10:26

          Но база размером в 30 ГБ еле работала у одного, не говоря уж о 10.

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

          Не важно 1 пользователь у вас или 40, на многоядерном сервере скорость работы будет для них +/- одинаковая.

          В случае с малоядерными десктопными ПК скорость работы 80 пользоватеелй будет значительно медленее чем скорость работы 1 пользователя. Но скорость работы 1 пользователя будет значительно выше чем скорость работы 1 пользователя на многоядерном сервере.

          (Ну и конечно напомню что мы говорим имеено о севере 1С а не о севере СУБД, потому что для СУБД ситуация более сложная, а если СБУД это PG на Windows то и вообще безвыходная).


  1. mentin
    25.11.2022 00:33
    +1

    Что-то здесь всё такие не сходится - как поднятие скорости проца в полтора раза, даже если все зависит только от него, ускорило всё не в полтора раза, а от состояния "еле ползает, пользоваться нельзя" до "все летает"?

    Подозреваю, основная причина возможно не скорость, а именно отключение лишних ядер, что сменило распределение задач по ядрам. У XEON отдельные процессорные кеши на каждое ядро, и если поток прыгает по ядрам, это катастрофа для производительности кеша. Тут уже 10х легко словить. Возможно, того же или лучшего эффекта можно было добиться установив процессам 1С или базы данных CPU Affinity.


    1. VVizard
      25.11.2022 10:41

      Вы вообще не понимаете о чем пишите.

       У XEON отдельные процессорные кеши на каждое ядро

      1. У всех процесоров х86 отдельные кэши на каждое ядро, называются они L2.

      2. У интел (в отличии от ZEN2) как раз L3 общий для всех ядер

      Остальное даже комментировать не буду, так как вы все равно не поймете.


  1. VVizard
    25.11.2022 10:05
    +1

    Сервер 1С однопоточный, в том плане что один сеанс пользователя / фонового задания - один поток. Самих потоков конечно может быть много так как пользователей у вас много, каждый из них генерирует много задач, но каждая такая задача выполняется исключительно одним ядром (одним потоком в случаее с HT).

    Соответственно важна для него производительность на одно ядро (а не частота процессора, так как для разной архитектуры IPC разное).

    Самый простой способ сравнить процессоры по этому показателю это CPU-Z

    В случае пока количество сеансов <= количеству потоков (с учетом HT) ПК с 12900 будет давать результаты в 2,2 раза лучше (см. примечание) чем сервер с 4216.

    По мере увеличения количества сеансов 12900 разрыв в производительности будет падать.

    Вы не написали сколько пользователей у вас. Если 300 пользователей, то нужно будет или смириться с меделенной работой сервера или подбирать соответсвующие сервера в кластер (5-7 серверов).

    Примечание

    Тут и дальше под термином "производительность сервера 1С" я имею в виду время выполнения кода.

    Очевидно что в реальной работе, например: "формирование отчета СКД, проведение документа, открытие формы списка и.т.п", Прироста в 2 раза не будет, так как там 98% времени работает СУБД и только 2% работает сервер 1С.

    Если до 50 человек то под Сервер 1С лучше взять хорошее десктопное железо (12900/12700, старшие ZEN3).

    Мало того что сэкономите на серверах, так еще и за счет огромного L2 (1,25МБ на ядро!) и быстрой памяти процессы 1С будут работать очень быстро. В случае ZEN3 там L2 стандартный но зато L3 - 32Mb. (Не знаю что из этого будет лучше но точно знаю что оба покажут себя хорошо)

    Из моего опыта если говорить о стандартной бух то сервер 1С на 12900 без проблем будет держать 60-70 пользователей (с учетом того что они работают не равномерно, если у вас работают операторы потокового ввода по всей стране и генерят нагрузку непрерывно то конечно цифры другие будут).

    Как убедить заказчика? Если вы +/- крупный франч купите себе один такой системник, и просто показывайте заказчку разницу.

    По другому убеждать людей что ПК за 80к будет лучше справляться с сервером 1С, чем сервер за 800к не реально.

    Даже под моим сообщением, уверен, будет не один комментарий по этому поводу :).

    Приложение "Сервер 1С" в отличии от СУБД не требует серверного оборудования, отлично масшатабируется по количеству ПК, т.е. если у вас 100 пользователей ставьте 2 системника, 150 ставьте 3 и.т.п. требований к диску каких то особых нет, к надежности тоже, особеено если у вас и так кластер из нескольких системников.

    Зато с СУБД вам лучше постараться уместить все на одном сервер так как в случае с 1С вам будет ОЧЕНЬ тяжело масштабировать СУБД добавлением еще одного сервера.

    Про отключение ядер

    Что касается вашего случая, и других случаев работы Turbo boost то все сводится к TDP. У процессоров 4216 TDP 100W и в зависимости от загрузки эти 100W набираются или 8ю ядрами на 3Ггц или 16ю на 2.9 и.т.п. Зеонщики со стажем (сам 2 года дома сидел на 2673v3) всю эту кухню знают, и так же по себе знают насколько важна однопоточная производительность для приложений которые не умеют в многопоток.


  1. Overgod
    25.11.2022 10:26
    +1

    Масштабируемый процессор потому что его можно устанавливать многопроцессорные конфигурации.

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


  1. zarxis
    25.11.2022 11:15

    По поводу низких частот процессора при работе.

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


    1. oller
      27.11.2022 05:40

      Это базовые настройке в 10, 7, никаких реестров

      В 11й не проверял.

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