You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: john[at]mckerrell.net [Submitted to the original trac issue database at 8.03am, Tuesday, 8th May 2007]
As a possible fix for the current resource problems we need to tell the FCGI processes to quite after N requests have been served. This most likely involves adding a counter to dispatch.fgi and calling exit! when the limit is reached, which should result in fcgi starting a new process to take the old one's place. IRC discussion about this follows:
08:59 < mcknut> http://weblog.textdrive.com/article/175/rails-optimizing-resource-usage[[BR]]
08:59 < SteveC> yeah we're not in development mode[[BR]]
08:59 < SteveC> next[[BR]]
08:59 < SteveC> :-)[[BR]]
08:59 < mcknut> oh, you turned that off?[[BR]]
08:59 < SteveC> yeah to see if it was better. it was but not good enough[[BR]]
08:59 < mcknut> ah[[BR]]
08:59 < LA2> Steve, if this is essentially fcgi, do you have a way to return a response and then kill the process?[[BR]]
09:00 < SteveC> that was my next option, you can periodically graceful the processes[[BR]]
09:00 < SteveC> but they get so much traffic they dont seem to pause long enough to get gracefulled so I have to kill them, which loses the process queue[[BR]]
09:01 < mcknut> "put a counter in the CGI wrapper, if you reach the count service the current request then exit"[[BR]]
09:01 < mcknut> dispatch.fcgi most likely, apparently[[BR]]
09:01 < SteveC> makes sense[[BR]]
09:01 < SteveC> then have fcgi auto-reload on crash[[BR]]
09:01 < LA2> in classic Perl fcgi, your script implements the main loop itself, so you can write out the response to this query, and then say "die" to kill any memory leaks, rather than taking the next turn in the loop (fetching the next request)[[BR]]
09:01 < mcknut> yeah, which apparently it does[[BR]]
09:02 < mcknut> (auto-reloading)[[BR]]
09:02 < SteveC> I could auto-die after 500 map requests or something[[BR]]
09:02 < LA2> or after the process eats X megs of memory[[BR]]
09:03 < SteveC> does someone fancy summarising this as a ticket as I have to get ready for a flight? I think at least nickb will take a look[[BR]]
09:04 < SteveC> should be as simple as[[BR]]
09:04 < SteveC> COUNT = 0[[BR]]
09:04 < SteveC> in environment.rb[[BR]]
09:04 < SteveC> COUNT += 1[[BR]]
09:04 < SteveC> if COUNT > 500[[BR]]
09:04 < SteveC> exit[[BR]]
09:04 < SteveC> end[[BR]]
09:04 < SteveC> in the map call handler[[BR]]
09:04 < mcknut> ok, I'll do it[[BR]]
09:04 < SteveC> or[[BR]]
09:04 < SteveC> exit![[BR]]
09:04 < SteveC> not exit[[BR]]
09:04 < SteveC> then just test it works like it says it should[[BR]]
09:05 < SteveC> and I'll deploy[[BR]]
09:05 < mcknut> I'll make a ticket and ping nick[[BR]]
The text was updated successfully, but these errors were encountered:
Reporter: john[at]mckerrell.net
[Submitted to the original trac issue database at 8.03am, Tuesday, 8th May 2007]
As a possible fix for the current resource problems we need to tell the FCGI processes to quite after N requests have been served. This most likely involves adding a counter to dispatch.fgi and calling exit! when the limit is reached, which should result in fcgi starting a new process to take the old one's place. IRC discussion about this follows:
08:59 < mcknut> http://weblog.textdrive.com/article/175/rails-optimizing-resource-usage[[BR]]
08:59 < SteveC> yeah we're not in development mode[[BR]]
08:59 < SteveC> next[[BR]]
08:59 < SteveC> :-)[[BR]]
08:59 < mcknut> oh, you turned that off?[[BR]]
08:59 < SteveC> yeah to see if it was better. it was but not good enough[[BR]]
08:59 < mcknut> ah[[BR]]
08:59 < LA2> Steve, if this is essentially fcgi, do you have a way to return a response and then kill the process?[[BR]]
09:00 < SteveC> that was my next option, you can periodically graceful the processes[[BR]]
09:00 < SteveC> but they get so much traffic they dont seem to pause long enough to get gracefulled so I have to kill them, which loses the process queue[[BR]]
09:01 < mcknut> "put a counter in the CGI wrapper, if you reach the count service the current request then exit"[[BR]]
09:01 < mcknut> dispatch.fcgi most likely, apparently[[BR]]
09:01 < SteveC> makes sense[[BR]]
09:01 < SteveC> then have fcgi auto-reload on crash[[BR]]
09:01 < LA2> in classic Perl fcgi, your script implements the main loop itself, so you can write out the response to this query, and then say "die" to kill any memory leaks, rather than taking the next turn in the loop (fetching the next request)[[BR]]
09:01 < mcknut> yeah, which apparently it does[[BR]]
09:02 < mcknut> (auto-reloading)[[BR]]
09:02 < SteveC> I could auto-die after 500 map requests or something[[BR]]
09:02 < LA2> or after the process eats X megs of memory[[BR]]
09:03 < SteveC> does someone fancy summarising this as a ticket as I have to get ready for a flight? I think at least nickb will take a look[[BR]]
09:04 < SteveC> should be as simple as[[BR]]
09:04 < SteveC> COUNT = 0[[BR]]
09:04 < SteveC> in environment.rb[[BR]]
09:04 < SteveC> COUNT += 1[[BR]]
09:04 < SteveC> if COUNT > 500[[BR]]
09:04 < SteveC> exit[[BR]]
09:04 < SteveC> end[[BR]]
09:04 < SteveC> in the map call handler[[BR]]
09:04 < mcknut> ok, I'll do it[[BR]]
09:04 < SteveC> or[[BR]]
09:04 < SteveC> exit![[BR]]
09:04 < SteveC> not exit[[BR]]
09:04 < SteveC> then just test it works like it says it should[[BR]]
09:05 < SteveC> and I'll deploy[[BR]]
09:05 < mcknut> I'll make a ticket and ping nick[[BR]]
The text was updated successfully, but these errors were encountered: