Jonathan wrote:
>
> On Aug 24, 2006, at 2:59 AM, Philip M. Gollucci wrote:
>> Every one of those looks as I would expect.
>
> really? i'd expect the memory usage to be more uniform
See another example of this here:
http://perl.apache.org/docs/1.0/guide/performance.html#_Bloatware__modules
[scroll down abit to this chart]
OpenBSD FreeBSD Redhat Linux Solaris
vsz rss vsz rss vsz rss vsz rss
Raw Perl 736 772 832 1208 2412 980 2928 2272
w/ CGI 1220 1464 1308 1828 2972 1768 3616 3232
w/ IO 2292 2580 2456 3016 4080 2868 5384 4976
These are quite a bit old, so I expect they would have changed some by now.
IF anyone is bored or wants to contribute recent numbers, we'll commit / add
them to this page.
> b- freebsd is showing a larger resident than size
One is in KB the other is in Bytes -- thats due to the way getrusage(3) reports
it.
> c- LARGE difference in what gtop is reporting as shared
> ubuntu is showing a size 42mb
> 30mb shared
> 12mb per child
Can't speak about this one.
> freebsd is showing a size of 46mb
> 8mb shared
> 38 unshared
I'm almost sure the Copy-on-Write reporting or Shared reporting is not correct
(see below)
Just because the reporting is wrong, doesn't mean that its not actually being
shared.
I think your best bet for that is to figure out how many children you need to
spawn until just
before you exhaust your physical ram. Then figure out how much of must be
shared for it to not be swapping.
> FreeBSD 6
>
> Startup ps
> root 93830 15.8 5.1 54928 51616 ?? Ss 4:44AM 0:02.42
> /usr/local/sbin/httpd
> www 93834 0.0 5.1 54984 51672 ?? S 4:44AM 0:00.01
> /usr/local/sbin/httpd
>
> Request 1 GTOP: (93834)
> ->size 46534656
> ->vsize 46534656
> ->resident 52944896
> ->share 8184509
> ->rss 52944896
>
> root 93830 0.0 5.1 54928 51616 ?? Ss 4:44AM 0:02.42
> /usr/local/sbin/httpd
> www 93834 0.0 5.1 55200 51852 ?? S 4:44AM 0:00.09
> /usr/local/sbin/httpd
>
> Request 2 GTOP: (93834)
> ->size 46727168
> ->vsize 46727168
> ->resident 53059584
> ->share 8184509
> ->rss 53059584
>
> root 93830 0.0 5.1 54928 51616 ?? Ss 4:44AM 0:02.42
> /usr/local/sbin/httpd
> www 93834 0.0 5.1 55200 51852 ?? S 4:44AM 0:00.11
> /usr/local/sbin/httpd
Did I miss something above? That makes sense to me.
Since your parent started at 54928Kb no more then that can ever be shared
unless you restart/change stuff.
Seems that on startup 54984Kb is given to a child which is a delta of 56bytes
that are not shared at startup.
Thats actually better then most.
After 1 request, your child is at 55200Kb which means you allocated (55220Kb -
54984Kb) 216bytes
None of which can ever be shared; however, when the child is reaped -- by A::SL
or similar
it should respawn at 54984Kb
Based on GTOP metrics above, you need to test the copy-on-write of FreeBSD..
The A::SL docs have a method to do this contributed by Torsten Forsch(sorry if
I spelled your name wrong)
You might e-mail [EMAIL PROTECTED] or [EMAIL PROTECTED] as they will be much
more authoritative then me.
The only thing you have to do differently is use BSD::Resource instead of
Linux::Smaps which Apache::SizeLimit
will do for just because your running it on a BSD based OS.
P.S. I've got to look up how GTOP from CPAN is interfacing with libtop2?.so and
then how it interfaces with getrusage(3)
=head3 Copy-on-write and Shared Memory
The following example shows the effect of copy-on-write:
<Perl>
require Apache2::SizeLimit;
package X;
use strict;
use Apache2::Const -compile => qw(OK);
my $x = "a" x (1024*1024);
sub handler {
my $r = shift;
my ($size, $shared) = $Apache2::SizeLimit->_check_size();
$x =~ tr/a/b/;
my ($size2, $shared2) = $Apache2::SizeLimit->_check_size();
$r->content_type('text/plain');
$r->print("1: size=$size shared=$shared\n");
$r->print("2: size=$size2 shared=$shared2\n");
return OK;
}
</Perl>
<Location /X>
SetHandler modperl
PerlResponseHandler X
</Location>
The parent Apache process allocates memory for the string in
C<$x>. The C<tr>-command then overwrites all "a" with "b" if the
handler is called with an argument. This write is done in place, thus,
the process size doesn't change. Only C<$x> is not shared anymore by
means of copy-on-write between the parent and the child.
If F</proc/self/smaps> is available curl shows:
[EMAIL PROTECTED]:~/work/mp2> curl http://localhost:8181/X
1: size=13452 shared=7456
2: size=13452 shared=6432
Shared memory has lost 1024 kB. The process' overall size remains unchanged.
Without F</proc/self/smaps> it says:
[EMAIL PROTECTED]:~/work/mp2> curl http://localhost:8181/X
1: size=13052 shared=3628
2: size=13052 shared=3636
One can see the kernel lies about the shared memory. It simply doesn't
count copy-on-write pages as shared.
--
------------------------------------------------------------------------
Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ /
/ /|_/ / // /\ \/ /_/ / /__
/_/ /_/\_, /___/\___\_\___/
<___/
