I'm not sure what the original numbers actually meant, they are quite large.Advertising
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?
[EMAIL PROTECTED] 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
-- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
