Re: Low Performance for big hospital server ..

From: William Yu <wyu(at)talisys(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Low Performance for big hospital server ..
Date: 2005-01-03 08:32:10
Message-ID: crb01v$hp4$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

amrit(at)health2(dot)moph(dot)go(dot)th wrote:
> I will try to reduce shared buffer to 1536 [1.87 Mb].

1536 is probaby too low. I've tested a bunch of different settings on my
8GB Opteron server and 10K seems to be the best setting.

>>also effective cache is the sum of kernel buffers + shared_buffers so it
>>should be bigger than shared buffers.
>
> also make the effective cache to 2097152 [2 Gb].
> I will give you the result , because tomorrow [4/12/05] will be the official day
> of my hospital [which have more than 1700 OPD patient/day].

To figure out your effective cache size, run top and add free+cached.

>>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.
>
> Why , could you give me the reason?

Pre 2.6, the kernel does not know the difference between logical and
physical CPUs. Hence, in a dual processor system with hyperthreading, it
actually sees 4 CPUs. And when assigning processes to CPUs, it may
assign to 2 logical CPUs in the same physical CPU.

>
>
>>I presume you are vacuuming on a regular basis?
>
> Yes , vacuumdb daily.

Do you vacuum table by table or the entire DB? I find over time, the
system tables can get very bloated and cause a lot of slowdowns just due
to schema queries/updates. You might want to try a VACUUM FULL ANALYZE
just on the system tables.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mike Mascari 2005-01-03 08:51:42 Re: Low Performance for big hospital server ..
Previous Message amrit 2005-01-03 08:18:56 Re: Low Performance for big hospital server ..