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.
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 |