Re: Upgrade to dual processor machine? - Mailing list pgsql-general

Dear Shridhar,

ok, so my system has got 362 MB of free RAM currently... this sounds good.

uname -a says:
Linux db2.city-map.de 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown

I didn't actually measure requests per minute through a longer period...
I tested it 2 hours ago using debug and logging all queries, and I saw
approx. 2500 requests per minute. but at that time of the day there are
only about 25 simultaneous users on our website. so i calculated 50
users and 5.000 rpm for average daytime usage. I guess the maximum peak
would be approx. 10.000 queries per minute.

--

Mit freundlichem Gruß

Henrik Steffen
Geschäftsführer

top concepts Internetmarketing GmbH
Am Steinkamp 7 - D-21684 Stade - Germany
--------------------------------------------------------
http://www.topconcepts.com          Tel. +49 4141 991230
mail: steffen@topconcepts.com       Fax. +49 4141 991233
--------------------------------------------------------
24h-Support Hotline:  +49 1908 34697 (EUR 1.86/Min,topc)
--------------------------------------------------------
Ihr SMS-Gateway: JETZT NEU unter: http://sms.city-map.de
System-Partner gesucht: http://www.franchise.city-map.de
--------------------------------------------------------
Handelsregister: AG Stade HRB 5811 - UstId: DE 213645563
--------------------------------------------------------

----- Original Message -----
From: "Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
To: <pgsql-general@postgresql.org>
Sent: Wednesday, November 13, 2002 11:00 AM
Subject: Re: [GENERAL] Upgrade to dual processor machine?


> On 13 Nov 2002 at 10:42, Henrik Steffen wrote:
> > > Yes. 2*max connection is minimum. Anything additional is always welcome as long
> > > as it does not starve the system.
> >
> > ok, I tried to set shared_buffers to 65535 now. but then restarting postgres
> > fails - it says:
> >
> > IpcMemoryCreate: shmget(key=5432001, size=545333248, 03600) failed: Invalid argument
> >
> > and a message telling me to either lower the shared_buffers or raise the
> > SHMMAX.
>
> Yes. you need to raise SHMMAX. A good feature of recent linux distro. is that
> they set SHMMAX to half of physical memory. A very good default IMO..
>
> >  11:06am  up 1 day, 16:46,  1 user,  load average: 1,32, 1,12, 1,22
> > 53 processes: 52 sleeping, 1 running, 0 zombie, 0 stopped
> > CPU states: 24,5% user, 11,2% system,  0,0% nice,  5,6% idle
> > Mem:  1020808K av, 1006156K used,   14652K free,    8520K shrd,   37204K buff
> > Swap: 1028112K av,      60K used, 1028052K free                  849776K cached
> > I have now changed the SHMMAX settings to 545333248 and changed the
> > shared_buffers to 65535 again. now postgres starts up correctly.
> >
> > the top result changes to:
> >
> >  11:40am  up 1 day, 17:20,  1 user,  load average: 2,24, 2,51, 2,14
> > 57 processes: 55 sleeping, 2 running, 0 zombie, 0 stopped
> > CPU states: 24,7% user, 11,3% system,  0,0% nice,  6,2% idle
> > Mem:  1020808K av, 1015844K used,    4964K free,  531420K shrd,   24796K buff
> > Swap: 1028112K av,      60K used, 1028052K free                  338376K cached
> > now, does this look better in your eyes?
>
> Well, don't look at top to find out free memoy. Use free. On my machine..
>
> [shridhar@perth shridhar]$ free
>              total       used       free     shared    buffers     cached
> Mem:        255828     250676       5152          0      66564      29604
> -/+ buffers/cache:     154508     101320
> Swap:       401616      12764     388852
> [shridhar@perth shridhar]$
>
> Here the important value is second value in second line, 101320. That's true
> free memory. Remeber when system needs memory, it can always shrunk
> cache/buffers. In both of your stats, cache+memory are roughly 400MB.
>
> Relax, your system is not starving for memory...
>
> > do you need more information here?
>
> Not for this problem, but just curious. What does uname -a says?
>
> Secondly just curious, with 5000 requests per minute, what is the peak number
> of connection you are getting? You should look int pooling parameters for
> better performance..
>
> HTH
>
>
> Bye
>  Shridhar
>
> --
> Hawkeye's Conclusion: It's not easy to play the clown when you've got to run
> the whole circus.
>
>
> ---------------------------(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