Guys, I setup a typo blog on DreamHost a few days back @ www.jimjeffers.com But the longer the app has been up the slower it''s gotten. How do I figure out the cuase of this performance decay? The app has been set to run in FastCGI: 1. I''ve removed the dispatch.cgi, and dispatch.rb files. 2. I''ve updated the .htaccess. 3. I''ve enabled Fast CGI on the Dreamhost control panel for the domain. This is what I see when I run top in the shell (SCROLL DOWN I''VE INCLUDED MY CRASH LOG BELOW AS WELL): top - 00:24:55 up 12 days, 1:44, 5 users, load average: 0.58, 0.80, 0.98 Tasks: 29 total, 1 running, 28 sleeping, 0 stopped, 0 zombie Cpu(s): 4.5% user, 1.8% system, 0.4% nice, 93.3% idle Mem: 1549476k total, 1471064k used, 78412k free, 10372k buffers Swap: 6313512k total, 2492120k used, 3821392k free, 322360k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 30002 treacher 10 0 1056 1056 852 R 0.3 0.1 0:01.33 top 23459 treacher 9 0 23684 2328 1996 S 0.0 0.2 0:03.75 ruby 1281 treacher 9 0 23696 2312 1992 S 0.0 0.1 0:03.51 ruby 24123 treacher 9 0 23388 2156 1924 S 0.0 0.1 0:02.55 ruby 27261 treacher 9 0 23600 2284 1924 S 0.0 0.1 0:03.30 ruby 5566 treacher 9 0 24252 3148 2576 S 0.0 0.2 0:03.40 ruby 5795 treacher 9 0 23860 2756 2356 S 0.0 0.2 0:03.45 ruby 29091 treacher 9 0 23548 2444 2168 S 0.0 0.2 0:02.49 ruby 15096 treacher 9 0 23420 2316 1908 S 0.0 0.1 0:02.75 ruby 4716 treacher 9 0 24344 3112 2704 S 0.0 0.2 0:03.66 ruby 30473 treacher 9 0 24320 3216 2700 S 0.0 0.2 0:03.18 ruby 24170 treacher 9 0 24380 3280 2708 S 0.0 0.2 0:03.36 ruby 2176 treacher 9 0 24156 3032 2672 S 0.0 0.2 0:02.52 ruby 18676 treacher 9 0 24168 3044 2680 S 0.0 0.2 0:02.33 ruby 26377 treacher 9 0 24168 3044 2684 S 0.0 0.2 0:03.51 ruby 6396 treacher 9 0 24164 3096 2680 S 0.0 0.2 0:02.59 ruby 6261 treacher 9 0 24324 8320 2684 S 0.0 0.5 0:04.14 ruby 1884 treacher 9 0 24388 3392 2684 S 0.0 0.2 0:03.75 ruby 25887 treacher 9 0 23896 12m 2408 S 0.0 0.8 0:03.55 ruby 23484 treacher 9 0 23424 2428 2028 S 0.0 0.2 0:02.81 ruby 9962 treacher 9 0 24196 3212 2480 S 0.0 0.2 0:03.32 ruby 16554 treacher 9 0 24092 22m 2400 S 0.0 1.5 0:03.24 ruby 6336 treacher 9 0 24040 22m 2336 S 0.0 1.5 0:03.59 ruby 16572 treacher 9 0 23040 2044 1556 S 0.0 0.1 0:02.83 ruby 24198 treacher 9 0 22656 1900 1260 S 0.0 0.1 0:02.50 ruby 24623 treacher 9 0 23688 23m 2296 S 0.0 1.5 0:02.65 ruby 25152 treacher 9 0 24380 23m 2684 S 0.0 1.6 0:03.08 ruby 5438 treacher 9 0 2020 1976 1772 S 0.0 0.1 0:00.12 sshd 9823 treacher 9 0 1636 1636 1208 S 0.0 0.1 0:00.01 bash My fastcgi.crash.log is full of information like the excerpt I''ve pasted below. I can''t make sense of any of this information. I understand what it''s telling me but I don''t know why the processes are being terminated or starting: [08/Aug/2005:20:30:54 :: 27809] starting [08/Aug/2005:20:33:30 :: 5223] told to terminate NOW [08/Aug/2005:20:33:30 :: 5223] terminated by explicit exit [09/Aug/2005:00:00:52 :: 6261] starting [09/Aug/2005:00:00:52 :: 1046] starting [09/Aug/2005:00:00:52 :: 19058] starting [09/Aug/2005:00:00:52 :: 8050] starting [09/Aug/2005:00:00:53 :: 10982] starting [09/Aug/2005:00:01:44 :: 26835] starting [09/Aug/2005:00:06:08 :: 19058] told to terminate NOW [09/Aug/2005:00:06:08 :: 19058] terminated by explicit exit [09/Aug/2005:10:48:22 :: 9962] starting [09/Aug/2005:10:48:22 :: 23484] starting [09/Aug/2005:10:48:22 :: 25887] starting [09/Aug/2005:10:48:22 :: 1884] starting [09/Aug/2005:10:48:28 :: 16554] starting [09/Aug/2005:10:48:45 :: 16933] starting [09/Aug/2005:10:48:45 :: 6336] starting [09/Aug/2005:10:49:00 :: 16572] starting [09/Aug/2005:10:50:18 :: 24198] starting [09/Aug/2005:13:28:19 :: 16933] told to terminate NOW [09/Aug/2005:13:28:19 :: 16933] told to terminate NOW [09/Aug/2005:13:28:19 :: 16933] terminated by explicit exit [09/Aug/2005:23:50:35 :: 4309] starting [09/Aug/2005:23:50:35 :: 31000] starting [09/Aug/2005:23:50:35 :: 10548] starting [09/Aug/2005:23:50:37 :: 20804] starting [09/Aug/2005:23:50:40 :: 1053] starting [09/Aug/2005:23:51:03 :: 1053] told to terminate NOW [09/Aug/2005:23:51:03 :: 1053] terminated by explicit exit [09/Aug/2005:23:56:03 :: 20804] told to terminate NOW [09/Aug/2005:23:56:03 :: 20804] terminated by explicit exit [10/Aug/2005:00:01:03 :: 10548] told to terminate NOW [10/Aug/2005:00:01:03 :: 10548] terminated by explicit exit [10/Aug/2005:00:06:03 :: 31000] told to terminate NOW [10/Aug/2005:00:06:03 :: 31000] terminated by explicit exit [10/Aug/2005:00:11:03 :: 4309] told to terminate NOW [10/Aug/2005:00:11:03 :: 4309] terminated by explicit exit [10/Aug/2005:00:15:41 :: 25152] starting [10/Aug/2005:00:15:41 :: 4012] starting [10/Aug/2005:00:15:41 :: 24623] starting [10/Aug/2005:00:16:04 :: 4012] told to terminate NOW [10/Aug/2005:00:16:04 :: 4012] terminated by explicit exit [10/Aug/2005:00:18:09 :: 17367] starting [10/Aug/2005:00:21:05 :: 17367] told to terminate NOW [10/Aug/2005:00:21:05 :: 17367] terminated by explicit exit [10/Aug/2005:00:26:02 :: 24623] told to terminate NOW [10/Aug/2005:00:26:02 :: 24623] terminated by explicit exit [10/Aug/2005:00:26:02 :: 25152] told to terminate NOW [10/Aug/2005:00:26:02 :: 25152] terminated by explicit exit
On 8/10/05, Jim Jeffers <rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org> wrote:> Guys, > > I setup a typo blog on DreamHost a few days back @ www.jimjeffers.com > > But the longer the app has been up the slower it''s gotten. How do I > figure out the cuase of this performance decay? The app has been set > to run in FastCGI: > > 1. I''ve removed the dispatch.cgi, and dispatch.rb files. > 2. I''ve updated the .htaccess. > 3. I''ve enabled Fast CGI on the Dreamhost control panel for the domain. >I''ve experienced this with 0.13.1 in development mode with FastCGI only. Disable FastCGI, or enable Production mode and see if the problem persists.
I''m also experiencing lots of trouble with Dreamhost + fastcgi + production mode. Sometimes my app works great, and then other times it sits there loading forever. --bryce On 8/10/05, James Earl <jamesd.earl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 8/10/05, Jim Jeffers <rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org> wrote: > > Guys, > > > > I setup a typo blog on DreamHost a few days back @ www.jimjeffers.com > > > > But the longer the app has been up the slower it''s gotten. How do I > > figure out the cuase of this performance decay? The app has been set > > to run in FastCGI: > > > > 1. I''ve removed the dispatch.cgi, and dispatch.rb files. > > 2. I''ve updated the .htaccess. > > 3. I''ve enabled Fast CGI on the Dreamhost control panel for the domain. > > > > I''ve experienced this with 0.13.1 in development mode with FastCGI only. > > Disable FastCGI, or enable Production mode and see if the problem persists. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 8/10/05, bryce benton <brycebenton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I''m also experiencing lots of trouble with Dreamhost + fastcgi + > production mode.FastCGI is a complete pain to work with I''m finding. Yesterday morning I wrote some new code using dispatch.cgi in development mode. I got done testing the new code and I switched to production mode and dispatch.fcgi. The same code that worked moments earlier with dispatch.cgi sat there acting broken for the better part of the day using dispatch.fcgi. Then later in the evening, out of nowhere, it began to work, and I never touched it along the way. -- Greg Donald Zend Certified Engineer MySQL Core Certification http://destiney.com/
I seem to be having similiar problems with Apache2+FastCGI, and I share these sentiments. This concerns me greatly because I am one of probably many people who are eager to dive into RoR development, but do _not_ want to stop using Apache for several reasons unmentioned. Is there any hope that mod_ruby can eventually come to save the day? Jason Greg Donald wrote:> FastCGI is a complete pain to work with I''m finding. Yesterday > morning I wrote some new code using dispatch.cgi in development mode. > I got done testing the new code and I switched to production mode and > dispatch.fcgi. The same code that worked moments earlier with > dispatch.cgi sat there acting broken for the better part of the day > using dispatch.fcgi. Then later in the evening, out of nowhere, it > began to work, and I never touched it along the way.
Just to confirm I have set it correctly can you confirm the process of setting rails to run in production mode? - Jim On Aug 10, 2005, at 7:38 AM, James Earl wrote:> On 8/10/05, Jim Jeffers <rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org> wrote: > >> Guys, >> >> I setup a typo blog on DreamHost a few days back @ www.jimjeffers.com >> >> But the longer the app has been up the slower it''s gotten. How do I >> figure out the cuase of this performance decay? The app has been set >> to run in FastCGI: >> >> 1. I''ve removed the dispatch.cgi, and dispatch.rb files. >> 2. I''ve updated the .htaccess. >> 3. I''ve enabled Fast CGI on the Dreamhost control panel for the >> domain. >> >> > > I''ve experienced this with 0.13.1 in development mode with FastCGI > only. > > Disable FastCGI, or enable Production mode and see if the problem > persists. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
Case in point I think this should be something the rails development team should focus on. It''s a major deterrent from using rails as I can''t create an app in rails for my client until I''m confident I can deploy it effectively. Unfortunately, I think there is a lack of clarity of dealing with Fast CGI and hope people smarter than myself may be able to rekindle the community around that project to further sort out bugs and allow it to be more stable / coder friendly. - Jim On Aug 10, 2005, at 7:57 AM, Greg Donald wrote:> On 8/10/05, bryce benton <brycebenton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> I''m also experiencing lots of trouble with Dreamhost + fastcgi + >> production mode. >> > > FastCGI is a complete pain to work with I''m finding. Yesterday > morning I wrote some new code using dispatch.cgi in development mode. > I got done testing the new code and I switched to production mode and > dispatch.fcgi. The same code that worked moments earlier with > dispatch.cgi sat there acting broken for the better part of the day > using dispatch.fcgi. Then later in the evening, out of nowhere, it > began to work, and I never touched it along the way. > > > -- > Greg Donald > Zend Certified Engineer > MySQL Core Certification > http://destiney.com/ > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
There''s a number of different ways to change to the production environment. This link should help: http://wiki.rubyonrails.com/rails/show/Environments Unfortunatily, I''m not familiar with DreamHost if that is where you''re hosted through. On 8/10/05, Jim Jeffers <rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org> wrote:> Just to confirm I have set it correctly can you confirm the process > of setting rails to run in production mode? > > - Jim > > On Aug 10, 2005, at 7:38 AM, James Earl wrote: > > > On 8/10/05, Jim Jeffers <rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org> wrote: > > > >> Guys, > >> > >> I setup a typo blog on DreamHost a few days back @ www.jimjeffers.com > >> > >> But the longer the app has been up the slower it''s gotten. How do I > >> figure out the cuase of this performance decay? The app has been set > >> to run in FastCGI: > >> > >> 1. I''ve removed the dispatch.cgi, and dispatch.rb files. > >> 2. I''ve updated the .htaccess. > >> 3. I''ve enabled Fast CGI on the Dreamhost control panel for the > >> domain. > >> > >> > > > > I''ve experienced this with 0.13.1 in development mode with FastCGI > > only. > > > > Disable FastCGI, or enable Production mode and see if the problem > > persists. > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Consider mod_fcgid instead of mod_fcgi. -Brian On Aug 10, 2005, at 12:12 PM, Jason Hines wrote:> > I seem to be having similiar problems with Apache2+FastCGI, and I > share these sentiments. This concerns me greatly because I am one > of probably many people who are eager to dive into RoR development, > but do _not_ want to stop using Apache for several reasons > unmentioned. > > Is there any hope that mod_ruby can eventually come to save the day? > > Jason > > > Greg Donald wrote: > >> FastCGI is a complete pain to work with I''m finding. Yesterday >> morning I wrote some new code using dispatch.cgi in development >> mode. I got done testing the new code and I switched to production >> mode and >> dispatch.fcgi. The same code that worked moments earlier with >> dispatch.cgi sat there acting broken for the better part of the day >> using dispatch.fcgi. Then later in the evening, out of nowhere, it >> began to work, and I never touched it along the way. >> > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > >
Jim Jeffers wrote:> Guys, > > I setup a typo blog on DreamHost a few days back @ www.jimjeffers.com > > But the longer the app has been up the slower it''s gotten. How do I > figure out the cuase of this performance decay?Look at memory usage. We have been seeing memory leak problems with Rails and FastCGI in development and production mode, and performance degradation, much like you are seeing. Zach
Jason Hines wrote:> > I seem to be having similiar problems with Apache2+FastCGI, and I share > these sentiments. This concerns me greatly because I am one of probably > many people who are eager to dive into RoR development, but do _not_ > want to stop using Apache for several reasons unmentioned.We have tested Apache+FastCGI and Lighttpd+FastCGI and we have seen the same problems with both environments. Zach
I am seeing exactly the same problem on an app I just deployed on Dreamhost. You can be filling out a form, submit it, and the user gets a Rails not starting error. Refresh, and it works. And will continue to work a few times, until it happens again. The FCGI processes seem to be getting taken out from underneath. Using ''top'', there are only 2-3 fcgi processes running at any one time. Sometimes it drops to 0, then gets kicked off again. Wish I knew what was happening. Brett On Aug 10, 2005, at 1:04 PM, Jim Jeffers wrote:> Guys, > > I setup a typo blog on DreamHost a few days back @ www.jimjeffers.com > > But the longer the app has been up the slower it''s gotten. How do > I figure out the cuase of this performance decay? The app has been > set to run in FastCGI: > > 1. I''ve removed the dispatch.cgi, and dispatch.rb files. > 2. I''ve updated the .htaccess. > 3. I''ve enabled Fast CGI on the Dreamhost control panel for the > domain. > > This is what I see when I run top in the shell (SCROLL DOWN I''VE > INCLUDED MY CRASH LOG BELOW AS WELL): > > top - 00:24:55 up 12 days, 1:44, 5 users, load average: 0.58, > 0.80, 0.98 > Tasks: 29 total, 1 running, 28 sleeping, 0 stopped, 0 zombie > Cpu(s): 4.5% user, 1.8% system, 0.4% nice, 93.3% idle > Mem: 1549476k total, 1471064k used, 78412k free, 10372k > buffers > Swap: 6313512k total, 2492120k used, 3821392k free, 322360k > cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 30002 treacher 10 0 1056 1056 852 R 0.3 0.1 0:01.33 top > 23459 treacher 9 0 23684 2328 1996 S 0.0 0.2 0:03.75 ruby > 1281 treacher 9 0 23696 2312 1992 S 0.0 0.1 0:03.51 ruby_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Is it possible that since Dreamhost is a shared environment that other users are restarting apache and it kill soff your fcgi''s? On Aug 11, 2005, at 4:04 AM, Brett Walker wrote:> I am seeing exactly the same problem on an app I just deployed on > Dreamhost. You can be filling out a form, submit it, and the user > gets a Rails not starting error. Refresh, and it works. And will > continue to work a few times, until it happens again. The FCGI > processes seem to be getting taken out from underneath. > > Using ''top'', there are only 2-3 fcgi processes running at any one > time. Sometimes it drops to 0, then gets kicked off again. Wish I > knew what was happening. > > Brett > > On Aug 10, 2005, at 1:04 PM, Jim Jeffers wrote: > >> Guys, >> >> I setup a typo blog on DreamHost a few days back @ www.jimjeffers.com >> >> But the longer the app has been up the slower it''s gotten. How do >> I figure out the cuase of this performance decay? The app has >> been set to run in FastCGI: >> >> 1. I''ve removed the dispatch.cgi, and dispatch.rb files. >> 2. I''ve updated the .htaccess. >> 3. I''ve enabled Fast CGI on the Dreamhost control panel for the >> domain. >> >> This is what I see when I run top in the shell (SCROLL DOWN I''VE >> INCLUDED MY CRASH LOG BELOW AS WELL): >> >> top - 00:24:55 up 12 days, 1:44, 5 users, load average: 0.58, >> 0.80, 0.98 >> Tasks: 29 total, 1 running, 28 sleeping, 0 stopped, 0 zombie >> Cpu(s): 4.5% user, 1.8% system, 0.4% nice, 93.3% idle >> Mem: 1549476k total, 1471064k used, 78412k free, 10372k >> buffers >> Swap: 6313512k total, 2492120k used, 3821392k free, 322360k >> cached >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 30002 treacher 10 0 1056 1056 852 R 0.3 0.1 0:01.33 top >> 23459 treacher 9 0 23684 2328 1996 S 0.0 0.2 0:03.75 ruby >> 1281 treacher 9 0 23696 2312 1992 S 0.0 0.1 0:03.51 ruby > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-Ezra Zygmuntowicz Yakima Herald-Republic WebMaster 509-577-7732 ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org
I spent much of yesterday in communication with Dreamhost support, and although the issue has not been completely resolved, part of the solution turned out to be: 1) me: turn off svnserve (was becoming resource intensive, so procwatch was automatically killing new processes) 2) them: install a different (new?) version of Apache So maybe the issue is that in the shared environment, either you or someone nearby is hogging resources. ?? --bryce http://lightincense.com (built with Ruby on Rails) On 8/11/05, Ezra Zygmuntowicz <ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org> wrote:> Is it possible that since Dreamhost is a shared environment that > other users are restarting apache and it kill soff your fcgi''s? >
Blast. I need to get a dedicated host! On Aug 11, 2005, at 8:25 AM, bryce benton wrote:> I spent much of yesterday in communication with Dreamhost support, and > although the issue has not been completely resolved, part of the > solution turned out to be: > > 1) me: turn off svnserve (was becoming resource intensive, so > procwatch was automatically killing new processes) > > 2) them: install a different (new?) version of Apache > > So maybe the issue is that in the shared environment, either you or > someone nearby is hogging resources. ?? > > --bryce > > http://lightincense.com (built with Ruby on Rails) > > On 8/11/05, Ezra Zygmuntowicz <ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org> wrote: > >> Is it possible that since Dreamhost is a shared environment that >> other users are restarting apache and it kill soff your fcgi''s? >> >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
Bryce how do you turn off svsnserve. Is it on by default for all dreamhost accounts or did you manually turn it on in the past? On Aug 11, 2005, at 8:25 AM, bryce benton wrote:> I spent much of yesterday in communication with Dreamhost support, and > although the issue has not been completely resolved, part of the > solution turned out to be: > > 1) me: turn off svnserve (was becoming resource intensive, so > procwatch was automatically killing new processes) > > 2) them: install a different (new?) version of Apache > > So maybe the issue is that in the shared environment, either you or > someone nearby is hogging resources. ?? > > --bryce > > http://lightincense.com (built with Ruby on Rails) > > On 8/11/05, Ezra Zygmuntowicz <ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org> wrote: > >> Is it possible that since Dreamhost is a shared environment that >> other users are restarting apache and it kill soff your fcgi''s? >> >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
Ruby on Rails List, Is Jim right... would a dedicated server solve this problem? I''m not eager to start paying a lot more per month... unless it would actually solve the fastcgi issue. Jim, If you haven''t explicitly turned it on svnserve, then you don''t need to worry about it. It''s a server for Subversion. --bryce On 8/11/05, Jim Jeffers <rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org> wrote:> Bryce how do you turn off svsnserve. Is it on by default for all > dreamhost accounts or did you manually turn it on in the past? > > On Aug 11, 2005, at 8:25 AM, bryce benton wrote: > > > I spent much of yesterday in communication with Dreamhost support, and > > although the issue has not been completely resolved, part of the > > solution turned out to be: > > > > 1) me: turn off svnserve (was becoming resource intensive, so > > procwatch was automatically killing new processes) > > > > 2) them: install a different (new?) version of Apache > > > > So maybe the issue is that in the shared environment, either you or > > someone nearby is hogging resources. ?? > > > > --bryce > > > > http://lightincense.com (built with Ruby on Rails) > > > > On 8/11/05, Ezra Zygmuntowicz <ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org> wrote: > > > >> Is it possible that since Dreamhost is a shared environment that > >> other users are restarting apache and it kill soff your fcgi''s? > >> > >> > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Bryce, Do you know how to set the rails environment on a shared hosting platform? Do you just set the RAILS_ENV variable to production in your .htaccess? On Aug 11, 2005, at 11:14 AM, bryce benton wrote:> Ruby on Rails List, > > Is Jim right... would a dedicated server solve this problem? I''m not > eager to start paying a lot more per month... unless it would actually > solve the fastcgi issue. > > Jim, > > If you haven''t explicitly turned it on svnserve, then you don''t need > to worry about it. It''s a server for Subversion. > > --bryce > > On 8/11/05, Jim Jeffers <rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org> wrote: > >> Bryce how do you turn off svsnserve. Is it on by default for all >> dreamhost accounts or did you manually turn it on in the past? >> >> On Aug 11, 2005, at 8:25 AM, bryce benton wrote: >> >> >>> I spent much of yesterday in communication with Dreamhost >>> support, and >>> although the issue has not been completely resolved, part of the >>> solution turned out to be: >>> >>> 1) me: turn off svnserve (was becoming resource intensive, so >>> procwatch was automatically killing new processes) >>> >>> 2) them: install a different (new?) version of Apache >>> >>> So maybe the issue is that in the shared environment, either you or >>> someone nearby is hogging resources. ?? >>> >>> --bryce >>> >>> http://lightincense.com (built with Ruby on Rails) >>> >>> On 8/11/05, Ezra Zygmuntowicz <ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org> wrote: >>> >>> >>>> Is it possible that since Dreamhost is a shared environment that >>>> other users are restarting apache and it kill soff your fcgi''s? >>>> >>>> >>>> >>> _______________________________________________ >>> Rails mailing list >>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>> http://lists.rubyonrails.org/mailman/listinfo/rails >>> >>> >>> >>> >> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
Jim, There are several ways to set the RAILS_ENV variable. The way I did it was by editing the file: config/environment.rb I commented out the second line, and hardcoded a new line, so that it now looks like this: #RAILS_ENV = ENV[''RAILS_ENV''] || ''development'' RAILS_ENV = ''production'' --bryce http://lightincense.com On 8/11/05, Jim Jeffers <rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org> wrote:> Bryce, > > Do you know how to set the rails environment on a shared hosting > platform? Do you just set the RAILS_ENV variable to production in > your .htaccess? > > On Aug 11, 2005, at 11:14 AM, bryce benton wrote: > > > Ruby on Rails List, > > > > Is Jim right... would a dedicated server solve this problem? I''m not > > eager to start paying a lot more per month... unless it would actually > > solve the fastcgi issue. > > > > Jim, > > > > If you haven''t explicitly turned it on svnserve, then you don''t need > > to worry about it. It''s a server for Subversion. > > > > --bryce > > > > On 8/11/05, Jim Jeffers <rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org> wrote: > > > >> Bryce how do you turn off svsnserve. Is it on by default for all > >> dreamhost accounts or did you manually turn it on in the past? > >> > >> On Aug 11, 2005, at 8:25 AM, bryce benton wrote: > >> > >> > >>> I spent much of yesterday in communication with Dreamhost > >>> support, and > >>> although the issue has not been completely resolved, part of the > >>> solution turned out to be: > >>> > >>> 1) me: turn off svnserve (was becoming resource intensive, so > >>> procwatch was automatically killing new processes) > >>> > >>> 2) them: install a different (new?) version of Apache > >>> > >>> So maybe the issue is that in the shared environment, either you or > >>> someone nearby is hogging resources. ?? > >>> > >>> --bryce > >>> > >>> http://lightincense.com (built with Ruby on Rails) > >>> > >>> On 8/11/05, Ezra Zygmuntowicz <ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org> wrote: > >>> > >>> > >>>> Is it possible that since Dreamhost is a shared environment that > >>>> other users are restarting apache and it kill soff your fcgi''s? > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> Rails mailing list > >>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >>> http://lists.rubyonrails.org/mailman/listinfo/rails > >>> > >>> > >>> > >>> > >> > >> _______________________________________________ > >> Rails mailing list > >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails > >> > >> > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Bryce-
I have a large rails site for the newspaper I work for that I
will be launching within the net two weeks. At first I tried to
shoehorn it in on a colocated server I have that also runs some 30
other web sites. I got these random 500 errors from apache. So I have
put my site on its own dedicated server so it can be the main apache
server instead of in a vhost and there are no other sites on this
machine. It is running great so far , none of the 500''s. I have been
testing it with seige and apache bench and have been able to get very
good performance out of it with no errors until I really torture it
with unrealistic traffic conditions.
So short answer is most likely yes. I think you would be much
better off with some dedicated hosting. Especially if you are doing
ecommerce or plan on having medium - high traffic. Feel free to
contact me off list and I can send you my apache configs and some
info on a dedicated hosting provider I highly recommend.
HTH-
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
509-577-7732
ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org
On Aug 11, 2005, at 11:14 AM, bryce benton wrote:
> Ruby on Rails List,
>
> Is Jim right... would a dedicated server solve this problem? I''m
not
> eager to start paying a lot more per month... unless it would actually
> solve the fastcgi issue.
>
> Jim,
>
> If you haven''t explicitly turned it on svnserve, then you
don''t need
> to worry about it. It''s a server for Subversion.
>
> --bryce
>
> On 8/11/05, Jim Jeffers
<rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org> wrote:
>
>> Bryce how do you turn off svsnserve. Is it on by default for all
>> dreamhost accounts or did you manually turn it on in the past?
>>
>> On Aug 11, 2005, at 8:25 AM, bryce benton wrote:
>>
>>
>>> I spent much of yesterday in communication with Dreamhost
>>> support, and
>>> although the issue has not been completely resolved, part of the
>>> solution turned out to be:
>>>
>>> 1) me: turn off svnserve (was becoming resource intensive, so
>>> procwatch was automatically killing new processes)
>>>
>>> 2) them: install a different (new?) version of Apache
>>>
>>> So maybe the issue is that in the shared environment, either you or
>>> someone nearby is hogging resources. ??
>>>
>>> --bryce
>>>
>>> http://lightincense.com (built with Ruby on Rails)
>>>
>>> On 8/11/05, Ezra Zygmuntowicz
<ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org> wrote:
>>>
>>>
>>>> Is it possible that since Dreamhost is a shared environment
that
>>>> other users are restarting apache and it kill soff your
fcgi''s?
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Rails mailing list
>>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Rails mailing list
>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
Ezra, Thanks for your input on this. Although I''m still getting the occasional out-of-the-blue 500 error, I''ve managed to reduce it from about 1:20 requests to about 1:100 or less (estimated). I modified my dispatch.fcgi to reference the fcgi gem rather than the fcgi_handler: ## dispatch.cgi #require ''fcgi_handler'' require ''rubygems'' require_gem ''fcgi'' I killed all of the 25 or so existing dispatch.fcgi processes [1] with: killall -9 dispatch.fcgi The new dispatch.fcgi processes seem to be a bit more stable. I also implemented caches_action in my controllers, but I''m not sure if that has had any effect or not on fastcgi. Having said all that, I must admit that I don''t *really* know what I''m doing, but all this seems to have helped. Now I''m back into the "almost comfortable" level of failure rate, whereas before I was in the "I feel like crap... my application is a jalopy" level of failure rate. The basic message, I guess if a request is made during a time when CPU resources are maxed out, the 500 is likely to appear. Apparently, sloppy code may also cause the fastcgi process to be more brittle[2]. --bryce [1] http://convergentarts.com/articles/2005/07/26/restarting-all-fastcgi-processes [2] http://article.gmane.org/gmane.comp.lang.ruby.rails/10454/match=fastcgi+hansson -- http://lightincense.com
Hi DreamHostees,
DreamHost now automatically sets up FastCGI to put your app into
production mode so you don''t have to do it manually. It will be in
development mode if you use dispatch.cgi and production mode if you
use dispatch.fcgi. You can also still set it the way described here,
of course. It''s just not necessary if you''re using FastCGI
(everyone
is, right?).
Also, a quick note... if you are having problems with your Rails
apps, check how many processes you have running. A quick ''ps
aux''
will show you. If it''s more than 30 or so, there''s a good
chance our
process watcher is killing new ones out from under you.
dispatch.fcgi seems to like to hang around without dying sometimes.
Sorry this was a bit off-topic.
Dallas (of DreamHost)
On Aug 11, 2005, at 11:28 AM, bryce benton wrote:
> Jim,
>
> There are several ways to set the RAILS_ENV variable. The way I did it
> was by editing the file:
> config/environment.rb
>
> I commented out the second line, and hardcoded a new line, so that it
> now looks like this:
>
> #RAILS_ENV = ENV[''RAILS_ENV''] ||
''development''
> RAILS_ENV = ''production''
>
> --bryce
>
> http://lightincense.com
>
>
> On 8/11/05, Jim Jeffers
<rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org> wrote:
>
>> Bryce,
>>
>> Do you know how to set the rails environment on a shared hosting
>> platform? Do you just set the RAILS_ENV variable to production in
>> your .htaccess?
>>
>> On Aug 11, 2005, at 11:14 AM, bryce benton wrote:
>>
>>
>>> Ruby on Rails List,
>>>
>>> Is Jim right... would a dedicated server solve this problem?
I''m not
>>> eager to start paying a lot more per month... unless it would
>>> actually
>>> solve the fastcgi issue.
>>>
>>> Jim,
>>>
>>> If you haven''t explicitly turned it on svnserve, then you
don''t need
>>> to worry about it. It''s a server for Subversion.
>>>
>>> --bryce
>>>
>>> On 8/11/05, Jim Jeffers
<rails-u78NUfcIof50Y1uG8So6J1aTQe2KTcn/@public.gmane.org> wrote:
>>>
>>>
>>>> Bryce how do you turn off svsnserve. Is it on by default for
all
>>>> dreamhost accounts or did you manually turn it on in the past?
>>>>
>>>> On Aug 11, 2005, at 8:25 AM, bryce benton wrote:
>>>>
>>>>
>>>>
>>>>> I spent much of yesterday in communication with Dreamhost
>>>>> support, and
>>>>> although the issue has not been completely resolved, part
of the
>>>>> solution turned out to be:
>>>>>
>>>>> 1) me: turn off svnserve (was becoming resource intensive,
so
>>>>> procwatch was automatically killing new processes)
>>>>>
>>>>> 2) them: install a different (new?) version of Apache
>>>>>
>>>>> So maybe the issue is that in the shared environment,
either
>>>>> you or
>>>>> someone nearby is hogging resources. ??
>>>>>
>>>>> --bryce
>>>>>
>>>>> http://lightincense.com (built with Ruby on Rails)
>>>>>
>>>>> On 8/11/05, Ezra Zygmuntowicz
<ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Is it possible that since Dreamhost is a shared
environment that
>>>>>> other users are restarting apache and it kill soff your
fcgi''s?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
Please try my patch and see if it works.. http://www.tuxsoft.se/oss/rails -> "Self-spawning FastCGI handler" In your dispatch.fcgi you can set these variables before the "require ''fcgi_handler''" line if you can''t controll the environment variables in your shared environment: ENV[''FCGI_CHILDREN''] = 5 # Will spawn and always keep alive 5 dispatchers ENV[''FCGI_MAX_REQUESTS''] = 500 # Dispatchers will kill themselves and be respawned after handling 500 requests. Setting the FCGI_CHILDREN variable will make dispatch.fcgi act as a spawner that only spawns and keep X number of children alive without handling any requests itself so make sure that the webserver only start ONE instance. Let me know how it works! // Per 10 aug 2005 kl. 09.34 skrev Jim Jeffers:> Guys, > > I setup a typo blog on DreamHost a few days back @ www.jimjeffers.com > > But the longer the app has been up the slower it''s gotten. How do > I figure out the cuase of this performance decay? The app has been > set to run in FastCGI: > > 1. I''ve removed the dispatch.cgi, and dispatch.rb files. > 2. I''ve updated the .htaccess. > 3. I''ve enabled Fast CGI on the Dreamhost control panel for the > domain. > > This is what I see when I run top in the shell (SCROLL DOWN I''VE > INCLUDED MY CRASH LOG BELOW AS WELL): > > top - 00:24:55 up 12 days, 1:44, 5 users, load average: 0.58, > 0.80, 0.98 > Tasks: 29 total, 1 running, 28 sleeping, 0 stopped, 0 zombie > Cpu(s): 4.5% user, 1.8% system, 0.4% nice, 93.3% idle > Mem: 1549476k total, 1471064k used, 78412k free, 10372k > buffers > Swap: 6313512k total, 2492120k used, 3821392k free, 322360k > cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 30002 treacher 10 0 1056 1056 852 R 0.3 0.1 0:01.33 top > 23459 treacher 9 0 23684 2328 1996 S 0.0 0.2 0:03.75 ruby > 1281 treacher 9 0 23696 2312 1992 S 0.0 0.1 0:03.51 ruby > 24123 treacher 9 0 23388 2156 1924 S 0.0 0.1 0:02.55 ruby > 27261 treacher 9 0 23600 2284 1924 S 0.0 0.1 0:03.30 ruby > 5566 treacher 9 0 24252 3148 2576 S 0.0 0.2 0:03.40 ruby > 5795 treacher 9 0 23860 2756 2356 S 0.0 0.2 0:03.45 ruby > 29091 treacher 9 0 23548 2444 2168 S 0.0 0.2 0:02.49 ruby > 15096 treacher 9 0 23420 2316 1908 S 0.0 0.1 0:02.75 ruby > 4716 treacher 9 0 24344 3112 2704 S 0.0 0.2 0:03.66 ruby > 30473 treacher 9 0 24320 3216 2700 S 0.0 0.2 0:03.18 ruby > 24170 treacher 9 0 24380 3280 2708 S 0.0 0.2 0:03.36 ruby > 2176 treacher 9 0 24156 3032 2672 S 0.0 0.2 0:02.52 ruby > 18676 treacher 9 0 24168 3044 2680 S 0.0 0.2 0:02.33 ruby > 26377 treacher 9 0 24168 3044 2684 S 0.0 0.2 0:03.51 ruby > 6396 treacher 9 0 24164 3096 2680 S 0.0 0.2 0:02.59 ruby > 6261 treacher 9 0 24324 8320 2684 S 0.0 0.5 0:04.14 ruby > 1884 treacher 9 0 24388 3392 2684 S 0.0 0.2 0:03.75 ruby > 25887 treacher 9 0 23896 12m 2408 S 0.0 0.8 0:03.55 ruby > 23484 treacher 9 0 23424 2428 2028 S 0.0 0.2 0:02.81 ruby > 9962 treacher 9 0 24196 3212 2480 S 0.0 0.2 0:03.32 ruby > 16554 treacher 9 0 24092 22m 2400 S 0.0 1.5 0:03.24 ruby > 6336 treacher 9 0 24040 22m 2336 S 0.0 1.5 0:03.59 ruby > 16572 treacher 9 0 23040 2044 1556 S 0.0 0.1 0:02.83 ruby > 24198 treacher 9 0 22656 1900 1260 S 0.0 0.1 0:02.50 ruby > 24623 treacher 9 0 23688 23m 2296 S 0.0 1.5 0:02.65 ruby > 25152 treacher 9 0 24380 23m 2684 S 0.0 1.6 0:03.08 ruby > 5438 treacher 9 0 2020 1976 1772 S 0.0 0.1 0:00.12 sshd > 9823 treacher 9 0 1636 1636 1208 S 0.0 0.1 0:00.01 bash > > > > > My fastcgi.crash.log is full of information like the excerpt I''ve > pasted below. I can''t make sense of any of this information. I > understand what it''s telling me but I don''t know why the processes > are being terminated or starting: > > [08/Aug/2005:20:30:54 :: 27809] starting > [08/Aug/2005:20:33:30 :: 5223] told to terminate NOW > [08/Aug/2005:20:33:30 :: 5223] terminated by explicit exit > [09/Aug/2005:00:00:52 :: 6261] starting > [09/Aug/2005:00:00:52 :: 1046] starting > [09/Aug/2005:00:00:52 :: 19058] starting > [09/Aug/2005:00:00:52 :: 8050] starting > [09/Aug/2005:00:00:53 :: 10982] starting > [09/Aug/2005:00:01:44 :: 26835] starting > [09/Aug/2005:00:06:08 :: 19058] told to terminate NOW > [09/Aug/2005:00:06:08 :: 19058] terminated by explicit exit > [09/Aug/2005:10:48:22 :: 9962] starting > [09/Aug/2005:10:48:22 :: 23484] starting > [09/Aug/2005:10:48:22 :: 25887] starting > [09/Aug/2005:10:48:22 :: 1884] starting > [09/Aug/2005:10:48:28 :: 16554] starting > [09/Aug/2005:10:48:45 :: 16933] starting > [09/Aug/2005:10:48:45 :: 6336] starting > [09/Aug/2005:10:49:00 :: 16572] starting > [09/Aug/2005:10:50:18 :: 24198] starting > [09/Aug/2005:13:28:19 :: 16933] told to terminate NOW > [09/Aug/2005:13:28:19 :: 16933] told to terminate NOW > [09/Aug/2005:13:28:19 :: 16933] terminated by explicit exit > [09/Aug/2005:23:50:35 :: 4309] starting > [09/Aug/2005:23:50:35 :: 31000] starting > [09/Aug/2005:23:50:35 :: 10548] starting > [09/Aug/2005:23:50:37 :: 20804] starting > [09/Aug/2005:23:50:40 :: 1053] starting > [09/Aug/2005:23:51:03 :: 1053] told to terminate NOW > [09/Aug/2005:23:51:03 :: 1053] terminated by explicit exit > [09/Aug/2005:23:56:03 :: 20804] told to terminate NOW > [09/Aug/2005:23:56:03 :: 20804] terminated by explicit exit > [10/Aug/2005:00:01:03 :: 10548] told to terminate NOW > [10/Aug/2005:00:01:03 :: 10548] terminated by explicit exit > [10/Aug/2005:00:06:03 :: 31000] told to terminate NOW > [10/Aug/2005:00:06:03 :: 31000] terminated by explicit exit > [10/Aug/2005:00:11:03 :: 4309] told to terminate NOW > [10/Aug/2005:00:11:03 :: 4309] terminated by explicit exit > [10/Aug/2005:00:15:41 :: 25152] starting > [10/Aug/2005:00:15:41 :: 4012] starting > [10/Aug/2005:00:15:41 :: 24623] starting > [10/Aug/2005:00:16:04 :: 4012] told to terminate NOW > [10/Aug/2005:00:16:04 :: 4012] terminated by explicit exit > [10/Aug/2005:00:18:09 :: 17367] starting > [10/Aug/2005:00:21:05 :: 17367] told to terminate NOW > [10/Aug/2005:00:21:05 :: 17367] terminated by explicit exit > [10/Aug/2005:00:26:02 :: 24623] told to terminate NOW > [10/Aug/2005:00:26:02 :: 24623] terminated by explicit exit > [10/Aug/2005:00:26:02 :: 25152] told to terminate NOW > [10/Aug/2005:00:26:02 :: 25152] terminated by explicit exit > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >Mvh Tuxie, Dekadance http://www.dekadance.se
Today I found there are substantial changes to fcgi_handler in the trunk of rails svn: http://dev.rubyonrails.org/svn/rails/trunk/railties/lib/fcgi_handler.rb This is new since rails 0.13.1. I ran it for a while on my test machine with no problems and so tried it on my production machine and it seems to be working very well. I haven''t gotten a 500 error since (know on wood). It may be worth giving it a shot. It seems to be otherwise perfectly compatible. There aren''t any changes to dispatch.fcgi. -Tom -- Tom Wilcoxen http://convergentarts.com http://www.dreamhost.com/r.cgi?twilcoxen
On Wed, Aug 10, 2005 at 01:03:33PM -0400, Brian McCallister wrote:> Consider mod_fcgid instead of mod_fcgi.right, I''m running several rails applications in virtual hosts using Apache2/mod_fcgid [1] on a Debian system, without any problems so far. Jens [1] http://fastcgi.coremail.cn/ or ''apt-get install libapache2-mod-fcgid'' -- Jens Krämer jk-UayuY8ajoWPk1uMJSBkQmQ@public.gmane.org
In looking at the change log for the new fcgi_handler I see this bit:
"This means that you''ll have to ''nudge'' all FCGI
processes with a
request in order to ensure that they have all reloaded. This can be
done by something like ./script/process/repear --nudge
''http://www.myapp.com'' --instances 10, which will load the
myapp site
10 times (and thus hit all of the 10 FCGI processes once, enough to
shut down)."
I can''t find what ./script/process/repear refers to. Anybody know?
I''ve googled on that and on ''repair --nudge'' in case
there is a
misspelling, but without any luck. Is it a custom script?
I''m now seeing that I get my processes asked nicely to shut down or
reload, but then they wait around to get served a request before they
do so. Then they shut down quite nicely. But it looks like some may
hang around indefinitely if they aren''t handed a request.
I tried hitting the site with wget, which seemed to work, but the
above program (''repear'') seems to be able to do it in a bit
more of a
batch mode.
Thanks,
Tom
btw, the new fcgi_handler is still working well...
SwitchTower has a "reaper", which I is what this is referring to. http://manuals.rubyonrails.com/read/chapter/100#page270 --bryce On 8/17/05, Tom Wilcoxen <tomwilcoxen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> In looking at the change log for the new fcgi_handler I see this bit: > > "This means that you''ll have to ''nudge'' all FCGI processes with a > request in order to ensure that they have all reloaded. This can be > done by something like ./script/process/repear --nudge > ''http://www.myapp.com'' --instances 10, which will load the myapp site > 10 times (and thus hit all of the 10 FCGI processes once, enough to > shut down)." > > I can''t find what ./script/process/repear refers to. Anybody know? > I''ve googled on that and on ''repair --nudge'' in case there is a > misspelling, but without any luck. Is it a custom script? > > I''m now seeing that I get my processes asked nicely to shut down or > reload, but then they wait around to get served a request before they > do so. Then they shut down quite nicely. But it looks like some may > hang around indefinitely if they aren''t handed a request. > > I tried hitting the site with wget, which seemed to work, but the > above program (''repear'') seems to be able to do it in a bit more of a > batch mode. > > Thanks, > Tom > > btw, the new fcgi_handler is still working well... > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- http://lightincense.com
On Aug 17, 2005, at 8:32 AM, Tom Wilcoxen wrote:> In looking at the change log for the new fcgi_handler I see this bit: > > "This means that you''ll have to ''nudge'' all FCGI processes with a > request in order to ensure that they have all reloaded. This can be > done by something like ./script/process/repear --nudge > ''http://www.myapp.com'' --instances 10, which will load the myapp site > 10 times (and thus hit all of the 10 FCGI processes once, enough to > shut down)." > > I can''t find what ./script/process/repear refers to. Anybody know? > I''ve googled on that and on ''repair --nudge'' in case there is a > misspelling, but without any luck. Is it a custom script?It should be ''reaper'', not ''repear''. It ''reaps'' the FCGI processes. (I believe the reaper and friends have never seen an official release--they are only in HEAD right now.) You can read more about the reaper, spawner, and spinner scripts at: http://manuals.rubyonrails.com/read/chapter/100#page268 - Jamis