PostgreSQL 12-1C проведение документов в ~3 раза медленнее на Linux

Доброго дня всем.

Есть тестовый стенд с Hyper-V 2019 (2xIntel E5-2650v2, 256GB RAM, Intel SSDs in RAID):
* Одна VM с сервером 1C
* Две VM c PostgreSQL c идентичными базами (~56Gb, Бухгалтерия 3.0):
1. CentOS 7 c postgresql_12.6_6.1C_x86_64 (интеграция стоит
2. Windows Server 2019 с тем же postgresql_12.6_6.1C_x86_64

Для теста провожу 10 одних и тех же документах в каждой базе 1C/PostgreSQL. Базы идентичны и прямо перед тестом загружаются из ДТ.
На Windows Server проводится за 20 - 30 seconds, на Linux занимает 1м - 1м10с. Виртуалки PostgreSQL крутятся на одном и том же гипервизоре с одинаковыми ресурсами (16 vCPU, 90Гб, места с запасом).
Тюнинг конфига PostgreSQL и/или CentOS результата не дает. На Windows напротив - вижу почти в 3 раза лучшую производительность на дефолтном конфиге.

Что может быть не так?

--
Тарас Савчук

я бы начал с теста на баред-метал инсталяции Win и linux, чтобы сразу исключить путь до диска в VM и особености обработки системных вызовов ядра ОС в виртуальной машине. Сейчас у вас "путь" до процессора, RAM, диска и сети по сути непредсказуем и известен только коду гипервизора.

On июнь 4 2021, at 3:01 дня, Taras Savchuk <taras(at)1adm(dot)ru> wrote:
>
> Доброго дня всем.
>
>
> Есть тестовый стенд с Hyper-V 2019 (2xIntel E5-2650v2, 256GB RAM, Intel SSDs in RAID):
> * Одна VM с сервером 1C
> * Две VM c PostgreSQL c идентичными базами (~56Gb, Бухгалтерия 3.0):
> 1. CentOS 7 c postgresql_12.6_6.1C_x86_64 (интеграция стоит
> 2. Windows Server 2019 с тем же postgresql_12.6_6.1C_x86_64
>
> Для теста провожу 10 одних и тех же документах в каждой базе 1C/PostgreSQL. Базы идентичны и прямо перед тестом загружаются из ДТ.
> На Windows Server проводится за 20 - 30 seconds, на Linux занимает 1м - 1м10с. Виртуалки PostgreSQL крутятся на одном и том же гипервизоре с одинаковыми ресурсами (16 vCPU, 90Гб, места с запасом).
> Тюнинг конфига PostgreSQL и/или CentOS результата не дает. На Windows напротив – вижу почти в 3 раза лучшую производительность на дефолтном конфиге.
>
> Что может быть не так?
>
> --
> Тарас Савчук
>
>
>

Привет

> я бы начал с теста на баред-метал инсталяции Win и linux, чтобы сразу исключить путь до диска в VM и особености обработки системных вызовов ядра ОС в виртуальной машине. Сейчас у вас "путь" до процессора, RAM, диска и сети по сути непредсказуем и известен только коду гипервизора.

Поддержу.
Я бы сходу даже предложил гипотезу, что для своей родной системы MS автоматически включает паравиртуальный режим и соответственно выкидывает существенную часть эмуляции железа. А вот для generic виртуалок это весьма вероятно нужно включать явно где-то в настройках.

regards, Sergei

> Привет
>
> > я бы начал с теста на баред-метал инсталяции Win и linux, чтобы сразу
> исключить путь до диска в VM и особености обработки системных
> вызовов ядра ОС в виртуальной машине. Сейчас у вас "путь" до
> процессора, RAM, диска и сети по сути непредсказуем и известен только
> коду гипервизора.
>
> Поддержу.
> Я бы сходу даже предложил гипотезу, что для своей родной системы MS
> автоматически включает паравиртуальный режим и соответственно
> выкидывает существенную часть эмуляции железа. А вот для generic
> виртуалок это весьма вероятно нужно включать явно где-то в
> настройках.

Железное железо под тест быстро организовать - это, конечно, проблема сейчас ) А вариантов кроме "гипервизор виноват" не видно. Попробую на KVM ту же базу посмотреть, такой вариант есть под рукой. Пока прогнал тест сети (iperf): win-win на 40% быстрее win-linux (5,97Gbps vs 3,6Gbps). 40% там, 30% там - так может и набраться на 2 раза.

--
Тарас

> Привет
>
> > я бы начал с теста на баред-метал инсталяции Win и linux, чтобы сразу
> исключить путь до диска в VM и особености обработки системных
> вызовов ядра ОС в виртуальной машине. Сейчас у вас "путь" до
> процессора, RAM, диска и сети по сути непредсказуем и известен только
> коду гипервизора.
>
> Поддержу.
> Я бы сходу даже предложил гипотезу, что для своей родной системы MS
> автоматически включает паравиртуальный режим и соответственно
> выкидывает существенную часть эмуляции железа. А вот для generic
> виртуалок это весьма вероятно нужно включать явно где-то в
> настройках.
>
> regards, Sergei

А какую из вашего опыта стоит ожидать разницу виртуализация vs железо на том самом оборудовании? Десятки процентов или все же разы?

Субъективно - разы (может быть даже десятки раз), но для объективного ответа на этот вопрос надо тестировать.
Очень зависит от всех составляющих: и гипервизора, и железа, и настройки самого приложения, и данных в нем, и настройки ядра ОС даже, сетевой стек тоже, если вы гоняете данные по сети (даже если не гоняете - то сетевой стек влияет, т.к. конечная цель пакетов tcp/ip - быть обработанными процессором и попасть в свое приложение, т.е. соседнее приложение тоже занимает процессорное время)

Я говорил про то, что если вы хотите протестировать в равных условиях - то надо избавиться от прослойки в виде гипервизора, а потом крутить настройки дальше.
On июнь 8 2021, at 12:25 дня, Taras Savchuk <taras(at)1adm(dot)ru> wrote:
> > Привет
> >
> > > я бы начал с теста на баред-метал инсталяции Win и linux, чтобы сразу
> > исключить путь до диска в VM и особености обработки системных
> > вызовов ядра ОС в виртуальной машине. Сейчас у вас "путь" до
> > процессора, RAM, диска и сети по сути непредсказуем и известен только
> > коду гипервизора.
> >
> > Поддержу.
> > Я бы сходу даже предложил гипотезу, что для своей родной системы MS
> > автоматически включает паравиртуальный режим и соответственно
> > выкидывает существенную часть эмуляции железа. А вот для generic
> > виртуалок это весьма вероятно нужно включать явно где-то в
> > настройках.
> >
> > regards, Sergei
>
> А какую из вашего опыта стоит ожидать разницу виртуализация vs железо на том самом оборудовании? Десятки процентов или все же разы?

привет

> А какую из вашего опыта стоит ожидать разницу виртуализация vs железо на том самом оборудовании? Десятки процентов или все же разы?

На внятных дисках - а intel делать SSD умеют и весьма хорошо - запросто в разы разница бывает на IO. Довольно много вещей всё ещё не рассчитано на хорошие быстрые диски. Взять даже аппаратные raid-контроллеры - без аккуратного чтения документации к нему можно легко просесть в 2 раза по IO относительно глупого HBA с программным рейдом. Что уж говорить о виртуализации? Эмуляция периферии никогда не была быстрой. А у вас я всё так же предполагаю причину именно в разнице эмуляции периферии для одного гостя и паравиртуализации в другом госте.

regards, Sergei