Re: Postgresql TPS Bottleneck

2022-03-31 Thread Mladen Gogala
On 3/31/22 07:50, wakandavis...@outlook.com wrote: Hi everyone, I am a bachelor's student and writing my thesis about the scaling and performance of an application. The application is using postgresql as a database but we can't scale any further currently as it seems postgres is hitting the limi

Re: Postgresql TPS Bottleneck

2022-03-31 Thread Tomas Vondra
On 3/31/22 13:50, wakandavis...@outlook.com wrote: > Hi everyone, > > I am a bachelor's student and writing my thesis about the scaling and > performance of an application. The application is using postgresql as a > database but we can't scale any further currently as it seems postgres > is hit

Re: Postgresql TPS Bottleneck

2022-03-31 Thread MichaelDBA
While setting these 2 parameters to off will make things go faster (especially for fsync), it is unrealistic to have these settings in a production environment, especiall fsync=off.  You might get by with synchronous_commit=off, but with fsync=off you could end up with corruption in your databa

Re: HIGH IO and Less CPU utilization

2022-03-31 Thread Mladen Gogala
On 3/29/22 14:04, Rambabu g wrote: Hi All, We have an issue with high load and IO Wait's but less cpu on postgres Database, The emp Table size is around 500GB, and the connections are very less. Please suggest to us do we need to change and config parameters at system level or Postgres conf

Re: Postgresql TPS Bottleneck

2022-03-31 Thread Guillaume Cottenceau
writes: > Optimally I would like to fully use the CPU and get about 3-4 times > more TPS (if even possible). Disclaimer: I'm really not a pg performance expert. I don't understand your hope to fully use the CPU; if your scenario is disk-limited, which may very well be the case, then of course yo

Postgresql TPS Bottleneck

2022-03-31 Thread wakandavision
Hi everyone, I am a bachelor's student and writing my thesis about the scaling and performance of an application. The application is using postgresql as a database but we can't scale any further currently as it seems postgres is hitting the limit. With the application, as well as with pgbench, we