From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: spin_delay() for ARM |
Date: | 2020-04-17 17:24:09 |
Message-ID: | CA+TgmobRAH82_Ot44gE==PGQgzejG0escF-4uqCK2W5Qdfmn2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 16, 2020 at 3:18 AM Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> wrote:
> Not relevant to the PAUSE stuff .... Note that when the parallel
> clients reach from 24 to 32 (which equals the machine CPUs), the TPS
> shoots from 454189 to 1097592 which is more than double speed gain
> with just a 30% increase in parallel sessions.
I've seen stuff like this too. For instance, check out the graph from
this 2012 blog post:
http://rhaas.blogspot.com/2012/04/did-i-say-32-cores-how-about-64.html
You can see that the performance growth is basically on a straight
line up to about 16 cores, but then it kinks downward until about 28,
after which it kinks sharply upward until about 36 cores.
I think this has something to do with the process scheduling behavior
of Linux, because I vaguely recall some discussion where somebody did
benchmarking on the same hardware on both Linux and one of the BSD
systems, and the effect didn't appear on BSD. They had other problems,
like a huge drop-off at higher core counts, but they didn't have that
effect.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2020-04-17 17:33:53 | Re: Should we add xid_current() or a int8->xid cast? |
Previous Message | Tom Lane | 2020-04-17 17:07:15 | Re: Possible cache reference leak by removeExtObjInitPriv |