Re: Postgres stucks in deadlock detection

On Fri, Apr 20, 2018 at 12:14 PM, Konstantin Knizhnik wrote: > With the extension lock patch performance in increased to 1146 TPS. > So it is much better than with vanilla postgres and about 40% better than > with deadlock patch (1146 vs. 719 TPS). Cool, that's good to

Re: Postgres stucks in deadlock detection

Konstantin Knizhnik wrote: > As I have mentioned at the beginning of this thread the same problem with > deadlock detection timeout expiration we have with YSCB benchmark with zipf > distribution. > Here the source of contention are tuple locks. And as far as I understand > from the discussion in

Re: Postgres stucks in deadlock detection

On 20.04.2018 18:36, Robert Haas wrote: On Wed, Apr 18, 2018 at 10:08 AM, Konstantin Knizhnik wrote: And it is very hard not to notice 17-times difference. Certainly it is true in the assumption that most deadlock timeout expiration are caused by high workload and

Re: Postgres stucks in deadlock detection

On Wed, Apr 18, 2018 at 10:08 AM, Konstantin Knizhnik wrote: > And it is very hard not to notice 17-times difference. > Certainly it is true in the assumption that most deadlock timeout expiration > are caused by high workload and contention, and not by real deadlocks.

Re: Postgres stucks in deadlock detection

On 16.04.2018 14:11, Konstantin Knizhnik wrote: On 14.04.2018 10:09, Юрий Соколов wrote: пт, 13 апр. 2018 г., 21:10 Andres Freund >: Hi, On 2018-04-13 19:13:07 +0300, Konstantin Knizhnik wrote: > On 13.04.2018 18:41, Andres

Re: Postgres stucks in deadlock detection

On 14.04.2018 10:09, Юрий Соколов wrote: пт, 13 апр. 2018 г., 21:10 Andres Freund >: Hi, On 2018-04-13 19:13:07 +0300, Konstantin Knizhnik wrote: > On 13.04.2018 18:41, Andres Freund wrote: > > On 2018-04-13 16:43:09 +0300,

Re: Postgres stucks in deadlock detection

пт, 13 апр. 2018 г., 21:10 Andres Freund : > Hi, > > On 2018-04-13 19:13:07 +0300, Konstantin Knizhnik wrote: > > On 13.04.2018 18:41, Andres Freund wrote: > > > On 2018-04-13 16:43:09 +0300, Konstantin Knizhnik wrote: > > > > Updated patch is attached. > > > > + /* > > > > +

Re: Postgres stucks in deadlock detection

Hi, On 2018-04-13 19:13:07 +0300, Konstantin Knizhnik wrote: > On 13.04.2018 18:41, Andres Freund wrote: > > On 2018-04-13 16:43:09 +0300, Konstantin Knizhnik wrote: > > > Updated patch is attached. > > > + /* > > > + * Ensure that only one backend is checking for deadlock. > > > + * Otherwise

Re: Postgres stucks in deadlock detection

On 13.04.2018 18:41, Andres Freund wrote: Hi, On 2018-04-13 16:43:09 +0300, Konstantin Knizhnik wrote: Updated patch is attached. + /* +* Ensure that only one backend is checking for deadlock. +* Otherwise under high load cascade of deadlock timeout expirations can

Re: Postgres stucks in deadlock detection

Hi, On 2018-04-13 16:43:09 +0300, Konstantin Knizhnik wrote: > Updated patch is attached. > + /* > + * Ensure that only one backend is checking for deadlock. > + * Otherwise under high load cascade of deadlock timeout expirations > can cause stuck of Postgres. > + */ > +

Re: Postgres stucks in deadlock detection

> On Apr 5, 2018, at 11:03, Konstantin Knizhnik > wrote: > > From the other side, the fact that any of this > > a) increasing deadlock timeout > b) avoid concurrent execution of deadlock check > c) perform first stage of deadlock check under shared lock > > have

Re: Postgres stucks in deadlock detection

Updated patch is attached. On 05.04.2018 11:03, Konstantin Knizhnik wrote: Hi, Thank for your feedback. On 04.04.2018 21:15, Andres Freund wrote: Hi, On 2018-04-04 11:54:14 +0300, Konstantin Knizhnik wrote: Several times we and our customers are suffered from the problem that Postgres got

Re: Postgres stucks in deadlock detection

Hi, Thank for your feedback. On 04.04.2018 21:15, Andres Freund wrote: Hi, On 2018-04-04 11:54:14 +0300, Konstantin Knizhnik wrote: Several times we and our customers are suffered from the problem that Postgres got stuck in deadlock detection. One scenario is YCSB workload with Zipf's

Re: Postgres stucks in deadlock detection

Hi, On 2018-04-04 21:55:10 +0300, Teodor Sigaev wrote: > > > > Have you ever observed that in the field? This sounds more artificial > > > > than real to me. > > > > > > Zabbix storage with 50Gb WAL per hour on insertion. > > > > That's not a very detailed description. Isn't that a largely

Re: Postgres stucks in deadlock detection

Have you ever observed that in the field? This sounds more artificial than real to me. Zabbix storage with 50Gb WAL per hour on insertion. That's not a very detailed description. Isn't that a largely insertion only workload? It's mostly insert load, collecting monitoring information. Also

Re: Postgres stucks in deadlock detection

On 2018-04-04 21:34:27 +0300, Teodor Sigaev wrote: > > Have you ever observed that in the field? This sounds more artificial > > than real to me. > > Zabbix storage with 50Gb WAL per hour on insertion. That's not a very detailed description. Isn't that a largely insertion only workload?

Re: Postgres stucks in deadlock detection

Have you ever observed that in the field? This sounds more artificial than real to me. Zabbix storage with 50Gb WAL per hour on insertion. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: Postgres stucks in deadlock detection

Hi, On 2018-04-04 11:54:14 +0300, Konstantin Knizhnik wrote: > Several times we and our customers are suffered from the problem that > Postgres got stuck in deadlock detection. > One scenario is YCSB workload with Zipf's distribution when many clients are > trying to update the same record and

Re: Postgres stucks in deadlock detection

So, I see three possible ways to fix this problem: 1. Yury Sololov's patch with two phase deadlock check I could be wrong, but LWLocks in pgsql aren't a "fair" locks: if LWLock is share locked then exclusive lock will wait, but next shared lock will be acquired immediately. If so, the we have a