Re: Performance issue - high Free buff wait

From: Pap <oracle.developer35_at_gmail.com>
Date: Fri, 15 Jan 2021 12:41:47 +0530
Message-ID: <CAEjw_fjmE=KnEno2zrvHUy09pByO8LFhJ4UZfGi9g-U2Qo5FRg_at_mail.gmail.com>



Thanks Much.

I am yet to have the SAN details. And as I see it, we have the db writer response time logged in awr as ~100ms+ during issue period vs ~35ms during normal period. So is it an acceptable range? Or whether making the "ASYNCH_IO" OFF for data file and temp file is a recommended setting and it will help us getting the db writer response faster?

Also from the dev team we got to know we have ~4 app servers and each having a ~40 max session limit which means they can submit a total Max ~160 session at any point in time. So thinking , if that means we are prone to saturating our ~64 cores. And thus we should rather ask the dev team to reduce the max session ,limit of the app server to 64 cores/4= ~16 Per app server. Is this the correct analogy? And hope this will also help in reducing load on the Db writer too.

Regards

Pap

On Thu, Jan 14, 2021 at 7:59 AM Mladen Gogala <gogala.mladen_at_gmail.com> wrote:

> I have never seen the case where more than 3 or 4 DB writer processes
> were needed. That is usually the case with SGA > 128G and 40 or more
> cores are available. DBWR is activated at least once per minute, unless
> there is a segment checkpoint (usually the case with PQ) or log switch.
> How much data do you write in a minute? What kind of SAN do you have?
> More DBWR processes means that those processes will each operate on
> their own buffer chain and each one will fire a few KB in async IO
> requests. You will gain nothing.
>
> On 1/13/21 11:14 AM, Pap wrote:
> > SGA is ~24GB for this database and total host memory is 500gb+ and its
> > hosting 5 databases.
> > db_writer_processes is set as "8" for this database.
>
> --
> Mladen Gogala
> Database Consultant
> http://mgogala.byethost5.com
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Jan 15 2021 - 08:11:47 CET

Original text of this message