Pull to refresh

Comments 46

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очепятка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сервер 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) всю эту кухню знают, и так же по себе знают насколько важна однопоточная производительность для приложений которые не умеют в многопоток.

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

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

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

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

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

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

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

Sign up to leave a comment.

Articles