Hey Zed- I had a user with an app that was leaking memory with mongrel but not lighty/fcgi. I have been doing anything I can to track it down. I already did the Mutex patch to use unshitf and pop instead of shift and push and it didn''t really help much. The mem leak only really shows up when you use the wsess option to httperf. The other day I saw a ruby C extension that Mentalguy built called optimized_locking. It has an OptimizedMutex class that is written in C. Its actually pretty small amount of C code and fairly easy to understand. Anyway, long story short, I patch the latest mongrel trunk and added this optimized_locking.c in as another C extension that gets built when you make the gem. It has helped quite a bit with the mem leak and seems to have better performance then Sync. I''m not suggesting this is needed in core mongrel but I thought I would share with you anyway to see what you think. I am attaching a gem built from svn trunk mongrel with the new OptimizedMutex C extension built it. I only used the OptimizedMutex for the rails handler so thats all that is patched in this gem. Play around with it and let me know if you can tell the difference. I have been using the same OptimizedMutex in Merb and it hasn''t caused any issues yet. In fact it is measurably faster then the normal Mutex or Sync, even if only by a little. But it has pretty flatline memory consumption Installing the gem will build the optimized_locking c extension after it builds http11. Grab it here: http://brainspl.at/mongrel-c-mutex-0.3.14.gem.zip If anyone has any leaky apps and they want to try this out then please measure before and after and let me know the results. Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273)
On 11/8/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:> Hey Zed-[snip]> > The other day I saw a ruby C extension that Mentalguy built called > optimized_locking. It has an OptimizedMutex class that is written in > C. Its actually pretty small amount of C code and fairly easy to > understand. > > Anyway, long story short, I patch the latest mongrel trunk and added > this optimized_locking.c in as another C extension that gets built > when you make the gem. It has helped quite a bit with the mem leak > and seems to have better performance then Sync. I''m not suggesting > this is needed in core mongrel but I thought I would share with you > anyway to see what you think. I am attaching a gem built from svn > trunk mongrel with the new OptimizedMutex C extension built it. I > only used the OptimizedMutex for the rails handler so thats all that > is patched in this gem. Play around with it and let me know if you > can tell the difference. >That''s good, checked your code but build on win32 failed miserably.> I have been using the same OptimizedMutex in Merb and it hasn''t > caused any issues yet. In fact it is measurably faster then the > normal Mutex or Sync, even if only by a little. But it has pretty > flatline memory consumption >Because cannot get extension built, could you run this pastie against the new locking mechanism? http://pastie.caboo.se/10194 Thank you Ezra for your time, and thank you for pointing this info. Hope we could get it working on Win32 side too. (I''m getting illegal use of this type errors in WaitEntry *e)> > If anyone has any leaky apps and they want to try this out then > please measure before and after and let me know the results. > > Cheers- > -- Ezra Zygmuntowicz > -- Lead Rails Evangelist > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >-- Luis Lavena 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
On Nov 8, 2006, at 7:07 PM, Luis Lavena wrote:> On 11/8/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote: >> <snip> > > That''s good, checked your code but build on win32 failed miserably.Yeah at this point I hadn''t even considered windows yet. I am not much of a C coder so I don''t know if this optimized_locking extension will be able to work on windows.> > Because cannot get extension built, could you run this pastie against > the new locking mechanism? > > http://pastie.caboo.se/10194 > > Thank you Ezra for your time, and thank you for pointing this info. > Hope we could get it working on Win32 side too. (I''m getting illegal > use of this type errors in WaitEntry *e)> -- > Luis Lavena > Multimedia systemsHey Louis- How did you make the graph? I just ran the test and watched top while it ran. The memory fluctuated between 2Mb and 7.8Mb. And it cycled. As in it would grow to almost 8Mb and then drop back down to 2 and grow again. Thats what we are looking for in a good memory alooc/free pattern right? If you tell me how to make that graph I will run it again and make one so you can see. Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273)
On 11/9/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:> > On Nov 8, 2006, at 7:07 PM, Luis Lavena wrote: > > > On 11/8/06, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote: > >> <snip> > > > > That''s good, checked your code but build on win32 failed miserably. > > Yeah at this point I hadn''t even considered windows yet. I am not > much of a C coder so I don''t know if this optimized_locking extension > will be able to work on windows.Me neither, also was very tired to check the code in deep. I''ll contact mentalguy, but I guess the answer will be ''what, windows?'' :-P> > > > Because cannot get extension built, could you run this pastie against > > the new locking mechanism? > > > > http://pastie.caboo.se/10194 > > > > Thank you Ezra for your time, and thank you for pointing this info. > > Hope we could get it working on Win32 side too. (I''m getting illegal > > use of this type errors in WaitEntry *e) > > > -- > > Luis Lavena > > Multimedia systems > > Hey Louis- > > How did you make the graph? I just ran the test and watched top > while it ran. The memory fluctuated between 2Mb and 7.8Mb. And it > cycled. As in it would grow to almost 8Mb and then drop back down to > 2 and grow again. Thats what we are looking for in a good memory > alooc/free pattern right? If you tell me how to make that graph I > will run it again and make one so you can see. >I didn''t make it, was Zed. Guess the data was collected from ps or something... right Zed? Monitoring the memory used/allocation of the processes guess will be the idea. What I did was take a few screenshots of Process Explorer on Windows to proof Sync/Mutex differences: http://rubyforge.org/pipermail/mongrel-users/2006-August/001253.html> Cheers- > -- Ezra Zygmuntowicz > -- Lead Rails Evangelist > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >-- Luis Lavena 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
On 11/9/06, Luis Lavena <luislavena at gmail.com> wrote:> > Yeah at this point I hadn''t even considered windows yet. I am not > > much of a C coder so I don''t know if this optimized_locking extension > > will be able to work on windows. > > Me neither, also was very tired to check the code in deep. > > I''ll contact mentalguy, but I guess the answer will be ''what, windows?'' :-PI''ve been testing it with IOWA, too, and so far, so good. I do think it should be fine on Windows if built in an appropriate build environment. Kirk Haines
On 11/9/06, Kirk Haines <wyhaines at gmail.com> wrote:> On 11/9/06, Luis Lavena <luislavena at gmail.com> wrote: > > > > Yeah at this point I hadn''t even considered windows yet. I am not > > > much of a C coder so I don''t know if this optimized_locking extension > > > will be able to work on windows. > > > > Me neither, also was very tired to check the code in deep. > > > > I''ll contact mentalguy, but I guess the answer will be ''what, windows?'' :-P > > I''ve been testing it with IOWA, too, and so far, so good. I do think > it should be fine on Windows if built in an appropriate build > environment. >I could provide you with 2003 toolkit bundled with platform sdk headers & libs, the same env used to build mongrel on Windows. Drop me a line (off the list) and I will sent you a link (due licenses I cannot put it in public). -- Luis Lavena 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
On Thu, 9 Nov 2006 09:23:23 -0700 "Kirk Haines" <wyhaines at gmail.com> wrote:> On 11/9/06, Luis Lavena <luislavena at gmail.com> wrote: > > > > Yeah at this point I hadn''t even considered windows yet. I am not > > > much of a C coder so I don''t know if this optimized_locking extension > > > will be able to work on windows. > > > > Me neither, also was very tired to check the code in deep. > > > > I''ll contact mentalguy, but I guess the answer will be ''what, windows?'' :-P > > I''ve been testing it with IOWA, too, and so far, so good. I do think > it should be fine on Windows if built in an appropriate build > environment. >I''ve got it in the Mongrel code and it all tests out. I think part of the build problems come from mentalguy''s use of k&r and c99 semantics in the same code. GCC can probably handle it but I''m guessing lame as vc2003 can''t. I''ll do some work to get it working on win32 and see about a release. If this works, I''d love to just make it compatible with Mutex and rip that damn thing out. What do you think Kirk? -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://www.awprofessional.com/title/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.