From: | amrit(at)health2(dot)moph(dot)go(dot)th |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Cc: | Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>, Michael Adler <adler(at)pobox(dot)com> |
Subject: | Re: Low Performance for big hospital server .. |
Date: | 2005-01-02 16:28:13 |
Message-ID: | 1104683293.41d8211d62221@webmail.moph.go.th |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2005-01-02 16:56:33 | Re: Low Performance for big hospital server .. |
Previous Message | Michael Adler | 2005-01-02 14:08:28 | Re: Low Performance for big hospital server .. |