Server recommendations

[Dennis Gearon]

Anyone got links to good db server boxes, not rackmount though?

Include any for HP, Gateway, etc.

--
"You are behaving like a man",
is an insult from some women,
a compliment from a good woman.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Christopher Browne]

Oops! ge*****@fireserve.net (Dennis Gearon) was seen spray-painting on a wall:

Anyone got links to good db server boxes, not rackmount though?

Include any for HP, Gateway, etc.

It's the components that matter moreso than the sticker on the front
of the box.

Presently, I have a Dell 6600 PowerEdge (I think that's the model)
named "hathi" (apparently that's Hindi for "elephant") under my desk;
4 Pentium IV's, 12 72GB drives, 8GB RAM, and one of those MegaRAID
controllers that has been discussed lately. It's being used for "data
warehouse" stuff, but I suspect it would make a better TP server than
anything else we've got locally.

It was consistently taking about 6-7 minutes to run a data load that,
on the "production" TP server (2 CPUs, only a couple SCSI drives),
took about 2.5h to load. Arguably, I should have done the load on
"hathi," and FTPed a tarball of the resulting database to production,
as that almost certainly would have saved a couple of hours! (There
were good reasons to not imagine that as a rational answer, but it's a
fun idea...)

If it weren't that the heat and the noise of the array of 6 fans was
annoying everyone around me, I'd like to keep it as my desktop box,
but any time I voice the suggestion, everyone objects vigorously :-).

But seriously, look for the right components, and make sure you have
goodly redundancy of things like fans and power supplies. Battery
backed cache on a RAID controller is just _gold_, performance-wise;
more RAM and more SCSI disks are always a nice thing too.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www.ntlug.org/~cbbrowne/sap.html
I am not a number!
I am a free man!

[Shridhar Daithankar]

Christopher Browne wrote:

Oops! ge*****@fireserve.net (Dennis Gearon) was seen spray-painting on a wall:

Anyone got links to good db server boxes, not rackmount though?

Include any for HP, Gateway, etc.

It's the components that matter moreso than the sticker on the front
of the box.

Presently, I have a Dell 6600 PowerEdge (I think that's the model)
named "hathi" (apparently that's Hindi for "elephant") under my desk;
4 Pentium IV's, 12 72GB drives, 8GB RAM, and one of those MegaRAID
controllers that has been discussed lately. It's being used for "data
warehouse" stuff, but I suspect it would make a better TP server than
anything else we've got locally.

Heh.. "hathi" is quite right description for that..:-)

From what I read on postgresql lists, it seems that opteron based machines are
doing quite a good job as database server with right kind of disk. You could
look at any such machine for database server..

Check this..

http://www.polywell.com/us/rackservers/poly1u2c.asp
http://www.opteronics.com/opteron-servers.htm

IMO they could be better machine for databases. Get a 64 bit linux kernel and
run 32 bit postgresql on it. Should work like a charm..

HTH

Shridhar


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

http://www.postgresql.org/docs/faqs/FAQ.html

[Ron Johnson]

On Fri, 2003-10-03 at 10:37, Shridhar Daithankar wrote:

Christopher Browne wrote:

Oops! ge*****@fireserve.net (Dennis Gearon) was seen spray-painting on a wall:

[snip] From what I read on postgresql lists, it seems that opteron based machines are
doing quite a good job as database server with right kind of disk. You could
look at any such machine for database server..

Check this..

http://www.polywell.com/us/rackservers/poly1u2c.asp
http://www.opteronics.com/opteron-servers.htm

IMO they could be better machine for databases. Get a 64 bit linux kernel and
run 32 bit postgresql on it. Should work like a charm..

Why not run 64-bit PG on the 64-bit kernel? A bunch of distros
are releasing support for the AMD64 this month.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA

"Knowledge should be free for all."
Harcourt Fenton Mudd, Star Trek:TOS, "I, Mudd"
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Dennis Gearon]

Actually,
I don't need something so big as that, and the people who are going
to be using this don't have the kind of IT dept that can maintain it. It
needs to be a standard PC based architecture, just server grade.

Opteron - PC compatible, by Intel?
Opteron - Costs vs Xeon or Pentium?

Ron Johnson wrote:

On Fri, 2003-10-03 at 10:37, Shridhar Daithankar wrote:

Christopher Browne wrote:

Oops! ge*****@fireserve.net (Dennis Gearon) was seen spray-painting on a wall:

[snip]

From what I read on postgresql lists, it seems that opteron based machines are
doing quite a good job as database server with right kind of disk. You could
look at any such machine for database server..

Check this..

http://www.polywell.com/us/rackservers/poly1u2c.asp
http://www.opteronics.com/opteron-servers.htm

IMO they could be better machine for databases. Get a 64 bit linux kernel and
run 32 bit postgresql on it. Should work like a charm..

Why not run 64-bit PG on the 64-bit kernel? A bunch of distros
are releasing support for the AMD64 this month.

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Ron Johnson]

On Fri, 2003-10-03 at 11:49, Dennis Gearon wrote:

Actually,
I don't need something so big as that, and the people who are going
to be using this don't have the kind of IT dept that can maintain it. It
needs to be a standard PC based architecture, just server grade.

Opteron - PC compatible, by Intel?
http://www.upgradingandrepairingpcs....de07_03_08.asp
http://www.amd.com/us-en/Processors/...9_9003,00.html
http://www.laclinux.com/en/opt

The Opteron can act like a 32 bit x86 system (and run 32 bit
binaries *directly* in the h/w w/o slowdown for translation), or
it can run in 64 bit mode and go even faster because of extra
registers. There's also a mixed mode, where 32-bit x86 apps
can run on a system running a 64-bit AMD64 (generic name for
Opteron and Athlon64) kernel.
Opteron - Costs vs Xeon or Pentium?
More expensive than P4, less than Xeon.

The Athlon64 is the consumer-grade version of the Opteron, and
is cheaper than the P4.
Ron Johnson wrote:

On Fri, 2003-10-03 at 10:37, Shridhar Daithankar wrote:

Christopher Browne wrote:

Oops! ge*****@fireserve.net (Dennis Gearon) was seen spray-painting on a wall:

[snip]

From what I read on postgresql lists, it seems that opteron based machines are
doing quite a good job as database server with right kind of disk. You could
look at any such machine for database server..

Check this..

http://www.polywell.com/us/rackservers/poly1u2c.asp
http://www.opteronics.com/opteron-servers.htm

IMO they could be better machine for databases. Get a 64 bit linux kernel and
run 32 bit postgresql on it. Should work like a charm..

Why not run 64-bit PG on the 64-bit kernel? A bunch of distros
are releasing support for the AMD64 this month.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA

"What's your genius, perfect 20 years too late Monday morning
quarterback answer to how the US should have responded to the
Soviet invasion of Afghanistan? Oh wait, you're just talking
crap - you don't have a real answer, you're just regurgitating
crap from NPR."
http://slashdot.org/comments.pl?sid=76597&cid=6839483
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Shridhar Daithankar]

Ron Johnson wrote:

IMO they could be better machine for databases. Get a 64 bit linux kernel and
run 32 bit postgresql on it. Should work like a charm..

Why not run 64-bit PG on the 64-bit kernel? A bunch of distros
are releasing support for the AMD64 this month.

The best performance is by running 32 bit applications on 64 bit kernel/hardware
, according to a migration guide by HP. The reasoning is using space optimally

Imagine, if every long in pg is 8byte that would be waste most of the times.
However given a native 8 byte integer/float is available, there is no reason to
use a 8 byte data type unless required.

Its about exploiting wide and fast bus of a 64bit machine in a most optimal
fashion. I think except for kernel and glibc, nothing else requires 64 bit in
general unless application insists on doing it's own caching.
Of course benchmarks have the last words..:-)

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

http://www.postgresql.org/docs/faqs/FAQ.html

[Ron Johnson]

On Mon, 2003-10-06 at 01:43, Shridhar Daithankar wrote:

Ron Johnson wrote:

IMO they could be better machine for databases. Get a 64 bit linux kernel and
run 32 bit postgresql on it. Should work like a charm..

Why not run 64-bit PG on the 64-bit kernel? A bunch of distros
are releasing support for the AMD64 this month.

The best performance is by running 32 bit applications on 64 bit kernel/hardware
, according to a migration guide by HP. The reasoning is using space optimally

Does HP have any AMD64 servers?
Imagine, if every long in pg is 8byte that would be waste most of the times.
However given a native 8 byte integer/float is available, there is no reason to
use a 8 byte data type unless required.
From what I've read, longs are still 32-bit; it's only pointers
that have upped to 64-bit.
Its about exploiting wide and fast bus of a 64bit machine in a most optimal
fashion. I think except for kernel and glibc, nothing else requires 64 bit in
general unless application insists on doing it's own caching.
In PG's case, if the app uses BIGINT a lot, then 64-bit PG should
be more efficient.

Besides, in 64-bit mode, the compilers get to use 2x as many GP
registers, which should increase performance.
Of course benchmarks have the last words..:-)

As always.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA

PETA - People Eating Tasty Animals
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Shridhar Daithankar]

Ron Johnson wrote:

On Mon, 2003-10-06 at 01:43, Shridhar Daithankar wrote:

The best performance is by running 32 bit applications on 64 bit kernel/hardware
, according to a migration guide by HP. The reasoning is using space optimally

Does HP have any AMD64 servers?

No. But while migrating from PA1.1 to PA2.0, they have had that pain..:-) And I
just went thr. opteron optimization guide from a link you provided. Basically
same stuff HP was pitching.

And I also configured a system on laclinux.com, just for curiosity. 2x
1.8GHz/4GB/36GBx2 10K RPM SCSI/Adaptec 29320 for $4800/- is damn cheap a system.
HP does not even start below $5K for 64 bit systems.

Imagine, if every long in pg is 8byte that would be waste most of the times.
However given a native 8 byte integer/float is available, there is no reason to
use a 8 byte data type unless required.
From what I've read, longs are still 32-bit; it's only pointers

that have upped to 64-bit.

I thought under 64 bits short==2 bytes, int==4 bytes and long==8 bytes. i.e.
this is another architecture/word length where int != long in size.

Its about exploiting wide and fast bus of a 64bit machine in a most optimal
fashion. I think except for kernel and glibc, nothing else requires 64 bit in
general unless application insists on doing it's own caching.

In PG's case, if the app uses BIGINT a lot, then 64-bit PG should
be more efficient.

Possibly. Source code availability has a great advantage here. Compile the way
you want.

But still, as long as PG in itself does not use 8 byte data types exclusively, I
would like it to be a 32 bit app. A bigint is 8 byte on a 64 bit machine,
whether or not the app. is 32 bit.
Besides, in 64-bit mode, the compilers get to use 2x as many GP
registers, which should increase performance.

Well, if a 32 bit app. is optimised for opteron, compiler will use those
registers anyway..:-) At least on HP, such trick can be done. IMO thats very
handy..

Shridhar
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Ron Johnson]

On Mon, 2003-10-06 at 08:32, Shridhar Daithankar wrote:

Ron Johnson wrote:

On Mon, 2003-10-06 at 01:43, Shridhar Daithankar wrote:

The best performance is by running 32 bit applications on 64 bit kernel/hardware
, according to a migration guide by HP. The reasoning is using space optimally

Does HP have any AMD64 servers?

No. But while migrating from PA1.1 to PA2.0, they have had that pain..:-) And I
just went thr. opteron optimization guide from a link you provided. Basically
same stuff HP was pitching.

And I also configured a system on laclinux.com, just for curiosity. 2x
1.8GHz/4GB/36GBx2 10K RPM SCSI/Adaptec 29320 for $4800/- is damn cheap a system.
HP does not even start below $5K for 64 bit systems.

Imagine, if every long in pg is 8byte that would be waste most of the times.
However given a native 8 byte integer/float is available, there is no reason to
use a 8 byte data type unless required.
From what I've read, longs are still 32-bit; it's only pointers

that have upped to 64-bit.

I thought under 64 bits short==2 bytes, int==4 bytes and long==8 bytes. i.e.
this is another architecture/word length where int != long in size.

Sounds like we are saying the same thing.

Its about exploiting wide and fast bus of a 64bit machine in a most optimal
fashion. I think except for kernel and glibc, nothing else requires 64 bit in
general unless application insists on doing it's own caching.

In PG's case, if the app uses BIGINT a lot, then 64-bit PG should
be more efficient.

Possibly. Source code availability has a great advantage here. Compile the way
you want.

But still, as long as PG in itself does not use 8 byte data types exclusively, I
would like it to be a 32 bit app. A bigint is 8 byte on a 64 bit machine,
whether or not the app. is 32 bit.

Besides, in 64-bit mode, the compilers get to use 2x as many GP
registers, which should increase performance.

Well, if a 32 bit app. is optimised for opteron, compiler will use those
registers anyway..:-) At least on HP, such trick can be done. IMO thats very
handy..

Don't think it works that way in AMD64. The way I've read it, you
only get "32-bit apps" when you compile with the 32-bit compiler
switches, and thus it doesn't use the extra GPRs.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA

"Fair is where you take your cows to be judged."
Unknown
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Christopher Browne]

sh*****************@persistent.co.in (Shridhar Daithankar) writes:

And I also configured a system on laclinux.com, just for curiosity. 2x
1.8GHz/4GB/36GBx2 10K RPM SCSI/Adaptec 29320 for $4800/- is damn cheap
a system. HP does not even start below $5K for 64 bit systems.

What is _most_ interesting about these systems is the fact that they
can support 12GB of RAM. It seems disappointing to spec it out with
less than 8GB. And I'd rather throw on a MegaRAID controller...
--
let name="cbbrowne" and tld="libertyrms.info" in name ^ "@" ^ tld;;
<http://dev6.int.libertyrms.com/>
Christopher Browne
[phone] x124 (land)

[Shridhar Daithankar]

Christopher Browne wrote:

sh*****************@persistent.co.in (Shridhar Daithankar) writes:

And I also configured a system on laclinux.com, just for curiosity. 2x
1.8GHz/4GB/36GBx2 10K RPM SCSI/Adaptec 29320 for $4800/- is damn cheap
a system. HP does not even start below $5K for 64 bit systems.

What is _most_ interesting about these systems is the fact that they
can support 12GB of RAM. It seems disappointing to spec it out with
less than 8GB. And I'd rather throw on a MegaRAID controller...

Nops. Check http://www.tyan.com/products/html/thunderk8w.html which is followed
from http://www.laclinux.com/en/opt.

They support 16GB RAM..:-)

Shridhar

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org