Re: CPUs for new databases

Поиск
Список
Период
Сортировка
От Scott Carey
Тема Re: CPUs for new databases
Дата
Msg-id 15C3CE0E-B25A-42AB-A618-DBB98A678AAF@richrelevance.com
обсуждение исходный текст
Ответ на Re: CPUs for new databases  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-performance
On Nov 26, 2010, at 2:30 PM, Greg Smith wrote:

>
> In addition to the memory issues, there's also thread CPU scheduling
> involved here.  Ideally the benchmark would pin each thread to a single
> core and keep it there for the runtime of the test, but it's not there
> yet.  I suspect one source of variation at odd numbers of threads
> involves processes that bounce between CPUs more than in the more even
> cases.
>

Depends on what you're interested in.

Postgres doesn't pin threads to processors.  Postgres doesn't use threads.  A STREAM benchmark that used multiple
processes,with half SYSV shared and half in-process memory access, would be better.   How the OS schedules the
processesand memory access is critical.  One server might score higher on an optimized 'pin the processes' STREAM test,
butbe slower in the real world for Postgres because its not testing anything that Postgres can do. 


> --
> Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
> PostgreSQL Training, Services and Support        www.2ndQuadrant.us
> "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance


В списке pgsql-performance по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: executor stats / page reclaims
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: problem with from_collapse_limit and joined views