You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Max Kanat-Alexander <mk...@bugzilla.org> on 2007/10/06 03:52:40 UTC
Apache2::SizeLimit & Linux::Smaps on x86_64
I have an x86_64 machine running RHEL5 but with the mod_perl
2.0.3 from Fedora 7.
Without Linux::Smaps installed, Apache2::SizeLimit thinks my
processes are taking up 300MB and terminates them after every hit.
("top" thinks so too, but "free -m" quickly proves that's untrue.)
With Linux::Smaps, Apache2::SizeLimit simply doesn't work at
all, because Linux::Smaps apparently doesn't work under x86_64.
See this RT bug I filed against Linux::Smaps:
http://rt.cpan.org//Ticket/Display.html?id=29803
I do have a kernel that supports smaps, 2.6.18.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Perrin Harkins <pe...@elem.com>.
On 10/6/07, Max Kanat-Alexander <mk...@bugzilla.org> wrote:
> Yes, they really are using that much but nearly all of it is
> shared via copy-on-write, as far as I can tell. SizeLimit is supposed
> to be able to detect that situation on modern kernels if you have
> Linux::Smaps installed, according to its docs.
Yes, provided Linux::Smaps works on your system. If it doesn't,
you'll have to remove it and just set a very maximum process size for
SizeLimit.
- Perrin
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Max Kanat-Alexander <mk...@bugzilla.org>.
On Sat, 6 Oct 2007 00:39:42 -0400 "Perrin Harkins" <pe...@elem.com>
wrote:
> If top can't figure out how much memory a process is using, I don't
> see how SizeLimit is going to. Is it possible they really are using
> that much, but a lot of it is shared via copy-on-write?
Yes, they really are using that much but nearly all of it is
shared via copy-on-write, as far as I can tell. SizeLimit is supposed
to be able to detect that situation on modern kernels if you have
Linux::Smaps installed, according to its docs. (I have only
MAX_UNSHARED_SIZE set.)
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Perrin Harkins <pe...@elem.com>.
On 10/5/07, Max Kanat-Alexander <mk...@bugzilla.org> wrote:
> I have an x86_64 machine running RHEL5 but with the mod_perl
> 2.0.3 from Fedora 7.
>
> Without Linux::Smaps installed, Apache2::SizeLimit thinks my
> processes are taking up 300MB and terminates them after every hit.
> ("top" thinks so too, but "free -m" quickly proves that's untrue.)
If top can't figure out how much memory a process is using, I don't
see how SizeLimit is going to. Is it possible they really are using
that much, but a lot of it is shared via copy-on-write?
- Perrin
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Max Kanat-Alexander <mk...@bugzilla.org>.
On Mon, 8 Oct 2007 01:38:23 -0700 Max Kanat-Alexander
<mk...@bugzilla.org> wrote:
> Okay, it's not SELinux. For some reason, smaps is set
> root:root 400 for all processes, even though /proc/$$/ is properly
> owned by the "apache" user. I'll have to investigate how to change
> that, I suppose.
Okay, it seems to be a bug or intentional security modification
in RHEL. I've filed a bug against RHEL:
https://bugzilla.redhat.com/show_bug.cgi?id=322881
Thanks for all your help, Torsten. :-)
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Max Kanat-Alexander <mk...@bugzilla.org>.
On Mon, 8 Oct 2007 01:35:02 -0700 Max Kanat-Alexander
<mk...@bugzilla.org> wrote:
> I suspect SELinux, at the moment.
Okay, it's not SELinux. For some reason, smaps is set root:root
400 for all processes, even though /proc/$$/ is properly owned by the
"apache" user. I'll have to investigate how to change that, I suppose.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Max Kanat-Alexander <mk...@bugzilla.org>.
On Mon, 8 Oct 2007 09:45:58 +0200 Torsten Foertsch
<to...@gmx.net> wrote:
> Is it possible that your httpd cannot access /proc/self/smaps?
Yes, that seems to be the problem. It can stat it, but not read
it.
In order to find this out, I had to make Linux::Smaps::update
return $I when it fails, and check ->lasterror inside SizeLimit.
I suspect SELinux, at the moment.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Torsten Foertsch <to...@gmx.net>.
On Monday 08 October 2007 08:35, Max Kanat-Alexander wrote:
> No, because it still doesn't work, even with the patch. I don't
> even see the warning. The error I get from SizeLimit is:
>
> Can't call method "all" on an undefined value at
> /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/Apache2/SizeLi
>mit.pm line 113.
Is it possible that your httpd cannot access /proc/self/smaps? Maybe it's
chrooted lacking the /proc filesystem in the new root? Something like this?
Linux::Smaps->new($pid) can fail only if a $pid<0 is passed or
if /proc/$pid/smaps is not readable.
Torsten
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Max Kanat-Alexander <mk...@bugzilla.org>.
On Mon, 8 Oct 2007 08:26:51 +0200 Torsten Foertsch
<to...@gmx.net> wrote:
> In your modperl environment "use warnings FATAL=>qw/all/" is active.
> Hence, the portable warning is turned into a portable error. That's
> all.
No, because it still doesn't work, even with the patch. I don't
even see the warning. The error I get from SizeLimit is:
Can't call method "all" on an undefined value at
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/Apache2/SizeLimit.pm
line 113.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Torsten Foertsch <to...@gmx.net>.
On Sunday 07 October 2007 23:29, Max Kanat-Alexander wrote:
> So it looks like it works fine for what smem is doing, but it
> somehow doesn't work right for Apache2::SizeLimit.
In your modperl environment "use warnings FATAL=>qw/all/" is active. Hence,
the portable warning is turned into a portable error. That's all.
Torsten
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Torsten Foertsch <to...@gmx.net>.
On Sunday 07 October 2007 23:29, Max Kanat-Alexander wrote:
> So it looks like it works fine for what smem is doing, but it
> somehow doesn't work right for Apache2::SizeLimit.
In your modperl environment "use warnings FATAL=>qw/all/" is active. Hence,
the portable warning is turned into a portable error. That's all.
Torsten
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Max Kanat-Alexander <mk...@bugzilla.org>.
On Sun, 7 Oct 2007 14:29:30 -0700 Max Kanat-Alexander
<mk...@bugzilla.org> wrote:
> Hrm, okay. I've attached the output of your smem script,
> [snip]
And in case it helps, here's the gzipped output of smaps for the
same process.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Max Kanat-Alexander <mk...@bugzilla.org>.
On Sun, 07 Oct 2007 21:14:23 +0200 Clinton Gormley
<cl...@traveljury.com> wrote:
> Max - try using this script to see where your memory is being used:
>
> http://www.contrib.andrew.cmu.edu/~bmaurer/memory/smem.pl
Hrm, okay. I've attached the output of your smem script, which
curiously seemed to work just fine, even without any patch, though it
does throw those warnings with -w. With the patch, it doesn't throw the
"portable" warnings. (Of course.)
So it looks like it works fine for what smem is doing, but it
somehow doesn't work right for Apache2::SizeLimit.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Clinton Gormley <cl...@traveljury.com>.
> Yes, I think so. The point is 64bit integers are not portable to 32bit perls.
> Hence, even on a 64bit system with warnings enabled a non-portable warning is
> issued:
Ahhh I get it - so it isn't warning you that there is a problem using
this on your system, just that the same input on a 32 bit system
wouldn't work.
So, presumably Max's size reports are actually correct then.
Max - try using this script to see where your memory is being used:
http://www.contrib.andrew.cmu.edu/~bmaurer/memory/smem.pl
Clint
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Torsten Foertsch <to...@gmx.net>.
On Sunday 07 October 2007 15:31, Clinton Gormley wrote:
> > -no warnings qw(uninitialized);
> > +no warnings qw(uninitialized portable);
>
> This patch certaily removes the warnings, and all of the tests pass. But
> does that mean that the module works correctly?
Yes, I think so. The point is 64bit integers are not portable to 32bit perls.
Hence, even on a 64bit system with warnings enabled a non-portable warning is
issued:
# perl -we 'print hex("100000002"),"\n",2**32+2,"\n"'
Hexadecimal number > 0xffffffff non-portable at -e line 1.
4294967298
4294967298
The same on a 32bit perl throws an additional overflow warning:
$ perl -we 'print hex("100000002"),"\n",2**32+2,"\n"'
Integer overflow in hexadecimal number at -e line 1.
Hexadecimal number > 0xffffffff non-portable at -e line 1.
4294967298
4294967298
Nevertheless the arithmetic is correct. 0xffffffff is 4294967295. Add 3 and
you get 4294967298.
Now try on a 64bit system the command again but turn warnings into errors:
# perl -e 'use warnings FATAL=>qw/all/; print
hex("100000002"),"\n",2**32+2,"\n"'
Hexadecimal number > 0xffffffff non-portable at -e line 1.
This is what happens on Max' system.
Now turn of the portable warning:
# perl -e 'use warnings FATAL=>qw/all/; no warnings "portable"; print
hex("100000002"),"\n",2**32+2,"\n"'
4294967298
4294967298
But on a 32bit perl we still get an error:
$ perl -e 'use warnings FATAL=>qw/all/; no warnings "portable"; print
hex("100000002"),"\n",2**32+2,"\n"'
Integer overflow in hexadecimal number at -e line 1.
Torsten
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Clinton Gormley <cl...@traveljury.com>.
(Resent with smaller attachment - previous version refused because too large)
> Linux::Smaps simply analyzes /proc/$PID/smaps. It was initially written on a
> 32bit system. Looking at your bug report I assume the hex() function doesn't
> work for 64bit hex values. Can you show us the output of /proc/$PID/smaps of
> one of your apache processes? Is your perl compiled with 64bit support?
>
> -no warnings qw(uninitialized);
> +no warnings qw(uninitialized portable);
This patch certaily removes the warnings, and all of the tests pass. But
does that mean that the module works correctly?
I have attached a sample output of /proc/$PID/smaps for an apache
process from my x86_64 machine running linux 2.6.18 SMP
Clint
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
Posted by Torsten Foertsch <to...@gmx.net>.
On Saturday 06 October 2007 03:52, Max Kanat-Alexander wrote:
> I have an x86_64 machine running RHEL5 but with the mod_perl
> 2.0.3 from Fedora 7.
>
> Without Linux::Smaps installed, Apache2::SizeLimit thinks my
> processes are taking up 300MB and terminates them after every hit.
> ("top" thinks so too, but "free -m" quickly proves that's untrue.)
>
> With Linux::Smaps, Apache2::SizeLimit simply doesn't work at
> all, because Linux::Smaps apparently doesn't work under x86_64.
>
> See this RT bug I filed against Linux::Smaps:
>
> http://rt.cpan.org//Ticket/Display.html?id=29803
>
> I do have a kernel that supports smaps, 2.6.18.
Linux::Smaps simply analyzes /proc/$PID/smaps. It was initially written on a
32bit system. Looking at your bug report I assume the hex() function doesn't
work for 64bit hex values. Can you show us the output of /proc/$PID/smaps of
one of your apache processes? Is your perl compiled with 64bit support?
Assuming the latter this patch may work for you. Otherwise you'll get an
integer overflow.
--- lib/Linux/Smaps.pm~ 2005-09-23 20:55:12.000000000 +0200
+++ lib/Linux/Smaps.pm 2007-10-07 12:13:06.000000000 +0200
@@ -2,7 +2,7 @@
use 5.008;
use strict;
-no warnings qw(uninitialized);
+no warnings qw(uninitialized portable);
use Class::Member::HASH qw{pid lasterror
_elem -CLASS_MEMBERS};
Please let me know if it works.
Torsten