Message from discussion
God's memory leak - a scientific treatment
MIME-Version: 1.0
Message-ID: <68c6cc16-d7d2-49c6-bc02-7f6ccb6accbf@d70g2000hsb.googlegroups.com>
Date: Wed, 13 Feb 2008 17:00:39 -0800 (PST)
Received: by 10.100.168.18 with SMTP id q18mr1197722ane.12.1202950839394; Wed,
13 Feb 2008 17:00:39 -0800 (PST)
In-Reply-To: <0e904c2f-6a80-4a8d-9b33-e0b81e6bfb51@d4g2000prg.googlegroups.com>
X-IP: 208.84.6.212
References: <0e904c2f-6a80-4a8d-9b33-e0b81e6bfb51@d4g2000prg.googlegroups.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en)
AppleWebKit/523.12.2 (KHTML, like Gecko) Version/3.0.4 Safari/523.12.2,gzip(gfe),gzip(gfe)
Subject: Re: God's memory leak - a scientific treatment
From: Tom Werner <mojo...@gmail.com>
To: "god.rb" <god-rb@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
I know that the memory leak isn't caused by leaking Ruby objects and I
know that a basic looping Ruby program does not leak memory. There
must, then, be some part of the code that causes Ruby to leak memory
internally. Since the memory leak seems to be related to how
frequently the driver loop executes, I hypothesize that most or all of
the memory leak is contained within the driver loop handlers.
Experiment B
In this experiment I will disable the handler part of the driver loop,
instead rescheduling the condition immediately. The code for this test
can be found at
https://github.com/mojombo/god/tree/f59621c270c5d804ff362c152823946d6942e07c
The specific change is hilighted at
https://github.com/mojombo/god/tree/f59621c270c5d804ff362c152823946d6942e07c/lib/god/driver.rb#L73-75
For these memory leak tests, I will consider god NOT leaking if it
does not vary significantly from the startup memory usage after 10,000
seconds. Here are the test results:
memory in kb (second)
---------------------------------
7604 (1)
7604 (2)
7604 (3)
7604 (4)
7604 (5)
...
7588 (9996)
7588 (9997)
7588 (9998)
7588 (9999)
7588 (10000)
This is running under ruby 1.8.5 (2006-12-25 patchlevel 12) [i686-
darwin8.9.1].
I conclude that the memory leak is caused by code within the driver
handlers. Some Ruby call or calls must be leaking memory within that
code. Isolating the offending code should hopefully allow me to work
|
