Comments on: Saving memory in Ruby on Rails with fork() and copy-on-write

By: bandsxbands

bandsxbands — Wed, 03 Mar 2010 08:48:01 +0000

Virtual Memory sure is becoming cheaper and cheaper and cheaper. I’m curious as to when we will eventually reach the ratio of 1c to 1 Gigabyte.I’m quietly waiting for the day when I will finally be able to afford a 20 TB hard disk, hahaha. But for now I guess I will be satisfied with having a 32 GB Micro SD Card in my R4i.(Submitted from FFBrows for R4i Nintendo DS.)

By: Hongli

Hongli — Mon, 10 Dec 2007 21:35:48 +0000

Ben Knight: Yes. Actually I’ve already solved it. Please click on the “Optimizing Rails” category for more recent posts on this subject.

I’m not sure whether JRuby will solve the problem. Java is a memory hog on its own, and Ruby on Rails is not thread-safe so RoR on JRuby will not use threads (I think).

By: Ben Knight

Ben Knight — Mon, 10 Dec 2007 14:28:54 +0000

Are there any good solutions to this problem? I’m facing this problem currently.

Is JRuby a good workaround to this problem since it uses threads to service multiple HTTP requests?

By: Hongli

Hongli — Fri, 12 Oct 2007 09:13:37 +0000

Yes, I discovered that later. That’s what my garbage collector blog posts are devoted on.

By: Dan42

Dan42 — Fri, 12 Oct 2007 01:19:18 +0000

I think there’s one little problem with this picture: when the garbage collector runs, ALL memory pages are touched. In other words, copy-on-write offers memory savings only until the first run of the garbage collector. For long-running processes, there will be no memory savings (well, except for static libraries maybe). Forking does help to reduce startup time but IMHO your memory measurements are flawed.

By: Matt

Matt — Wed, 19 Sep 2007 18:36:42 +0000

Something like the following will prevent AR in the child from sharing the connection with the parent, so that one of the processes closing it doesn’t break the other.

dbconfig = ActiveRecord::Base.remove_connection
pid = fork do
begin
ActiveRecord::Base.establish_connection(dbconfig)
ensure
ActiveRecord::Base.remove_connection
end
end
ActiveRecord::Base.establish_connection(dbconfig)

By: Hongli

Hongli — Thu, 06 Sep 2007 13:50:20 +0000

Eh, mr “asdf”, if I’m so dumb and you’re so smart then why don’t you teach me how to gauge memory the right way, oh great l33t master?

Secondly, why is this “junk science”? I posted the entire process in a verifiable way. Anybody can review the process and point out mistakes. Isn’t this the entire point of the scientific method?

And why are you posting anonymously anyway? If you have constructive criticism you shouldn’t have anything to fear. You do realize that you’re undermining your credibility by posting anonymously, don’t you?

By: asdf

asdf — Thu, 06 Sep 2007 00:11:10 +0000

Linux NOOB,

try using ps to gauge your mongrel memory consumption…using free..what a joke…stupid linux NOOB

Your blog page is 100% junk science…way to add to the lies and misinformation

By: 赖洪礼的 blog » Saving memory in Ruby on Rails with fork() - failed

赖洪礼的 blog » Saving memory in Ruby on Rails with fork() - failed — Mon, 23 Jul 2007 09:50:46 +0000

[...] been working on mongrel_light_cluster, an extension for mongrel_cluster which automatically uses copy-on-write semantics to save memory in Ruby on Rails applications. The initial measurements were exciting – one can [...]

By: Florian Frank

Florian Frank — Thu, 24 May 2007 10:11:06 +0000

@Hongli:
> This suggests that the problem is likely to be caused by an exit handler – when the child process calls exit the exit handler does things which screws up the database connection. Ruby doesn’t seem to have a way to call _exit() to bypass exit handlers.

Actually you can bypass exit handlers in Ruby, if you call the exit! (with bang) method.