Amrit --
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Sent: Mon 1/3/2005 12:18 AM
>To: Mark Kirkwood
>Cc: PGsql-performance
>Subject: Re: [PERFORM] Low Performance for big hospital server ..
>> shared_buffers = 12000 will use 12000*8192 bytes (i.e about 96Mb). It is
>> shared, so no matter how many connections you have it will only use 96M.
>
>Now I use the figure of 27853
>
>> >
>> >Will the increasing in effective cache size to arround 200000 make a >little
>> bit
>> >improvement ? Do you think so?
>> >
>Decrease the sort mem too much [8196] make the performance much slower so I
>>use
>sort_mem = 16384
>and leave effective cache to the same value , the result is quite better but >I
>should wait for tomorrow morning [official hour] to see the end result.
>
>> >
>> I would leave it at the figure you proposed (128897), and monitor your
>> performance.
>> (you can always increase it later and see what the effect is).
>Yes , I use this figure.
>
>If the result still poor , putting more ram "6-8Gb" [also putting more money
>too] will solve the problem ?
Adding RAM will almost always help, at least for a while. Our small runitme
servers have 2 gigs of RAM; the larger ones have 4 gigs; I do anticipate the
need to add RAM as we add users.
If you have evaluated the queries that are running and verified that they are
using indexes properly, etc., and tuned the other parameters for your system
and its disks, adding memory helps because it increases the chance that data is
already in memory, thus saving the time to fetch it from disk. Studying
performance under load with top, vmstat, etc. and detailed analysis of queries
can often trade some human time for the money that extra hardware would cost.
Sometimes easier to do than getting downtime for a critical server, as well.
If you don't have a reliable way of reproducing real loads on a test system, it
is best to change things cautiously, and observe the system under load; if you
change too many things (ideally only 1 at a time but often that is not
possible) you mau actually defeat a good change with a bad one; at the least,m
you may not know which change was the most important one if you make several at
once.
Best of luck,
Greg Williamson
DBA
GlobeXplorer LLC
>Thanks ,
>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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
