Работа PostgreSQL на процессорах с гетерогенной архитектурой под Windows?
Имеется "сервер" на базе Intel i7-13700 (8p+8E), работает под управлением Windows Server 2019.
Развернута полусамописная CRM для управления товарами и ценами, использующая БД PostgreSQL (18.1).
Нагрузка в основном OLTP (обновление цен, импорт прайс-листов, генерация фидов).
postgresql.conf настроен с учётом параметров ЦП и ОЗУ.
Какая конфигурация будет оптимальной:
1. Сток
2. Отключены E-ядра, но включен HT
3. Отключён HT на P-ядрах, но включены E-ядра
Ну так тем более, что никто кроме вас не сделает за вас тест производительности на вашего железа, вашей конфигурации ПО и вашей нагрузки. Или вы хотите поиграть в ребусы, чтобы мы тут отгадывали телепатически?
Плюс хотелось бы теоретическое обоснование.
Какое вы хотите теоретическое обоснование? И обоснование чего именно? Производительности? Так она разная бывает. Там очень много разных критериев. В общем случае — чем лучше ТТХ железа и чем лучше оптимизировано ПО, тем больше производительность.
В общем, на текущий момент ваш вопрос не имеет смысла и вероятнее всего его просто удалят.
когда то давно пролетала инфа о плагине к PostgreSQL, который использует GPU для ускорения обработки запросов. не могу ни чего добавить об актуальности и уместности к вашей задаче и железу. просто кидаю тему, может пригодится.
Определенно здесь Windows является лишним звеном. Непонятно зачем вы тратили лишнюю лицензию.
По поводу включения и выключения HT. Я думаю что никто не ответит на ваш вопрос. Потому что нет такой теории которая бы объясняла OLTP нагрузку в сочетании с таким сложным стеком технологий.
Поэтому найдите метрику, на которую нужно смотреть. Пускай это будет среднее время отклика для OLTP query с точки зрения конечного потребителя. Или даже лучше не среднее время а квартиль или процентиль.
И проведите 2-3 эксперимента. А уже после того как будут цифры - можно искать теоретическое объяснения.
В целом: только на P-ядрах быстрее. Сравнивал как по логам CRM, так и через pg_stats.
В итоге - перенастроил postgresql.conf под количество p-ядер.
E-ядра оставил активными, но все процессы CRM и postgres повесил на p-ядра с помощью process lasso.
Если есть задачи, которые выполняются долго (десятки секунд) и упираются в одно ядро - разумеется, лучше сделать меньшее количество более производительных ядер.
Но учитывая, что у вас "сервер" на винде - сомнительно, что мы имеет дело с хайлоадом, требующим столь глубокой оптимизации.
Средний
