| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | jasrajd <jasrajd(at)microsoft(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: An attempt to reduce WALWriteLock contention |
| Date: | 2017-06-24 03:23:55 |
| Message-ID: | CAA4eK1LRWXT57wWMrFHvL3S_12LfNeb3kaRxG19X3vyktJhzOw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 22, 2017 at 6:54 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2017-06-21 00:57:32 -0700, jasrajd wrote:
>> We are also seeing contention on the walwritelock and repeated writes to the
>> same offset if we move the flush outside the lock in the Azure environment.
>> pgbench doesn't scale beyond ~8 cores without saturating the IOPs or
>> bandwidth. Is there more work being done in this area?
>
That should not happen if the writes from various backends are
combined in some way. However, it is not very clear what exactly you
have done as part of taking flush calls out of walwritelock. Can you
share patch or some details about how you have done it and how have
you measured the contention you are seeing?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2017-06-24 03:49:10 | Re: Broken hint bits (freeze) |
| Previous Message | Tom Lane | 2017-06-24 02:50:51 | Re: Logical replication: stuck spinlock at ReplicationSlotRelease |