Re: Linux: more cores = less concurrency.
От | Glyn Astill |
---|---|
Тема | Re: Linux: more cores = less concurrency. |
Дата | |
Msg-id | 976931.36062.qm@web26004.mail.ukl.yahoo.com обсуждение исходный текст |
Ответ на | Linux: more cores = less concurrency. (Glyn Astill <glynastill@yahoo.co.uk>) |
Ответы |
Re: Linux: more cores = less concurrency.
Re: Linux: more cores = less concurrency. |
Список | pgsql-performance |
--- On Mon, 11/4/11, david@lang.hm <david@lang.hm> wrote: > From: david@lang.hm <david@lang.hm> > Subject: Re: [PERFORM] Linux: more cores = less concurrency. > To: "Steve Clark" <sclark@netwolves.com> > Cc: "Scott Marlowe" <scott.marlowe@gmail.com>, "Joshua D. Drake" <jd@commandprompt.com>, "Kevin Grittner" <Kevin.Grittner@wicourts.gov>,pgsql-performance@postgresql.org, "Glyn Astill" <glynastill@yahoo.co.uk> > Date: Monday, 11 April, 2011, 21:04 > On Mon, 11 Apr 2011, Steve Clark > wrote: > > the limit isn't 8 cores, it's that the hyperthreaded cores > don't work well with the postgres access patterns. > This has nothing to do with hyperthreading. I have a hyperthreaded benchmark purely for completion, but can we please forgetabout it. The issue I'm seeing is that 8 real cores outperform 16 real cores, which outperform 32 real cores under high concurrency. 32 cores is much faster than 8 when I have relatively few clients, but as the number of clients is scaled up 8 cores winsoutright. I was hoping someone had seen this sort of behaviour before, and could offer some sort of explanation or advice.
В списке pgsql-performance по дате отправления: