Perrin Harkins wrote:
On 11/2/07, Gary Sewell <[EMAIL PROTECTED]> wrote:
Firstly, we are running a mod_perl application on 4 separate servers due to
its bulkiness.
Do you have a lot of traffic? Most people don't need this many
servers if they run a reverse proxy in front of mod_perl.
Usually most setups that need to use a reverse proxy need at least 3
backend servers. So 4 is not a lot really.
If you need a reverse proxy then it presumes you have plenty of traffic.
Multiple boxes are needed so that one box can be taken down at a time
for planned maintenance/upgrades while the remaining cluster can handle
peak load (and possibly provide redudancy/failover of the active set
while maintenance on one node is being performed).
So lets presume any 2 nodes can handle his peak traffic, this allows one
extra node for failover (during maintenance) and one extra node for
planned maintenance.
The fact mod_perl is being used, presumes that there is a component of
dynamic content, which presumes a reverse proxy can not meet that demand
(since its just a proxy not a dynamic content http server).
Maybe what you mean is you don't need nearly this many servers if you
don't have availably targets to meet.
We have found each apache instance is almost double on the 64-bit servers
I think this has to do with how you compile perl. There was some
discussion in the list archives. Try searching the archives and maybe
Google the archives for comp.lang.perl.misc or p5p too, since it's a
general perl issue and not a mod_perl thing.
Ensure you are measuring the RSS difference, the VSIZE includes all
mappings as well, possibly including files mmap()ed by glibc. The 32bit
and 64bit strategy for standard file I/O maybe different.
You must accept that all pointers are twice the size, also the stack
usage (per thread) will be bigger, so its pretty easy to see larger
footprint.
Even simple processes like 'grep' can see an additional 48Mb usage in
SIZE (but not RSS) due to glibc mapping some MESSAGES file.
My own experience with 32bit vs 64bit is that 32bit is better for any
application that does not need > 3Gb heap. There are very few
applications that will benefit from access to more address space. I'd
really like to see a Linux 32bit+ ELF ABI, this would be like Sun's
SPARCV8+ ABI, in that its 32bit application address space on a 64bit
kernel and 64bit capable CPU which ensures access to the additional
registers to allow better code generation and less use of the stack
(more use of registers) for function calling conventions.
Is it worth installing a 32-bit distribution on the 64-bit processors? Will
the 8Gb RAM cause problems as 32-bit distributions if we did this?
You won't be able to use most of that RAM if you run a 32-bit OS.
Huh... He uses prefork model a process per connection, a single process
is limited to around 3Gb of usable heap on 32bit Linux application
space. So as few as 3 processes could eat enough memory to need swap.
Even if you have no application usage for all 8Gb the kernel itself can
use it for buffer cache.
A 32bit Linux kernel can access memory > 4Gb (I think this mechanism is
called PAE and was even a feature of older Pentium 3 CPUs).
How can I get a split/rundown of what is taking up so much memory for each
apache instance, 100Mb is a lot, let alone 200Mb on the 64 bit servers. I'm
sure we are going wrong somewhere.
cat /proc/<pid>/maps
cat /proc/<pid>/smaps
There is a tools to help parse the info somewhere, google for Linux
memory usage and "smaps".
Darryl
