From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | amrit(at)health2(dot)moph(dot)go(dot)th |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Low Performance for big hospital server .. |
Date: | 2005-01-02 16:56:33 |
Message-ID: | 41D827C1.3050707@fastcrypt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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(at)health2(dot)moph(dot)go(dot)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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
>
>
>
--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561
From | Date | Subject | |
---|---|---|---|
Next Message | amrit | 2005-01-03 01:54:03 | Re: Low Performance for big hospital server .. |
Previous Message | amrit | 2005-01-02 16:28:13 | Re: Low Performance for big hospital server .. |