Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)

From: MichaelDBA <MichaelDBA(at)sqlexec(dot)com>
To: Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
Date: 2023-01-01 16:54:59
Message-ID: d99d24d9-e29e-46e8-41af-dacef4bf8bc6@sqlexec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

You said it's a dedicated server, but pgbouncer is running locally,
right?  PGBouncer has a small footprint, but is the CPU high for it?

Maxim Boguk wrote on 1/1/2023 11:51 AM:
>
>
> On Sun, Jan 1, 2023 at 6:43 PM MichaelDBA <MichaelDBA(at)sqlexec(dot)com
> <mailto:MichaelDBA(at)sqlexec(dot)com>> wrote:
>
> Hi Maxim,
>
> 10-20 active, concurrent connections is way below any CPU load
> problem you should have with 48 available vCPUs.
> You never explicitly said what the load is, so what is it in the
> context of the 1,5,15?
>
>
> LA 10-15 all time, servers are really overprovisioned (2-3x by
> available CPU resources) because an application is quite sensitive to
> the database latency.
> And during these latency spikes - EXECUTE work without any issues
> (e.g. only PARSE/BIND suck).
>
>
> --
> Maxim Boguk
> Senior Postgresql DBA
> https://dataegret.com/
>
> Phone UA: +380 99 143 0000
> Phone AU: +61  45 218 5678
>

Regards,

Michael Vitale

Michaeldba(at)sqlexec(dot)com <mailto:michaelvitale(at)sqlexec(dot)com>

703-600-9343

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Maxim Boguk 2023-01-01 17:06:49 Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)
Previous Message Maxim Boguk 2023-01-01 16:51:07 Re: How to analyze of short but heavy intermittent slowdown on BIND on production database (or BIND vs log_lock_waits)