Re: Apache2::SizeLimit Linux::Smaps on x86_64
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 pgpdbQyi2CiIb.pgp Description: PGP signature
Re: Apache2::SizeLimit Linux::Smaps on x86_64
On Mon, 8 Oct 2007 08:26:51 +0200 Torsten Foertsch [EMAIL PROTECTED] 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
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 $pid0 is passed or if /proc/$pid/smaps is not readable. Torsten pgp57vbuTj1bb.pgp Description: PGP signature
Re: Apache2::SizeLimit Linux::Smaps on x86_64
On Mon, 8 Oct 2007 09:45:58 +0200 Torsten Foertsch [EMAIL PROTECTED] 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
On Mon, 8 Oct 2007 01:35:02 -0700 Max Kanat-Alexander [EMAIL PROTECTED] 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
On Mon, 8 Oct 2007 01:38:23 -0700 Max Kanat-Alexander [EMAIL PROTECTED] 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
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.0 +0200
+++ lib/Linux/Smaps.pm 2007-10-07 12:13:06.0 +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
pgpN0gZjGSJ1e.pgp
Description: PGP signature
Re: Apache2::SizeLimit Linux::Smaps on x86_64
(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 0040-00487000 r-xp fd:00 9764993 /opt/httpd-2.2.4_prefork_perl_php/bin/httpd Size: 540 kB Rss:172 kB Shared_Clean: 172 kB Shared_Dirty: 0 kB Private_Clean:0 kB Private_Dirty:0 kB 00686000-00687000 r--p 00086000 fd:00 9764993 /opt/httpd-2.2.4_prefork_perl_php/bin/httpd Size: 4 kB Rss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 4 kB Private_Clean:0 kB Private_Dirty:0 kB 00687000-0068c000 rw-p 00087000 fd:00 9764993 /opt/httpd-2.2.4_prefork_perl_php/bin/httpd Size:20 kB Rss: 16 kB Shared_Clean: 0 kB Shared_Dirty: 4 kB Private_Clean:0 kB Private_Dirty: 12 kB 0068c000-026d8000 rw-p 0068c000 00:00 0 [heap] Size: 33072 kB Rss: 32708 kB Shared_Clean: 0 kB Shared_Dirty: 31576 kB Private_Clean:0 kB Private_Dirty: 1132 kB 2b91f88ff000-2b91f891b000 r-xp fd:01 851970 /lib64/ld-2.5.so Size: 112 kB Rss: 32 kB Shared_Clean:32 kB Shared_Dirty: 0 kB Private_Clean:0 kB Private_Dirty:0 kB 2b91f891b000-2b91f891c000 rw-p 2b91f891b000 00:00 0 Size: 4 kB Rss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 4 kB Private_Clean:0 kB Private_Dirty:0 kB 2b91f895-2b91f8951000 rw-p 2b91f895 00:00 0 Size: 4 kB Rss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean:0 kB Private_Dirty:4 kB 2b91f8b1b000-2b91f8b1d000 rw-p 0001c000 fd:01 851970 /lib64/ld-2.5.so Size: 8 kB Rss: 8 kB Shared_Clean: 0 kB Shared_Dirty: 4 kB Private_Clean:0 kB Private_Dirty:4 kB 2b91f8b1d000-2b91f8b72000 r-xp fd:01 851985 /lib64/libm-2.5.so Size: 340 kB Rss: 4 kB Shared_Clean: 4 kB Shared_Dirty: 0 kB Private_Clean:0 kB Private_Dirty:0 kB 2b91f8b72000-2b91f8d71000 ---p 00055000 fd:01 851985 /lib64/libm-2.5.so Size: 2044 kB Rss: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean:0 kB Private_Dirty:0 kB 2b91f8d71000-2b91f8d73000 rw-p 00054000 fd:01 851985 /lib64/libm-2.5.so Size: 8 kB Rss: 8 kB Shared_Clean: 0 kB Shared_Dirty: 8 kB Private_Clean:0 kB Private_Dirty:0 kB 2b91f8d73000-2b91f8d8d000 r-xp fd:00 9764963 /opt/httpd-2.2.4_prefork_perl_php/lib/libaprutil-1.so.0.2.8 Size: 104 kB Rss: 36 kB Shared_Clean:36 kB Shared_Dirty: 0 kB Private_Clean:0 kB Private_Dirty:0 kB 2b91f8d8d000-2b91f8f8d000 ---p 0001a000 fd:00 9764963 /opt/httpd-2.2.4_prefork_perl_php/lib/libaprutil-1.so.0.2.8 Size: 2048 kB Rss: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean:0 kB Private_Dirty:0 kB [cut]
Re: Apache2::SizeLimit Linux::Smaps on x86_64
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(10002),\n,2**32+2,\n' Hexadecimal number 0x non-portable at -e line 1. 4294967298 4294967298 The same on a 32bit perl throws an additional overflow warning: $ perl -we 'print hex(10002),\n,2**32+2,\n' Integer overflow in hexadecimal number at -e line 1. Hexadecimal number 0x non-portable at -e line 1. 4294967298 4294967298 Nevertheless the arithmetic is correct. 0x 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(10002),\n,2**32+2,\n' Hexadecimal number 0x 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(10002),\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(10002),\n,2**32+2,\n' Integer overflow in hexadecimal number at -e line 1. Torsten pgpy3cq5q1r6W.pgp Description: PGP signature
Re: Apache2::SizeLimit Linux::Smaps on x86_64
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
On Sun, 07 Oct 2007 21:14:23 +0200 Clinton Gormley [EMAIL PROTECTED] 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. VMSIZE: 338044 kb RSS: 44856 kb total 44536 kb shared 0 kb private clean 320 kb private dirty PRIVATE MAPPINGS vmsize rss clean rss dirty file 40676 kb0 kb 180 kb 88 kb0 kb 28 kb [stack] 20 kb0 kb 16 kb 16 kb0 kb 12 kb /usr/sbin/httpd 8 kb0 kb8 kb /usr/lib64/libaprutil-1.so.0.2.7 12 kb0 kb8 kb 16 kb0 kb8 kb 4 kb0 kb4 kb /lib64/ld-2.5.so 8 kb0 kb4 kb 4 kb0 kb4 kb 4 kb0 kb4 kb /usr/lib64/libapr-1.so.0.2.7 4 kb0 kb4 kb /lib64/libpthread-2.5.so 16 kb0 kb4 kb 4 kb0 kb4 kb 4 kb0 kb4 kb /lib64/libc-2.5.so 8 kb0 kb4 kb /usr/lib64/httpd/modules/mod_log_config.so 8 kb0 kb4 kb /usr/lib64/httpd/modules/mod_status.so 8 kb0 kb4 kb /usr/lib64/httpd/modules/mod_rewrite.so 8 kb0 kb4 kb /usr/lib64/httpd/modules/mod_proxy.so 20 kb0 kb4 kb /usr/lib64/httpd/modules/mod_python.so 4 kb0 kb4 kb /lib64/libnss_files-2.5.so 12 kb0 kb4 kb SHARED MAPPINGS vmsize rss clean rss dirty file 40676 kb0 kb40172 kb 456 kb0 kb 452 kb 1296 kb 384 kb0 kb /lib64/libc-2.5.so 260 kb0 kb 256 kb 444 kb0 kb 216 kb /usr/lib64/httpd/modules/libphp5.so 308 kb 208 kb0 kb /usr/sbin/httpd 196 kb0 kb 196 kb 260 kb0 kb 188 kb 260 kb0 kb 188 kb 184 kb0 kb 160 kb /usr/lib64/libpython2.4.so.1.0 124 kb0 kb 124 kb /lib64/libcrypto.so.0.9.8b 152 kb 112 kb0 kb /usr/lib64/libapr-1.so.0.2.7 112 kb 68 kb0 kb /usr/lib64/libaprutil-1.so.0.2.7 84 kb 52 kb0 kb /lib64/libpthread-2.5.so 212 kb 52 kb0 kb /usr/lib64/httpd/modules/mod_perl.so 52 kb0 kb 48 kb 56 kb 44 kb0 kb /usr/lib64/httpd/modules/mod_rewrite.so 1196 kb 44 kb0 kb /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl 104 kb 40 kb0 kb /lib64/ld-2.5.so 64 kb 40 kb0 kb /usr/lib64/httpd/modules/mod_proxy.so 108 kb 36 kb0 kb /lib64/libpcre.so.0.0.1 36 kb0 kb 36 kb /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl 36 kb0 kb 36 kb /usr/lib64/libxml2.so.2.6.26 1024 kb 36 kb0 kb /usr/lib64/libpython2.4.so.1.0 32 kb0 kb 32 kb 88 kb0 kb 32 kb [stack] 28 kb0 kb 28 kb /usr/lib64/libaspell.so.15.1.3 156 kb 28 kb0 kb /usr/lib64/httpd/modules/mod_ssl.so 24 kb0 kb 24 kb /lib64/libssl.so.0.9.8b 24 kb0 kb 24 kb /usr/lib64/libstdc++.so.6.0.8 40 kb 24 kb0 kb /lib64/libnss_files-2.5.so 20 kb0 kb 20 kb /lib64/libdb-4.3.so 24 kb 20 kb0 kb /usr/lib64/httpd/modules/mod_auth_digest.so 24 kb 20 kb0 kb /usr/lib64/httpd/modules/mod_proxy_http.so 96 kb 20 kb0 kb /usr/lib64/httpd/modules/mod_python.so 16 kb0 kb 16 kb /lib64/libc-2.5.so 20 kb0 kb 16 kb 16 kb0 kb 16 kb /usr/lib64/libkrb5.so.3.2 16 kb0 kb 16 kb /usr/lib64/httpd/modules/mod_perl.so 20 kb0 kb 16 kb /usr/lib64/httpd/modules/mod_python.so 964 kb 12 kb0 kb /lib64/libdb-4.3.so 12 kb0 kb 12 kb /lib64/libexpat.so.0.5.0 20 kb 12 kb0 kb /usr/lib64/httpd/modules/mod_log_config.so 28 kb 12 kb0 kb /usr/lib64/httpd/modules/mod_negotiation.so 16 kb 12 kb0 kb
Re: Apache2::SizeLimit Linux::Smaps on x86_64
On Sun, 7 Oct 2007 14:29:30 -0700 Max Kanat-Alexander [EMAIL PROTECTED] 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. httpd-smaps.gz Description: GNU Zip compressed data
Re: Apache2::SizeLimit Linux::Smaps on x86_64
On Sat, 6 Oct 2007 00:39:42 -0400 Perrin Harkins [EMAIL PROTECTED] 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
On 10/6/07, Max Kanat-Alexander [EMAIL PROTECTED] 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
On 10/5/07, Max Kanat-Alexander [EMAIL PROTECTED] 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
