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 doesn't scale beyond ~8 cor
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 beyond ~8 cores without sa
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 Azure environment.
>> pgbench doesn't scale beyond
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]
> https://www.postgresql.org/message-id/flat/84c22fbb-b9c4-a02f-384b-b4feb2c67193%402ndquadrant.com
>
Hell
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
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 or
> bandwidth. Is there
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 messag
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
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
