Deciphering objects.log

Server Mongrel
1

Howdy – I’ve been tracking down mem leaks (oh, the fun…), and I think
there is a clue in objects.log. There are a few mentions of this file,
but
usually Zed saying “look at this file and it will help you”. Can anyone
clue
me in to what the actual columns mean?

18,Float,143952,256821,112869,
18,String,39543,41693,2150,24.727076,55.526376,2308.000000
18,Array,3014,4232,1218,4.445888,23.633335,612.000000
18,Proc,1699,1750,51,
18,Regexp,1300,1310,10,
18,Hash,691,730,39,8.008219,36.218131,519.000000
18,Time,134,168,34,
18,YAML::Syck::Scalar,60,108,48,
18,Mongrel::Stats,44,57,13,
18,MatchData,14,24,10,1.416667,1.138904,5.000000
18,StringIO,9,12,3,166.833333,178.322401,408.000000
19,Float,256821,107916,-148905,
19,String,41693,39700,-1993,23.864257,52.626340,2308.000000
19,Array,4232,3086,-1146,5.254051,27.529250,612.000000
19,Proc,1750,1697,-53,
19,Regexp,1310,1298,-12,
19,Hash,730,702,-28,8.056980,36.770207,519.000000
19,Time,168,122,-46,
19,YAML::Syck::Scalar,108,46,-62,
19,Mongrel::Stats,57,31,-26,
19,MatchData,24,12,-12,1.333333,1.154701,5.000000

TIA,
Carlos

2

I RTFCd and got this:

$objects_out.puts

“run,classname,last,count,delta,lenmean,lensd,lenmax”

So,
run: a serial number of the request
classname: obvious
last: number of object from previous run
count: number of objects in this run
delta: last - count
lenmean: average length of object
lensd: std deviation
lenmax: largest-seen (or maybe largest-existing?) object of this class

Right?

3

On Fri, 12 Oct 2007 11:39:20 -0700
Carlos [email protected] wrote:

lenmean: average length of object
lensd: std deviation
lenmax: largest-seen (or maybe largest-existing?) object of this class

Right?

Yep, except len(mean|sd|max) are used for objects that report a length,
and that header should be created if the file is first created. You
must have truncated it at some point.

How you use this file is you run a sequential number of hits and do it
in production mode. When it’s done you load it into a spreadsheet or
R or some Ruby and you look for the following:

  1. Any class which seems to have a count who’s delta mean isn’t close to
    0 for all runs. A leak can actually be defined in a GC language as: any
    class who’s object count delta over time do not have a mean of 0.
  2. Any class who’s average length or sd.dev length is gigantic
    (send_file anyone?).
  3. Any classes who have a mean of 0, but have a sd.dev that’s massive.
    This shows poor GC management since it’s a huge number of object being
    created and destroyed.
  4. Any other column that for any class seems to be not like the others.

Also look at bleakhouse.

–
Zed A. Shaw

4

Bleakhouse isn’t as detailed as it could be, but it’s better than
using Objectspace.

Zed, do you think we should remove the object.log? My guess is that it
leads people astray as much as it helps.

Ara Howard has some good ideas in his leak checker “Dike”, but again,
it uses Objectspace.

Evan

5

On 10/13/07, Evan W. [email protected] wrote:

Bleakhouse isn’t as detailed as it could be, but it’s better than
using Objectspace.

Zed, do you think we should remove the object.log? My guess is that it
leads people astray as much as it helps.

Ara Howard has some good ideas in his leak checker “Dike”, but again,
it uses Objectspace.

Objectspace is like Heisenberg principle [1], you cannot touch it
without altering the results.

Maybe Dike and Bleak could merge and get something more powerful? :wink:

[1] Uncertainty principle - Wikipedia

–
Luis L.
Multimedia systems

Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

6

On Fri, 12 Oct 2007 23:52:24 -0400
“Evan W.” [email protected] wrote:

Zed, do you think we should remove the object.log? My guess is that it
leads people astray as much as it helps.

I don’t hear anyone complaining it leads them astray. I’ve used it to
find plenty of leaks.

If you could improve it that’d be better than just removing it.

–
Zed A. Shaw