Re: sinval synchronization considered harmful
От | Noah Misch |
---|---|
Тема | Re: sinval synchronization considered harmful |
Дата | |
Msg-id | 20110729030514.GB30354@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: sinval synchronization considered harmful (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: sinval synchronization considered harmful
|
Список | pgsql-hackers |
On Thu, Jul 28, 2011 at 03:03:05PM -0400, Robert Haas wrote: > On Thu, Jul 28, 2011 at 10:05 AM, Robert Haas <robertmhaas@gmail.com> wrote: > >> I'll also test out creating and dropping some tables. > > > > Still need to work on this one. > > And there results are in. I set up the following sophisticated test > script for pgbench: > > CREATE TEMP TABLE foo (a int); > DROP TABLE foo; > > And then did 5-minute test runs with varying numbers of clients on > Nate Boley's 32-core machine with (a) master, (b) master + > sinval-hasmessages, (c) master + lazy-vxid, and (d) master + lazy-vxid > + sinval-hasmessages. The comparison I had in mind was (a) master + lazy-vxid + [1]sinval-fastpath vs. (b) master + lazy-vxid + [2]sinval-hasmessages. The only claimed benefit of [2] over [1], as far as I can see, is invulnerability to the hazard described in [3]. Before selecting [2] over [1], it would be instructive to know how much performance we exchange for its benefit. I did a bit of (relatively unrigorous) poking at this workload with oprofile, and I never saw SIInsertDataEntries take more than 0.26% of CPU time. It's perhaps too cheap relative to the workload's other costs to matter. That's good enough for me. [1] http://archives.postgresql.org/message-id/CA+TgmoZc8Z_JTj44xvpWpXKQt2jGjB5YGCZ3T9u5-QZVdBmyCA@mail.gmail.com [2] http://archives.postgresql.org/message-id/CA+TgmoZjo1bkP6eX=xOX3aHuPYbmJT9+PKW6qubQzN7sukK3Dg@mail.gmail.com [3] http://archives.postgresql.org/message-id/20110727033537.GB18910@tornado.leadboat.com > 80L tps = 1192.768020 (including connections establishing) > 80L tps = 1165.545010 (including connections establishing) > 80L tps = 1169.776066 (including connections establishing) > 80LS tps = 1510.778084 (including connections establishing) > 80LS tps = 1484.423486 (including connections establishing) > 80LS tps = 1480.692051 (including connections establishing) > 80 tps = 1154.272515 (including connections establishing) > 80 tps = 1168.805881 (including connections establishing) > 80 tps = 1173.971801 (including connections establishing) > 80S tps = 1483.037788 (including connections establishing) > 80S tps = 1481.059504 (including connections establishing) > 80S tps = 1487.215748 (including connections establishing) > > So, apparently, the extra work in SIInsertDataEntries() is more than > paid for by the speedup in SIGetDataEntries(). I'm guessing that at > high client counts you win because of reduced spinlock contention, and > at low client counts you still win a little bit because > SIGetDataEntries() is called multiple times per transaction, whereas > SIInsertDataEntries() is only called once. I could be all wet on the > reason, but at any rate the numbers look pretty good. Interesting. I had hypothesized that at two clients per core, nearly every call to SIGetDataEntries() would find work to do, making the patch a strict loss. A bit of instrumented testing showed otherwise: at two clients per core, sinval-hasmessages optimized away 93% of the calls. At fifty clients per core, it still optimized away more than half of the calls. -- Noah Misch http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: