Производительность 1С на Intel Xeon Gold 6254 | Linux PostgreSQL Open Source

В статье приведены результаты тестирования производительности сервера на базе 2 процессоров Intel Xeon Gold 6254. В качестве тома, на котором располагается база данных, выступал раздел на массиве RAID 10 из 12 SSD Intel D3-S4610 Series, кроме теста локальной файловой БД в Windows. В этом случае база находилась на системном томе из двух SSD Samsung 970 EVO Plus Series на интерфейсах M2. Подробнее о сервере можно прочитать здесь. В качестве теста приметен ТРС от Гилева, предназначенный для тестирования производительности платформы на определенном оборудовании. Этот интегральный тест выбран, так как наиболее точно удовлетворяет требованию — проверить скорость работы оборудования при работе на нем платформы 1С, без учета параллельности и профилей нагрузок. Среди прочего, стоит отметить, что во время тестирования хост был полностью свободен от других потребителей вычислительных мощьностей, а каждый из тестов в статье воспроизводился по 3-5 раз, поэтому приведенные результаты — не случайность. Подробнее о тесте ТРС можно прочитать здесь.

Тест не учитывает особенности параллельной работы и другие нюансы, а тестирует именно скорость работы платформы 1С. Задачей исследования является выяснение влияния виртуализации на производительность 1С на различных системах.

Для тестирования применялись Windows Server 2016, Ubuntu 18, MSSQL 2017, Postgres 10.5-24.1C, 1C 8.3.15.1565 и 1C 8.3.14.1854. В настройках виртуальных машин в качестве типа процессора везде был применен kvm64, включен NUMA и отключен Balooning Device для памяти.

В начале рассмотрим результаты тестирования на физической машине с включенными функциями энергосбережения в BIOS. В качестве системы использован Ubuntu + Postgres + 1C 8.3.15. Для Postgres устанавливались параметры памяти, в соответствиями с рекомендациями от 1.

Результат составил 25.

После отключения функций энергосбережения результат заметно изменился в большую сторону:

Результат составил 45,05.

Можно сделать вывод, что для повышения производительности 1С имеет смысл отключать энергосбережение на сервере. Следует отметить, что в данном случае на материнской плате SuperMicro X11DPH-T-O, как и в большинстве других, энергосбережение по умолчанию включено.

Рассмотрим результаты для Windows Server 2016 + MS SQL 2017 + 1C 8.3.15.1565 на физической машине:

Результат составил 40.

Результат для файловой базы данных на той же машине:

Результат составил 67,57.

На основании полученных результатов можно сделать вывод, что не смотря на использование протокола Shared memory MS SQL Server, на данной машине производительность с Postgres, установленном на Ubuntu 18 немного выше.

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

Производительность на виртуальных машинах

Далее на этот же сервер был установлен Proxmox 6, на нем развернуты машины на базе Windows Server 2016 и, в связи с рядом обстоятельств, Debian 10. В качестве СУБД применены MSSQL 2017 и Postgres 10.5-24.1C соответственно. Также в связи с рядом обстоятельств применена платформа 8.3.14.1854

Тестирование на Windows + MSSQL:

Результат составил 25,38.

Локальная файловая база на этой же машине:

Результат составил 42,02.

Для Debian и Postgres результат получился снова немного выше, чем для MSSQL:

Результат составил 32,05.

Если разместить СУБД и 1С на разных машинах?

Часто встречаются конфигурации систем, в которых сервер 1С и сервер СУБД представляют собой 2 различные машины. В этом случае в работу включается еще стек TCP/IP со всем своим подмножеством протоколов. Если СУБД и 1С находятся на одном узле, в зависимости от типа ОС, будет использоваться протокол SharedMemory или сокеты.

Для Windows + MSSQL + 1C, при условии, что 1С и SQL находятся на разных виртуальных машинах одного физического узла:

Результат 12,22 Это значительно ниже, чем любой из ранее полученных результатов.

Для Debian и Postgres выполнение теста завершилось несколько лучше:

Результат 28,74

Взаимодействие между 1С и СУБД по через стек сетевых протоколов может значительно снизить производительность, пусть даже при отсутствии физического сетевого соединения как такового. Следовательно, если есть возможность держать СУБД и 1С на одном узле, имеет смысл делать это именно так.СохранениеВзаимодействие между 1С и СУБД по через стек сетевых протоколов может значительно снизить производительность, пусть даже при отсутствии физического сетевого соединения как такового. Следовательно, если есть возможность держать СУБД и 1С на одном узле, имеет смысл делать это именно так.

Выводы

Для сравнения полученные результаты необходимо собрать в общей таблице:

	Физический	Виртуальный	Замедление
Win+MSSQL	40	25,38	36,55% (по сравнению с физическим)
Win+FileLocal	67,57	42,02	37,81% (по сравнению с физическим)
Linux+Postgres	45,05	32,05	28,86% (по сравнению с физическим)
Win+MSSQL (2 nodes)	—	12,22	51,85% (по сравнению с виртуальным)
Linux+Postgres (2 nodes)	—	28,74	10,32% (по сравнению с виртуальным)

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

• При выполнении, по крайней мере, некоторых операций, связка Linux + PostgreSQL будет работать с немного большей производительностью, чем Windows+MSSQL
• Потери от виртуализации Linux + Postgres + 1C ниже почти на 10 %, чем при виртуализации Windows + MSSQL + 1C. В обоих случаях на виртуальные машины были установлены последние актуальный драйверы для паравиртуальных устройств.
• Платформа не сильно теряет в производительности при разнесении СУБД и 1С на разные узлы, в случае использования PostgreSQL, однако, все будет зависеть от объема передаваемых во время данных

Наличие замедления по сравнению с файловой БД вызвано присутствием двух сложных механизмов — сервера 1С и СУБД, которые показывают свое преимущество во время параллельной работы большого количества пользователей, реализуя механизмы для параллельной работы.