Options for growth 
Author Message
 Options for growth

Due to the fact that we are growing out of our current system (PostgreSQL on
PCs) we are looking for ways to expand and one of the suggestions has been to
toss PostgreSQL in favour of Oracle with Remote Access Cluster (RAC)
software.  The theory is that you can just plug machines into the cluster if
the database appears to be straining and they automagically take over some of
the load.  Not knowing much about it I can only argue about price and source
code availability.  The first has some value but the second is harder to
argue without knowing about RAC.  Is it really as simple as it sounds or
would we just be giving up the other two for a new set of problems.

My idea is to create a new middleware layer that allows me to split things up
based on various criteria without changing my application.  RAC sounds like
it does that at the database/SQL level.  Does it?

We are also looking at hardware solutions, multi-CPU PCs with tons (24GB) of
memory.  I know that memory will improve access if it prevents swapping but
how well does PostgreSQL utilize multiple CPUs?

And finally, if you had your dream machine to run on, what would it be?  We
are also looking outside of PC hardware but we are concerned about not having
access to that nice, cheap, generic hardware for when we need to grow again
or for redundant backup.

Thanks for any tips and suggestions.

--

http://www.***.com/ ;              |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly



Tue, 05 Jul 2005 00:39:25 GMT
 Options for growth

--=-1SBoaIf8KPcC6/SVSYod
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Quote:

> We are also looking at hardware solutions, multi-CPU PCs with tons (24GB)=
 of=20
> memory.  I know that memory will improve access if it prevents swapping b=
ut=20
> how well does PostgreSQL utilize multiple CPUs?

At most one CPU is used for any single postgres backend (that means for
any single database connection). So, if your load problem is single
queries being too slow, thee's nothing you can do with adding more CPUs.
If your problem is many connections maxing out the db, PostgreSQL can
take full advantage of multiple CPUs.

Of course, most db apps still are not cpu bound, so you'd have to do
some careful benchmarking first or you'll be spending too much money.

cheers
-- vbi

--=20
get my gpg key here: http://fortytwo.ch/gpg/92082481

--=-1SBoaIf8KPcC6/SVSYod
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: get my key from http://fortytwo.ch/gpg/92082481

iHMEABECADMFAj4m5OYsGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h
aWwuMjAwMjA4MjIACgkQi6Qxi+Wn99bGYwCcCyymCYimK0L8FqtdXWayR0vqP/oA
n37/cJCHlhCyHeNVrrGdlSTToxgJ
=IPLD
-----END PGP SIGNATURE-----
Signature policy: http://fortytwo.ch/legal/gpg/email.20020822

--=-1SBoaIf8KPcC6/SVSYod--



Tue, 05 Jul 2005 00:59:25 GMT
 Options for growth

Quote:

> Is [Oracle RAC] really as simple as it sounds or would we just be
> giving up the other two for a new set of problems.

That's a question you should be asking to an authority on Oracle RAC
(which pgsql-hackers is not).

Quote:
> My idea is to create a new middleware layer that allows me to split things up
> based on various criteria without changing my application.

Personally, I would not be very eager to use home-brew replication for a
heavy-load, production-critical application (which is what your app
sounds like). But YMMV...

Quote:
> We are also looking at hardware solutions, multi-CPU PCs with tons (24GB) of
> memory.  I know that memory will improve access if it prevents swapping but
> how well does PostgreSQL utilize multiple CPUs?

The estimates I've heard from a couple parties are that PostgreSQL tends
to scale well up to 4 CPUs. I've been meaning to take a look at
improving that, but I haven't had a chance yet...

Another option is to put some money toward the current development
effort to get truly scalable replication for PostgreSQL. In the end, I'd
think the cost of subsidizing some of that development would be a
fraction of the license fees you'll end up paying Oracle over the
years...

Cheers,

Neil
--

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Tue, 05 Jul 2005 01:24:02 GMT
 Options for growth

Quote:
> Due to the fact that we are growing out of our current system
> (PostgreSQL on
> PCs) we are looking for ways to expand and one of the suggestions
> has been to
> toss PostgreSQL in favour of Oracle with Remote Access Cluster (RAC)
> software.

You mean Real Application Clusters?

Chris

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly



Tue, 05 Jul 2005 09:54:34 GMT
 Options for growth

Quote:

> > Is [Oracle RAC] really as simple as it sounds or would we just be
> > giving up the other two for a new set of problems.

> That's a question you should be asking to an authority on Oracle RAC
> (which pgsql-hackers is not).

True but I already have their perspective.  Now I am looking for reasons to
stay with PostgreSQL.

Quote:
> > My idea is to create a new middleware layer that allows me to split
> > things up based on various criteria without changing my application.

> Personally, I would not be very eager to use home-brew replication for a
> heavy-load, production-critical application (which is what your app
> sounds like). But YMMV...

Not replication per se although I suppose that could be built in.  What I am
talking about is an application that knows our business logic and brokers
requests for data from the database(s) in an OO way.  The idea is to split
data up in the middleware whenever necessary.

Quote:
> > We are also looking at hardware solutions, multi-CPU PCs with tons (24GB)
> > of memory.  I know that memory will improve access if it prevents
> > swapping but how well does PostgreSQL utilize multiple CPUs?

> The estimates I've heard from a couple parties are that PostgreSQL tends
> to scale well up to 4 CPUs. I've been meaning to take a look at
> improving that, but I haven't had a chance yet...

Cool.  I am looking at Tyan boards that have 4 CPUs and 24GB memory.

Quote:
> Another option is to put some money toward the current development
> effort to get truly scalable replication for PostgreSQL. In the end, I'd
> think the cost of subsidizing some of that development would be a
> fraction of the license fees you'll end up paying Oracle over the
> years...

This is definitely an option.  I can probably put both people and money into
such an effort.  I would be happy to hear from people who can work on that.

--

http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Tue, 05 Jul 2005 20:02:14 GMT
 Options for growth

Quote:
> > toss PostgreSQL in favour of Oracle with Remote Access Cluster (RAC)
> > software.

> You mean Real Application Clusters?

Oops, yes.

--

http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster



Tue, 05 Jul 2005 20:03:48 GMT
 Options for growth

Quote:

> > We are also looking at hardware solutions, multi-CPU PCs with tons (24GB)
> > of memory.  I know that memory will improve access if it prevents
> > swapping but how well does PostgreSQL utilize multiple CPUs?

> At most one CPU is used for any single postgres backend (that means for
> any single database connection). So, if your load problem is single
> queries being too slow, thee's nothing you can do with adding more CPUs.
> If your problem is many connections maxing out the db, PostgreSQL can
> take full advantage of multiple CPUs.

I most definitely have multiple queries running at once.  My main issue is
whether PostgreSQL scales up properly or does it get bogged down with too
many locked queries.

Quote:
> Of course, most db apps still are not cpu bound, so you'd have to do
> some careful benchmarking first or you'll be spending too much money.

Natch.

--

http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly



Tue, 05 Jul 2005 20:06:16 GMT
 
 [ 7 post ] 

 Relevant Pages 

1. Options for growth

2. Options for growth

3. Restricting a datafile growth disables all other options

4. problems with reinstallations with bitmap option and paralell-select option

5. dbbackup and the -n Option Versus the -r -n Options

6. User Options of Configuration Options

7. Error is "302: No GRANT option or illegal option on multi-table v

8. Option Group/Option Button

9. Q:Data file/log file growth

10. Java and tempdb excessive growth

11. Used memory growth in SQL2000

12. File size and growth


 
Powered by phpBB® Forum Software