Peter Cordes wrote: > Dirk H. Schulz wrote: > > I want to run a server with more than 4 GB of RAM. I do not need > > applications/processes to address more than 4 GB each. Let's say I > > want to have 2 instances of apache on the machine, and each > > instance should address a max of 4 GB. I think if you really look at memory use of apache what you describe does not match the reality of an apache web server. You are expecting much more memory than will actually be used. Let me suggest some research to understand exactly what your memory needs will be. > > Do I need a 64Bit Linux then? Or can I install a 32Bit Linux on a Server > > with 8 GB RAM, set up my 2 instances of apache, and that`s it? > Ok, here are your options: A nice summary. Thanks for providing that. > 32bit kernel, 32bit user space: Each process gets 3GB of virtual address > space. The kernel can divvy that up however it wants. You'll need to > enable highmem support for that. If CPU performance isn't your bottleneck, > it won't matter that you don't get to use the extra registers. You lose > maybe 15% CPU performance, depending on what you're doing. (Compare SPEC > scores breakdowns for AMD's submission, if you're curious.) Our own benchmarks at work show about a 7%-8% decrease in performance when you turn on CONFIG_HIGHMEM64G. This was for a configuration like this: xw8000 dual P4 3.06GHz w/ 6GB ram running two 3GB processes. In that configuration you get a good return from the 64G mode. Or needing twice as many machines to run the jobs upon. The non-alternative is swapping and running at disk drive speeds which as you can imagine is very slow and a waste of a fast cpu. But otherwise I tend to think the 64G mode is good to avoid. But it is very stable and we have had no issues with it. > This will be the most stable configuration, because you can just > install i386 Sarge, and forget all about 64bit. (Yes, Opterons > support PAE and all that's needed for a 32bit kernel to use lots of > RAM.) The kernel has to use bounce buffers to move data around, > because it can't map all the memory. Nicely stating why there is a performance penalty. > 64bit kernel, 32bit userspace: ... Good points but let me add that this. It is a configuration you should be somewhat knowledgable about as an admin because it will be different than your buddy and you will have to be confident of your own system debugging skills. This is actually a mode I am contemplating very seriously for a work configuration. It is very similar to some of the commercial UN*X offerings. But until multi-arch realizes it is thwart with policy issues such as where things should go. > 64bit kernel, 64bit userspace: ... I currently have an amd64 server running in this mode. I have installed a full i386 chroot. If this evaluates well then this is the simplest to administer. Two machines in one running apt in parallel. (64-bit superior and 32-bit inferior in the chroot.) This is a rock solid configuration. Bob
Attachment:
pgp0JCLZotDwX.pgp
Description: PGP signature