Re: Low Performance for big hospital server ..

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

In response to

Responses

Browse pgsql-performance by date

  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 ..