DamageControl and resource use

[Are Vattekar]

We use DamageControl v.03, and after 800 builds the ruby process uses approx.
100% cpu and 1GB of memory.
Are there any files we can delete to prevent DamageControl from getting this
slow?

Are

[Aslak Hellesoy]

You're using a very old version. Have you tried to upgrade to the
latest version?

See http://hieraki.lavalamp.ca/ for details.

Aslak

On 11/30/05, Are Vattekar <are@...> wrote:
> We use DamageControl v.03, and after 800 builds the ruby process uses approx.
> 100% cpu and 1GB of memory.
> Are there any files we can delete to prevent DamageControl from getting this
> slow?
>
> Are
>
>

[Are Vattekar]

On Wednesday 30 November 2005 17:25, aslak hellesoy wrote:
> You're using a very old version. Have you tried to upgrade to the
> latest version?
>
I've tried to upgrade to the latest version from Subversion. It crashed when I
tried to access it at localhost:3000 with this error message:

http://localhost:3000/project/new -> /images/project/browser.png
deadlock 0x2a98726990: sleep:T(1133429886.420858)  
- /usr/local/lib/ruby/1.8/timeout.rb:41
deadlock 0x2a98697a60: run:-/usr/local/lib/ruby/1.8/webrick/httpserver.rb:51:
[BUG] Segmentation fault
ruby 1.8.2 (2004-12-25) [x86_64-linux]

This was fixed when I upgraded to ruby 1.8.3.

So far so good. But when I kill the ruby 'ruby init.rb' process it hangs the
machine for a couple of minutes. It looks like the process tries to use a
wast amount of memory and swap, 1GB mem and 4GB swap, before it dies. Is this
normal?

Are

> See http://hieraki.lavalamp.ca/ for details.
>
> Aslak
>
> On 11/30/05, Are Vattekar <are@...> wrote:
> > We use DamageControl v.03, and after 800 builds the ruby process uses
> > approx. 100% cpu and 1GB of memory.
> > Are there any files we can delete to prevent DamageControl from getting
> > this slow?
> >
> > Are

[Aslak Hellesoy]

On 12/1/05, Are Vattekar <are@...> wrote:

> On Wednesday 30 November 2005 17:25, aslak hellesoy wrote:
> > You're using a very old version. Have you tried to upgrade to the
> > latest version?
> >
> I've tried to upgrade to the latest version from Subversion. It crashed when I
> tried to access it at localhost:3000 with this error message:
>
> http://localhost:3000/project/new -> /images/project/browser.png
> deadlock 0x2a98726990: sleep:T(1133429886.420858)
> - /usr/local/lib/ruby/1.8/timeout.rb:41
> deadlock 0x2a98697a60: run:-/usr/local/lib/ruby/1.8/webrick/httpserver.rb:51:
> [BUG] Segmentation fault
> ruby 1.8.2 (2004-12-25) [x86_64-linux]
>

I've never seen WEBrick segfaulting, but then again, I develop mostly
on OSX and Win32

> This was fixed when I upgraded to ruby 1.8.3.
>

Good. Sounds more like a WEBrick problem than DC

> So far so good. But when I kill the ruby 'ruby init.rb' process it hangs the
> machine for a couple of minutes. It looks like the process tries to use a
> wast amount of memory and swap, 1GB mem and 4GB swap, before it dies. Is this
> normal?
>

Absolutely not :-/

I would recommend not using the init.rb script (which is a wrapper for
script/server and script/builder. Instead, try:

ruby script/server --environment=production
ruby script/builder --environment=production --id=1

(I don't think I've got the forking right in init.rb)

If you do this, does it still consume a lot of memory? If so, how much
for each process?

If you still see memory problems, try to run with lighttpd instead. I
have heard that WEBrick is quite leaky. You'll have to install fcgi
and lighttpd for that. (Rails' script/server tries lighttpd first and
falls back to WEBrick if lighty/fcgi isn't installed).

Of course, it might be that you've discovered some memory leaks
somewhere else. If that's the case, I'll have to investigate more.

Thanks for trying out DamageControl!

Cheers,
Aslak

> Are
>
> > See http://hieraki.lavalamp.ca/ for details.
> >
> > Aslak
> >
> > On 11/30/05, Are Vattekar <are@...> wrote:
> > > We use DamageControl v.03, and after 800 builds the ruby process uses
> > > approx. 100% cpu and 1GB of memory.
> > > Are there any files we can delete to prevent DamageControl from getting
> > > this slow?
> > >
> > > Are
>
>