perl-docs-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: modperl-docs/src/docs/1.0/guide Changes.pod performance.pod
Date Thu, 21 Mar 2002 10:16:35 GMT
stas        02/03/21 02:16:35

  Modified:    src/docs/1.0/guide Changes.pod performance.pod
  added a new section: "Potential Drawbacks of Memory Sharing
  Revision  Changes    Path
  1.2       +3 -0      modperl-docs/src/docs/1.0/guide/Changes.pod
  Index: Changes.pod
  RCS file: /home/cvs/modperl-docs/src/docs/1.0/guide/Changes.pod,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Changes.pod	20 Mar 2002 17:43:03 -0000	1.1
  +++ Changes.pod	21 Mar 2002 10:16:35 -0000	1.2
  @@ -22,6 +22,9 @@
       Apache::GTopLimit which now both sport the shared and unshared
       memory thresholds.
  +  o added a new section: "Potential Drawbacks of Memory Sharing
  +    Restriction"
   * guide::
     o most of the internal links were changed to use the whole title and
  1.6       +35 -0     modperl-docs/src/docs/1.0/guide/performance.pod
  Index: performance.pod
  RCS file: /home/cvs/modperl-docs/src/docs/1.0/guide/performance.pod,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- performance.pod	20 Mar 2002 18:15:36 -0000	1.5
  +++ performance.pod	21 Mar 2002 10:16:35 -0000	1.6
  @@ -5060,6 +5060,41 @@
   which can be modified any time, even after the module was loaded.
  +=head3 Potential Drawbacks of Memory Sharing Restriction
  +It's very important that the system won't be heavily engaged in
  +swapping process. Some systems do swap in and out every so often even
  +if they have plenty of real memory available and it's OK. The
  +following applies to conditions when there is hardly any free memory
  +So if the system uses almost all of its real memory (including the
  +cache), there is a danger of parent's process memory pages being
  +swapped out (written to a swap device). If this happens the memory
  +usage reporting tools will report all those swapped out pages as
  +non-shared, even though in reality these pages are still shared on
  +most OSs. When these pages are getting swapped in, the sharing will be
  +reported back to normal after a certain amount of time. If a big chunk
  +of the memory shared with child processes is swapped out, it's most
  +likely that C<Apache::SizeLimit> or C<Apache::GTopLimit> will notice
  +that the shared memory floor threshold was crossed and as a result
  +kill those processes. If many of the parent process' pages are swapped
  +out, and the newly created child process is already starting with
  +shared memory below the limit, it'll be killed immediately after
  +serving a single request (assuming that we the
  +C<$CHECK_EVERY_N_REQUESTS> is set to one). This is a very bad
  +situation which will eventually lead to a state where the system won't
  +respond at all, as it'll be heavily engaged in swapping process.
  +This effect may be less or more severe depending on the memory
  +manager's implementation and it certainly varies from OS to OS, and
  +different kernel versions. Therefore you should be aware of this
  +potential problem and simply try to avoid situations where the system
  +needs to swap at all, by adding more memory, reducing the number of
  +child servers or spreading the load across more machines, if reducing
  +the number of child servers is not an options because of the request
  +rate demands.
   =head3 Defining the Maximum Memory Size Threshold
   Not less important than maximizing shared memory is restricting the

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message