From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Perf Benchmarking and regression. |
Date: | 2016-05-06 15:05:45 |
Message-ID: | 20160506150545.lwfdtoppa4icubfy@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Thanks for benchmarking!
On 2016-05-06 19:43:52 +0530, Mithun Cy wrote:
> 1. # first bad commit: [ac1d7945f866b1928c2554c0f80fd52d7f977772] Make idle
> backends exit if the postmaster dies.
> this made performance to drop from
>
> 15947.21546 (15K +) to 13409.758510 (arround 13K+).
Let's debug this one first, it's a lot more local. I'm rather surprised
that you're seing a big effect with that "few" TPS/socket operations;
and even more that our efforts to address that problem haven't been
fruitful (given we've verified the fix on a number of machines).
Can you verify that removing
AddWaitEventToSet(FeBeWaitSet, WL_POSTMASTER_DEATH, -1, NULL, NULL);
in src/backend/libpq/pqcomm.c : pq_init() restores performance?
I think it'd be best to test the back/forth on master with
bgwriter_flush_after = 0
checkpointer_flush_after = 0
backend_flush_after = 0
to isolate the issue.
Also, do you see read-only workloads to be affected too?
> 2. # first bad commit: [428b1d6b29ca599c5700d4bc4f4ce4c5880369bf] Allow to
> trigger kernel writeback after a configurable number of writes.
FWIW, it'd be very interesting to test again with a bigger
backend_flush_after setting.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-05-06 15:13:40 | Re: Poorly-thought-out handling of double variables in pgbench |
Previous Message | Kohei KaiGai | 2016-05-06 14:44:31 | Re: textlike under the LIKE operator for char(n) |