Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
    • Bummer, smem wants 2.6.27+ but Ubuntu LTS, the server distro, is only at 2.6.24. In theory, the 10.4 Ubuntu release will be the next LTS update and my opportunity to use smem.

  • I found the old mod_perl guide informative on this topic:

    http://perl.apache.org/docs/1.0/guide/performance.html#How_Shared_Is_My_Memory_ [apache.org]

    One thing I've long wondered about is the effect of reference counting on memory sharing. Does all the incrementing and decrementing of refcounts unshare the entire page the object is on? Can anything be done about this, either within Perl or below?

    • Does all the incrementing and decrementing of refcounts unshare the entire page the object is on?

      I can't imagine how it wouldn't.

      Can anything be done about this, either within Perl or below?

      The standard trick in GCs is to move the fields used to track liveness from the objects themselves into a special-purpose structure which tracks multiple objects. The corresponding memory pages get unshared, but the number of pages modified is far fewer.

      This also improves cache behavior during GC operations.

    • Funny you should ask... The chart http://diotalevi.isa-geek.net/~josh/090909/memory-0.png [isa-geek.net] from http://use.perl.org/~jjore/journal/39604 [perl.org] shows that at least in that sample program, all the reference counts are tightly clustered. You can write off those pages as unshared *but* you can also likely reasonably expect they aren't taking other pages with them.

  • Have you tried Linux::Smaps? [cpan.org]

    From the CPAN description: "The /proc/PID/smaps files in modern linuxes provides very detailed information about a processes memory consumption. It particularly includes a way to estimate the effect of copy-on-write. This module implements a Perl interface."

    • I'd recalled /proc/#/smaps also wasn't available on the 2.6.10. Taking a quick look at Linux::Smaps, it appears I can consume text of the format:

      00602000-00c39000 rw-p 00602000 00:00 0                                  [heap]
      Size:               6364 kB
      Rss:                6340 kB
      Shared_Clean:          0 kB
      Shared_Dirty:

      • But for practical purposes of controlling apache process growth, just counting the private memory is the right thing to do (or counting all the root process's memory + just private from the kids to get a reasonable total.)

        I'm curious to know just what you are seeing shared in apache children that isn't copy-on-write memory?