Предисловие или предпосылки к статье
В очередной раз ко мне обратился коллега из одного франчайзи 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 где английским по белому была представлена табличка зависимости тактовой частоты от количества ядер
Сразу оговорюсь - если вдруг это общеизвестный факт - то мои искренние извинения за потраченное читателем время.
Так вот далее родилось ТЗ для заказчика - в BIOS отключить все что связано с энергоэффективностью, отключить Hyper-Threading (что было в рекомендациях на сайте Гилева) ну и уменьшить количество ядер до 8 (что судя по табличке из интернетов, представленной выше, должно было дать 2,9 ГГц) Буду до конца честным - я в такую магию не особо верил - но тут уже ситуация в формате - поможет - отлично, не поможет - сорян. Без нужной тактовой частоты вся эта конструкция никуда с 1С не полетит.
Результат меня порадовал и удивил.
Комментарии (46)
starik-2005
24.11.2022 10:39+3У меня на ноутбуке с процем I5-8250U Гилев на серверной кажет 30, при том проц имеет "базовую" частоту 1,6ГГц. ЧЯДНТ?
В файловой вообще 80, кстати.
ИМХО, Вы из приличного многоядерного сервера сделали клиенту аналог моего ноутбука - те же 8 потоков )))
ЗЫ: Ну и память. Если вставить в серверный комп с процем, у которого стопиццот каналов памяти всего две планки, то угадайте, сколько каналов памяти будет использовать процессор?
DeathRAMCC Автор
24.11.2022 11:49+1Ну к физической конфигурации сервера - вопросы не ко мне. Что заказчик выбрал и купил - то и оживлял.
Как связаны 8 потоков и 8 ядер, я не понял.
DeathRAMCC Автор
24.11.2022 12:03Кстати довольно частая картина. Заказчик раньше работал на простом компе с условным i7 десктопном где был развернут сервер 1С. Потом админ выпросил денег на нормальный сервер, но не учел тактовую частоту и результат, описанный мной выше, будет повторен.
На новом сервере база еле работает. А на домашнем компе летает.
S0LDER
25.11.2022 10:19Недавно на работе обновил сервер под 1с, взял самый топ на тот моент i9 9900K, и intel ssd Optane 900P в RAID1, как же все стало летать в сравнении с замученым xeonom даже не помню уже модель..)) некоторые обработки стали выполнялся за 2 минуты в место 30 минут)) сейчас правда все уже забыли как плохо было раньше и просто работают))
starik-2005
25.11.2022 11:36У меня на прошлой работе я долго пинал народ, чтобы купили уж если и не сервер новый навороченный, то хотя бы комп приличный для сервера. В итоге купили райзен 5 2600Х, NVME, память DDR4 ECC-3200CL22. В итоге у нас чел, который билдил релизы, т.е. фактически основное время его работы - это медитация на прогресс-бар сравнения и объединения (до 3-х часов для приличной большой конфы уровня ЕРП), внезапно стал жаловаться, что если раньше он успевал в столовку сходить, вокруг здания пройтись и все такое прочее, то теперь он в окно не успевал взглянуть. Т.е. скорость ожидания окна сравнения/объединения выросла в овер дофига раз (ну с часа минимум до минуты максимум). Старые сервера - это какие-то древние ксеоны с рейдами и всем таким прочим еще на старых дисках с минимальными йопсами, на которых крутились в основном файловые базы разрабов.
А частота - да, она важна. Но если бы все дело было только в частоте, то 2.1ГГц, даже работая в 2 всего раза медленнее, чем 4,2ГГц, не давали бы разницу на порядок. В действительности все еще хуже, ибо проц в режиме высокой производительности, нагрузка на котором не перемещается между NUMAX и NUMAY и частота активного ядра которого удерживается выше стока, будет выигрывать у систем, в которых несколько сокетов, между которыми непрерывно передается рабочая нагрузка, даже если они настроены на высокую производительность. При том в системах, где сокетов больше одного, и память (физическая планка) привязана к соответствующему каналу физического сокета, и если на него вдруг переехала задача с ядра другого сокета, то и к памяти сильно дольше доступ будет осуществляться. Ну и лесенка изменения частот - с ней так же все, как с китайским рейтингом: потерять легко, обратно до турбобустовых частот догнать долго. Ну и латентность серверных ядер обычно выше, поэтому и шаг изменения частоты там больше. В итоге сервера работают в основном на околостоковых частотах, разгоняясь только при наличии устойчивой нагрузки на конкретном ядре. Поэтому правильные энтерпрайзные не 1С-ные перцы даже просто вынося нагрузку по обслуживанию сети на какие-нить отдельные ядра, только этим уже повышают производительность, исключая прерывания от процессов обслуживания. Была тут статья об этом - ищите.
echo10
24.11.2022 10:50Удалось ли точно выявить "зеленый" параметр, который привел к увеличению частоты? Был ли такой параметр один или несколько? Какой был прирост от выключения каждого зеленого параметра?
Какой RAID был выбран всё-таки для тестов? Raid1, Raid10 или что-то еще? Какой тип и модель дисков стояли в сервере?
У вас был физический сервер или виртуалка? В нем стоял один процессор или два? Слово DELL как бы намекает на физический, но все же?
Где именно и какой настройкой вы уменьшили кол-во ядер до восьми?
-
Какой был конфиг у Postgress?
DeathRAMCC Автор
24.11.2022 11:43К увеличению привел не зелёный параметр, а отключение половины ядер. Что привело к увеличению частоты оставшихся.
RAID10. SSD Intel DC S4500 960 Гб.
Физический
В BIOS. Не я - а владельцы сервера. У меня физического доступа не было.
Вопрос не понял если честно. 13й постгрес с конфигурацией настроенной согласно рекомендациям 1с.
SensR9
24.11.2022 12:05-4-
очень интересно, в каком месте RAID10 стал быстрее RAID5, как в статье написано? он никогда не был и не может быть быстрее. намного надёжнее? да. но не быстрее. не может такого быть, что raid5 в 8 раз медленнее.
idrac в следующий раз просите ????
лицензирование ms, в отличие от 1с, никто не проверяет на практике, так что делать на кактусе БД - сомнительное удовольствие
DeathRAMCC Автор
24.11.2022 12:07Есть вариант что вместе с заменой raid поменяли диски. Я ж физические манипуляции производимые с сервером не мог контролировать.
Про лицензионность - есть требование заказчика. Мне то, что на сиквеле, что слонах, в целом все равно на чем разводить базу
ivankudryavtsev
24.11.2022 13:16+2С чего бы. R5 без батарейки будет всегда медленнее R10, особенно на random io.
sYB-Tyumen
24.11.2022 13:46На запись RAID10 быстрее. У RAID 10 penalty = 2, у RAID5 = 4. То есть чисто на запись, без чтения, RAID10 будет в два раза быстрее, чем RAID5 при том же количестве дисков для СХД.
Klim4War
24.11.2022 14:10Давайте посмотрим на то, какой «штраф на запись» есть у популярных типов RAID: RAID 1 — 2; RAID 5 — 4; RAID 6 — 6; RAID 10 — 2.
В 8 не может, но в 2 да.
VVizard
25.11.2022 10:28Если вы ставите PG под Windows (а по косвенным признкам видно что дело было под Windows) то там может быть вообще что угодно.
-
panvartan
24.11.2022 11:17+2На Linux будет еще плюс 30-50% попугаев, если для вас это важно. Но не забывайте, что не важно на сколько быстры ваши потоки, если их не хватает. Все-таки на сервере не один человек работает.
Mayurifag
24.11.2022 11:47+2Для незаточенных под многопоточность игр (подавляющее большинство) совет с отключением гипертрединга так же часто всплывает. Я, cобственно, отключаю по этой причине упомянутую технологию, как и все энергосберегайки в ПК.
Забавно, кстати, получается, как маркетологи рекламируют стотыщ потоков у процессора, а на практике тебе чаще нужна производительность одного конкретного ядра и потоками ты легко готов жертвовать.
atd
24.11.2022 12:18в BIOS отключить все что связано с энергоэффективностью, отключить Hyper-Threading
Попросите ещё найти настройку "Dell controlled turbo" и включить её. Не кардинально, но на сколько-то процентов ещё может повысить скорость.
Cruz_Castillo
24.11.2022 12:38Standard.
Боевой сервер с именем WIN-*******? За гранью...
DeathRAMCC Автор
24.11.2022 12:39Очепятка
С чего вы решили что боевой? Тестовый. Потом был переименован конечно.
Canti
24.11.2022 14:04Простите за глупый вопрос, совершенно не в теме, а что не так с названием WIN-******
DeathRAMCC Автор
24.11.2022 14:05Как минимум охренеешь в названиях баз вводить. Но ничего связанного с надёжностью, скоростью, безопасностью и тэдэ нету. Исключительно про удобство использования имхо.
13werwolf13
24.11.2022 13:00+8стандартный же набор действий для 1С сервера:
1) выкидываем винду, ставим centos/debian
2) ставим постгресПРО для 1С (доступ к репам высылают бесплатно по запросу
3) в бивисе/ефи выключаем HT и всё что связано с оптимизацией энергопотребления
4) проц стараемся подбирать такой чтобы была максимальная производительность на ядро а не 100500 ядерда и вообще лучше держать 1С сервер и постгрю на разных тачках так как требования к железу у них разные, для потгри кол-во ядер имеет значение, у неё в отличии от самой 1С с многопоточностью всё более менее нормально
DeathRAMCC Автор
24.11.2022 13:09+2Согласен по всем пунктам. Это прямо правильный рецепт.
Но!! есть требования заказчика и слушать чужое мнение, особенно если оно кардинально отличается от собственного, умеют очень немногие из них, к сожалению. Поэтому часто имеет что имеем(
nikweter
24.11.2022 16:36+11с любит совать в темп tables огромное количество данных. А а пазгресс выполняет ставку в темп tables в один поток на одном ядре. Так что легко словить ситуацию когда один insert в темп выполняется десятки часов. И количество ядер тут совершенно не поможет, а вот частота ядра очень даже.
VVizard
25.11.2022 10:30Спасибо за инфу, привык что MS SQL использует все до чего дотянется, а с PG только недавно...
Fragster
24.11.2022 15:05тест Гилева стал показывать не 8 единиц, а 9. Что ситуацию в корне не улучшило.
В тесте Гилева в нижней части есть отдельная многопоточная часть, изменряющая немного другие попугаи (и завязанная больше на дисковую подсистему)
Верхняя часть практически всегда была завязана на частоту процессора. А то, что винда не умеет нормально поднимать частоту при "рваных" нагрузках и нужно устанавливать профиль "высокая производительность" - давно известно и описано во всех мануалах по настройке и обслуживанию 1с + sql. Сам видел разницу в три (!!!) раза на проде между "оптимальная" и "высокая". И не в попугаях, а в реальных операциях (например отчеты с RLS, работа динамических списков с тем же RLS, формирование всяких XML и прочем).
DeathRAMCC Автор
24.11.2022 17:04Установленный профиль высокая производительность, в данном конкретном случае, в винде принес ровным счётом ничего. Первое что сделал.
По нижней части теста получалось что-то фантастически хорошее типа 200 пользователей. Но база размером в 30 ГБ еле работала у одного, не говоря уж о 10.
Fragster
24.11.2022 18:04Установленный профиль высокая производительность, в данном конкретном случае, в винде
Ну в мануалах также пишут и про биос и (иногда) про необходимость контроля температуры (да, сервера тоже троттлят)
Нижняя часть теста показывает (грубо говоря), до скольки пользователей верхняя часть теста актуальна, если всё упирается не в проц, а в диск. Хоть там и код закрыт, но я имею некоторое отношение к созданию нижней части ;)
Есть еще https://fragster.ru/performanceTest который делает примерно то же самое, что верхняя часть гилевского теста (по качеству попугаев), но многопоточно.
DeathRAMCC Автор
24.11.2022 18:09Спасибо за наводку на тест, попробую.
А вот интерпретация нижней части теста Гилева - отличное. Мне как то не приходило в голову связать верхнюю и нижнюю части в таком контексте.
Fragster
24.11.2022 18:25Уточню про интерпретацию: она актуальна, если упирается не в проц, а во что-то другое - например в диск (разница между рейдами сразу бы это показала, да и величина прироста файлов БД тоже влияет на самом деле некисло) или в сеть между сервером СУБД и 1с (тут ооооочень сильно влияет латентность сети, даже для локалки была разница между подключением через хаб или напрямую, но может упираться и в ширину канала)
VVizard
25.11.2022 10:26Но база размером в 30 ГБ еле работала у одного, не говоря уж о 10.
В этом и суть многоядерных серверных процессоров. Они оптимизированы под большую нагрузку, а с маленькой работают плохо.
Не важно 1 пользователь у вас или 40, на многоядерном сервере скорость работы будет для них +/- одинаковая.
В случае с малоядерными десктопными ПК скорость работы 80 пользоватеелй будет значительно медленее чем скорость работы 1 пользователя. Но скорость работы 1 пользователя будет значительно выше чем скорость работы 1 пользователя на многоядерном сервере.
(Ну и конечно напомню что мы говорим имеено о севере 1С а не о севере СУБД, потому что для СУБД ситуация более сложная, а если СБУД это PG на Windows то и вообще безвыходная).
mentin
25.11.2022 00:33+1Что-то здесь всё такие не сходится - как поднятие скорости проца в полтора раза, даже если все зависит только от него, ускорило всё не в полтора раза, а от состояния "еле ползает, пользоваться нельзя" до "все летает"?
Подозреваю, основная причина возможно не скорость, а именно отключение лишних ядер, что сменило распределение задач по ядрам. У XEON отдельные процессорные кеши на каждое ядро, и если поток прыгает по ядрам, это катастрофа для производительности кеша. Тут уже 10х легко словить. Возможно, того же или лучшего эффекта можно было добиться установив процессам 1С или базы данных CPU Affinity.
VVizard
25.11.2022 10:41Вы вообще не понимаете о чем пишите.
У XEON отдельные процессорные кеши на каждое ядро
У всех процесоров х86 отдельные кэши на каждое ядро, называются они L2.
У интел (в отличии от ZEN2) как раз L3 общий для всех ядер
Остальное даже комментировать не буду, так как вы все равно не поймете.
VVizard
25.11.2022 10:05+1Сервер 1С однопоточный, в том плане что один сеанс пользователя / фонового задания - один поток. Самих потоков конечно может быть много так как пользователей у вас много, каждый из них генерирует много задач, но каждая такая задача выполняется исключительно одним ядром (одним потоком в случаее с HT).
Соответственно важна для него производительность на одно ядро (а не частота процессора, так как для разной архитектуры IPC разное).
Самый простой способ сравнить процессоры по этому показателю это CPU-Z
Intel Xeon Silver 4216 - 370/8400 (https://valid.x86.fr/bench/lf3a0q)
Intel Core i9-12900K - 800/11400 (https://valid.x86.fr/bench/9ar1d6)
Intel Core i7-12700K - 850/9800 (https://valid.x86.fr/bench/f8003w)
В случае пока количество сеансов <= количеству потоков (с учетом 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) всю эту кухню знают, и так же по себе знают насколько важна однопоточная производительность для приложений которые не умеют в многопоток.
Overgod
25.11.2022 10:26+1Масштабируемый процессор потому что его можно устанавливать многопроцессорные конфигурации.
Ситуация с частотой это общеизвестный факт, на десктопных процессорах ситуация такая-же, но меньше разброс между минимальной и максимальной частотой
zarxis
25.11.2022 11:15По поводу низких частот процессора при работе.
Насколько я помню, у винды в настройках энергопотребления есть пара скрытых параметров (которые надо включать через реестр, видимо для отладки использовалось), отвечающих за частоту процессора и там можно было выставить как нижний порог общей частоты процессора, так и верхний (именно эту настройку я одно время использовал на ноутбуке для принудительного понижения частоты, так как он часто задирал ее до 4.8ггц, что постоянно вызывало повышение шума вентиляторов с определенным промежутком при скачущей нагрузке)
oller
27.11.2022 05:40Это базовые настройке в 10, 7, никаких реестров
В 11й не проверял.
Также автору статьи рекомендую отключить защиты от митлдовн и спектр, прям мастхев для баз данных
ivankudryavtsev
Ну так все равно, при всех активных ядрах турбо-частота может до 2.7GHz взлетать. Мне кажется, что выигрыш стал достигаться за счет отключения плавающей частоты ядра и большего кэша на одно ядро при уменьшении их количества за счет (а) отключения HT, (б) отключения части ядер. В итоге эффективность работы с кэшем (L2, L3) возросла, степень его блокировки уменьшилась и все улучшилось. Однако, не то чтобы прям сильно улучшилось, как я вижу.
Кстати, известный факт для маршрутизаторов на Linux рекомендовалось (раньше, особенно с NAT-ом): отключить HT, отключить часть ядер, отключить плавающую частоту ядра. А еще это делали какие-то люди в высокочастотном трейдинге.
Есть предположение что в сервере RAM может быть косячно скомплектована. Посмотрите через тесты памяти пропускную способность RAM и Latency. Я встречал ситуацию, правда один раз, когда из супового набора плашек получилось собрать очень-очень медленную RAM с дикими задержками доступа. При этом сервер работал как ни в чем не бывало, но все сказочно тупило.
Не похоже, что вы докопались до первопричины проблемы.
DeathRAMCC Автор
По моему опыту, с 8ю единицами теста - даже база бухгалтерии объемом в 2 гига еле шаволится. Да и рост в 300% вполне себе результат. На серверах где 30 +- единиц гарантированно работают 25-30 человек вольготно. Многое зависит ещё от объема базы, но это уже решения и железо для крупных заказчиков и там вообще другие развлечения.
И память и жёсткие показывали отличную скорость, сейчас по памяти не воспроизведу результат, доступа к этому серверу уже нет. Проект мной сдан. Дальше там 1Сники развлекаются.
ivankudryavtsev
Ну вы же сами сказали, что 4 ядра Selectel-а вас переехали, а это CPU гипервизора с кучей переключения контекста между VM. А у вас аж монопольный CPU с 32 ядрами, 64 потоками. Выглядит что 3х кратный рост (300%, конечно, звучат внушительнее) не очень-то.
DeathRAMCC Автор
4 ядра selectel были для подтверждению заказчику важности частоты процессора в работе 1С.
В этом то и боль специфики 1С. По всем параметрам более крутой сервер но с низкой тактовой частотой будет работать хуже чем условный ноутбук на мобильном проце с тактовой частотой 3.5 ГГц.
ЗЫ все ж таки 16 ядер в процессоре на железе. 32 это HT от Интел)))