Dave Cramer wrote:
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.
I had that already set on my database , and when i look at the log for all the problem queries, most of the queries are slow from one of the table. when i look at the stats on that table they are really wrong, not sure how to fix them. i run vacuumdb and analyze daily.
Also hyperthreading may not be helping you..
does it do any harm to the system if it is hyperthreaded ?
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
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
