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
