Re: [HACKERS] An attempt to reduce WALWriteLock contention

2017-06-23 Thread Amit Kapila
On Thu, Jun 22, 2017 at 6:54 AM, Andres Freund 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

Re: [HACKERS] An attempt to reduce WALWriteLock contention

2017-06-22 Thread Sokolov Yura
On 2017-06-22 04:16, Michael Paquier wrote: On Wed, Jun 21, 2017 at 4:57 PM, 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

Re: [HACKERS] An attempt to reduce WALWriteLock contention

2017-06-21 Thread Kuntal Ghosh
On Thu, Jun 22, 2017 at 6:46 AM, Michael Paquier wrote: > On Wed, Jun 21, 2017 at 4:57 PM, 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

Re: [HACKERS] An attempt to reduce WALWriteLock contention

2017-06-21 Thread Kuntal Ghosh
On Thu, Dec 22, 2016 at 11:29 PM, Tomas Vondra wrote: > > How do these counts compare to the other wait events? For example > CLogControlLock, which is what Amit's patch [1] is about? > > [1] >

Re: [HACKERS] An attempt to reduce WALWriteLock contention

2017-06-21 Thread Andres Freund
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

Re: [HACKERS] An attempt to reduce WALWriteLock contention

2017-06-21 Thread Michael Paquier
On Wed, Jun 21, 2017 at 4:57 PM, 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

Re: [HACKERS] An attempt to reduce WALWriteLock contention

2017-06-21 Thread jasrajd
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? -- View this

Re: [HACKERS] An attempt to reduce WALWriteLock contention

2016-12-22 Thread Tomas Vondra
On 12/22/2016 04:00 PM, Kuntal Ghosh wrote: Hello all, > ... > \t select wait_event_type, wait_event from pg_stat_activity where pid != pg_backend_pid(); \watch 0.5 HEAD 48642 LWLockNamed | WALWriteLock With Patch -- 31889 LWLockNamed

[HACKERS] An attempt to reduce WALWriteLock contention

2016-12-22 Thread Kuntal Ghosh
Hello all, In a recent post[1] by Robert, wait events for different LWLOCKS have been analyzed. The results clearly indicate a significant lock contention overhead on WAL Write locks. To get an idea of this overhead, we did the following two tests. 1. Hacked the code to comment out WAL write and