Re: Very Bad Performance.

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Pallav Kalva <pkalva(at)deg(dot)cc>
Cc: Postgres Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Very Bad Performance.
Date: 2005-01-03 23:44:01
Message-ID: 41D9D8C1.4090906@fastcrypt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Well, it's not quite that simple

the rule of thumb is 6-10% of available memory before postgres loads is
allocated to shared_buffers.
then effective cache is set to the SUM of shared_buffers + kernel buffers

Then you have to look at individual slow queries to determine why they
are slow, fortunately you are running 7.4 so you can set
log_min_duration to some number like 1000ms and then
try to analyze why those queries are slow.

Also hyperthreading may not be helping you..

Dave

Pallav Kalva wrote:

> Hi ,
>
> I am experiencing a very bad performance on my production database
> lately , all my queries are slowing down. Our application is a
> webbased system with lot of selects and updates. I am running
> "vacuumdb" daily on all the databases, are the below postgres
> configuration parameters are set properly ? can anyone take a look.
> Let me know if you need anymore information.
>
>
> Postgres Version: 7.4
> Operating System: Linux Red Hat 9
> Cpus: 2 Hyperthreaded
> RAM: 4 gb
> Postgres Settings:
> max_fsm_pages | 20000
> max_fsm_relations | 1000
> shared_buffers | 65536
> sort_mem | 16384
> vacuum_mem | 32768
> wal_buffers | 64
> effective_cache_size | 393216
>
> Thanks!
> Pallav
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Stan Y 2005-01-04 00:13:45 PostgreSQL's Statspack?
Previous Message Pallav Kalva 2005-01-03 22:19:15 Very Bad Performance.