Re: Tuning for mid-size server

From: "Anjan Dave" <adave(at)vantage(dot)com>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>, "Richard Huxton" <dev(at)archonet(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Tuning for mid-size server
Date: 2003-10-21 18:59:01
Message-ID: 2F2E24372F10744588A27DEECC85FE04B6769F@vt-pe2550-001.vantage.vantage.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Josh,

The app servers are seperate dual-cpu boxes with 2GB RAM on each.

Yes, from all the responses i have seen, i will be reducing the numbers to what has been suggested.

Thanks to all,
anjan

-----Original Message-----
From: Josh Berkus [mailto:josh(at)agliodbs(dot)com]
Sent: Tue 10/21/2003 1:22 PM
To: Anjan Dave; Richard Huxton; pgsql-performance(at)postgresql(dot)org
Cc:
Subject: Re: [PERFORM] Tuning for mid-size server

Anjan,

> From what I know, there is a cache-row-set functionality that doesn't
> exist with the newer postgres...

What? PostgreSQL has always used the kernel cache for queries.

> Concurrent users will start from 1 to a high of 5000 or more, and could
> ramp up rapidly. So far, with increased users, we have gone up to
> starting the JVM (resin startup) with 1024megs min and max (recommended
> by Sun) - on the app side.

Well, just keep in mind when tuning that your calculations should be based on
*available* RAM, meaning RAM not used by Apache or the JVM.

With that many concurrent requests, you'll want to be *very* conservative with
sort_mem; I might stick to the default of 1024 if I were you, or even lower
it to 512k.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Browse pgsql-performance by date

  From Date Subject
Next Message Will LaShell 2003-10-21 19:00:05 Re: PostgreSQL data on a NAS device ?
Previous Message Anjan Dave 2003-10-21 18:53:03 Re: Tuning for mid-size server