Re: Tuning for mid-size server

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Anjan Dave <adave(at)vantage(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Tuning for mid-size server
Date: 2003-10-21 17:30:36
Message-ID: Pine.LNX.4.33.0310211128002.10645-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, 21 Oct 2003, Josh Berkus wrote:

> Scott,
>
> > Also, if it's a read only environment, RAID5 with n drives equals the
> > performance of RAID0 with n-1 drives.
>
> True.
>
> > Josh, you gotta get out more. IA32 has supported >4 gig ram for a long
> > time now, and so has the linux kernel. It uses a paging method to do it.
> > Individual processes are still limited to ~3 gig on Linux on 32 bit
> > hardware though, so the extra mem will almost certainly spend it's time as
> > kernel cache.
>
> Not that you'd want a sigle process to grow that large anyway.

True :-) Especially a pgsql backend.

> So what is the ceiling on 32-bit processors for RAM? Most of the 64-bit
> vendors are pushing Athalon64 and G5 as "breaking the 4GB barrier", and even
> I can do the math on 2^32. All these 64-bit vendors, then, are talking
> about the limit on ram *per application* and not per machine?

I think it's 64 gigs in the current implementation, but that could just be
a chip set thing, i.e. the theoretical limit is probably 2^63 or 2^64, but
the realistic limitation is that the current mobo chipsets are gonna have
a much lower limit, and I seem to recall that being 64 gig last I looked.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message scott.marlowe 2003-10-21 17:33:43 Re: Tuning for mid-size server
Previous Message Josh Berkus 2003-10-21 17:22:49 Re: Tuning for mid-size server