Skip site navigation (1) Skip section navigation (2)

Re: Hardware suggestions for Linux/PGSQL server

From: Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: Jeff Bohmer <bohmer(at)visionlink(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Hardware suggestions for Linux/PGSQL server
Date: 2003-12-12 06:35:49
Message-ID: 3FD961C5.9070204@persistent.co.in (view raw or flat)
Thread:
Lists: pgsql-performance
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 good point.  I had forgotten about the option to run 32bit on 
> an Operton.  If we had 3GB or 4GB initially on an Opteron, we'd need 
> bigmem for 32bit Linux, right?
> 
> This might work nicely since we'd factor in the penalty from PAE for now 
> and have the performance boost from moving to 64bit available on 
> demand.  Not having to build another DB server in a year would also be 
> nice.

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 like 
effectively using the cache. Unless you need 64bit, going for 64bit software is 
not advised.

  Shridhar

-- 
-----------------------------
Shridhar Daithankar
LIMS CPE Team Member, PSPL.
mailto:shridhar_daithankar(at)persistent(dot)co(dot)in
Phone:- +91-20-5676700 Extn.270
Fax  :- +91-20-5676701
-----------------------------


In response to

Responses

pgsql-performance by date

Next:From: Bruce MomjianDate: 2003-12-12 06:49:26
Subject: fsync method checking
Previous:From: Alfranio Tavares Correia JuniorDate: 2003-12-12 02:35:16
Subject: Re: Performance problems with a higher number of clients

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group