Thread: Server recommendations
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.
Oops! gearond@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!
Christopher Browne wrote: > Oops! gearond@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
On Fri, 2003-10-03 at 10:37, Shridhar Daithankar wrote: > Christopher Browne wrote: > > > Oops! gearond@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. ron.l.johnson@cox.net Jefferson, LA USA "Knowledge should be free for all." Harcourt Fenton Mudd, Star Trek:TOS, "I, Mudd"
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! gearond@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.
>
>
>
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.com/articles/2003/upgrade07_03_08.asp http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_739_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! gearond@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. ron.l.johnson@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
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
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. ron.l.johnson@cox.net Jefferson, LA USA PETA - People Eating Tasty Animals
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
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. ron.l.johnson@cox.net Jefferson, LA USA "Fair is where you take your cows to be judged." Unknown
shridhar_daithankar@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 (416) 646 3304 x124 (land)
Christopher Browne wrote: > shridhar_daithankar@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