Выбор серверного оборудования и настроек для работы с 1С — это ключевой вопрос для бизнеса, где важны скорость, стабильность и масштабируемость. Мы провели масштабное тестирование: сравнили производительность процессоров AMD EPYC и Intel Xeon, протестировали работу ПО на Windows и Ubuntu, а также оценили влияние дисковых контроллеров и других параметров настройки.
Результаты оказались неочевидными: удалось достичь почти двукратного прироста производительности в некоторых сценариях. Уже поделились опытом на вебинаре и рассказываем здесь, какое решение лучше подойдет для бизнеса и как избежать ошибок при выборе инфраструктуры для 1С.
Какие процессоры мы тестировали
Для тестирования выбрали два процессора из разных семейств и от конкурирующих брендов: Intel® Xeon® Gold 6242R и AMD EPYC™ 9374F. Последний мы добавили в инфраструктуру облака mClouds в четвертом квартале и именно поэтому выбрали его для сравнения с уже зарекомендовавшим себя Intel Xeon.
Оба процессора используются в нашей облачной инфраструктуре, так что результаты тестов отражают штатные показатели работы.
Вот что можно сказать о каждом из процессоров:
Intel® Xeon® Gold 6242R. Этот процессор хорошо зарекомендовал себя при работе с 1С. У него 20 ядер, базовая частота 3,1 ГГц и 3,9 ГГц в режиме постоянного буста на все ядра. Это стабильное и широко используемое решение для корпоративных задач, включая работу с 1С.
AMD EPYC™ 9374F. Процессор с 32 ядрами, частотой до 4,1 ГГц в режиме all-core и базовой частотой 3,85 ГГц, а также с поддержкой памяти DDR5. Именно базовая частота стала одним из факторов выбора этой платформы, так как в новом поколении Xeon пока нет процессоров с аналогичным показателем. Тестирование 9374F поможет оценить, насколько новые технологии могут повысить производительность 1С.
Серверное оборудование для тестов. Наши облачные кластеры работают на серверах Dell, поэтому именно они использовались при тестировании:
Intel: процессоры установлены в платформе Dell R640. Она популярна для задач виртуализации и работы с базами данных. В нашем облаке используются и хосты виртуализации на базе серверов Dell R650 с процессорами Xeon Gold 6354, но тесты проводили на R640 и Xeon Gold 6242R.
AMD: процессоры работают в платформе Dell R7625, которая поддерживает DDR5 память. Эта платформа создана для обработки больших объемов данных и высоких нагрузок. Кроме того, она выбрана для работы с GPU — на базе этих серверов у нас функционируют GPU-серверы с видеокартами NVIDIA A16 и L40S.
Система хранения данных. В тестах мы использовали быстрые системы хранения IBM Flash System. Они обеспечивают высокие показатели IOPS, низкие задержки и высокую отказоустойчивость, что критически важно для работы с 1С и СУБД.
Конфигурация виртуальных машин
Тестирование проводилось в нашей облачной платформе на базе VMware — это те же условия, в которых работают системы наших заказчиков. Все тесты проводились на одинаковой конфигурации виртуальных машин, чтобы исключить влияние аппаратных различий. Настройки были такими:
Процессор: 8 виртуальных ядер (1 сокет с 8 ядрами). Это оптимальное решение для типичной нагрузки 1С.
Оперативная память: 32 ГБ. Отношение памяти к ядрам — 1 к 4, что обеспечивает хороший баланс для работы 1С.
Операционные системы: Windows Server и Ubuntu. Протестировали обе платформы, чтобы сравнить их производительность.
Как мы измеряли производительность
Для оценки производительности мы выбрали два популярных инструмента, которые охватывают разные аспекты работы серверов: HammerDB и тест Гилёва.
HammerDB. Это универсальный инструмент для тестирования производительности СУБД. Он моделирует нагрузку, близкую к реальным сценариям бизнес-приложений. В наших тестах мы использовали HammerDB для работы с двумя популярными СУБД:
PostgreSQL. Эта база данных часто используется в 1С, особенно в средах на Linux.
Microsoft SQL Server. Традиционное решение для пользователей Windows, которое остается стандартом для многих 1С-систем.
HammerDB позволил нам оценить производительность процессоров в условиях интенсивной работы с базами данных. Мы посмотрели, как каждая платформа справляется с обработкой большого объема данных и выполняет сложные транзакции.
Тест Гилёва. Это один из самых популярных инструментов среди пользователей 1С. Он предназначен для оценки производительности серверов именно в контексте работы 1С:Предприятие. Тест измеряет, насколько быстро сервер может выполнять типовые операции и обрабатывать запросы.
Что мы выяснили во время тестирования процессоров
Процессор AMD EPYC™ 9374F показал заметное преимущество над Intel® Xeon® Gold 6242R, особенно в задачах с высокой многопоточностью. Вот ключевые факторы, которые оказали влияние на результаты:
Оперативная память. В обновленном облачном кластере на базе AMD EPYC используется DDR5 с частотой 4800 МГц. У него более современные и быстрые характеристики, что обеспечивает высокую скорость обработки данных, особенно при работе с БД.
Частота процессора. AMD гарантирует стабильную работу благодаря высокой базовой частоте (от 3,85 до 4,1 ГГц).
Кеш-память. У AMD объем кеша более чем в 5 раз превышает показатели Intel. Это дает ощутимый козырь в многопоточных задачах.
HammerDB показал, что переход на AMD и использование дискового контроллера Paravirtual SCSI увеличили скорость обработки транзакций до 65% по сравнению с Intel.
В тесте Гилёва разница между AMD и Intel была менее заметной. Прирост составил не более 5%. Это объясняется спецификой теста: он фокусируется на типовых операциях 1С, которые не всегда нагружают процессор на полную мощность.
В результате AMD EPYC стал очевидным лидером в задачах с высокой нагрузкой. Он подходит для работы с большими базами данных и сложными сценариями многопоточности.
Что мы выяснили во время тестирования ОС
Мы протестировали производительность 1С на двух операционных системах: Windows Server и Ubuntu. Цель — понять, стоит ли переходить на Linux для работы с 1С. Результаты оказались интересными.
Ubuntu с PostgreSQL оказалась быстрее Windows Server с Microsoft SQL Server. Прирост особенно заметен на процессорах AMD EPYC. Вот ключевые результаты:
В тесте Гилёва на AMD Ubuntu показала самый высокий прирост производительности.
Ubuntu лучше справляется с многопоточными нагрузками благодаря оптимизации PostgreSQL и эффективности ядра Linux.
Также посмотрели, как показывает себя Intel в тесте Гилёва на Ubuntu и Windows. Результат:
Несмотря на это, Windows Server остается более привычным выбором для многих пользователей 1С. Для работы с этой ОС не требуются специальные навыки, а многие модули и доработки 1С традиционно создаются под Windows.
Почему Ubuntu быстрее?
Результаты тестов показали, что Ubuntu выигрывает за счет нескольких факторов:
Оптимизация PostgreSQL. PostgreSQL на Linux работает стабильнее и быстрее, чем SQL Server на Windows.
Эффективное использование ресурсов. Ubuntu в сочетании с процессорами AMD EPYC использует ресурсы процессоров и памяти более рационально. Это особенно заметно в тестах с большими объемами данных.
Меньше системных затрат. Linux требует меньше системных ресурсов, чем Windows Server, что позволяет выделить их под приложения и базы данных.
Так что, если ваши компетенции позволяют работать с Linux, переход на Ubuntu с PostgreSQL — отличное решение для достижения максимальной производительности.
А если вы привыкли работать с Windows Server и SQL Server, менять систему необязательно. Windows обеспечивает стабильную работу для 1С и не требует дополнительных усилий.
Что мы выяснили во время тестирования дисковых контроллеров
Мы проверили, как тип виртуального дискового контроллера влияет на производительность в среде VMware. Для тестов использовали два типа виртуальных контроллеров:
LSI Logic SAS — стандартный контроллер, который используется по умолчанию.
Paravirtual SCSI (PV SCSI) — контроллер, оптимизированный для виртуализации, с меньшими задержками.
Результаты показали, что смена контроллера может заметно повлиять на производительность.
Замена стандартного контроллера LSI Logic SAS на Paravirtual SCSI дала значительный прирост производительности в тесте HammerDB. Вот основные выводы:
Использование PV SCSI заметно ускорило работу с базой данных на 15–20%. Это особенно заметно в сценариях с высокой нагрузкой и множеством операций.
Сократилось время отклика. HammerDB показал, что время обработки транзакций стало короче, а общая скорость выполнения операций возросла.
Эти результаты связаны с оптимизацией PV SCSI под виртуализированные среды. Он лучше подходит для высоких нагрузок и больших объемов данных.
В тесте Гилёва, ориентированном на задачи 1С, разница оказалась минимальной. Прирост не превысил 5%, что можно считать погрешностью. Это объясняется спецификой теста: задачи 1С меньше зависят от скорости работы дискового контроллера. Поэтому использование PV SCSI в этом случае не дало заметного эффекта.
Результаты показывают, что выбор типа контроллера зависит от ваших задач:
Используйте PV SCSI, если работаете с базами данных. Это особенно актуально для PostgreSQL и других СУБД, где важно уменьшить задержки и ускорить обработку транзакций.
LSI Logic SAS подходит для базовых задач. Если ваша система не зависит от высокой производительности дисков, разница между контроллерами будет минимальной.
Сводные результаты тестирования
Итак, мы проверили, как разные технологии влияют на производительность систем, и вот что у нас получилось:
Платформы на базе Intel остаются проверенным решением для задач, где важны стабильность и совместимость со старым программным обеспечением. В то же время новая платформа на AMD EPYC в тестах показала более высокую производительность в сложных задачах благодаря более современным характеристикам.
Хоть Windows Server и является привычным решением для большинства пользователей 1С, стоит задуматься о переходе на Ubuntu — в некоторых сценариях Ubuntu может показать лучшие результаты, как это произошло у нас. Но не факт, что такой же прирост будет и на других задачах.
Как выбрать оптимальную конфигурацию: 3 распространенных сценария
Каждая компания уникальна, поэтому универсального ответа на вопрос «что лучше?» не существует. Всё зависит от ваших задач, объема данных и бюджета. Мы подготовили простые рекомендации для разных сценариев. Они помогут вам быстро определиться с оптимальным решением.
Для больших баз данных и работы с SQL
Если вы обрабатываете большие объемы данных, подойдет связка AMD EPYC + Ubuntu + PostgreSQL.
Почему это решение лучше:
AMD EPYC обеспечивает высокую производительность и мощность для задач с интенсивной нагрузкой.
Ubuntu дает прирост скорости до 89% по сравнению с Windows Server.
PostgreSQL отлично работает с большими базами данных и позволяет тонко настроить систему под ваши задачи.
Такое решение максимально эффективно для компаний, готовых работать с Linux и заинтересованных в увеличении скорости обработки данных.
Для небольших компаний и стандартных задач
Если у вас типовые сценарии работы с 1С и нет сложных требований, Windows Server на Intel станет надежным и удобным выбором.
Почему стоит выбрать это решение:
Простота: Windows Server уже знаком большинству 1С-ников, что сокращает время на внедрение.
Стабильность и совместимость: Intel и Windows Server хорошо подходят для работы в привычной среде, особенно если у вас есть старое ПО, которое важно поддерживать.
Это подход для компаний, которым важны минимальные усилия и проверенные технологии.
Для тех, кому важна гибкость
Если вы хотите гибко масштабировать систему и использовать современные технологии, виртуализация станет ключевым решением. Мы рекомендуем:
Использовать виртуализацию. Это удобнее и эффективнее, чем работа с «чистым» железом. Она упрощает резервное копирование, масштабирование и управление инфраструктурой.
Применять современные настройки. Например, настройка дискового контроллера Paravirtual SCSI дает прирост в производительности до 20% по сравнению с LSI Logic SAS. Оптимизация BIOS (включение режима High Performance, отключение C-State) также важна для повышения скорости.
Этот вариант подходит для компаний, которые растут и нуждаются в быстрой адаптации инфраструктуры под изменяющиеся задачи.
Тестируйте оборудование — это важно
Один из ключевых выводов наших тестов — не существует идеального оборудования или ПО, которое подходит всем. Всё зависит от ваших задач, объема данных, нагрузки и бюджета.
Посмотреть полную запись вебинара можно на YouTube-канале или в ВК, где мы еще подробнее рассказали о результатах тестов. Если вы хотите протестировать свои задачи на платформе с высокочастотными процессорами AMD EPYC 9374F — обращайтесь.
От себя рекомендуем попробовать обе конфигурации: и Windows Server на Intel, и Ubuntu на AMD, чтобы понять, какая из них лучше подходит вашему бизнесу.
А на каких процессорах и ОС работает ваша 1С? И как производительность? Поделитесь в комментариях — соберем статистику Хабра)
Комментарии (15)
mClouds_editor Автор
23.01.2025 07:03Еще вопрос - вы предварительную оптимизацию делали для СУБД Postgresql? Или взяли стоковую сборку от 1С и на ней запускали тесты? Поскольку по умолчанию postgresql настроен на минимальное потребление ресурсов, в отличие от MS SQL, который тюниися под систему прямо при установке.
В тестировании, помимо самих тестов, проверяли различные конфигурации СУБД, чтобы посмотреть, как влияют на производительность эти изменения. Преимущественно, оптимизация под текущие параметры ВМ - лимит памяти, параллелизм и т.п.
Основные параметры, что затрагивались, мы указывали в блоге на своем сайте.
По моим наблюдениям за последние пару лет, разница может достигать 30% до и после настройки параметров.
Да, иногда обращаются клиенты и тестируют старые версии, как 1С, так и MS SQL - всегда говорим, проверьте перед внедрением на пилотном проекте, как работает система, а затем делайте выводы и используйте лучшее.
Кроме этого важна версия СУБД, 12 от 17 отличаются достаточно сильно, а кроме того крайне важна версия платформы. 8.3.24 и 8.3.25 отличаются между собой по производительности на 10-15% в пользу 8.3.25, при этом очень много пользователей работают под 8.3.24, об этом также важно помнить.
Тестировали на 8.3.25.1394.
beerchaser
23.01.2025 07:03Интересно было бы увидеть подобные тесты с зависимостями от количества ядер и от частот ядер. Причём для Postgres и для 1С отдельно.
haumea
23.01.2025 07:03Как показала практика, частота влияет, но в совокупности с другими параметрами.
Разница в ~250 мгц, а в тесте Гилёва отрыв у AMD сильный, влияет в том числе из-за - частоты памяти, кэш процессора.beerchaser
23.01.2025 07:03Вопрос немного не про это. Интерес связан с необходимостью технического обоснования выбора процессора. Требуется информация, на основании которой можно обосновать выбор, например, 8-ядерного 3,3 GHz процессора 6xxx серии против 20-ядерного 2,3 GHz процессора 4xxx серии. Причем для сервера приложениеи и для субд раздельно.
Sergey-S-Kovalev
23.01.2025 07:03Ох уж этот тест Гилева.
Там у сервера 1С есть встроенный счетчик производительности (Кластер / Рабочие процессы / Доступ. производительность), вы на него то хоть разок посмотрели? можно увидеть его детализацию? Там прям во время любого теста можно из ТЖ собрать детальный отчет о производительности каждого компонента системы CPU, начиная с 8.3.25 даже сразу в JSON можно.
Вот пример:
{"ts":"2025-01-23T14:24:22.024004","duration":"0","name":"CLSTR","depth":"2","level":"INFO","process":"rmngr","OSThread":"5432","t:clientID":"477762","t:applicationName":"Notification","t:computerName":"server-name-here","Event":"Performance update","Data":"process=tcp://server-name-here:1568,pid=3644,sql=0,cpu=1,queue_length=0,queue_length/cpu_num=0,memory_performance=19,disk_performance=7,response_time=27,average_response_time=27.41"}
По каждому процессу можно понять, какой компонент в системе тормозил в тот или иной момент времени. Вы можете накидать любой крутой проц/памяти/nvme и глядя на цифры в тесте Гилева выписывать себе премию за то что вы такие молодцы, а потом выяснится что сервер лицензирования с клиентскими лицензиями на двух ядрах и двух гигах ставит на колени стоящие вокруг мегасервера потому что к нему очередь на обновление валидности клиентской лицензии работающего пользователя.
За статью спасибо, но жаль что сделано много бесполезной работы.
mClouds_editor Автор
23.01.2025 07:03Тут все-таки, у нас не было задачи оценивать вообще продуктив по 1С целостно и искать в нем баги и что тормозит, а провести анализ синтетики и подсветить разность результатов на них на как разных платформах, так и разных ОС. Мы получили по ним результаты и решили поделиться ими на Хабре, статья не претендует на решение вопросов комплексных, абсолютно все охватывающих. Мы понимаем что по 1С практики очень много не только с точки зрения подбора аппаратных платформ, но и программных.
haumea
23.01.2025 07:03Сергей, давайте вместе напишем статью и поделимся нужной информацией по оптимизации и метрикам, как 1С, так и СУБД. Узкими специалистами в 1С не являюсь, но было бы круто, совместно с экспертом посмотреть глубже на оптимизацию и мониторинг компонентов/подсистем.
Можете отправить ссылку на тех.журнал, который хорошо описывает данные параметры, с вашей точки зрения? Я гляну и перепроверю результаты и поделюсь.
Sergey-S-Kovalev
23.01.2025 07:03Я регулярно пишу статьи во внутренней вики, в рамках рабочего процесса конечно же, так что эта потребность у меня закрыта. Я тоже не являюсь узким специалистом 1С, и технологическим экспертом тоже не являюсь. У меня просто много серверов в зоне моей ответственности 1С и очень опытные коллеги 1Сники, что бы им доказать, что 1С тормозит не из-за сервера/ОС/БД недостаточно показать им скриншот из таскменеджера, где все в приделах 5-10%.
Что касаемо мониторинга доступной производительности, то я не нашел статей комплексно описывающих именно этот аспект системы, мол сделай конфиг, парси json и будет тебе реалтайм производительность именно сервера 1С, а не железа в котором он крутится.
Самое близкое это описание где этой включить в logcfg.xml события CLSTR: https://its.1c.ru/db/v8325doc#bookmark:adm:TI000000996
блок:
performance update ‑ обновлены показатели производительности процесса. Для события определены следующие свойства:
● Data ‑ значения параметров, характеризующих уровень производительности процесса в виде «параметр=значение», разделенные запятой. Данные параметры могут использоваться администраторами серверов 1С:Предприятие для оценки изменения производительности рабочих процессов, СУБД и нагрузки на оборудование. Доступны следующие параметры производительности:
● average_response_time ‑ усредненное (за 5 минут) время выполнения эталонных операций для вычисления доступной производительности, миллисекунды.
● cpu ‑ процент загруженности процессора.
● disk_performance ‑ время выполнения эталонных операций с файлами, миллисекунды.
● memory_performance ‑ время выполнения эталонных операций с памятью, миллисекунды.
● pid ‑ системный идентификатор процесса.
● process ‑ адрес процесса кластера.
● queue_length ‑ длина очереди запросов к процессору.
● queue_length/cpu_num ‑ соотношение длины очереди запросов к количеству ядер процессора.
● response_time ‑ время выполнения эталонных операций для вычисления доступной производительности, миллисекунды.
● sql ‑ время выполнения эталонных запросов к СУБД, миллисекунды.
Дальше опять кусочки информации:
https://its.1c.ru/db/v8326doc#bookmark:cs:TI000000036
2.2.7.1. Доступная производительность рабочего процесса
Каждый рабочий процесс имеет свойство Доступная производительность. Оно определяет, насколько быстро данный рабочий процесс способен выполнить эталонные операции по сравнению с другими рабочими процессами. Эталонные операции состоят из:
● Операции с памятью: выделение массива, заполнение массива, освобождение массива.
● Операции с файлами: создание, запись, удаление.
● Определение степени загрузки процессоров компьютера, на котором работает рабочий процесс и количество потоков, ожидающих исполнения. Это значение корректирует время выполнения эталонного вызова в сторону увеличения.
При работе под управлением ОС Windows пользователь, от имени которого работает сервер, должен входить в группу Пользователи журналов производительности (Performance Log Users). В противном случае определение степени загрузки процессора не выполняется.
Значение свойства Доступная производительность вычисляется делением числа 10 000 на среднее (за 5 минут) время выполнения эталонных операций текущим рабочим процессом. Измерение скорости выполнения эталонных операций выполняется каждые 5 секунд.
Клиенты распределяются между рабочими процессами так, чтобы сделать доступную производительность всех рабочих процессов примерно одинаковой. Существенным считается отличие доступной производительности более чем на 25%.
При изменении соотношения между доступной производительностью рабочих процессов клиенты динамически в течение не более 10 минут перераспределяются между рабочими процессами.
При выключении рабочего процесса его клиенты динамически перераспределяются между оставшимися включенными рабочими процессами.
Но все выше описанное это грустные игры в парсинг регулярками ТЖ в реалтайме что бы графики в графане рисовали актуальное и красивое.
Однако счастливые обладатели КОРП (а в некоторых случаях, как выяснилось и в ПРОФ, но это отдельная печальная история которую разработчики пофиксят в будущих релизах) могут прямо с RAS в виде метрик для прометея забирать все что надо:
https://its.1c.ru/db/metod8dev/content/6019/hdoc/_top/--monitor-address=any --monitor-port=1555
Sergey-S-Kovalev
23.01.2025 07:03Я замечу, что не я такой красивый и умный. Меня в это настоящий технологический эксперт 1С направил, ну а дальше уже сам копал и внедрял в компании вместе с коллегами из разработки.
Но да, после того как разобрался с этим аспектом, понял что половина моей админской жизни в части анализа производительности и
выбора оборудованиярешения проблем с производительностью, для 1С была ложью.
HADGEHOGs
23.01.2025 07:03Вы там, когда наиграетесь, выгрузите табличку всех тестов Гилева в Excel других пользоватей и посмотрите на каком месте ваши мощные сервера.
mClouds_editor Автор
23.01.2025 07:03Мы уже наигрались и выложили результаты ) Не с целью что у нас мощные сервера, а с целью показать разницу одного и того-же, но на разных ОС и БД.
Irit_LS
Что ж вы тесты Гилева не до конца проводите для AMD Epyc? Почему нет теста многопоточности, при том что для Intel вы его провели?
Кроме этого, результаты Гилева надо брать средние от 3-5 запусков, так как первый тест ВСЕГДА выдает прирост производительности на 10-15% поскольку сама база пустая и индексы не мешают для операций.
Смотреть надо не только однопоточные операции (они важны, но только для спортивного интереса и для сравнительной оценки), но и многопоточные, так как системы рассчитаны на многопользовательскую работу в первую очередь.
А так что Intel Xeon что AMD Epyc крайне слабы для синтетических однопоточных тестов даже по сравнению с Intel 8400 (48 баллов Гилева) или AMD Ryzen 7700X (77 баллов Гилева). Но это ж не значит что надо брать десктоп камни для 100+ пользователей.
mClouds_editor Автор
Результаты Гилева брали несколько раз, скрин выложили уже наиболее близкий к среднем результату.
mClouds_editor Автор
Возвращаюсь с комментариями от непосредственно нашей тех команды, участвовавшей в тестировании )
Коллеги делали скрины в таком формате, не всегда дожидались теста многопоточной записи на диск.
Да, так и делали, брали среднее значение, Артём на вебинаре говорил об этом, что было не менее пяти запусков каждого теста, пример в карусели - https://imgur.com/a/ghWZwjl
Верно, в зависимости от системы и её конфигурации можно получить разные результаты, которые могут не коррелироваться с цифрами производительности, грубо - десктопный процессор в тестах может быть лучше, но при работе в продакшене на 70+ пользователей, разница в производительности может быть сильной.
Irit_LS
Еще вопрос - вы предварительную оптимизацию делали для СУБД Postgresql? Или взяли стоковую сборку от 1С и на ней запускали тесты? Поскольку по умолчанию postgresql настроен на минимальное потребление ресурсов, в отличие от MS SQL, который тюниися под систему прямо при установке.
По моим наблюдениям за последние пару лет, разница может достигать 30% до и после настройки параметров.
Кроме этого важна версия СУБД, 12 от 17 отличаются достаточно сильно, а кроме того крайне важна версия платформы. 8.3.24 и 8.3.25 отличаются между собой по производительности на 10-15% в пользу 8.3.25, при этом очень много пользователей работают под 8.3.24, об этом также важно помнить.