> your machine. Therefore you should configure the server, so that the
> maximum number of possible processes will be small enough using the
> C<MaxClients> directive. This will ensure that at the peak hours the
> system won't swap. Remember that swap space is an emergency pool, not
> a resource to be used routinely. If you are low on memory and you
> badly need it, buy it or reduce a number of processes to prevent
> swapping.
One common mistake that people make is to not load
test against a server to trigger the full MaxClients
in production. In order to prevent swapping, one must
simulate the server at its point of greatest RAM stress,
and one can start to do this by running ab against
a program so that each of the MaxClient httpd processes
goes through its MaxRequests.
So lets say MaxRequests is set to 1000 and MaxClients
is set to 100, then in order to see the system go
through a full cycle fully maxed out in RAM, one might
ab -c 100 -n 100000 http://yoursite.loadtest/modperl/ramhog
Then fire up top, sit back, and enjoy the show!
In summary this aids in swapping prevention, by load testing
the server under highest RAM stress preproduction, and seeing
if it swaps. Then one can tune their parameters to avoid
swapping under this highest load, by decreasing MaxClients
or MaxRequests.
-- Joshua
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks >> free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
Stas Bekman wrote:
>
> I've rewritten the guide's swapping section now delving into quite
> technical details. Please take a moment to review this section and comment
> on it.
>
> I have tried to stay on focus to deliver as much as possible relevant
> details without actually delving into the fine details of memory
> management techniques like virtual memory, sharing and alike, therefore
> this version is a simplified one. I hope that it'll be still educating and
> clear for folks with no CS background. The goal is to helps to understand
> the reasoning behind desired swapping prevention under mod_perl.
>
> Submitting of the additional techniques/details and possible
> problems/solutions that I've not covered or covered incorrectly is very
> welcome. Remember that I'm not trying to reproduce the operating systems
> course but provide only the relevant details. Thanks a lot!
>
> So here we go:
>
> =head2 Swapping Prevention
>
> Before we delve into swapping process details, let's refresh our
> memory management knowledge.
>
> The computer memory is called RAM, which stands for Random Access
> Memory. Reading and writing to RAM is by a few orders faster than
> doing the same operations with a hard disk, the former uses the
> non-movable memory cells, while the latter uses the rotating magnetic
> media.
>
> On most operating systems a swap memory is used as an extension for
> RAM and not as a duplication of it. So if your OS is one of those, if
> you have 128MB of RAM and 256MB swap partition, you have a total of
> 384MB of memory available for OS. You should never count this extra
> memory when you decide on the maximum number of processes to be run,
> and we will show why in the moment.
>
> The swapping memory can be built of a number of hard disk partitions
> and swap files formatted to be used as a swap memory. When you need
> more swap memory you can always extend it on demand as long as you
> have some free disk space (for more information see the I<mkswap> and
> I<swapon> manpages).
>
> System memory is quantified in units called memory pages. Usually the
> size of the memory page is 4KB or 8KB. So if you have 256MB of RAM
> installed on your machine and the page size is 4KB your system has
> 64,000 memory pages to work with. When the system is started all
> memory pages are available for use by the programs (processes).
>
> When a process asks for a specific memory page, the system checks
> whether this page is already loaded in memory and if it's not, the
> I<page fault> event occurs, which requires the system to allocate a
> free memory page and load this page into memory.
>
> Each program asks a system for a certain number of the RAM memory
> pages when it started. For example if a program needs 512KB of memory
> when it starts and the memory page size is 4KB, the system will have
> to allocate 128 memory pages for this program. Note that if some of
> the pages can be shared with other processes it's possible that less
> pages will be needed. For examples pages that are occupied by all
> kind of I<libc> libraries are generally shared between the processes that
> use these libraries.
>
> After the process was started it might ask the OS for additional
> memory pages when it needs them. While there are memory pages
> available, the OS allocates these demanded memory pages and delivers
> them to the process that asks for them. Most programs, particularly
> Perl programs, on most modern OSs don't return memory pages while they
> are running to improve the performance. If some of the memory gets
> freed it's reused when needed by the process, without creating an
> additional overhead by asking the system to allocate new memory pages.
> That's why you can observe that Perl programs are usually growing in
> size and almost never shrink.
>
> When the process quits it returns its memory pages to the pool of
> freely available pages for other processes to reuse.
>
> The more processes are running the more memory pages are used, the
> less available memory pages remain. At some point when a process asks
> for memory pages the system cannot find any available, since all of
> them are in use. That's the moment when the system starts the swapping
> process which uses the swapping memory.
>
> When there is no free memory pages available, in order to gain the
> required number of memory pages requested by the process the system
> (kernel) has to page out (i.e. move to a hard disk's swap partition)
> exactly the same number of pages. The kernel pages out memory pages
> using the LRU (least recently used) or a similar algorithm to decide
> which pages to take out, in attempt to prevent the situation where the
> next process which is going to get CPU will need exactly the pages
> that were just paged out, and therefore prevent the page fault (when
> the page is not found in RAM). Because if the page faults occur, more
> pages will have to be swapped out in order to free the memory for the
> pages that get swapped in (loaded from swap into RAM).
>
> When the CPU has to page memory pages in and out, the system slows
> down, and not serving the process as fast as before. This leads to
> accumulation of the processes waiting for CPU, which causes processing
> demands to go up, which in turn slows down the system even more as
> more memory is required. This ever worsening spiral will lead the
> machine to halt, unless the resource demand suddenly drops down and
> allows the processes to catch up with their tasks and go back to
> normal memory usage.
>
> This scenario is certainly educating, and it should be now obvious
> that your system that runs the web server should never swap. It's
> absolutely normal for your desktop to start swapping. You will see it
> immediately since things will slow down and sometimes the system will
> freeze for a short periods. But as we just mentioned, you can stop
> starting new programs and can quit some, thus allowing the system to
> catch up with the load and come back to use the RAM. In the case of
> the web server you have much less control since it's users who load
> your machine. Therefore you should configure the server, so that the
> maximum number of possible processes will be small enough using the
> C<MaxClients> directive. This will ensure that at the peak hours the
> system won't swap. Remember that swap space is an emergency pool, not
> a resource to be used routinely. If you are low on memory and you
> badly need it, buy it or reduce a number of processes to prevent
> swapping.
>
> However sometimes due to the faulty code, some process might start
> spinning in some unconstrained loop, consuming all the available RAM
> and starting to heavily use the swap memory. In such a situation it
> helps when you have a big emergency pool (i.e. lots of swap
> memory). But you have to resolve this problem as soon as possible since
> this pool
> won't last for a long time. In the meanwhile the C<Apache::Resource>
> module can be handy.
>
> Sometimes calling an undefined subroutine in a module can cause a
> tight loop that consumes all the available memory. Here is a way to
> catch such errors. Define an C<AUTOLOAD> subroutine:
>
> sub UNIVERSAL::AUTOLOAD {
> my $class = shift;
> warn "$class can't \$UNIVERSAL::AUTOLOAD!\n";
> }
>
> This will produce a nice error in I<error_log>, giving the line number
> of the call and the name of the undefined subroutine.
>
> _____________________________________________________________________
> Stas Bekman JAm_pH -- Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide http://perl.apache.org/guide
> mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
> http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
