Да, действительно, можно было ограничиться и тремя физическими серверами или четырьмя. Главное, что выполняется условие, что сумма vCPU не превышает количество физических ядер.
Что касается компромисса "производительность/стоимость" - полностью согласен с комментарием. В бизнесе это всегда так и работает. Статья намеренно ориентирована на технические моменты, возникающие при разных типах размещения. Имея на руках техническую фактуру, можно рассчитать стоимость в выбранном облачном провайдере/частном облаке и принять бизнес-решение.
По поводу количества процессов Postgres... На каждом сегменте запущен 1 слушающий процесс "query executor", на каждый запрос порождается новый процесс. Но он, обычно не один. Дело в том, что если в плане запроса присутствуют операции, которые можно распараллелить, то greenplum это делает. Таким образом, в каждом сегменте на 1 запрос порождается несколько процессов. И их число меняется по мере исполнения плана запроса. Возвращаясь к таблице, на concurrency = 4 кол-во параллельно работающих процессов УЖЕ превышает кол-во vCPU, что видно по увеличенному значению времени в Сценариях 2. А вот при concurrency = 1 ЕЩЁ НЕ превышает.
Полочка по CPU обусловлена настройкой ресурсной группы, в которой запускались тесты (gp_resource_group_cpu_limit = 0,9). Делалось специально, чтобы оставить небольшой запас для системных процессов. По поводу рекомендаций буду благодарен за ссылку.
Не уверен, что правильно понял вопрос, т.к. цифры в 200% не нашёл в статье. Предположу, что речь о таблице с результатами измерений времени. Там приводятся высчитанные проценты увеличения времени исполнения запросов при росте конкуренции за ресурсы процессора. Т.е. чем больше процент, тем медленнее отрабатывают запросы, что является отрицательным результатом.
Это тянет на отдельное исследование. У нас была немного другая цель изначально. В любом случае, спасибо за комментарий. Возможно, в будущем доберёмся и до подобной задачи.
Да, действительно, можно было ограничиться и тремя физическими серверами или четырьмя. Главное, что выполняется условие, что сумма vCPU не превышает количество физических ядер.
Что касается компромисса "производительность/стоимость" - полностью согласен с комментарием. В бизнесе это всегда так и работает. Статья намеренно ориентирована на технические моменты, возникающие при разных типах размещения. Имея на руках техническую фактуру, можно рассчитать стоимость в выбранном облачном провайдере/частном облаке и принять бизнес-решение.
По поводу количества процессов Postgres... На каждом сегменте запущен 1 слушающий процесс "query executor", на каждый запрос порождается новый процесс. Но он, обычно не один. Дело в том, что если в плане запроса присутствуют операции, которые можно распараллелить, то greenplum это делает. Таким образом, в каждом сегменте на 1 запрос порождается несколько процессов. И их число меняется по мере исполнения плана запроса. Возвращаясь к таблице, на concurrency = 4 кол-во параллельно работающих процессов УЖЕ превышает кол-во vCPU, что видно по увеличенному значению времени в Сценариях 2. А вот при concurrency = 1 ЕЩЁ НЕ превышает.
Полочка по CPU обусловлена настройкой ресурсной группы, в которой запускались тесты (gp_resource_group_cpu_limit = 0,9). Делалось специально, чтобы оставить небольшой запас для системных процессов. По поводу рекомендаций буду благодарен за ссылку.
Не уверен, что правильно понял вопрос, т.к. цифры в 200% не нашёл в статье. Предположу, что речь о таблице с результатами измерений времени. Там приводятся высчитанные проценты увеличения времени исполнения запросов при росте конкуренции за ресурсы процессора. Т.е. чем больше процент, тем медленнее отрабатывают запросы, что является отрицательным результатом.
Это тянет на отдельное исследование. У нас была немного другая цель изначально. В любом случае, спасибо за комментарий. Возможно, в будущем доберёмся и до подобной задачи.
Спасибо за комментарий! Это действительно так. Мы хотели показать, как именно это влияет на производительность Arenadata DB в условиях переподписки.