Vmware Esxi — старая проблема с производительностью 32-битного программного обеспечения на многоядерном процессоре

Уже 2 дня схожу с ума, прошу помощи.

У меня есть программа, разработанная в Delphi (около начала 2000-х годов), которая обращается к базе данных firebird v3, которая в настоящее время установлена ​​на том же компьютере (Windows Server 2016 x64 - db и программа x86).

Машина представляет собой виртуальную машину, настроенную на vmware esxi, я перехожу к сути: если я настрою виртуальную машину только с 1 виртуальным ЦП, программа работает очень хорошо, если я также настрою ее с 2 виртуальными ЦП (1 сокет и 2 ядра) или более, производительность снижается вдвое.

Проблема в том, что, оставив только один виртуальный ЦП, ЦП постоянно загружен на 100%, даже только для заданий сервера Windows (например, для поиска обновлений и прочего).

Есть ли у вас какие-либо рекомендации?

PS: я не могу переключиться на firebird x64, потому что многие библиотеки x86.

PPS: ОС на виртуальной машине — Windows Server 2016 Standard ed.

Оставьте гостя на одном процессоре. И задокументируйте причину в некоторых заметках об этом госте в инвентаре.

Сосредоточьтесь больше на показателях производительности приложений и меньше на вводящих в заблуждение основных показателях, таких как загрузка ЦП. Отвечают ли интерактивные приложения? Выполняются ли пакетные запросы за приемлемое время? Если это так, не беспокойтесь о процессоре.

Изменить: «Заблокировать» уровни плохой производительности не было в вашем исходном вопросе, это важный контекст. Решение этой проблемы может стоить дополнительных усилий:

• Запланируйте время обслуживания, когда база данных выключается, для применения обновлений и других задач.
• Увеличьте количество ЦП и примените конфигурацию CPUAffinity на уровне приложения, упомянутую в других комментариях, чтобы зафиксировать ее на одном.

Если вы зафиксируете привязку процесса к одному ядру, другое ядро ​​останется свободным для других процессов. В зависимости от фактической проблемы с планированием может возникнуть необходимость настроить сервер Firebird на то же или другое ядро.

Однако, поскольку ESXi также виртуализирует ядра ЦП, он будет продолжать перемещать ядра виртуального ЦП между вашими физическими ядрами. Возможно, вам также потребуется исправить привязку виртуальных машин к определенным ядрам.

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

Это известная проблема FireBird.

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

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

Поточно-ориентированная клиентская библиотека

Поточно-ориентированная клиентская библиотека

Дмитрий Еманов
Владислав Хорсун
Алексей Пешков

Референс трекера CORE-707.

Клиентские библиотеки, включая встроенную, теперь можно использовать в многопоточных приложениях без какого-либо уровня приложений.

синхронизация.