Re: Low Performance for big hospital server ..

Dave Cramer <pg@fastcrypt.com>

From: Dave Cramer <pg@fastcrypt.com>
To: amrit@health2.moph.go.th
Cc: pgsql-performance@postgresql.org
Date: 2005-01-02T16:56:33Z
Lists: pgsql-performance
The common wisdom of shared buffers is around 6-10% of available memory. 
Your proposal below is about 50% of memory.

I'm not sure what the original numbers actually meant, they are quite large.

also effective cache is the sum of kernel buffers + shared_buffers so it 
should be bigger than shared buffers.

Also turning hyperthreading off may help, it is unlikely it is doing any 
good unless you are running a relatively new (2.6.x) kernel.

I presume you are vacuuming on a regular basis?

amrit@health2.moph.go.th wrote:

>>>postgresql 7.3.2-1 with RH 9 on a mechine of 2 Xeon 3.0 Ghz and ram of 4
>>>      
>>>
>>Gb.
>>
>>You may want to try disabling hyperthreading, if you don't mind
>>rebooting.
>>    
>>
>
>Can you give me an idea why should I use the SMP kernel instead of Bigmen kernel
>[turn off the hyperthreading]? Will it be better to turn off ?
>
>  
>
>>>grew up to 3.5 Gb and there were more than 160 concurent connections.
>>>      
>>>
>>Looks like your growing dataset won't fit in your OS disk cache any
>>longer. Isolate your most problematic queries and check out their
>>query plans. I bet you have some sequential scans that used to read
>>from cache but now need to read the disk. An index may help you.
>>
>>More RAM wouldn't hurt. =)
>>    
>>
>
>I think so that there may be some query load on our programe and I try to locate
>it.
>But if I reduce the config to :
>max_connections = 160
>shared_buffers =  2048	  [Total = 2.5 Gb.]
>sort_mem  = 8192   [Total = 1280 Mb.]
>vacuum_mem = 16384
>effective_cache_size  = 128897 [= 1007 Mb. = 1 Gb.  ]
>Will it be more suitable for my server than before?
>
>Thanks for all comment.
>Amrit
>Thailand
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: if posting/reading through Usenet, please send an appropriate
>      subscribe-nomail command to majordomo@postgresql.org so that your
>      message can get through to the mailing list cleanly
>
>
>  
>

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