On Tue, Mar 29, 2011 at 18:52, Torsten Förtsch wrote:
> Meanwhile Ævar uploaded his own quite specialized smaps parser
> (Linux::Smaps::Tiny) to CPAN. Here is what I get in comparison:
>
> perl -Ilib -MLinux::Smaps -MLinux::Smaps::Tiny \
> -MBenchmark=:all,:hireswallclock -
Hi,
after having been told by Ævar that Linux::Smaps is really slow I tuned it a
bit. Here is what I get. "new" is version 0.07, "old" is 0.06:
perl -MBenchmark=:all,:hireswallclock -MData::Dumper -e '
sub tm {
my ($title)=@_;
if( my $pid=open my $fh, "-|
che/SizeLimit/Core.pm
> ===
> --- lib/Apache/SizeLimit/Core.pm (revision 905815)
> +++ lib/Apache/SizeLimit/Core.pm (working copy)
> @@ -175,7 +175,7 @@
> return $class->_linux_size_check() unless $USE_SMAPS;
>
> my $s = Linux:
che/SizeLimit/Core.pm(working copy)
@@ -175,7 +175,7 @@
return $class->_linux_size_check() unless $USE_SMAPS;
my $s = Linux::Smaps->new($$)->all;
-return ($s->size, $s->shared_clean + $s->shared_dirty);
+return ($s->rss, $s->shared_clean +
So, I just recently installed the very latest release of SizeLimit, and
this is still a problem. SizeLimit **definitely** returns the wrong
unshared size for processes on any modern Linux system.
-Max
On 02/03/2010 12:05 PM, Max Kanat-Alexander wrote:
> On 02/03/2010 04:57 AM, Tor
On 02/03/2010 04:57 AM, Torsten Förtsch wrote:
> Well, I tend to disagree. (Fred, Adam please read on.)
Okay. Have you looked at the actual output of test.cgi?
Here's an example of these values just on my local machine, for my bash
interpreter:
[mka...@es-compy ~]$ cat /proc/self
>size on the Linux::Smaps object, when instead it should be returning
> $s->rss as the process size.
>
Well, I tend to disagree. (Fred, Adam please read on.)
The /proc/PID/statm based check returns the fields 0 and 2. According to the
following table from KERNEL/Documentation/filesys
PM, Max Kanat-Alexander wrote:
> All of my processes kept exiting with a report that they had a 300M
> unshared size, which was clearly untrue, even from looking at top. After
> some investigation, I discovered that Apache2::SizeLimit was calling
> $s->size on the Linux::Sma
All of my processes kept exiting with a report that they had a 300M
unshared size, which was clearly untrue, even from looking at top. After
some investigation, I discovered that Apache2::SizeLimit was calling
$s->size on the Linux::Smaps object, when instead it should be returning
$s-&
On Wed 22 Jul 2009, Jonathan Swartz wrote:
> I'm running into the problem using Linux::Smaps on RHEL with an
> Apache server on port 80. Namely, that the httpd child doesn't have
> permissions to look at the smaps file.
>
> Linux::Smaps: Cannot open /proc/20074
g the
setuid bit to force the auditing process to run under the user owning the maps.
Good luck
Hans
- "Jonathan Swartz" escribió:
> I'm running into the problem using Linux::Smaps on RHEL with an Apachee
>
> server on port 80. Namely, that the httpd child doesn'
I'm running into the problem using Linux::Smaps on RHEL with an Apache
server on port 80. Namely, that the httpd child doesn't have
permissions to look at the smaps file.
Linux::Smaps: Cannot open /proc/20074/smaps: Permission denied
or
Linux::Smaps: Cannot open /proc/
Torsten,
many thanks for the time taken for the explanation.
I still understand only slightly less than 50% of it, but then I don't
really need to understand more either. I am just very glad and thankful
that there are people such as you who apparently do understand it, upon
which we can rel
On Tue 03 Jun 2008, André Warnier wrote:
> I find it interesting that the answers are all different on system (1),
> but all the same on system (2).
> I don't have a clue as to what it means, or what it does to my systems,
> but I trust you do.
Just to enlighten you. Originally linux on x86 used t
Torsten Foertsch wrote:
On Tue 03 Jun 2008, Torsten Foertsch wrote:
[...]
Thanks to all so far. But could you please try that command for PERLIO=perlio
and perhaps PERLIO=unix too?
Here you go.
I find it interesting that the answers are all different on system (1),
but all the same on sy
Torsten Foertsch wrote:
> It should print 2 almost identical lines. If there are more please report.
Perl 5.8.8 and Linux 2.6.20 only prints 2.
--
Michael Peters
Plus Three, LP
On Tue 03 Jun 2008, Torsten Foertsch wrote:
> Could you please run the following command on various combinations of linux
> kernel and perlio?
>
> PERLIO="stdio" perl -pe 'BEGIN {my $smaps="/proc/$$/smaps";
> open STDIN, "<", $smaps or die "$!\n"; system "cat -n $smaps"}
> $_="$.\t$_"' | grep v
x27;
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP THREADS_HAVE_PIDS USE_64_BIT_ALL
USE_
Hi,
I have recently got a bug report about Linux::Smaps. The poster said it'd
report 2 [vdso] areas and that it can be cured if /proc/self/smaps is opened
with '<:stdio'. Later on he also found the behavior depends on the kernel
version, 2.6.25.3 shows 2 vdsos 2.6.23.1-21 only o
On Mon, 8 Oct 2007 17:52:46 +0200 Torsten Foertsch
<[EMAIL PROTECTED]> wrote:
> this version mainly disables the portable warning. Further the
> constructor now throws an exception if the smaps file cannot be read.
> Also a short note in the docs about swapped pages and mlockall(2) was
> added.
Linux-Smaps-0.04.tar.gz
has entered CPAN as
file: $CPAN/authors/id/O/OP/OPI/Linux-Smaps-0.04.tar.gz
size: 22163 bytes
md5: 20faeb2df7ccbd2931222e97e7bc7e0e
...
---
pgpj7Q458jVjF.pgp
Description: PGP signature
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.
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 inves
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::upda
b64/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&
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
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
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/
Compe
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
> 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 b
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 64bi
(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
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
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
> Linu
a 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_UNSHARE
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
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
On Wednesday 07 September 2005 04:25, Philip M. Gollucci wrote:
> Torsten Foertsch wrote:
> > Hi,
> >
> > this patch introduces $Apache2::SizeLimit::USE_SMAPS which is 1 by
> > default. If /proc/PID/smaps are not available Apache::SizeLimit resets it
> > to 0 itself. It can be reset by the user if
Torsten Foertsch wrote:
Hi,
this patch introduces $Apache2::SizeLimit::USE_SMAPS which is 1 by default.
If /proc/PID/smaps are not available Apache::SizeLimit resets it to 0 itself.
It can be reset by the user if he prefers using /proc/PID/statm before the
first size check.
If $USE_SMAPS is
Torsten Foertsch wrote:
Hi,
this patch introduces $Apache2::SizeLimit::USE_SMAPS which is 1 by default.
If /proc/PID/smaps are not available Apache::SizeLimit resets it to 0 itself.
It can be reset by the user if he prefers using /proc/PID/statm before the
first size check.
If $USE_SMAPS is
= 0;
our $MAX_UNSHARED_SIZE = 0;
+our $USE_SMAPS = 1;
our ($HOW_BIG_IS_IT, $START_TIME);
@@ -56,7 +57,12 @@
} elsif (LINUX) {
-$HOW_BIG_IS_IT = \&linux_size_check;
+if ( eval { require Linux::Smaps } and Linux::Smaps->new($$) ) {
+ $HOW_BI
41 matches
Mail list logo
