Re: Low Performance for big hospital server ..
От | William Yu |
---|---|
Тема | Re: Low Performance for big hospital server .. |
Дата | |
Msg-id | crb01v$hp4$1@news.hub.org обсуждение исходный текст |
Ответ на | Re: Low Performance for big hospital server .. (amrit@health2.moph.go.th) |
Ответы |
Re: Low Performance for big hospital server ..
Re: Low Performance for big hospital server .. |
Список | pgsql-performance |
amrit@health2.moph.go.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.
В списке pgsql-performance по дате отправления: