Re: Low Performance for big hospital server ..

William Yu wrote:

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

Be careful here, he is not using opterons which can access physical
memory above 4G efficiently. Also he only has 4G the 6-10% rule still
applies

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

My understanding is that effective cache is the sum of shared buffers,
plus kernel buffers, not sure what free + cached gives you?

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

Right, the pre 2.6 kernels don't really know how to handle hyperthreaded
CPU's

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

You may want to try this but regular vacuum analyze should work fine as
long as you have the free space map settings correct. Also be aware that
pre-7.4.x the free space map is not populated on startup so you should
do a vacuum analyze right after startup.

>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
>

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561