In the last exciting episode, josh@agliodbs.com (Josh Berkus) wrote:
> 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 have been seeing ia-32 servers with 8GB of RAM; it looks as though
there are ways of having them support ("physically, in theory, if you
could get a suitable motherboard") as much as 64GB.
But that certainly doesn't get you past 2^32 bytes per process, and
possibly not past 2^31 bytes/process.
From Linux kernel help:
CONFIG_NOHIGHMEM:
Linux can use up to 64 Gigabytes of physical memory on x86
systems. However, the address space of 32-bit x86 processors is
only 4 Gigabytes large. That means that, if you have a large
amount of physical memory, not all of it can be "permanently
mapped" by the kernel. The physical memory that's not permanently
mapped is called "high memory".
And that leaves open the question of how much shared memory you can
address. That presumably has to fit into the 4GB, and if your
PostgreSQL processes had (by some fluke) 4GB of shared memory, there
wouldn't be any "local" memory for sort memory and the likes.
Add to that the consideration that there are reports of Linux "falling
over" when you get to right around 2GB/4GB. I ran a torture test a
while back that _looked_ like it was running into that; I can't verify
that, unfortunately.
I don't see there being a whole lot of use of having more than about
8GB on an ia-32 system; what with shared memory maxing out at
somewhere between 1 and 2GB, that suggests having ~8GB in total.
I'd add another PG cluster if I had 16GB...
--
let name="aa454" and tld="freenet.carleton.ca" in name ^ "@" ^ tld;;
http://www.ntlug.org/~cbbrowne/postgresql.html
"A statement is either correct or incorrect. To be *very* incorrect is
like being *very* dead ... "
-- Herbert F. Spirer
Professor of Information Management
University of Conn.
(DATAMATION Letters, Sept. 1, 1984)