Backgroundrb devel - Apr 2008 - Cutting down BackgrounDRb memory issue

Hi Folks,

I have been working to fix BackgrounDRb memory usage as such. Ruby1.8 GC
isn''t fork friendly and it seems to use a lot of memory because when
you
fork, it sets a bit in all the objects in global scope which causes OS
to all pages in child process.

A classic solution is to use fork and exec, rather than just fork. Its
working and pretty stable, but you loose ability to pass complex
arguments when invoking MiddleMan.new_worker, because essentially I can
only pass arguments in form of strings when using exec.

This help significantly in improving stability of BackgrounDRb and code
written on top of packet. So what you guys think? Shall we go for this
change?

On Fri, Apr 11, 2008 at 8:22 PM, hemant kumar <gethemant at gmail.com>
wrote:
>
>  A classic solution is to use fork and exec, rather than just fork. Its
>  working and pretty stable, but you loose ability to pass complex
>  arguments when invoking MiddleMan.new_worker, because essentially I can
>  only pass arguments in form of strings when using exec.
Is that really a problem?

irb(main):001:0> a = [{:key=>''value'',''another
one''=>''something''}, 3,
56, "foobar"]
=> [{"another one"=>"something",
:key=>"value"}, 3, 56, "foobar"]
irb(main):002:0> s = Marshal.dump(a)
=> "\004\b[\t{\a\"\020another
one\"\016something:\bkey\"\nvaluei\bi=\"\vfoobar"
irb(main):003:0> b = Marshal.load(s)
=> [{"another one"=>"something",
:key=>"value"}, 3, 56, "foobar"]
irb(main):004:0> a == b
=> true
>  This help significantly in improving stability of BackgrounDRb and code
>  written on top of packet. So what you guys think? Shall we go for this
>  change?
It sounds good to me. Anything that helps stability and improves
memory usage will always get my vote.

Regards,
Ryan

>
> >  This help significantly in improving stability of BackgrounDRb and
code
> >  written on top of packet. So what you guys think? Shall we go for
this
> >  change?
>
> It sounds good to me. Anything that helps stability and improves
> memory usage will always get my vote.

I agree.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080413/1d589f50/attachment.html

On Fri, 2008-04-11 at 20:54 -0400, Ryan Leavengood
wrote:
> On Fri, Apr 11, 2008 at 8:22 PM, hemant kumar <gethemant at
gmail.com> wrote:
> >
> >  A classic solution is to use fork and exec, rather than just fork.
Its
> >  working and pretty stable, but you loose ability to pass complex
> >  arguments when invoking MiddleMan.new_worker, because essentially I
can
> >  only pass arguments in form of strings when using exec.
> 
> Is that really a problem?
> 
> irb(main):001:0> a =
[{:key=>''value'',''another
one''=>''something''}, 3,
> 56, "foobar"]
> => [{"another one"=>"something",
:key=>"value"}, 3, 56, "foobar"]
> irb(main):002:0> s = Marshal.dump(a)
> => "\004\b[\t{\a\"\020another
one\"\016something:\bkey\"\nvaluei\bi=\"\vfoobar"
> irb(main):003:0> b = Marshal.load(s)
> => [{"another one"=>"something",
:key=>"value"}, 3, 56, "foobar"]
> irb(main):004:0> a == b
> => true
Nevermind, that wasn''t a problem at all. As a simple fix, I am avoiding
passing anything other than file descriptors as command line argument
and before forking and execing the process, I am writing worker_options
to write end of master process. Seems to be working well.

Something like this:

require "socket"

def enable_nonblock io
  f = io.fcntl(Fcntl::F_GETFL,0)
  io.fcntl(Fcntl::F_SETFL,Fcntl::O_NONBLOCK | f)
end


master_read_end,worker_write_end = UNIXSocket.pair(Socket::SOCK_STREAM)

worker_read_end,master_write_end = UNIXSocket.pair(Socket::SOCK_STREAM)

master_write_end.puts "Hello from parent"

if(!(pid = fork))
  [master_write_end,master_read_end].each { |x| x.close }
  [worker_read_end,worker_write_end].each {  |x| enable_nonblock(x) }
 
exec("bar.rb","#{worker_read_end.fileno}:#{worker_write_end.fileno}")
end

[master_write_end,master_read_end].each { |x| enable_nonblock(x) }
p pid

worker_read_end.close
worker_write_end.close

a = master_read_end.gets
puts a

On Sun, 2008-04-13 at 16:41 -0700, Paul Kmiec wrote:
>         >  This help significantly in improving stability of
>         BackgrounDRb and code
>         >  written on top of packet. So what you guys think? Shall we
>         go for this
>         >  change?
>         
>         It sounds good to me. Anything that helps stability and
>         improves
>         memory usage will always get my vote.
> 
> I agree. 
> 
> Paul 
Okay folks, 

I have updated git repo of just packet with latest changes wherein 
I have removed fork in favour of fork and exec:

http://github.com/gnufied/packet/tree/master

The only catch is, now we need some kinda runner to run our workers 
since exec takes argument in form of string only. For example:

 exec "packet_worker_runner
##{t_worker_name}:{worker_read_end.fileno}:#{worker_write_end.fileno}:#{option_dump_length}"

One option we have is to have "packet_worker_runner" as installed
executable when user installs packet gem.

Any other ideas?

> One option we have is to have "packet_worker_runner" as installed
executable when user installs packet gem.

The more I think about the idea of a packet runner, the more I like it.

One reason I like it: it solves a problem with the Windows port I wrote. The
Windows implementation needs to know what process to launch to create a new
worker. It currently relaunches PACKET_APP, but I was concerned that might
be a misuse of PACKET_APP and it forces the author of a PACKET_APP to
implement code like what I wrote in script/backgroundrb to handle a "worker
parameter. If there''s a separate app whose only purpose in life is to
be the
runner, no one else has to write code to handle those parameters.

- Brian

On Sun, Apr 13, 2008 at 6:53 PM, hemant kumar <gethemant at gmail.com>
wrote:
>
> On Sun, 2008-04-13 at 16:41 -0700, Paul Kmiec wrote:
> >         >  This help significantly in improving stability of
> >         BackgrounDRb and code
> >         >  written on top of packet. So what you guys think? Shall
we
> >         go for this
> >         >  change?
> >
> >         It sounds good to me. Anything that helps stability and
> >         improves
> >         memory usage will always get my vote.
> >
> > I agree.
> >
> > Paul
>
> Okay folks,
>
> I have updated git repo of just packet with latest changes wherein
> I have removed fork in favour of fork and exec:
>
> http://github.com/gnufied/packet/tree/master
>
> The only catch is, now we need some kinda runner to run our workers
> since exec takes argument in form of string only. For example:
>
>  exec "packet_worker_runner
>
##{t_worker_name}:{worker_read_end.fileno}:#{worker_write_end.fileno}:#{option_dump_length}"
>
> One option we have is to have "packet_worker_runner" as installed
> executable when user installs packet gem.
>
> Any other ideas?
>
>
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>


-- 
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080415/873e2d17/attachment.html

On Tue, Apr 15, 2008 at 10:59 PM, Brian Morearty <brian at morearty.org>
wrote:
>
> > One option we have is to have "packet_worker_runner" as
installed
> executable when user installs packet gem.
>
> The more I think about the idea of a packet runner, the more I like it.
>
> One reason I like it: it solves a problem with the Windows port I wrote.
The
> Windows implementation needs to know what process to launch to create a new
> worker. It currently relaunches PACKET_APP, but I was concerned that might
> be a misuse of PACKET_APP and it forces the author of a PACKET_APP to
> implement code like what I wrote in script/backgroundrb to handle a
"worker
> parameter. If there''s a separate app whose only purpose in life is
to be the
> runner, no one else has to write code to handle those parameters.
>
Brian,

Just a quick update. I have updated both BackgrounDRb and packet with
new changes of fork, exec and runner binaries.I will start merging
your changes and making it run on Windows sometime tomorrow.
Also, this is our opportunity to have 100% test case coverage of
BackgrounDRb. If you can be online on IRC tomorrow, it will be
awesome. Time is around 19th April, 18.23 UTC.