Re: Low Performance for big hospital server ..
От | Dave Cramer |
---|---|
Тема | Re: Low Performance for big hospital server .. |
Дата | |
Msg-id | 41D827C1.3050707@fastcrypt.com обсуждение исходный текст |
Ответ на | Re: Low Performance for big hospital server .. (amrit@health2.moph.go.th) |
Ответы |
Re: Low Performance for big hospital server ..
|
Список | 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@health2.moph.go.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@postgresql.org so that your > message can get through to the mailing list cleanly > > > > -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561
В списке pgsql-performance по дате отправления: