In the last exciting episode, [EMAIL PROTECTED] ("Andrew G. Hammond") wrote:
I don't know what your budget is, but there are now 10k RPM SATA 150
drives on the market. Their price/performance is impressive. You may
want to consider going with a bunch of these instead of SCSI disks
(more spindle
In the last exciting episode, [EMAIL PROTECTED] ("Andrew G. Hammond") wrote:
> I don't know what your budget is, but there are now 10k RPM SATA 150
> drives on the market. Their price/performance is impressive. You may
> want to consider going with a bunch of these instead of SCSI disks
> (more spi
I don't know what your budget is, but there are now 10k RPM SATA 150
drives on the market. Their price/performance is impressive. You may
want to consider going with a bunch of these instead of SCSI disks (more
spindles vs. faster spindles). 3ware makes a hardware raid card that can
drive up to
Shridhar Daithankar wrote:
FWIW, there are only two pieces of software that need 64bit aware
for a typical server job. Kernel and glibc. Rest of the apps can do
fine as 32 bits unless you are oracle and insist on outsmarting OS.
In fact running 32 bit apps on 64 bit OS has plenty of advantages
Just one more piece of advice, you might want to look into a good battery
backed cache hardware RAID controller. They work quite well for heavily
updated databases. The more drives you throw at the RAID array the faster
it will be.
I've seen this list often recommended such a setup. We'll probab
Shridhar Daithankar wrote:
FWIW, there are only two pieces of software that need 64bit aware for a
typical server job. Kernel and glibc. Rest of the apps can do fine as 32
bits unless you are oracle and insist on outsmarting OS.
In fact running 32 bit apps on 64 bit OS has plenty of advantages l
Jeff Bohmer wrote:
Well if this is the case, you probably should get an Opteron server
*now* and just run 32-bit Linux on it until you're sure about the
software. No point in buying a Xeon and then throwing the machine away
in a year when you decide you need 64-bit for more speed.
That's a goo
Jeff Bohmer wrote:
It seems I don't fully understand the bigmem situation. I've searched
the archives, googled, checked RedHat's docs, etc. But I'm getting
conflicting, incomplete and/or out of date information. Does anyone
have pointers to bigmem info or configuration for the 2.4 kernel?
Big
Just one more piece of advice, you might want to look into a good battery
backed cache hardware RAID controller. They work quite well for heavily
updated databases. The more drives you throw at the RAID array the faster
it will be.
---(end of broadcast)--
Properly tuned, PG on Linux runs really nice. A few people have
mentioned the VM swapping algorithm on Linux is semi-dumb. I get
around that problem by having a ton of memory and almost no swap.
I think we want your approach: enough RAM to avoid swapping altogether.
With 4GB of RAM, you're al
Jeff Bohmer wrote:
We're willing to shell out extra bucks to get something that will
undoubtedly handle the projected peak load in 12 months with excellent
performance. But we're not familiar with PG's performance on Linux and
don't like to waste money.
Properly tuned, PG on Linux runs really n
11 matches
Mail list logo
