Re: 32-bit vs AMD64 on Opteron for LAMP server
On 07/08/07 09:49:32AM -0500, Neil Gunton wrote:
> Jim Crilly wrote:
> >For 32-bit systems only if the kernel is compiled with CONFIG_HIGHMEM64G
> >enabled so you need one of the "bigmem" kernels. And the BIOS on the
> >machine
> >has to support remapping the lost memory above the 4G mark, if it won't do
> >that for you there's nothing you can do to get access to that memory.
> >
> >The per-process limit will be 3G since 4G is the max addressable and 1G of
> >that space is reserved for the kernel. And part of the 3G will be used for
> >the binary itself, shared libraries, mmap'd files, etc so you'll never even
> >get the full 3G out of a single process.
>
> Ok, here's another thought: It's easy to get into a purist frame of mind
> with this where you end up obsessing over numbers like 3 GB or 4 GB or
> 64 GB. But taking a step back, does any real world process, especially
> in the LAMP stack, actually need that amount of memory? I know MySQL can
> probably use whatever you want to throw at it, for index buffer caching
> particularly, but I can only envisage giving MySQL 3 GB if the total
> system RAM was a lot more than that - probably at least 6 GB, and I
> don't plan on doing that soon with this server.
>
Well I can't really comment on how useful it would be because that would be
dependent on the usage patterns of the installation and I've never had to
deal with a LAMP installation of any real size. But the memory limits are
virtual, not physical. So if you had planned on giving MySQL 3G for
anything you would need a larger VM space because a chunk of it will
already be used.
>
> >I'm not sure if this was mentioned but another option would be to install
> >the 32-bit i386 distribution but run a 64-bit kernel, that way each 32-bit
> >process would have 4G of VM since the kernel wouldn't have to share their
> >address space and you would also have the option of running some select
> >64-bit binaries if you find that something needs more VM.
>
> I didn't even know you could do that! Sounds interesting, though. Seems
> a little weird mixing the two modes, because I would have thought that
> processes talking to the kernel would need to be using the same
> underlying libs and agree on what size an integer is, for example. But
> evidently it's possible, so thanks for the idea.
>
It's essentially the same concept as installing the 64-bit release and then
putting a 32-bit chroot on that box to run things like flash, the same
kernel is executing both sets of executables. Most processes talk to the
kernel very little and do so in via well defined syscalls so there's no
problem running 32-bit binaries on a 64-bit kernel. Occasionally something
that does do odd things with the kernel, like the iptables userland stuff,
can have issues but those are special cases.
The kernel doesn't use any libraries itself so that's not a problem, but
yes you do need all the right versions and builds of any dependencies. So
if you have a 32-bit userland and decide that you want to run a 64-bit
MySQL you need to build 64-bit versions of MySQL and all of the libraries
that it needs before it'll run. I'm not sure if you could setup a 64-bit
chroot on the 32-bit system to make that simpler but if so that would take
away the pain of having to build anything.
>
> /Neil
>
Jim.
Reply to: