From larseidnes at gmail.com Mon Oct 1 10:07:55 2007 From: larseidnes at gmail.com (Lars Eidnes) Date: Mon, 01 Oct 2007 16:07:55 +0200 Subject: [Mongrel] Getting started on win32 - without Rails. Message-ID: Hi, I'm trying to get started developing my first ruby-powered web-app. I wont be using Rails for this, at least I don't see any reason why I should. However, the "getting started" sections in the documentation only shows you how to start a Rails application. My mindset comes from PHP/JSP-type languages where you embed code into HTML. It seems the way to do this with ruby is to use Apache + mod_ruby + eruby. It also seems this is not the preferred way to do things. (Right?) So: How can I get a simple hello world webpage running from Mongrel, without any framework? Should I not be using Mongrel to do this? Am I asking the wrong questions? -Lars From _ at whats-your.name Mon Oct 1 11:23:09 2007 From: _ at whats-your.name (cdr) Date: Mon, 1 Oct 2007 11:23:09 -0400 Subject: [Mongrel] Getting started on win32 - without Rails. In-Reply-To: References: Message-ID: <20071001152308.GA2803@replic.net> > My mindset comes from PHP/JSP-type languages where you embed code into > HTML. It seems the way to do this with ruby is to use Apache + mod_ruby > + eruby. It also seems this is not the preferred way to do things. (Right?) its not the 'Rails' way of doing things[1], but its a way that will be alive as long as the web. even new projects, such as IBM's Project Zero "focused on the agile development of the next generation of dynamic Web applications" take this approach with a directory containing more or less one PHP file for each resource class, organized by HTTP path.. [1] the Rails way is to use synthetic URLs, and Ruby code to map those to ActiveRecord objects, which reside in SQL tables. Merb, Iowa also share similar paradigm.. you can adjust the GET method below to do something like: path = PathName.new('./resources/'+r.params["REQUEST_PATH"]) (path.exist && path.extname.match(/\.mab$/) && MarkabyHandler || Mongrel::DirHandler).new(Path).process(r,re) MarkabyHandler is an exercise to you. i'd do (Templates[path] ||= eval("lambda{"+path.read+"}")).call or similar to reuse (memoize) the parsed file.. of course you could make a controllers/ dir to match resources (renaming that to views), consolidating both to only have a file per controller/view per resource class [2], etc.. Mongrel lets you build up exactly what you need, instead of what framework authors think you need. [2] Mongrel facilitates this due to a feature of its URIClassifier. '/trinkets/3' will actually match a '/trinkets' registry. afaik you can even get the 'excess' portion of the match so you dont need to do regex of your own (it returns 3 results on a lookup). forget the details as its been a couple months since i dug into the URIClassifier code. > So: How can I get a simple hello world webpage running from Mongrel, > without any framework? setup a configurator line and a class to match, eg: #!/usr/bin/env ruby Path=File.dirname __FILE__ %w{rubygems markaby mongrel}.each{|r|require r} class Resource < Mongrel::HttpHandler def GET r,e e.start{|h,o| o.write "hello world"} end def process r,e send r.params["REQUEST_METHOD"], r, e end end if __FILE__== $0 Mongrel::Configurator.new :host => (ARGV[0] || "0.0.0.0") do listener :port => (ARGV[1] || 80) do uri '/', :handler => Resource.new run end end.join end cheers, and welcome to Mongrel land - where all the animals are ugly > > -Lars > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From sid.webnews at gmail.com Mon Oct 1 15:44:26 2007 From: sid.webnews at gmail.com (Sid Jay) Date: Mon, 01 Oct 2007 14:44:26 -0500 Subject: [Mongrel] Error with Mongrel_cluster Message-ID: Hi Guys, I?m getting this error with mongrel_cluster. I am able to start mongrel through mongrel_rails start but the cluster is not working. Initially mongrel_rails wouldn?t work but after I added $ORACLE_HOME and $PD_LIBRARY_PATH variables it worked but mongrel_cluster isn?t working still. The mongrel log file looks like below. Any help is appreciated. Thanks. -----------begin mongrel.8000.log--------------- ** Daemonized, any open files are closed. Look at tmp/pids/mongrel.8000.pid and log/mongrel.8000.log for info. ** Starting Mongrel listening at 0.0.0.0:8000 ** Changing group to xxxxx. ** Changing user to xxxxx. ** Starting Rails with production environment... /usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection _adapters/oracle_adapter.rb:536: undefined method `define_a_column' for class `OCI8::Cursor' (NameError) from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependenc ies.rb:495:in `require' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependenc ies.rb:342:in `new_constants_in' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependenc ies.rb:495:in `require' from /usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record.rb:81 from /usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record.rb:80 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:162:in `require_frameworks' ... 10 levels... from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:83:in `run' from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in `run' from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:243 from /usr/bin/mongrel_rails:16 --------------------------end log ------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071001/f7eb9ab3/attachment.html From wayneeseguin at gmail.com Mon Oct 1 15:58:57 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Mon, 1 Oct 2007 15:58:57 -0400 Subject: [Mongrel] Error with Mongrel_cluster In-Reply-To: References: Message-ID: On 10/1/07, Sid Jay wrote: > > Hi Guys, > I'm getting this error with mongrel_cluster. I am able to start mongrel > through mongrel_rails start but the cluster is not working. Initially > mongrel_rails wouldn't work but after I added $ORACLE_HOME and > $PD_LIBRARY_PATH variables it worked but mongrel_cluster isn't working > still. The mongrel log file looks like below. > Any help is appreciated. > Thanks. > Sid, See if you can startup the console without errors. Then see if you can start a single instance without errors. This does not appear to be a Mongrel related issue but instead something missing or incorrectly configured in the application. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071001/c1410f76/attachment.html From piyush.pr at gmail.com Mon Oct 1 16:21:19 2007 From: piyush.pr at gmail.com (Piyush Ranjan) Date: Tue, 2 Oct 2007 01:51:19 +0530 Subject: [Mongrel] Error with Mongrel_cluster In-Reply-To: References: Message-ID: <325148f70710011321xe3c1291qee0c34309d770f6f@mail.gmail.com> $PD_LIBRARY_PATH or $LD_LIBRARY_PATH? or is it just a typo ? I have faced this problem is past but setting these two correctly does the trick. Are u sure u did add these variables in your .bashrc ? On 10/2/07, Sid Jay wrote: > > Hi Guys, > I'm getting this error with mongrel_cluster. I am able to start mongrel > through mongrel_rails start but the cluster is not working. Initially > mongrel_rails wouldn't work but after I added $ORACLE_HOME and > $PD_LIBRARY_PATH variables it worked but mongrel_cluster isn't working > still. The mongrel log file looks like below. > Any help is appreciated. > Thanks. > > -----------begin mongrel.8000.log--------------- > ** Daemonized, any open files are closed. Look at > tmp/pids/mongrel.8000.pid and log/mongrel.8000.log for info. > ** Starting Mongrel listening at 0.0.0.0:8000 > ** Changing group to xxxxx. > ** Changing user to xxxxx. > ** Starting Rails with production environment... > /usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/oracle_adapter.rb:536: > undefined method `define_a_column' for class `OCI8::Cursor' (NameError) > from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:495:in > `require' > from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:342:in > `new_constants_in' > from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:495:in > `require' > from /usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3 > /lib/active_record.rb:81 > from /usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3 > /lib/active_record.rb:80 > from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:162:in > `require_frameworks' > ... 10 levels... > from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:83:in > `run' > from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in > `run' > from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1 > /bin/mongrel_rails:243 > from /usr/bin/mongrel_rails:16 > > --------------------------end log ------------------------------------ > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071002/2c92e05b/attachment.html From piyush.pr at gmail.com Mon Oct 1 16:22:36 2007 From: piyush.pr at gmail.com (Piyush Ranjan) Date: Tue, 2 Oct 2007 01:52:36 +0530 Subject: [Mongrel] Error with Mongrel_cluster In-Reply-To: References: Message-ID: <325148f70710011322o7b9df78dqe43aff66962af760@mail.gmail.com> ** Changing group to xxxxx. ** Changing user to xxxxx. Guess this is what the problem is Did you set those variables for those userspace also ? On 10/2/07, Sid Jay wrote: > > Hi Guys, > I'm getting this error with mongrel_cluster. I am able to start mongrel > through mongrel_rails start but the cluster is not working. Initially > mongrel_rails wouldn't work but after I added $ORACLE_HOME and > $PD_LIBRARY_PATH variables it worked but mongrel_cluster isn't working > still. The mongrel log file looks like below. > Any help is appreciated. > Thanks. > > -----------begin mongrel.8000.log--------------- > ** Daemonized, any open files are closed. Look at > tmp/pids/mongrel.8000.pid and log/mongrel.8000.log for info. > ** Starting Mongrel listening at 0.0.0.0:8000 > ** Changing group to xxxxx. > ** Changing user to xxxxx. > ** Starting Rails with production environment... > /usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/oracle_adapter.rb:536: > undefined method `define_a_column' for class `OCI8::Cursor' (NameError) > from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:495:in > `require' > from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:342:in > `new_constants_in' > from /usr/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:495:in > `require' > from /usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3 > /lib/active_record.rb:81 > from /usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3 > /lib/active_record.rb:80 > from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:162:in > `require_frameworks' > ... 10 levels... > from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:83:in > `run' > from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in > `run' > from /usr/lib/ruby/gems/1.8/gems/mongrel-1.0.1 > /bin/mongrel_rails:243 > from /usr/bin/mongrel_rails:16 > > --------------------------end log ------------------------------------ > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071002/58673021/attachment-0001.html From wayneeseguin at gmail.com Mon Oct 1 16:25:39 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Mon, 1 Oct 2007 16:25:39 -0400 Subject: [Mongrel] Error with Mongrel_cluster In-Reply-To: References: Message-ID: On 10/1/07, Wayne E. Seguin wrote: > > On 10/1/07, Sid Jay wrote: > > > > Hi Guys, > > I'm getting this error with mongrel_cluster. I am able to start mongrel > > through mongrel_rails start but the cluster is not working. Initially > > mongrel_rails wouldn't work but after I added $ORACLE_HOME and > > $PD_LIBRARY_PATH variables it worked but mongrel_cluster isn't working > > still. The mongrel log file looks like below. > > Any help is appreciated. > > Thanks. > > > Also, are you also making sure that you use "export " when assigning the $ORACLE_HOME and $PD_LIBRARY_PATH variables? (assuming you're using bash) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071001/af40c202/attachment.html From sid.webnews at gmail.com Mon Oct 1 16:48:55 2007 From: sid.webnews at gmail.com (Sid News) Date: Mon, 1 Oct 2007 15:48:55 -0500 Subject: [Mongrel] Error with Mongrel_cluster In-Reply-To: References: Message-ID: <8ce27c380710011348m418c14d5hd067ef51c5b9835e@mail.gmail.com> Guys, Thanks for the replies. This is how my .bashrc looks like -----begin .bashrc .............. >more .bashrc #/etc/profile: system-wide .profile file for the Bourne shell (sh(1)) # and Bourne compatible shells (bash(1), ksh(1), ash(1), ...). ORACLE_HOME=/usr/lib/oracle/10.2.0.3/client PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/usr/lib/oracle/10.2.0.3/client/bin LD_LIBRARY_PATH=/usr/lib/oracle/10.2.0.3/client/lib export ORACLE_HOME export LD_LIBRARY_PATH if [ "$PS1" ]; then if [ "$BASH" ]; then PS1='>' fi fi umask 022 -------------------------------------------------- I follow these instructions to setup my mongrel_cluster http://mongrel.rubyforge.org/docs/mongrel_cluster.html The mongrel_cluster and mongrel_rails both worked fine, but my supervisor installed oci8 or oracle and then when i try to start mongrel_rails it would give me the same error. Googling it led me to add the environment variables $ORACLE_HOME and $LD_LIBRARY_PATH , after that mongrel_rails works. But mongrel_cluster is still broken and I'm not sure what more do I need to do to get it back running. I must be missing something about mongrel_cluster. My setup is Ubuntu 6.06.1 LTS , nginx (webserver) ruby 1.8.4 Thanks. On 10/1/07, Wayne E. Seguin wrote: > > > > On 10/1/07, Wayne E. Seguin wrote: > > > > On 10/1/07, Sid Jay wrote: > > > > > > Hi Guys, > > > I'm getting this error with mongrel_cluster. I am able to start > > > mongrel through mongrel_rails start but the cluster is not working. > > > Initially mongrel_rails wouldn't work but after I added $ORACLE_HOME and > > > $PD_LIBRARY_PATH variables it worked but mongrel_cluster isn't working > > > still. The mongrel log file looks like below. > > > Any help is appreciated. > > > Thanks. > > > > > > > Also, are you also making sure that you use "export " when assigning the > $ORACLE_HOME and $PD_LIBRARY_PATH variables? (assuming you're using bash) > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071001/804131c3/attachment.html From wayneeseguin at gmail.com Mon Oct 1 16:52:50 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Mon, 1 Oct 2007 16:52:50 -0400 Subject: [Mongrel] Error with Mongrel_cluster In-Reply-To: <8ce27c380710011348m418c14d5hd067ef51c5b9835e@mail.gmail.com> References: <8ce27c380710011348m418c14d5hd067ef51c5b9835e@mail.gmail.com> Message-ID: On 10/1/07, Sid News wrote: > > I follow these instructions to setup my mongrel_cluster > http://mongrel.rubyforge.org/docs/mongrel_cluster.html > > The mongrel_cluster and mongrel_rails both worked fine, but my supervisor > installed oci8 or oracle and then when i try to start mongrel_rails it would > give me the same error. Googling it led me to add the environment variables > $ORACLE_HOME and $LD_LIBRARY_PATH , after that mongrel_rails works. > But mongrel_cluster is still broken and I'm not sure what more do I need > to do to get it back running. I must be missing something about > mongrel_cluster. > > My setup is Ubuntu 6.06.1 LTS , nginx (webserver) ruby 1.8.4 > Thanks. Sid, I would try to re-install (or install if you don't have it) the oci8 adaptor to force it to rebuild against the new oracle installation. sudo gem uninstall ruby-oci8 sudo gem install ruby-oci8 http://rubyforge.org/projects/ruby-oci8/ Let us know if this works. Best, ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071001/c512f8ab/attachment.html From rogerpack2005 at gmail.com Mon Oct 1 16:59:33 2007 From: rogerpack2005 at gmail.com (Roger Pack) Date: Mon, 1 Oct 2007 14:59:33 -0600 Subject: [Mongrel] Error with Mongrel_cluster Message-ID: <966599840710011359j44d92390s2667ff5c5d7d5970@mail.gmail.com> Here's a link for some code that I once used to fight a somewhat similar problem. http://dev.rubyonrails.org/ticket/7452#comment:41 From sid.webnews at gmail.com Mon Oct 1 17:08:02 2007 From: sid.webnews at gmail.com (Sid News) Date: Mon, 1 Oct 2007 16:08:02 -0500 Subject: [Mongrel] Error with Mongrel_cluster In-Reply-To: References: <8ce27c380710011348m418c14d5hd067ef51c5b9835e@mail.gmail.com> Message-ID: <8ce27c380710011408j60c21242u3418786ee264badb@mail.gmail.com> Wayne, surprisingly i'm getting this error now: --------------begin error----------------- >sudo gem install ruby-oci8 ERROR: While executing gem ... (Gem::GemNotFoundException) Could not find ruby-oci8 (> 0) in any repository ---------end error ----------------------------- On 10/1/07, Wayne E. Seguin wrote: > > On 10/1/07, Sid News wrote: > > > > I follow these instructions to setup my mongrel_cluster http://mongrel.rubyforge.org > > /docs/mongrel_cluster.html > > > > The mongrel_cluster and mongrel_rails both worked fine, but my > > supervisor installed oci8 or oracle and then when i try to start > > mongrel_rails it would give me the same error. Googling it led me to add the > > environment variables $ORACLE_HOME and $LD_LIBRARY_PATH , after that > > mongrel_rails works. > > But mongrel_cluster is still broken and I'm not sure what more do I need > > to do to get it back running. I must be missing something about > > mongrel_cluster. > > > > My setup is Ubuntu 6.06.1 LTS , nginx (webserver) ruby 1.8.4 > > Thanks. > > > Sid, > > I would try to re-install (or install if you don't have it) the oci8 > adaptor to force it to rebuild against the new oracle installation. > > sudo gem uninstall ruby-oci8 > sudo gem install ruby-oci8 > > http://rubyforge.org/projects/ruby-oci8/ > > Let us know if this works. > > Best, > > ~Wayne > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071001/d883d7dd/attachment.html From wayneeseguin at gmail.com Mon Oct 1 21:12:17 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Mon, 1 Oct 2007 21:12:17 -0400 Subject: [Mongrel] Error with Mongrel_cluster In-Reply-To: <8ce27c380710011408j60c21242u3418786ee264badb@mail.gmail.com> References: <8ce27c380710011348m418c14d5hd067ef51c5b9835e@mail.gmail.com> <8ce27c380710011408j60c21242u3418786ee264badb@mail.gmail.com> Message-ID: On 10/1/07, Sid News wrote: > > Wayne, > surprisingly i'm getting this error now: You can download the gem manually from here and install from local: http://rubyforge.org/frs/?group_id=256&release_id=12694 The ruby-oci8 project page is here: http://ruby-oci8.rubyforge.org/en/ For example, on Linux you might do: wget http://rubyforge.org/frs/download.php/22320/ruby-oci8-1.0.0-rc3.tar.gz tar zxvf ruby-oci8-1.0.0-rc3.tar.gz cd ruby-oci8-1.0.0-rc3 make sudo make install I hope this helps. ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071001/0c5d0249/attachment-0001.html From ctmailinglists at googlemail.com Tue Oct 2 05:08:42 2007 From: ctmailinglists at googlemail.com (Chris T) Date: Tue, 02 Oct 2007 10:08:42 +0100 Subject: [Mongrel] Mongrel using way more memory on production than staging. Any ideas why? Message-ID: <47020A9A.5080609@googlemail.com> I've been trying to track down the culprit of erratic behaviour and crashes on my production server (which is split into a number of Xen instances), so set up a staging server so that I could really try to get to the bottom of it. The staging server (also split with Xen) is set up pretty much identically as far as the mongrel_cluster server is concerned (the production box has two servers/instances for mongrel_cluster each with 4 mongrels per cluster vs one server on the staging box with 2 mongrels per cluster -- otherwise they are the same: both Debian Etch, same gems, same Ruby - 1.8.5, same mongrel versions - 1.0.1, same mongrel_cluster - 1.0.2). Oh, and the data on the staging one is a clone of the production one. On the production box, pretty much immediately (and I'm talking about within one or two requests), the mongrels climb up to about 150-160MB. One the staging server, even when I'm hammering it with a benchmarking suite (have tried with httperf, and bench and crawl) the mongrels sit comfortably at about 60MB each. Here's some stats from top: Production server: top - 08:38:43 up 22 days, 13:21, 1 user, load average: 0.24, 0.23, 0.15 Tasks: 33 total, 3 running, 30 sleeping, 0 stopped, 0 zombie Cpu(s): 16.6%us, 24.5%sy, 0.0%ni, 51.0%id, 0.0%wa, 0.0%hi, 3.6%si, 4.3%st Mem: 524288k total, 384528k used, 139760k free, 1576k buffers Swap: 262136k total, 1352k used, 260784k free, 19644k cached and from ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND mongrel 20387 2.6 18.5 148780 97228 ? Sl 08:36 0:11 /usr/bin/ruby1.8 /usr/bin/mongrel_rail mongrel 20390 2.8 19.4 153396 101940 ? Sl 08:36 0:13 /usr/bin/ruby1.8 /usr/bin/mongrel_rail mongrel 20393 4.1 19.6 154356 102936 ? Sl 08:36 0:18 /usr/bin/ruby1.8 /usr/bin/mongrel_rail mongrel 20396 4.7 18.8 150124 98576 ? Rl 08:36 0:21 /usr/bin/ruby1.8 /usr/bin/mongrel_rail And here's the corresponding staging server ones: top - 10:00:55 up 15:22, 1 user, load average: 0.00, 0.01, 0.15 Tasks: 29 total, 2 running, 27 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 1.0%st Mem: 262336k total, 203064k used, 59272k free, 1156k buffers Swap: 262136k total, 4k used, 262132k free, 58636k cached USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND mongrel 3617 7.2 16.8 58808 44296 ? Sl 09:28 2:28 /usr/bin/ruby1.8 /usr/bin/mongrel_rail mongrel 3620 7.1 16.7 58424 43912 ? Sl 09:28 2:26 /usr/bin/ruby1.8 /usr/bin/mongrel_rail Anybody got any suggestions, or at least thoughts on tracking down the issues? Thanks, Chris -- ---------------------------- Autopendium :: Stuff about old cars http://autopendium.com From johan at johansorensen.com Tue Oct 2 05:27:20 2007 From: johan at johansorensen.com (=?ISO-8859-1?Q?Johan_S=F8rensen?=) Date: Tue, 2 Oct 2007 11:27:20 +0200 Subject: [Mongrel] Mongrel using way more memory on production than staging. Any ideas why? In-Reply-To: <47020A9A.5080609@googlemail.com> References: <47020A9A.5080609@googlemail.com> Message-ID: <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> On Oct 2, 2007, at 11:08 AM, Chris T wrote: > The staging server (also split with Xen) is set up pretty much > identically > > On the production box, pretty much immediately (and I'm talking about > within one or two requests), the mongrels climb up to about 150-160MB. > One the staging server, even when I'm hammering it with a benchmarking > suite (have tried with httperf, and bench and crawl) the mongrels sit > comfortably at about 60MB each. Same box, hardware+kernel wise (32 vs 64 bit)? Libraries built the same way? JS From dave at cheney.net Tue Oct 2 06:06:36 2007 From: dave at cheney.net (Dave Cheney) Date: Tue, 2 Oct 2007 06:06:36 -0400 Subject: [Mongrel] Mongrel using way more memory on production thanstaging. Any ideas why? In-Reply-To: <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> References: <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> Message-ID: <2034dbd20cd61125d50a1cedf42c1474@localhost> >> The staging server (also split with Xen) is set up pretty much >> identically >> >> On the production box, pretty much immediately (and I'm talking about >> within one or two requests), the mongrels climb up to about 150-160MB. >> One the staging server, even when I'm hammering it with a benchmarking >> suite (have tried with httperf, and bench and crawl) the mongrels sit >> comfortably at about 60MB each. Your issue may be related to the amount of data in your production database. In our codebase we're constantly be hit by AR calls that bring the whole table into memory, then filter out the bits they don't want rails side. In development we don't notice the bloat or delay but under a production dataset the effect was pronounced. Cheers Dave From ctmailinglists at googlemail.com Tue Oct 2 06:31:30 2007 From: ctmailinglists at googlemail.com (Chris T) Date: Tue, 02 Oct 2007 11:31:30 +0100 Subject: [Mongrel] Mongrel using way more memory on production than staging. Any ideas why? In-Reply-To: <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> Message-ID: <47021E02.2000905@googlemail.com> Johan S?rensen wrote: > > On Oct 2, 2007, at 11:08 AM, Chris T wrote: > >> The staging server (also split with Xen) is set up pretty much >> identically >> >> On the production box, pretty much immediately (and I'm talking about >> within one or two requests), the mongrels climb up to about 150-160MB. >> One the staging server, even when I'm hammering it with a benchmarking >> suite (have tried with httperf, and bench and crawl) the mongrels sit >> comfortably at about 60MB each. > > Same box, hardware+kernel wise (32 vs 64 bit)? Libraries built the > same way? > > JS > > No, the production box is Athlon64 X2 3800, the staging one i386 (actually a Pentium 4 I had lying around). However the ruby libraries were built the same way: sudo apt-get install ruby1.8 libzlib-ruby rdoc irb ruby1.8-dev libopenssl-ruby1.8 On production: #ruby -v ruby 1.8.5 (2006-08-25) [x86_64-linux] On staging: #ruby -v ruby 1.8.5 (2006-08-25) [i486-linux] -- ---------------------------- Autopendium :: Stuff about old cars http://autopendium.com From lists at ruby-forum.com Tue Oct 2 06:35:53 2007 From: lists at ruby-forum.com (Chris Taggart) Date: Tue, 2 Oct 2007 12:35:53 +0200 Subject: [Mongrel] Mongrel using way more memory on production thanstaging. In-Reply-To: <2034dbd20cd61125d50a1cedf42c1474@localhost> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <2034dbd20cd61125d50a1cedf42c1474@localhost> Message-ID: <9547f6bad80fba92abba9a5f2fd70926@ruby-forum.com> Dave Cheney wrote: >>> The staging server (also split with Xen) is set up pretty much >>> identically >>> >>> On the production box, pretty much immediately (and I'm talking about >>> within one or two requests), the mongrels climb up to about 150-160MB. >>> One the staging server, even when I'm hammering it with a benchmarking >>> suite (have tried with httperf, and bench and crawl) the mongrels sit >>> comfortably at about 60MB each. > > Your issue may be related to the amount of data in your production > database. In our codebase we're constantly be hit by AR calls that bring > the whole table into memory, then filter out the bits they don't want > rails > side. > > In development we don't notice the bloat or delay but under a production > dataset the effect was pronounced. > > Cheers > > Dave The staging server is using a copy of the production database, so that can't be it (though I thought it might be before setting up the staging server). -- Posted via http://www.ruby-forum.com/. From dee.zsombor at gmail.com Tue Oct 2 10:56:11 2007 From: dee.zsombor at gmail.com (Dee Zsombor) Date: Tue, 02 Oct 2007 17:56:11 +0300 Subject: [Mongrel] Mongrel using way more memory on production than staging. Any ideas why? In-Reply-To: <47021E02.2000905@googlemail.com> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> Message-ID: <47025C0B.1000701@gmail.com> Chris T wrote: > No, the production box is Athlon64 X2 3800, the staging one i386 > (actually a Pentium 4 I had lying around). However the ruby libraries > were built the same way: > > sudo apt-get install ruby1.8 libzlib-ruby rdoc irb ruby1.8-dev > libopenssl-ruby1.8 > > On production: > #ruby -v > ruby 1.8.5 (2006-08-25) [x86_64-linux] > > On staging: > #ruby -v > ruby 1.8.5 (2006-08-25) [i486-linux] This explains it well, pointers are 8 byte long on 64 bit while only 4 byte long on 32 bit. Each ruby object is essentially a pointer (plus some other magic encoded in the byte alignment and misc other data). A ruby process is bound to be more heavy on 64 bit. You can use a 64 bit db server and keep the application servers 32, this should give some benefits while trading in some uniformity. -- Company - http://primalgrasp.com Thoughts - http://deezsombor.blogspot.com From cremes.devlist at mac.com Tue Oct 2 10:56:34 2007 From: cremes.devlist at mac.com (Chuck Remes) Date: Tue, 2 Oct 2007 09:56:34 -0500 Subject: [Mongrel] performance observation on redhat In-Reply-To: <20070923104135.e7c28jtlno4w8wcc@lcgalaska.com> References: <20070923063054.43DE710A3D2@ws6-4.us4.outblaze.com> <0451432B-F007-443E-9831-F9B26B028F1A@gmail.com> <20070923104135.e7c28jtlno4w8wcc@lcgalaska.com> Message-ID: On Sep 23, 2007, at 1:41 PM, barsalou wrote: > Armin, > > Since your goofing around with that, how about some of the other > settings like maxtime and ttl values? > > Seems like you have deleayd when some garbage collection operations > are > taking place, so maybe tweeking that a little more will give you the > performance your looking for. > > I've never used this feature, but thought that might interesting as > well. > > Mike B. > > Quoting "Wayne E. Seguin" : > >> On Sep 23, 2007, at 02:30 , armin roehrl wrote: >>> Hi, >>> >>> I made an interesting observation using webservers (not just >>> mongrel) under red hat enterprise >>> linux ES release 4 (Nahant Update 5). Maybe this is helpful or >>> somebody with deeper networking >>> expertise can comment on this. >>> >>> [snip] >>> echo 500000 > /proc/sys/net/ipv4/inet_peer_threshold >>> >>> There is a trade-off here. A too small value causes too many delays >>> from inet-peer-storage cleaning >>> and a too big value makes life well for some limited time, but when >>> it hits you, it becomes really expensive. >>> >>> Did you ever see this? >>> >>> Thanks, >>> -Armin >> >> Armin, >> >> We might put this in the documentation, will discuss with the dev >> team. I've searched all over the place to confirm this issue with RHEL 4 update 5 and have come up empty. What's the original source of the "fix" ? Also, any suggestions on how to build a test harness to confirm new values actually *improve* the situation rather than make it worse? cr From wayneeseguin at gmail.com Tue Oct 2 12:44:12 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Tue, 2 Oct 2007 12:44:12 -0400 Subject: [Mongrel] Mongrel using way more memory on production than staging. Any ideas why? In-Reply-To: <47021E02.2000905@googlemail.com> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> Message-ID: On 10/2/07, Chris T wrote: > > Johan S?rensen wrote: > > > > On Oct 2, 2007, at 11:08 AM, Chris T wrote: > > > >> The staging server (also split with Xen) is set up pretty much > >> identically > >> > >> On the production box, pretty much immediately (and I'm talking about > >> within one or two requests), the mongrels climb up to about 150-160MB. > >> One the staging server, even when I'm hammering it with a benchmarking > >> suite (have tried with httperf, and bench and crawl) the mongrels sit > >> comfortably at about 60MB each. > > > > Same box, hardware+kernel wise (32 vs 64 bit)? Libraries built the > > same way? > > > > JS > > > > > No, the production box is Athlon64 X2 3800, the staging one i386 > (actually a Pentium 4 I had lying around). However the ruby libraries > were built the same way: > > sudo apt-get install ruby1.8 libzlib-ruby rdoc irb ruby1.8-dev > libopenssl-ruby1.8 > > On production: > #ruby -v > ruby 1.8.5 (2006-08-25) [x86_64-linux] > > On staging: > #ruby -v > ruby 1.8.5 (2006-08-25) [i486-linux] > I have not personally encountered this issue, however I also do not use apt-get to install anything in the Ruby application stack. I compile everything by hand. I'd recommend trying that next (compile-install Ruby and RubyGems) on the production server. Most production servers I work with are also 64 bit Linux boxes and as I said, I compile everything and haven't seen this issue. I hope that this helps, ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071002/1dbe9356/attachment.html From alexey.verkhovsky at gmail.com Tue Oct 2 13:07:00 2007 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Tue, 2 Oct 2007 11:07:00 -0600 Subject: [Mongrel] Mongrel using way more memory on production than staging. Any ideas why? In-Reply-To: <47020A9A.5080609@googlemail.com> References: <47020A9A.5080609@googlemail.com> Message-ID: <3945c4270710021007p67e327a6l8e8932bd7c913774@mail.gmail.com> On 10/2/07, Chris T wrote: > On the production box, pretty much immediately (and I'm talking about > within one or two requests), the mongrels climb up to about 150-160MB. > One the staging server, even when I'm hammering it with a benchmarking > suite (have tried with httperf, and bench and crawl) the mongrels sit > comfortably at about 60MB each. It is the difference between x86_64 and i386, mostly. Some of it may also be that you are not hitting Mongrel hard enough in staging. An overloaded Mongrel with default --num-procs setting of 1024 should eventually allocate enough memory for 1024 request handler threads, which takes even a skeleton Rails app above 60 Mb level. -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From lists at ruby-forum.com Tue Oct 2 15:21:53 2007 From: lists at ruby-forum.com (Chris Taggart) Date: Tue, 2 Oct 2007 21:21:53 +0200 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: <47025C0B.1000701@gmail.com> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <47025C0B.1000701@gmail.com> Message-ID: <856fa1fb938b79b13c8fbb81e2170dff@ruby-forum.com> Dee Zsombor wrote: > Chris T wrote: >> >> On staging: >> #ruby -v >> ruby 1.8.5 (2006-08-25) [i486-linux] > > > This explains it well, pointers are 8 byte long on 64 bit while only 4 > byte long on 32 bit. Each ruby object is essentially a pointer (plus > some > other magic encoded in the byte alignment and misc other data). A ruby > process is bound to be more heavy on 64 bit. > > You can use a 64 bit db server and keep the application servers 32, this > should give some benefits while trading in some uniformity. OK. I think I get this. How do i ensure the app servers are 32 bit. Do I need to use a 32-bit kernel when creating up the instances? -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Tue Oct 2 15:23:18 2007 From: lists at ruby-forum.com (Chris Taggart) Date: Tue, 2 Oct 2007 21:23:18 +0200 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> Message-ID: <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> Wayne E. Seguin wrote: > On 10/2/07, Chris T wrote: >> >> One the staging server, even when I'm hammering it with a benchmarking >> (actually a Pentium 4 I had lying around). However the ruby libraries >> #ruby -v >> ruby 1.8.5 (2006-08-25) [i486-linux] >> > > I have not personally encountered this issue, however I also do not use > apt-get to install anything in the Ruby application stack. I compile > everything by hand. I'd recommend trying that next (compile-install Ruby > and > RubyGems) on the production server. > > Most production servers I work with are also 64 bit Linux boxes and as I > said, I compile everything and haven't seen this issue. > > I hope that this helps, > > ~Wayne I may try that -- set up a test instance same as other ones but with Ruby compiled by hand. Did it once before and seem to remember it wasn't too bad. -- Posted via http://www.ruby-forum.com/. From evan at cloudbur.st Tue Oct 2 16:09:45 2007 From: evan at cloudbur.st (Evan Weaver) Date: Tue, 2 Oct 2007 16:09:45 -0400 Subject: [Mongrel] Mongrel using way more memory on production than staging. Any ideas why? In-Reply-To: <47025C0B.1000701@gmail.com> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <47025C0B.1000701@gmail.com> Message-ID: I really doubt the pointers are giving you 120% more memory usage. Overhead from switching from 32bit to 64bit addressing is usually about 15%. Evan On 10/2/07, Dee Zsombor wrote: > Chris T wrote: > > No, the production box is Athlon64 X2 3800, the staging one i386 > > (actually a Pentium 4 I had lying around). However the ruby libraries > > were built the same way: > > > > sudo apt-get install ruby1.8 libzlib-ruby rdoc irb ruby1.8-dev > > libopenssl-ruby1.8 > > > > On production: > > #ruby -v > > ruby 1.8.5 (2006-08-25) [x86_64-linux] > > > > On staging: > > #ruby -v > > ruby 1.8.5 (2006-08-25) [i486-linux] > > > This explains it well, pointers are 8 byte long on 64 bit while only 4 > byte long on 32 bit. Each ruby object is essentially a pointer (plus some > other magic encoded in the byte alignment and misc other data). A ruby > process is bound to be more heavy on 64 bit. > > You can use a 64 bit db server and keep the application servers 32, this > should give some benefits while trading in some uniformity. > > > -- > Company - http://primalgrasp.com > Thoughts - http://deezsombor.blogspot.com > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From alexey.verkhovsky at gmail.com Tue Oct 2 16:39:07 2007 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Tue, 2 Oct 2007 14:39:07 -0600 Subject: [Mongrel] Mongrel using way more memory on production than staging. Any ideas why? In-Reply-To: References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <47025C0B.1000701@gmail.com> Message-ID: <3945c4270710021339h7473be51na1414850b2f6dc32@mail.gmail.com> On 10/2/07, Evan Weaver wrote: > I really doubt the pointers are giving you 120% more memory usage. > Overhead from switching from 32bit to 64bit addressing is usually > about 15%. Usually, yes. And yet RSS of a Mongrel process running a skeleton Rails app is ~20 Mb on i386 and ~32 Mb on x86_64. -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From wayneeseguin at gmail.com Tue Oct 2 17:23:47 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Tue, 2 Oct 2007 17:23:47 -0400 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> Message-ID: This is something like what I use, modify to your own designs: mkdir ~/src package=ruby cd ~/src && curl -O ftp://ftp.ruby-lang.org/pub/ruby/stable-snapshot.tar.gz tar zxf stable-snapshot.tar.gz && cd ruby && ./configure --prefix=/usr/local --disable-pthread --with-readline-dir=/usr/local make && sudo make install && cd ~/src -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071002/a709f7b4/attachment.html From lists at ruby-forum.com Tue Oct 2 18:15:13 2007 From: lists at ruby-forum.com (Chris Taggart) Date: Wed, 3 Oct 2007 00:15:13 +0200 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> Message-ID: <067354a69ac7d64ccd5c202218ede245@ruby-forum.com> Wayne E. Seguin wrote: > This is something like what I use, modify to your own designs: > > mkdir ~/src > > package=ruby > > cd ~/src && curl -O > ftp://ftp.ruby-lang.org/pub/ruby/stable-snapshot.tar.gz > > tar zxf stable-snapshot.tar.gz && cd ruby && ./configure > --prefix=/usr/local > --disable-pthread --with-readline-dir=/usr/local > > make && sudo make install && cd ~/src OK. Will try a few things out tomorrow and report back. -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Wed Oct 3 09:12:01 2007 From: lists at ruby-forum.com (Chris Taggart) Date: Wed, 3 Oct 2007 15:12:01 +0200 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: <067354a69ac7d64ccd5c202218ede245@ruby-forum.com> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> <067354a69ac7d64ccd5c202218ede245@ruby-forum.com> Message-ID: <5fa4f4f91a463cf08f87851d6975e77c@ruby-forum.com> Chris Taggart wrote: > Wayne E. Seguin wrote: >> This is something like what I use, modify to your own designs: >> >> mkdir ~/src >> >> package=ruby >> >> cd ~/src && curl -O >> ftp://ftp.ruby-lang.org/pub/ruby/stable-snapshot.tar.gz >> >> tar zxf stable-snapshot.tar.gz && cd ruby && ./configure >> --prefix=/usr/local >> --disable-pthread --with-readline-dir=/usr/local >> >> make && sudo make install && cd ~/src > > OK. Will try a few things out tomorrow and report back. Update on what I've tried/found out so far. Set up a testbed xen server instance on the same box (AMD64x2) as my mongrel clusters. It's not quite a direct comparison as I compiled Ruby from source, whereas the staging server was installed from binaries via apt-get. I then ran stand alone mongrel in the same production environment with the same data on both server, and threw various requests at it via curl. The results are here: http://spreadsheets.google.com/pub?key=pHDcT1cywdrovBLlL7QV8Ow but briefly: -- on startup (before any requests have been made), the testbed (64-bit) server uses 87% more memory than the staging one (78MB vs 42MB) -- on the first request, both increase memory usage by 17%, and then both gradually climb by varying percentages, though the testbed's mem usage is always 80-95% more than the 32-bit staging server. -- memory usage increases inconsistently, sometimes staying the same when the requests are repeated, sometimes increasing. I'm wondering if this could be a memory leak to do with caching (which might explain why it wasn't showing up when I was httperf'ing the staging server). There's obviously more work to be done here, but all comments and suggestions are welcome. This is new territory for me, so I may be missing something completely obvious. Cheers Chris -- Posted via http://www.ruby-forum.com/. From zedshaw at zedshaw.com Wed Oct 3 11:59:52 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Wed, 3 Oct 2007 11:59:52 -0400 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: <5fa4f4f91a463cf08f87851d6975e77c@ruby-forum.com> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> <067354a69ac7d64ccd5c202218ede245@ruby-forum.com> <5fa4f4f91a463cf08f87851d6975e77c@ruby-forum.com> Message-ID: <20071003115952.08217eef.zedshaw@zedshaw.com> On Wed, 3 Oct 2007 15:12:01 +0200 Chris Taggart wrote: > Update on what I've tried/found out so far. > > http://spreadsheets.google.com/pub?key=pHDcT1cywdrovBLlL7QV8Ow What's funny is I've been stuggling with JRuby Rails applications running under *any* application server requring 2G (yes gigabytes) of RAM just to function. Many times we'd have to do complete restarts about 1 or 2 times a week. So it's strange to hear someone say that 120M is too much. :-) -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From wyhaines at gmail.com Wed Oct 3 12:35:08 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Wed, 3 Oct 2007 09:35:08 -0700 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: <5fa4f4f91a463cf08f87851d6975e77c@ruby-forum.com> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> <067354a69ac7d64ccd5c202218ede245@ruby-forum.com> <5fa4f4f91a463cf08f87851d6975e77c@ruby-forum.com> Message-ID: On 10/3/07, Chris Taggart wrote: > -- on startup (before any requests have been made), the testbed (64-bit) > server uses 87% more memory than the staging one (78MB vs 42MB) This appears to be in the reasonable ballpark of what to expect, based on my testing with a bunch of different frameworks. > -- on the first request, both increase memory usage by 17%, and then > both gradually climb by varying percentages, though the testbed's mem > usage is always 80-95% more than the 32-bit staging server. The initial bump is probably a factor of Rails and of your application's object initializations. An ongoing memory increase, though, is caused either by your application intentionally caching things in RAM, or by something leaking. RAM usage should stay pretty stable. > -- memory usage increases inconsistently, sometimes staying the same > when the requests are repeated, sometimes increasing. I'm wondering if > this could be a memory leak to do with caching (which might explain why > it wasn't showing up when I was httperf'ing the staging server). It could be. It could be that something your app is using is leaking, or that you are hitting a memory leak in Ruby. As of 1.8.6, the Array#shift bug is fixed, but there are probably others. I demonstrated a leak a few months ago in one of the get*by* methods. gethostbyname, IIRC, and I have no doubt that if one took the time to look into this intently, other leaky libs could be found. Do you use rmagick? Historically, people have had a lot of memory leak issues with it. > There's obviously more work to be done here, but all comments and > suggestions are welcome. This is new territory for me, so I may be > missing something completely obvious. Tracking down memory leaks in Ruby is a labor intensive process. Good luck. Kirk Haines From lists at ruby-forum.com Wed Oct 3 14:52:20 2007 From: lists at ruby-forum.com (Chris Taggart) Date: Wed, 3 Oct 2007 20:52:20 +0200 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: <20071003115952.08217eef.zedshaw@zedshaw.com> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> <067354a69ac7d64ccd5c202218ede245@ruby-forum.com> <5fa4f4f91a463cf08f87851d6975e77c@ruby-forum.com> <20071003115952.08217eef.zedshaw@zedshaw.com> Message-ID: <28135f2b83f4ec97d8b1dd2f3d5c25c1@ruby-forum.com> Zed A. Shaw wrote: > On Wed, 3 Oct 2007 15:12:01 +0200 > Chris Taggart wrote: > >> Update on what I've tried/found out so far. >> >> http://spreadsheets.google.com/pub?key=pHDcT1cywdrovBLlL7QV8Ow > > What's funny is I've been stuggling with JRuby Rails applications > running under *any* application server requring 2G (yes gigabytes) of > RAM just to function. Many times we'd have to do complete restarts > about 1 or 2 times a week. > > So it's strange to hear someone say that 120M is too much. :-) > > -- > Zed A. Shaw > - Hate: http://savingtheinternetwithhate.com/ > - Good: http://www.zedshaw.com/ > - Evil: http://yearofevil.com/ The problem isn't 120M -- but that it seems to keep climbing until much instability ensues... That's possibly a leak, but I'm still a bit confused as to why the 64-bit server is using so much more... and whether I should maybe run the mongrel_cluster instances on 32-bit kernel (assuming that's possible). -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Wed Oct 3 15:05:47 2007 From: lists at ruby-forum.com (Chris Taggart) Date: Wed, 3 Oct 2007 21:05:47 +0200 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> <067354a69ac7d64ccd5c202218ede245@ruby-forum.com> <5fa4f4f91a463cf08f87851d6975e77c@ruby-forum.com> Message-ID: <7a1c5334d7ac6ca7a91ba11f4ab934d8@ruby-forum.com> Kirk Haines wrote: > On 10/3/07, Chris Taggart wrote: >> -- on startup (before any requests have been made), the testbed (64-bit) >> server uses 87% more memory than the staging one (78MB vs 42MB) > > This appears to be in the reasonable ballpark of what to expect, based > on my testing with a bunch of different frameworks. So just to clarify, the 80%+ is not uncommon for 64-bit vs 32-bit. Any benefits (as far as mongrel is concerned) to being on 64-bt, or (if it's possible) is it worth running the app servers on 32-bit kernels? > >> -- on the first request, both increase memory usage by 17%, and then >> both gradually climb by varying percentages, though the testbed's mem >> usage is always 80-95% more than the 32-bit staging server. > > The initial bump is probably a factor of Rails and of your > application's object initializations. > That's what I figured > An ongoing memory increase, though, is caused either by your > application intentionally caching things in RAM, or by something > leaking. RAM usage should stay pretty stable. > The caching is all done using fragment caching (on disk -- haven't yet investigated memcached). >> -- memory usage increases inconsistently, sometimes staying the same >> when the requests are repeated, sometimes increasing. I'm wondering if >> this could be a memory leak to do with caching (which might explain why >> it wasn't showing up when I was httperf'ing the staging server). > > It could be. It could be that something your app is using is leaking, > or that you are hitting a memory leak in Ruby. As of 1.8.6, the > Array#shift bug is fixed, but there are probably others. I > demonstrated a leak a few months ago in one of the get*by* methods. > gethostbyname, IIRC, and I have no doubt that if one took the time to > look into this intently, other leaky libs could be found. Do you use > rmagick? Historically, people have had a lot of memory leak issues > with it. > I'd read about the Array#shift bug and had removed it everywhere but one place (must do that), but doing a search of the app see that it's used elsewhere, including a number of plugins and rails itself. I ditched rmagick some time ago due to concerns about it and no use ImageScience. >> There's obviously more work to be done here, but all comments and >> suggestions are welcome. This is new territory for me, so I may be >> missing something completely obvious. > > Tracking down memory leaks in Ruby is a labor intensive process. Good > luck. > Any suggestions for best practice/howtos/etc? > > Kirk Haines -- Posted via http://www.ruby-forum.com/. From zedshaw at zedshaw.com Wed Oct 3 16:15:26 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Wed, 3 Oct 2007 16:15:26 -0400 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: <28135f2b83f4ec97d8b1dd2f3d5c25c1@ruby-forum.com> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> <067354a69ac7d64ccd5c202218ede245@ruby-forum.com> <5fa4f4f91a463cf08f87851d6975e77c@ruby-forum.com> <20071003115952.08217eef.zedshaw@zedshaw.com> <28135f2b83f4ec97d8b1dd2f3d5c25c1@ruby-forum.com> Message-ID: <20071003161526.374fb911.zedshaw@zedshaw.com> On Wed, 3 Oct 2007 20:52:20 +0200 Chris Taggart wrote: > Zed A. Shaw wrote: > The problem isn't 120M -- but that it seems to keep climbing until much > instability ensues... > > That's possibly a leak, but I'm still a bit confused as to why the > 64-bit server is using so much more... and whether I should maybe run > the mongrel_cluster instances on 32-bit kernel (assuming that's > possible). I haven't tracked all the different things you've done, but have you tried: 1) Running with mongrel_rails -B and looking in the log/mongrel_debug/* files? Specifically objects.log 2) Trying bleakhouse? 3) Running it on jruby? See if you still have the leak there. If you've got a leak under jruby then it's your code dude. Apart from that, I've got no idea. Last time I dealt with this crap with the horrible Ruby GC implementation the entire Ruby world took out torches and chased me down the street screaming that I was ruining their party be exposing how crap the code is. But hey, that's just me. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From wyhaines at gmail.com Wed Oct 3 16:26:17 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Wed, 3 Oct 2007 13:26:17 -0700 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: <20071003161526.374fb911.zedshaw@zedshaw.com> References: <47020A9A.5080609@googlemail.com> <47021E02.2000905@googlemail.com> <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> <067354a69ac7d64ccd5c202218ede245@ruby-forum.com> <5fa4f4f91a463cf08f87851d6975e77c@ruby-forum.com> <20071003115952.08217eef.zedshaw@zedshaw.com> <28135f2b83f4ec97d8b1dd2f3d5c25c1@ruby-forum.com> <20071003161526.374fb911.zedshaw@zedshaw.com> Message-ID: On 10/3/07, Zed A. Shaw wrote: > Apart from that, I've got no idea. Last time I dealt with this crap with the > horrible Ruby GC implementation the entire Ruby world took out > torches and chased me down the street screaming that I was ruining > their party be exposing how crap the code is. Hey now. I was one of those torch carriers, but all I was worried about was making sure we were pointing in the right direction in identifying the real memory leak instead of just villifying poor, innocent Mutex. In the end, it was the influence of that dastardly Array#shift that had turned Mutex into the problem causing bad boy. What's really appalling is how long it took after that time before Array#shift was actually fixed in a ruby release. It should have been fixed in 1.8.5. I suspect that the leak in the gethostbyname code is a similar sort of sloppiness that had been overlooked (and probably still exists in 1.9). Chris, you asked about suggestions on how track down memory leaks. What Zed said. In addition, you can manually write code to check ObjectSpace object counts. If you suspect that the problem is actually at Ruby or C/C++ extension level, you can also use a tool like valgrind to analyze running code and see if you can pinpoint anything that is actualy a problem. Kirk Haines From lists at ruby-forum.com Wed Oct 3 16:32:43 2007 From: lists at ruby-forum.com (Roger Pack) Date: Wed, 3 Oct 2007 22:32:43 +0200 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: <28135f2b83f4ec97d8b1dd2f3d5c25c1@ruby-forum.com> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> <067354a69ac7d64ccd5c202218ede245@ruby-forum.com> <5fa4f4f91a463cf08f87851d6975e77c@ruby-forum.com> <20071003115952.08217eef.zedshaw@zedshaw.com> <28135f2b83f4ec97d8b1dd2f3d5c25c1@ruby-forum.com> Message-ID: > The problem isn't 120M -- but that it seems to keep climbing until much > instability ensues... > > That's possibly a leak, but I'm still a bit confused as to why the > 64-bit server is using so much more... and whether I should maybe run > the mongrel_cluster instances on 32-bit kernel (assuming that's > possible). Could try googl'ing for ruby memory profiler and possibly (if desperate) running ruby with valgrind. GL! -Roger -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Wed Oct 3 16:59:23 2007 From: lists at ruby-forum.com (Chris Taggart) Date: Wed, 3 Oct 2007 22:59:23 +0200 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> <067354a69ac7d64ccd5c202218ede245@ruby-forum.com> <5fa4f4f91a463cf08f87851d6975e77c@ruby-forum.com> <20071003115952.08217eef.zedshaw@zedshaw.com> <28135f2b83f4ec97d8b1dd2f3d5c25c1@ruby-forum.com> <20071003161526.374fb911.zedshaw@zedshaw.com> Message-ID: <68276713504a5f8c0d3e13d9150d23e8@ruby-forum.com> Kirk Haines wrote: > On 10/3/07, Zed A. Shaw wrote: > >> Apart from that, I've got no idea. Last time I dealt with this crap with the >> horrible Ruby GC implementation the entire Ruby world took out >> torches and chased me down the street screaming that I was ruining >> their party be exposing how crap the code is. > > Hey now. I was one of those torch carriers, but all I was worried > about was making sure we were pointing in the right direction in > identifying the real memory leak instead of just villifying poor, > innocent Mutex. In the end, it was the influence of that dastardly > Array#shift that had turned Mutex into the problem causing bad boy. > > What's really appalling is how long it took after that time before > Array#shift was actually fixed in a ruby release. It should have been > fixed in 1.8.5. > > I suspect that the leak in the gethostbyname code is a similar sort of > sloppiness that had been overlooked (and probably still exists in > 1.9). > > Chris, you asked about suggestions on how track down memory leaks. > What Zed said. In addition, you can manually write code to check > ObjectSpace object counts. If you suspect that the problem is > actually at Ruby or C/C++ extension level, you can also use a tool > like valgrind to analyze running code and see if you can pinpoint > anything that is actualy a problem. > > > Kirk Haines Thanks for all the suggestions. Will try them out, and perhaps try some direct comparisons of 1.8.5 and 1.8.6 to see how the Array#shift pro is affecting things. Anybody got any thoughts re the idea of running the app servers under 32-bit kernel? May seem naive, but would seem to improve the memory profile. -- Posted via http://www.ruby-forum.com/. From ml at syntheticplayground.com Thu Oct 4 02:37:12 2007 From: ml at syntheticplayground.com (Corey Jewett) Date: Wed, 3 Oct 2007 23:37:12 -0700 Subject: [Mongrel] Mongrel using way more memory on production than staging In-Reply-To: <28135f2b83f4ec97d8b1dd2f3d5c25c1@ruby-forum.com> References: <47020A9A.5080609@googlemail.com> <154F54F6-63DB-4C0A-AF3B-BED65136F4AF@johansorensen.com> <47021E02.2000905@googlemail.com> <74f8c4f45c848a72d39f6f258628d8f4@ruby-forum.com> <067354a69ac7d64ccd5c202218ede245@ruby-forum.com> <5fa4f4f91a463cf08f87851d6975e77c@ruby-forum.com> <20071003115952.08217eef.zedshaw@zedshaw.com> <28135f2b83f4ec97d8b1dd2f3d5c25c1@ruby-forum.com> Message-ID: <20071003233712926973.6d48faef@syntheticplayground.com> On Wed, 3 Oct 2007 20:52:20 +0200, Chris Taggart wrote: > That's possibly a leak, but I'm still a bit confused as to why the > 64-bit server is using so much more... and whether I should maybe run > the mongrel_cluster instances on 32-bit kernel (assuming that's > possible). On the Java side of the world I have an app that consumes 40% more memory running on 64-bit over 32-bit. This is under 64-bit linux. Our JVMs average around 5G so 32-bit kernels aren't really an option. (32-bit Java has a 2G per jvm cap). Corey From sid.webnews at gmail.com Thu Oct 4 14:05:01 2007 From: sid.webnews at gmail.com (Sid Jay) Date: Thu, 04 Oct 2007 13:05:01 -0500 Subject: [Mongrel] Error with Mongrel_cluster In-Reply-To: Message-ID: Wayne, I tried the below and still it won?t work. On 10/1/07 8:12 PM, "Wayne E. Seguin" wrote: > On 10/1/07, Sid News wrote: >> Wayne, >> surprisingly i'm getting this error now: > > You can download the gem manually from here and install from local: > http://rubyforge.org/frs/?group_id=256&release_id=12694 > > > The ruby-oci8 project page is here: > http://ruby-oci8.rubyforge.org/en/ > > > For example, on Linux you might do: > wget http://rubyforge.org/frs/download.php/22320/ruby-oci8-1.0.0-rc3.tar.gz > > tar zxvf ruby-oci8-1.0.0-rc3.tar.gz > cd ruby-oci8-1.0.0-rc3 > make > sudo make install > > > > I hope this helps. > > ~Wayne > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071004/3498f536/attachment.html From rogerpack2005 at gmail.com Fri Oct 5 12:43:46 2007 From: rogerpack2005 at gmail.com (Roger Pack) Date: Fri, 5 Oct 2007 10:43:46 -0600 Subject: [Mongrel] multi threaded theoretically useful? Message-ID: <966599840710050943o53510e2am582b8b2910ee348e@mail.gmail.com> Thanks to all for your helpful answers on this question. It's nice to belong to a mailing list that has smart users (not that others don't, of course). So overall the answer to my question is that a multi-threaded rails app might well not be significantly faster because say it has 10 threads, if 1 thread is waiting on a long-taking DB query, the other 9 are blocked anyway, so the benefits of a multi-threaded model are moot (so a single-threaded rails is perhaps about as fast as a multi-threaded rails). Bring on Ruby 2.0 :) Further question: would providing the option of having mongrel bind to UNIX sockets perhaps speed it? (i.e. bind to port 3000 and unix socket x). Just a thought. Probably not enough speed difference to matter, but perhaps useful for local processes and simple to implement. Thoughts? > Here's one question that I think would have an impact on how useful > green threads are for many server apps: > > If you are blocking on something like a database SELECT in one green > thread, will the Ruby interpreter switch to another green thread > while it's waiting for the response? > > Or does a blocking request block all green threads? >When the flow of execution leaves Ruby and goes into some 3rd party >extension (like that of a DB library), then ruby can't context switch. >So yes, when one does a DB query that is going through a C extension, >all of the other green threads are blocked, so that latency can't be >captured. >If it could be, then yes, there would be some benefit from some number >of green threads per process for typical web apps. From wyhaines at gmail.com Fri Oct 5 12:55:37 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Fri, 5 Oct 2007 09:55:37 -0700 Subject: [Mongrel] multi threaded theoretically useful? In-Reply-To: <966599840710050943o53510e2am582b8b2910ee348e@mail.gmail.com> References: <966599840710050943o53510e2am582b8b2910ee348e@mail.gmail.com> Message-ID: On 10/5/07, Roger Pack wrote: > Thanks to all for your helpful answers on this question. It's nice to > belong to a mailing list that has smart users (not that others don't, > of course). > So overall the answer to my question is that a multi-threaded rails > app might well not be significantly faster because say it has 10 > threads, if 1 thread is waiting on a long-taking DB query, the other 9 > are blocked anyway, so the benefits of a multi-threaded model are moot > (so a single-threaded rails is perhaps about as fast as a > multi-threaded rails). Bring on Ruby 2.0 :) Multi-threaded may even be slower, in fact. :) In a lot of the cases, it will definitely be slower. Even on a platform with native threads, multithreading may be no faster than a multiprocess model. It's not a magic bullet. > Further question: > would providing the option of having mongrel bind to UNIX sockets > perhaps speed it? (i.e. bind to port 3000 and unix socket x). Just a > thought. Probably not enough speed difference to matter, but perhaps > useful for local processes and simple to implement. Thoughts? I used to run all of my IOWA apps via unix sockets. I don't do that anymore, though. There are situations where it can arguably be useful, but most of the time it just doesn't matter. Any differences between 127.0.0.1:11111 and /path/to/a/unix/socket are lost in the noise of the rest of the performance affecting load -- they are just too small to matter much. Kirk Haines From garbagecat10 at gmail.com Fri Oct 5 13:11:01 2007 From: garbagecat10 at gmail.com (Francis Cianfrocca) Date: Fri, 5 Oct 2007 13:11:01 -0400 Subject: [Mongrel] multi threaded theoretically useful? In-Reply-To: <966599840710050943o53510e2am582b8b2910ee348e@mail.gmail.com> References: <966599840710050943o53510e2am582b8b2910ee348e@mail.gmail.com> Message-ID: <3a94cf510710051011r34da220ch7f3acedb7da621d3@mail.gmail.com> On 10/5/07, Roger Pack wrote: > > > Further question: > would providing the option of having mongrel bind to UNIX sockets > perhaps speed it? (i.e. bind to port 3000 and unix socket x). Just a > thought. Probably not enough speed difference to matter, but perhaps > useful for local processes and simple to implement. Thoughts? Depending on the kernel, you may find Unix sockets to be less performant than localhost TCP. The dominant effect on performance comes from getting the network out of the picture. Beyond that, I've often found that unix-domain I/O stacks don't seem to be as well-tuned as TCP stacks are. And use localhost/tcp instead of an IP address on a network interface. On most kernels, that saves you a trip through the network interface driver. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071005/22dd81de/attachment-0001.html From francois.beausoleil at gmail.com Fri Oct 5 14:41:02 2007 From: francois.beausoleil at gmail.com (=?UTF-8?Q?Fran=C3=A7ois_Beausoleil?=) Date: Fri, 5 Oct 2007 14:41:02 -0400 Subject: [Mongrel] Mongrel PID file permissions Message-ID: <41d5fadf0710051141t10ef5219t8ccbd1bbfd985bd@mail.gmail.com> Hi ! I'm using Mongrel 1.0.1 with --pid and --user/--group. The PID files are correctly owned by the user/group, but their permissions is 0666. Is that normal ? Shouldn't it be something like 0664 ? Just curious to know if I'm wrong. Configurator has this (line 77): # Writes the PID file but only if we're on windows. def write_pid_file if RUBY_PLATFORM !~ /mswin/ log "Writing PID file to #{@pid_file}" open(@pid_file,"w") {|f| f.write(Process.pid) } end end The comment's wrong, and we probably need a File.chmod call there somewhere. Should I submit a patch ? Thanks ! -- Fran?ois Beausoleil http://blog.teksol.info/ http://piston.rubyforge.org/ From luislavena at gmail.com Fri Oct 5 21:39:27 2007 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 5 Oct 2007 22:39:27 -0300 Subject: [Mongrel] Mongrel PID file permissions In-Reply-To: <41d5fadf0710051141t10ef5219t8ccbd1bbfd985bd@mail.gmail.com> References: <41d5fadf0710051141t10ef5219t8ccbd1bbfd985bd@mail.gmail.com> Message-ID: <71166b3b0710051839x70a82e14p891c3e2d9dc9adee@mail.gmail.com> On 10/5/07, Fran?ois Beausoleil wrote: > Hi ! > > I'm using Mongrel 1.0.1 with --pid and --user/--group. The PID files > are correctly owned by the user/group, but their permissions is 0666. > Is that normal ? Shouldn't it be something like 0664 ? > > Just curious to know if I'm wrong. > > Configurator has this (line 77): > > # Writes the PID file but only if we're on windows. > def write_pid_file > if RUBY_PLATFORM !~ /mswin/ > log "Writing PID file to #{@pid_file}" > open(@pid_file,"w") {|f| f.write(Process.pid) } > end > end > > The comment's wrong, and we probably need a File.chmod call there > somewhere. Should I submit a patch ? > Yes please! I don't see any reference to the file permission for the file, so maybe you require File.chmod after writting to it. Post it to RubyForge tracker (under patches) and someone will check and test it before commiting. Again, thank you for your time. -- 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 From chrisangileri at yahoo.com Tue Oct 9 15:23:09 2007 From: chrisangileri at yahoo.com (Eire Angel) Date: Tue, 9 Oct 2007 12:23:09 -0700 (PDT) Subject: [Mongrel] Monit reporting that pid changed Message-ID: <538044.86856.qm@web53409.mail.re2.yahoo.com> Hi, I was wondering if this is normal or if it something i need to wonder about. I get Monit alerts that my mongrels PID files have changed. Changed Service MONGREL_2 Date: Tue, 09 Oct 2007 14:19:38 +0000 Action: alert Host: sa.greenling.com Description: 'MONGREL_2' process PID changed to 18368 Your faithful employee, monit --------------------------------- Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071009/fd9939ab/attachment.html From kamil.kukura at gmail.com Tue Oct 9 16:40:09 2007 From: kamil.kukura at gmail.com (Kamil Kukura) Date: Tue, 9 Oct 2007 22:40:09 +0200 Subject: [Mongrel] Fix for using memcache store in mongrel cluster Message-ID: Hi, I was having problem with disappearing sessions when storing them in memcache and when runnning as mongrel cluster in production environment. I've created a patch and it seems it's now okay. A message to rails-core including the link to patch can be found in the group here: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/6427c8fda42683c2 -- Kamil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071009/3bb2828e/attachment.html From alexey.verkhovsky at gmail.com Tue Oct 9 21:52:58 2007 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Tue, 9 Oct 2007 19:52:58 -0600 Subject: [Mongrel] Monit reporting that pid changed In-Reply-To: <538044.86856.qm@web53409.mail.re2.yahoo.com> References: <538044.86856.qm@web53409.mail.re2.yahoo.com> Message-ID: <3945c4270710091852h84a02a6y9479c15e33581ad9@mail.gmail.com> On 10/9/07, Eire Angel wrote: > Hi, I was wondering if this is normal > or if it something i need to wonder about. > I get Monit alerts that my mongrels PID files > have changed. It means that Mongrel was restarted. If nobody actually wanted it to restart, it possibly crashed. I'd say, you do need to wonder about it. :) -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From rob at robmela.com Wed Oct 10 10:48:21 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 10 Oct 2007 10:48:21 -0400 Subject: [Mongrel] Mongrel SVN? In-Reply-To: <3945c4270710091852h84a02a6y9479c15e33581ad9@mail.gmail.com> References: <538044.86856.qm@web53409.mail.re2.yahoo.com> <3945c4270710091852h84a02a6y9479c15e33581ad9@mail.gmail.com> Message-ID: <470CE635.70302@robmela.com> What's the URL for checking things out of the Mongrel SVN? thx. -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071010/58c51105/attachment.vcf From todd.fisher at gmail.com Wed Oct 10 10:59:34 2007 From: todd.fisher at gmail.com (Todd Fisher) Date: Wed, 10 Oct 2007 10:59:34 -0400 Subject: [Mongrel] Mongrel SVN? In-Reply-To: <470CE635.70302@robmela.com> References: <538044.86856.qm@web53409.mail.re2.yahoo.com> <3945c4270710091852h84a02a6y9479c15e33581ad9@mail.gmail.com> <470CE635.70302@robmela.com> Message-ID: svn://rubyforge.org/var/svn/mongrel/trunk On 10/10/07, Robert Mela wrote: > > What's the URL for checking things out of the Mongrel SVN? > > thx. > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071010/fafc590a/attachment.html From evan at cloudbur.st Thu Oct 11 02:55:36 2007 From: evan at cloudbur.st (Evan Weaver) Date: Thu, 11 Oct 2007 02:55:36 -0400 Subject: [Mongrel] 1.0.2 release candidates Message-ID: Hello Mongrels, Release candidates for Mongrel 1.0.2 and its dependencies are now available. Note that gems are now signed, so please add the Mongrel public certificate via: $ wget http://rubyforge.org/frs/download.php/25325/mongrel-public_cert.pem $ gem cert --add mongrel-public_cert.pem Now you can verify and install the candidates via gem install: $ sudo gem install mongrel --include-dependencies --source http://mongrel.rubyforge.org/releases/ -P HighSecurity Manual downloads are available from http://mongrel.rubyforge.org/releases/ . Please report problems on the Rubyforge tracker at http://rubyforge.org/tracker/?group_id=1306 . We will finalize the release in a week or two, barring unforeseen difficulties. Thanks, Evan, and the Mongrel Team PS. If you really don't care about authenticity, and don't want to install the public certificate, you can omit the '-P HighSecurity' option in 'gem install'. -- Evan Weaver Cloudburst, LLC From 2828628 at gmail.com Thu Oct 11 03:03:50 2007 From: 2828628 at gmail.com (Ken) Date: Thu, 11 Oct 2007 15:03:50 +0800 Subject: [Mongrel] 1.0.2 release candidates In-Reply-To: References: Message-ID: <2a0834610710110003o214fcae8h1c5a47c1a3d0891f@mail.gmail.com> great! On 10/11/07, Evan Weaver wrote: > > Hello Mongrels, > > Release candidates for Mongrel 1.0.2 and its dependencies are now > available. Note that gems are now signed, so please add the Mongrel > public certificate via: > > $ wget > http://rubyforge.org/frs/download.php/25325/mongrel-public_cert.pem > $ gem cert --add mongrel-public_cert.pem > > Now you can verify and install the candidates via gem install: > > $ sudo gem install mongrel --include-dependencies --source > http://mongrel.rubyforge.org/releases/ -P HighSecurity > > Manual downloads are available from http://mongrel.rubyforge.org/releases/. > > Please report problems on the Rubyforge tracker at > http://rubyforge.org/tracker/?group_id=1306 . We will finalize the > release in a week or two, barring unforeseen difficulties. > > Thanks, > > Evan, and the Mongrel Team > > > PS. If you really don't care about authenticity, and don't want to > install the public certificate, you can omit the '-P HighSecurity' > option in 'gem install'. > > -- > Evan Weaver > Cloudburst, LLC > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- $B7/Ld]E4|L$M-4|!$GC;3Lk1+^}=)CS!#2?aD6&Qr@>cY?$!$RJOCGC;3Lk1+;~!#(B -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071011/8af2cbac/attachment.html From lists at lastonepicked.com Thu Oct 11 03:05:30 2007 From: lists at lastonepicked.com (Hunter Hillegas) Date: Thu, 11 Oct 2007 00:05:30 -0700 Subject: [Mongrel] 1.0.2 release candidates In-Reply-To: References: Message-ID: What's the word on the changes? On Oct 10, 2007, at 11:55 PM, Evan Weaver wrote: > Hello Mongrels, > > Release candidates for Mongrel 1.0.2 and its dependencies are now > available. Note that gems are now signed, so please add the Mongrel > public certificate via: > > $ wget http://rubyforge.org/frs/download.php/25325/mongrel- > public_cert.pem > $ gem cert --add mongrel-public_cert.pem > > Now you can verify and install the candidates via gem install: > > $ sudo gem install mongrel --include-dependencies --source > http://mongrel.rubyforge.org/releases/ -P HighSecurity > > Manual downloads are available from http://mongrel.rubyforge.org/ > releases/ . > > Please report problems on the Rubyforge tracker at > http://rubyforge.org/tracker/?group_id=1306 . We will finalize the > release in a week or two, barring unforeseen difficulties. > > Thanks, > > Evan, and the Mongrel Team > > > PS. If you really don't care about authenticity, and don't want to > install the public certificate, you can omit the '-P HighSecurity' > option in 'gem install'. > > -- > Evan Weaver > Cloudburst, LLC > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From evan at cloudbur.st Thu Oct 11 03:59:12 2007 From: evan at cloudbur.st (Evan Weaver) Date: Thu, 11 Oct 2007 03:59:12 -0400 Subject: [Mongrel] 1.0.2 release candidates In-Reply-To: References: Message-ID: The CHANGELOG message for Mongrel is just: v1.0.2. Signed gem; various bugfixes and patches. There should be no breaking changes. If you're interested in a specific bug, check the tracker and see what the resolution was. The detailed SVN log up to and including 1.0.2 is at http://mongrel.rubyforge.org/releases/Changelog . Mongrel_cluster v1.0.3 includes Capistrano 2 recipes. That's probably the most significant new feature. Evan On 10/11/07, Hunter Hillegas wrote: > What's the word on the changes? > > On Oct 10, 2007, at 11:55 PM, Evan Weaver wrote: > > > Hello Mongrels, > > > > Release candidates for Mongrel 1.0.2 and its dependencies are now > > available. Note that gems are now signed, so please add the Mongrel > > public certificate via: > > > > $ wget http://rubyforge.org/frs/download.php/25325/mongrel- > > public_cert.pem > > $ gem cert --add mongrel-public_cert.pem > > > > Now you can verify and install the candidates via gem install: > > > > $ sudo gem install mongrel --include-dependencies --source > > http://mongrel.rubyforge.org/releases/ -P HighSecurity > > > > Manual downloads are available from http://mongrel.rubyforge.org/ > > releases/ . > > > > Please report problems on the Rubyforge tracker at > > http://rubyforge.org/tracker/?group_id=1306 . We will finalize the > > release in a week or two, barring unforeseen difficulties. > > > > Thanks, > > > > Evan, and the Mongrel Team > > > > > > PS. If you really don't care about authenticity, and don't want to > > install the public certificate, you can omit the '-P HighSecurity' > > option in 'gem install'. > > > > -- > > Evan Weaver > > Cloudburst, LLC > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From francois.beausoleil at gmail.com Thu Oct 11 13:54:19 2007 From: francois.beausoleil at gmail.com (=?UTF-8?Q?Fran=C3=A7ois_Beausoleil?=) Date: Thu, 11 Oct 2007 13:54:19 -0400 Subject: [Mongrel] Mongrel PID file permissions In-Reply-To: <71166b3b0710051839x70a82e14p891c3e2d9dc9adee@mail.gmail.com> References: <41d5fadf0710051141t10ef5219t8ccbd1bbfd985bd@mail.gmail.com> <71166b3b0710051839x70a82e14p891c3e2d9dc9adee@mail.gmail.com> Message-ID: <41d5fadf0710111054g3cd690dbu9c1aa139fd2a4831@mail.gmail.com> Hi ! 2007/10/5, Luis Lavena : > I don't see any reference to the file permission for the file, so > maybe you require File.chmod after writting to it. > > Post it to RubyForge tracker (under patches) and someone will check > and test it before commiting. Take the patch from here: http://rubyforge.org/tracker/index.php?func=detail&aid=14641&group_id=1306&atid=5147 Bye ! Fran?ois From lists at ruby-forum.com Thu Oct 11 19:23:57 2007 From: lists at ruby-forum.com (Greg Willits) Date: Fri, 12 Oct 2007 01:23:57 +0200 Subject: [Mongrel] mongrel_rails not starting Message-ID: <3d1be0c7af64aabda8dcab0cecbd9084@ruby-forum.com> os x 10.4.10 used gem to install mongrel 1.0.1. seemed to go w/o errors. "mongrel_rails start -d" spits out this error /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/http11.bundle: Failed to load /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/http11.bundle (LoadError) from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in `require' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:11 from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in `gem_original_require' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in `require' from /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/bin/mongrel_rails:9 from /usr/local/bin/mongrel_rails:16:in `load' from /usr/local/bin/mongrel_rails:16 installed again with --include-dependencies still getting same error. lost. need a flashlight. -- gw -- Posted via http://www.ruby-forum.com/. From luislavena at gmail.com Thu Oct 11 19:33:30 2007 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 11 Oct 2007 20:33:30 -0300 Subject: [Mongrel] mongrel_rails not starting In-Reply-To: <3d1be0c7af64aabda8dcab0cecbd9084@ruby-forum.com> References: <3d1be0c7af64aabda8dcab0cecbd9084@ruby-forum.com> Message-ID: <71166b3b0710111633l445346cdu8693a182e98f8cc1@mail.gmail.com> On 10/11/07, Greg Willits wrote: > os x 10.4.10 > > used gem to install mongrel 1.0.1. seemed to go w/o errors. > > "mongrel_rails start -d" spits out this error > > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/http11.bundle: > Failed to load > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/http11.bundle > (LoadError) > from > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in > `require' > from > /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:11 It seems there is no bundle (compiled extension) for http11, which is need by Mongrel. > > installed again with --include-dependencies > > still getting same error. > > lost. need a flashlight. > Do you have everything to compile ruby extensions in place? Which version of ruby are you using? the broken one that came with OSX or compiled by hand? What's the output of gem install mongrel? You should see the details about "building native extensions"... -- 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 From lists at ruby-forum.com Thu Oct 11 20:08:49 2007 From: lists at ruby-forum.com (Greg Willits) Date: Fri, 12 Oct 2007 02:08:49 +0200 Subject: [Mongrel] mongrel_rails not starting In-Reply-To: <71166b3b0710111633l445346cdu8693a182e98f8cc1@mail.gmail.com> References: <3d1be0c7af64aabda8dcab0cecbd9084@ruby-forum.com> <71166b3b0710111633l445346cdu8693a182e98f8cc1@mail.gmail.com> Message-ID: <4a746b688910bfc7c3ee6b7000265536@ruby-forum.com> Luis Lavena wrote: > On 10/11/07, Greg Willits wrote: > It seems there is no bundle (compiled extension) for http11, which is > need by Mongrel. > Do you have everything to compile ruby extensions in place? Unknown. (ruby newbie). > Which version of ruby are you using? The one from here: http://rubyosx.rubyforge.org/ -- which I see should already have Mongrel in it, but then I installed... oh, hang on. Maybe I broke it by monkeying with gem installs afterwards. OK, I just re-installed using that installer, and now mongrel launches, but complains about a log path being invalid. So, I'm further along. I'll see if I can figure out the log thing. Thanks Luis, that got me to re-evaluate what I had done. -- gw -- Posted via http://www.ruby-forum.com/. From luislavena at gmail.com Thu Oct 11 20:15:57 2007 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 11 Oct 2007 21:15:57 -0300 Subject: [Mongrel] mongrel_rails not starting In-Reply-To: <4a746b688910bfc7c3ee6b7000265536@ruby-forum.com> References: <3d1be0c7af64aabda8dcab0cecbd9084@ruby-forum.com> <71166b3b0710111633l445346cdu8693a182e98f8cc1@mail.gmail.com> <4a746b688910bfc7c3ee6b7000265536@ruby-forum.com> Message-ID: <71166b3b0710111715j5e341ba5g8d6a7d320c5f172a@mail.gmail.com> On 10/11/07, Greg Willits wrote: > Luis Lavena wrote: > > > Which version of ruby are you using? > > The one from here: http://rubyosx.rubyforge.org/ -- which I see should > already have Mongrel in it, but then I installed... oh, hang on. Maybe I > broke it by monkeying with gem installs afterwards. > Yeah, Ruby for OSX have Mongrel pre-compiled (along with Ruby) so you don't need a compilation/build environment in place. Is like One-Click-Installer on Windows ;-) > OK, I just re-installed using that installer, and now mongrel launches, > but complains about a log path being invalid. > you're runnin mongrel_rails start inside the root of your Rails application? maybe there isn't a log folder inside it, or the permissions aren't valid. > So, I'm further along. I'll see if I can figure out the log thing. Could you post the messages mongrel_rails start is showing you? that could help us provide you better support :-) > Thanks Luis, that got me to re-evaluate what I had done. No problem, I'm glad being helpful. -- 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 From lists at ruby-forum.com Thu Oct 11 20:24:31 2007 From: lists at ruby-forum.com (Greg Willits) Date: Fri, 12 Oct 2007 02:24:31 +0200 Subject: [Mongrel] mongrel_rails not starting In-Reply-To: <71166b3b0710111715j5e341ba5g8d6a7d320c5f172a@mail.gmail.com> References: <3d1be0c7af64aabda8dcab0cecbd9084@ruby-forum.com> <71166b3b0710111633l445346cdu8693a182e98f8cc1@mail.gmail.com> <4a746b688910bfc7c3ee6b7000265536@ruby-forum.com> <71166b3b0710111715j5e341ba5g8d6a7d320c5f172a@mail.gmail.com> Message-ID: <072d207c3e12240f2af7b9058ef59791@ruby-forum.com> >> OK, I just re-installed using that installer, and now mongrel launches, >> but complains about a log path being invalid. >> > > you're runnin mongrel_rails start inside the root of your Rails > application? maybe there isn't a log folder inside it, or the > permissions aren't valid. Yeah I was one dir above my app, so that was the problem. All looks good now. (lots of voodoo to get this stuff running compared to what I am used to -- Lasso) -- gw -- Posted via http://www.ruby-forum.com/. From luislavena at gmail.com Thu Oct 11 20:29:14 2007 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 11 Oct 2007 21:29:14 -0300 Subject: [Mongrel] mongrel_rails not starting In-Reply-To: <072d207c3e12240f2af7b9058ef59791@ruby-forum.com> References: <3d1be0c7af64aabda8dcab0cecbd9084@ruby-forum.com> <71166b3b0710111633l445346cdu8693a182e98f8cc1@mail.gmail.com> <4a746b688910bfc7c3ee6b7000265536@ruby-forum.com> <71166b3b0710111715j5e341ba5g8d6a7d320c5f172a@mail.gmail.com> <072d207c3e12240f2af7b9058ef59791@ruby-forum.com> Message-ID: <71166b3b0710111729r6440ae52p7e632a0162392f@mail.gmail.com> On 10/11/07, Greg Willits wrote: > Yeah I was one dir above my app, so that was the problem. All looks good > now. > > (lots of voodoo to get this stuff running compared to what I am used to > -- Lasso) > Hehehe, Please, file a bug, feature-request at mongrel tracker: http://rubyforge.org/tracker/?group_id=1306 I guess we could make "mongrel_rails" script more intelligent about where you are and if that folder is a Rails one ;-) There is also Locomotive [1] which provides a simpler way to configure mongrels for your applications. It differs from Ruby OSX is that is tailored for Rails (and rubyosx is more ruby generic). [1] http://locomotive.raaum.org/ -- 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 From lists at ruby-forum.com Thu Oct 11 20:40:40 2007 From: lists at ruby-forum.com (Greg Willits) Date: Fri, 12 Oct 2007 02:40:40 +0200 Subject: [Mongrel] mongrel_rails not starting In-Reply-To: <71166b3b0710111729r6440ae52p7e632a0162392f@mail.gmail.com> References: <3d1be0c7af64aabda8dcab0cecbd9084@ruby-forum.com> <71166b3b0710111633l445346cdu8693a182e98f8cc1@mail.gmail.com> <4a746b688910bfc7c3ee6b7000265536@ruby-forum.com> <71166b3b0710111715j5e341ba5g8d6a7d320c5f172a@mail.gmail.com> <072d207c3e12240f2af7b9058ef59791@ruby-forum.com> <71166b3b0710111729r6440ae52p7e632a0162392f@mail.gmail.com> Message-ID: Luis Lavena wrote: > There is also Locomotive [1] which provides a simpler way to configure > mongrels for your applications. It differs from Ruby OSX is that is > tailored for Rails (and rubyosx is more ruby generic). My thought was maybe that would isolate me too much from what's going on. After I get my feet wet a little bit with just getting some stuff running and working in Rails, I'll probably go back and uninstall everything and try it by hand. Wandering off into another (related) topic... Right now I'm trying to figure out how to get multiple apps running on mongrels with dev URLs I'm used to using www.XYZ.dev and www.ABC.dev in my browser, and then using NetInfo machines or even hosts to map those to 127.0.0.1 I thought 127.0.0.1:3000 www.abc.dev would work but it didn't. I understand that I'll have to run multiple mongrels on unique ports, but haven't figured out how to map a URL to the localhost:port yet -- gw -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Thu Oct 11 20:48:53 2007 From: lists at ruby-forum.com (Greg Willits) Date: Fri, 12 Oct 2007 02:48:53 +0200 Subject: [Mongrel] mongrel_rails not starting In-Reply-To: References: <3d1be0c7af64aabda8dcab0cecbd9084@ruby-forum.com> <71166b3b0710111633l445346cdu8693a182e98f8cc1@mail.gmail.com> <4a746b688910bfc7c3ee6b7000265536@ruby-forum.com> <71166b3b0710111715j5e341ba5g8d6a7d320c5f172a@mail.gmail.com> <072d207c3e12240f2af7b9058ef59791@ruby-forum.com> <71166b3b0710111729r6440ae52p7e632a0162392f@mail.gmail.com> Message-ID: <678706ff4eae953532c5f414325227c0@ruby-forum.com> > Right now I'm trying to figure out how to get multiple apps running on > mongrels with dev URLs > > I'm used to using www.XYZ.dev and www.ABC.dev in my browser, and then > using NetInfo machines or even hosts to map those to 127.0.0.1 > > I thought 127.0.0.1:3000 www.abc.dev would work but it didn't. btw, I know I can use Apache 2.2 mod_proxy_balancer -- I actually helped set one of those up (though I didn't do the mongerl stuff then), so I can just do that I guess. Just more junk to install since using Apache 1.3 is fine for everything else I do on my dev system. -- gw -- Posted via http://www.ruby-forum.com/. From carlos at bueno.org Fri Oct 12 14:29:22 2007 From: carlos at bueno.org (Carlos) Date: Fri, 12 Oct 2007 11:29:22 -0700 Subject: [Mongrel] deciphering objects.log Message-ID: <887494480710121129i2af727f2o19c320922fd1968@mail.gmail.com> Howdy -- I've been tracking down mem leaks (oh, the fun...), and I think there is a clue in objects.log. There are a few mentions of this file, but usually Zed saying "look at this file and it will help you". Can anyone clue me in to what the actual columns mean? 18,Float,143952,256821,112869,,, 18,String,39543,41693,2150,24.727076,55.526376,2308.000000 18,Array,3014,4232,1218,4.445888,23.633335,612.000000 18,Proc,1699,1750,51,,, 18,Regexp,1300,1310,10,,, 18,Hash,691,730,39,8.008219,36.218131,519.000000 18,Time,134,168,34,,, 18,YAML::Syck::Scalar,60,108,48,,, 18,Mongrel::Stats,44,57,13,,, 18,MatchData,14,24,10,1.416667,1.138904,5.000000 18,StringIO,9,12,3,166.833333,178.322401,408.000000 19,Float,256821,107916,-148905,,, 19,String,41693,39700,-1993,23.864257,52.626340,2308.000000 19,Array,4232,3086,-1146,5.254051,27.529250,612.000000 19,Proc,1750,1697,-53,,, 19,Regexp,1310,1298,-12,,, 19,Hash,730,702,-28,8.056980,36.770207,519.000000 19,Time,168,122,-46,,, 19,YAML::Syck::Scalar,108,46,-62,,, 19,Mongrel::Stats,57,31,-26,,, 19,MatchData,24,12,-12,1.333333,1.154701,5.000000 TIA, Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071012/9191987d/attachment-0001.html From carlos at bueno.org Fri Oct 12 14:39:20 2007 From: carlos at bueno.org (Carlos) Date: Fri, 12 Oct 2007 11:39:20 -0700 Subject: [Mongrel] deciphering objects.log In-Reply-To: <887494480710121129i2af727f2o19c320922fd1968@mail.gmail.com> References: <887494480710121129i2af727f2o19c320922fd1968@mail.gmail.com> Message-ID: <887494480710121139y4954da86pf3cd7aa9c84de27a@mail.gmail.com> I RTFCd and got this: $objects_out.puts "run,classname,last,count,delta,lenmean,lensd,lenmax" So, run: a serial number of the request classname: obvious last: number of object from previous run count: number of objects in this run delta: last - count lenmean: average length of object lensd: std deviation lenmax: largest-seen (or maybe largest-existing?) object of this class Right? On 10/12/07, Carlos wrote: > > Howdy -- I've been tracking down mem leaks (oh, the fun...), and I think > there is a clue in objects.log. There are a few mentions of this file, but > usually Zed saying "look at this file and it will help you". Can anyone clue > me in to what the actual columns mean? > > 18,Float,143952,256821,112869,,, > 18,String,39543,41693,2150, 24.727076,55.526376,2308.000000 > 18,Array,3014,4232,1218,4.445888,23.633335,612.000000 > 18,Proc,1699,1750,51,,, > 18,Regexp,1300,1310,10,,, > 18,Hash,691,730,39,8.008219,36.218131,519.000000 > 18,Time,134,168,34,,, > 18,YAML::Syck::Scalar,60,108,48,,, > 18,Mongrel::Stats,44,57,13,,, > 18,MatchData,14,24,10,1.416667,1.138904,5.000000 > 18,StringIO,9,12,3,166.833333,178.322401,408.000000 > 19,Float,256821,107916,-148905,,, > 19,String,41693,39700,-1993,23.864257,52.626340,2308.000000 > 19,Array,4232,3086,-1146,5.254051,27.529250,612.000000 > 19,Proc,1750,1697,-53,,, > 19,Regexp,1310,1298,-12,,, > 19,Hash,730,702,-28,8.056980,36.770207,519.000000 > 19,Time,168,122,-46,,, > 19,YAML::Syck::Scalar,108,46,-62,,, > 19,Mongrel::Stats,57,31,-26,,, > 19,MatchData,24,12,-12,1.333333,1.154701,5.000000 > > > TIA, > Carlos > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071012/9cbf18ac/attachment.html From zedshaw at zedshaw.com Fri Oct 12 22:15:07 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Fri, 12 Oct 2007 22:15:07 -0400 Subject: [Mongrel] deciphering objects.log In-Reply-To: <887494480710121139y4954da86pf3cd7aa9c84de27a@mail.gmail.com> References: <887494480710121129i2af727f2o19c320922fd1968@mail.gmail.com> <887494480710121139y4954da86pf3cd7aa9c84de27a@mail.gmail.com> Message-ID: <20071012221507.8b4dcd70.zedshaw@zedshaw.com> On Fri, 12 Oct 2007 11:39:20 -0700 Carlos wrote: > I RTFCd and got this: > > $objects_out.puts "run,classname,last,count,delta,lenmean,lensd,lenmax" > > So, > run: a serial number of the request > classname: obvious > last: number of object from previous run > count: number of objects in this run > delta: last - count > lenmean: average length of object > lensd: std deviation > lenmax: largest-seen (or maybe largest-existing?) object of this class > > Right? Yep, except len(mean|sd|max) are used for objects that report a length, and that header should be created if the file is first created. You must have truncated it at some point. How you use this file is you run a *sequential* number of hits and do it in *production* mode. When it's done you load it into a spreadsheet or R or some Ruby and you look for the following: 1) Any class which seems to have a count who's delta mean isn't close to 0 for all runs. A leak can actually be defined in a GC language as: any class who's object count delta over time do not have a mean of 0. 2) Any class who's average length or sd.dev length is gigantic (send_file anyone?). 3) Any classes who have a mean of 0, but have a sd.dev that's massive. This shows poor GC management since it's a huge number of object being created and destroyed. 4) Any other column that for any class seems to be not like the others. Also look at bleakhouse. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From evan at cloudbur.st Fri Oct 12 23:52:24 2007 From: evan at cloudbur.st (Evan Weaver) Date: Fri, 12 Oct 2007 23:52:24 -0400 Subject: [Mongrel] deciphering objects.log In-Reply-To: <20071012221507.8b4dcd70.zedshaw@zedshaw.com> References: <887494480710121129i2af727f2o19c320922fd1968@mail.gmail.com> <887494480710121139y4954da86pf3cd7aa9c84de27a@mail.gmail.com> <20071012221507.8b4dcd70.zedshaw@zedshaw.com> Message-ID: Bleakhouse isn't as detailed as it could be, but it's better than using Objectspace. Zed, do you think we should remove the object.log? My guess is that it leads people astray as much as it helps. Ara Howard has some good ideas in his leak checker "Dike", but again, it uses Objectspace. Evan On 10/12/07, Zed A. Shaw wrote: > On Fri, 12 Oct 2007 11:39:20 -0700 > Carlos wrote: > > > I RTFCd and got this: > > > > $objects_out.puts "run,classname,last,count,delta,lenmean,lensd,lenmax" > > > > So, > > run: a serial number of the request > > classname: obvious > > last: number of object from previous run > > count: number of objects in this run > > delta: last - count > > lenmean: average length of object > > lensd: std deviation > > lenmax: largest-seen (or maybe largest-existing?) object of this class > > > > Right? > > Yep, except len(mean|sd|max) are used for objects that report a length, and that header should be created if the file is first created. You must have truncated it at some point. > > How you use this file is you run a *sequential* number of hits and do it in *production* mode. When it's done you load it into a spreadsheet or R or some Ruby and you look for the following: > > 1) Any class which seems to have a count who's delta mean isn't close to 0 for all runs. A leak can actually be defined in a GC language as: any class who's object count delta over time do not have a mean of 0. > 2) Any class who's average length or sd.dev length is gigantic (send_file anyone?). > 3) Any classes who have a mean of 0, but have a sd.dev that's massive. This shows poor GC management since it's a huge number of object being created and destroyed. > 4) Any other column that for any class seems to be not like the others. > > Also look at bleakhouse. > > -- > Zed A. Shaw > - Hate: http://savingtheinternetwithhate.com/ > - Good: http://www.zedshaw.com/ > - Evil: http://yearofevil.com/ > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From luislavena at gmail.com Fri Oct 12 23:57:51 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 13 Oct 2007 00:57:51 -0300 Subject: [Mongrel] deciphering objects.log In-Reply-To: References: <887494480710121129i2af727f2o19c320922fd1968@mail.gmail.com> <887494480710121139y4954da86pf3cd7aa9c84de27a@mail.gmail.com> <20071012221507.8b4dcd70.zedshaw@zedshaw.com> Message-ID: <71166b3b0710122057i1a6ab49bi261f371d9a292525@mail.gmail.com> On 10/13/07, Evan Weaver wrote: > Bleakhouse isn't as detailed as it could be, but it's better than > using Objectspace. > > Zed, do you think we should remove the object.log? My guess is that it > leads people astray as much as it helps. > > Ara Howard has some good ideas in his leak checker "Dike", but again, > it uses Objectspace. > Objectspace is like Heisenberg principle [1], you cannot touch it without altering the results. Maybe Dike and Bleak could merge and get something more powerful? ;-) [1] http://en.wikipedia.org/wiki/Uncertainty_principle -- 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 From luislavena at gmail.com Sat Oct 13 13:29:00 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 13 Oct 2007 14:29:00 -0300 Subject: [Mongrel] vista on mongrel In-Reply-To: <540203.56039.qm@web33012.mail.mud.yahoo.com> References: <540203.56039.qm@web33012.mail.mud.yahoo.com> Message-ID: <71166b3b0710131029k6e334e60o6514b407d680bbfe@mail.gmail.com> On 10/13/07, Raj Prakash wrote: > Hello, > > I am having the exact same problem described by Jonah Fox here: > > http://rubyforge.org/pipermail/mongrel-users/2007-May/003647.html > > I was wondering if you have found a solution yet. It is not the session > issue. > Are you sure about the session storage? have you tried changing it? On XP with cookie store happens, and get fixed when I change to pstore. Since I don't have Vista, I couldn't test it. (Also willb e useful know the ruby and rails version that you're using). -- 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 From luislavena at gmail.com Sat Oct 13 14:12:39 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 13 Oct 2007 15:12:39 -0300 Subject: [Mongrel] vista on mongrel In-Reply-To: <278233.10573.qm@web33004.mail.mud.yahoo.com> References: <71166b3b0710131029k6e334e60o6514b407d680bbfe@mail.gmail.com> <278233.10573.qm@web33004.mail.mud.yahoo.com> Message-ID: <71166b3b0710131112h6c0a8ear604fd7115c29a554@mail.gmail.com> On 10/13/07, Raj Prakash wrote: > Thank you for a a quick response, Luis. > > I am using Ruby 1.8.5 and Rails 1.2.3 > > According to the comment in ruby source In 1.8.5 the default is pstore. > Could you please tell me the specific changes that you did to the > environment > to force pstore. > > Apparently, Jonah Fox is still having the problem. I see a post from him > and a few replies just today at > > http://thread.gmane.org/gmane.comp.lang.ruby.rails/156245 > > There is one difference though I have problem in both IE and firefox > Let me explain this better: Latest versions of Rails (1.2.3 and Edge) sport a cookie-based session handling as default. The combination of this fact with Firefox on windows shows problems. On the other hand, webrick don't show this issue because cookies are handled in a different way. To workaround this problem, until deeper investigation of it, I suggest you switch for local/development to PStore based session (that was the default on previous versions). You need to uncomment and modify the config/environment.rb around lines 29-31: config.action_controller.session_store = :PStore Please note: that will work OK on development, but this will not under production since multiple mongrel instances will have problems accessing the session files (stored in tmp/sessions). For production I suggest change to :active_record_storage as suggested in environment.rb comments and perform the rake task needed to create these tables on the DB. Also, I'll like some volunteers to try the new release candidate of Mongrel (1.0.2) [1] and let us know [2] if worked for you under the same situation. [1] http://rubyforge.org/pipermail/mongrel-users/2007-October/004108.html [2] mongrel-users at rubyforge.org (mailing list) Regards, -- 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 From luislavena at gmail.com Sat Oct 13 15:11:00 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 13 Oct 2007 16:11:00 -0300 Subject: [Mongrel] vista on mongrel In-Reply-To: <60937.75029.qm@web33001.mail.mud.yahoo.com> References: <71166b3b0710131112h6c0a8ear604fd7115c29a554@mail.gmail.com> <60937.75029.qm@web33001.mail.mud.yahoo.com> Message-ID: <71166b3b0710131211h48e56087h9c6d0c0e83ba69c7@mail.gmail.com> On 10/13/07, Raj Prakash wrote: > Luis, > > I just tried the mongrel 1.0.2 rc. Unfortunately, it does not improve the > speed > with or without ...= :PStore. > > With this and the previous version of mongrel at start, I see the message > ** Ruby version is not up-to-date: loading cgi_multipart_eof_fix > > Could that cause speed problem? > It's weird, so I'll check later today at the office. With 1.8.6, cgi eof fix don't load but I'm using PStore... I'll check and let you know. -- 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 From zedshaw at zedshaw.com Sat Oct 13 20:53:15 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Sat, 13 Oct 2007 20:53:15 -0400 Subject: [Mongrel] deciphering objects.log In-Reply-To: References: <887494480710121129i2af727f2o19c320922fd1968@mail.gmail.com> <887494480710121139y4954da86pf3cd7aa9c84de27a@mail.gmail.com> <20071012221507.8b4dcd70.zedshaw@zedshaw.com> Message-ID: <20071013205315.bdee762a.zedshaw@zedshaw.com> On Fri, 12 Oct 2007 23:52:24 -0400 "Evan Weaver" wrote: > > Zed, do you think we should remove the object.log? My guess is that it > leads people astray as much as it helps. I don't hear anyone complaining it leads them astray. I've used it to find plenty of leaks. If you could improve it that'd be better than just removing it. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From basic70 at gmail.com Mon Oct 15 08:00:20 2007 From: basic70 at gmail.com (Daniel Brahneborg) Date: Mon, 15 Oct 2007 14:00:20 +0200 Subject: [Mongrel] POST with huge HTTP body Message-ID: Hi, I found the following page describing how to stream data from the server to the client: http://api.rubyonrails.com/classes/ActionController/Streaming.html I want to do the opposite, streaming data from the client to the server, letting the controller saving the data while it's being received. In particular, I want to upload large files to the RailsDav (http://www.liverail.net/railsdav) plugin, without having to store the entire file in memory during the operation. This seems to be a Mongrel problem, so I started looking at this plugin: http://mongrel.rubyforge.org/docs/upload_progress.html How do I get Mongrel to store the incoming POST data in a tempfile, passing a handler to that file as the raw_post field in the Rails request? Is it even possible? How is the "request" parameter to the process() method related to the "request" object in the Rails controllers? /Daniel From david at vrensk.com Mon Oct 15 08:49:27 2007 From: david at vrensk.com (David Vrensk) Date: Mon, 15 Oct 2007 14:49:27 +0200 Subject: [Mongrel] POST with huge HTTP body In-Reply-To: References: Message-ID: <81b453920710150549y32ebb0b3ta14b9d634ab437fc@mail.gmail.com> On 10/15/07, Daniel Brahneborg wrote: > > I want to do the opposite, streaming data from the client to the server, > letting the controller saving the data while it's being received. > In particular, I want to upload large files to the RailsDav > (http://www.liverail.net/railsdav) plugin, without having to store > the entire file in memory during the operation. > > This seems to be a Mongrel problem, [...] > I don't have the solution to your problem, but I think you are looking in the wrong place. Unless you plan to have mongrel listening on a public port, this is not a mongrel problem. The standard way to use mongrel, with Rails or not, is to set up a few of them behind a reverse proxy like nginx or apache+mod_proxy_balancer. In those cases, the proxy will not forward the data to mongrel before it has received it all, and once it has all the data, the latency between nginx and mongrel is negligible. On the other hand, the reverse proxy (I'm only speaking from experience with nginx here) saves the data to file while it is receiving it. I think you should look for a solution that lets nginx pass the path to that file to mongrel rather than sending the data again. I believe I have read about such a solution on this very list a few months ago. So, not the help you wanted, but I hope it leads you in the right direction. Well, if you actually intend to have mongrel face the public, then just forget what I said. Good luck! /David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071015/af934fb6/attachment.html From rob at robmela.com Mon Oct 15 09:20:18 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 15 Oct 2007 09:20:18 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close Message-ID: <47136912.6080107@robmela.com> Rails instances themselves are almost always single-threaded, whereas Mongrel, and it's acceptor, are multithreaded. In a situation with long-running Rails pages this presents a problem for mod_proxy_balancer. If num_processors is greater than 1 ( default: 950 ), then Mongrel will gladly accept incoming requests and queue them if its rails instance is currently busy. So even though there are non-busy mongrel instances, a busy one can accept a new request and queue it behind a long-running request. I tried setting num_processors to 1. But it looks like this is less than ideal -- I need to dig into mod_proxy_balancer to be sure. But at first glance, it appears this replaces queuing problem with a proxy error. That's because Mongrel still accepts the incoming request -- only to close the new socket immediately if Rails is busy. Once again, I do need to set up a test and see exactly how mod_proxy_balancer handles this... but... If I understand the problem correctly, then one solution might be moving lines 721 thru 734 into a loop, possibly in its own method, which does sth like this: def myaccept while true return @socket.accept if worker_list.length < num_processors ## check first to see if we can handle the request. Let client worry about connect timeouts. while @num_processors < reap_dead_workers sleep @loop_throttle end end end 720 @acceptor = Thread.new do 721 while true 722 begin * 723 client = @socket.accept * 724 725 if $tcp_cork_opts 726 client.setsockopt(*$tcp_cork_opts) rescue nil 727 end 728 729 worker_list = @workers.list 730 731 if worker_list.length >= @num_processors 732 STDERR.puts "Server overloaded with #{worker_list.length} processors (#@num_processors max). Dropping connection." * 733 client.close rescue Object* 734 reap_dead_workers("max processors") 735 else 736 thread = Thread.new(client) {|c| process_client(c) } 737 thread[:started_on] = Time.now 738 @workers.add(thread) 739 740 sleep @timeout/100 if @timeout > 0 741 end -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071015/40912d0f/attachment.vcf From kuijsten at yahoo.com Mon Oct 15 09:33:18 2007 From: kuijsten at yahoo.com (Tim Kuijsten) Date: Mon, 15 Oct 2007 06:33:18 -0700 (PDT) Subject: [Mongrel] POST with huge HTTP body Message-ID: <445886.78918.qm@web30907.mail.mud.yahoo.com> A while ago I wrote a plugin to limit uploads in Mongrel. Mongrel does save uploads to a tempfile on disk - if the upload is bigger than about 12 KB - using a Ruby TempFile-object. (which stores in the $TMPDIR, /tmp on most systems). The request is handed over to Rails after it's fully received by Mongrel. I'm not sure if this "saving to disk" works the same with chunked uploads (uploads without a Content-Length header). Maybe my plugin can help you: http://slasaus.netsend.nl/articles/show/7 (warning: it works, but is not very elegant). Gl, Tim ----- Original Message ---- From: Daniel Brahneborg To: mongrel-users at rubyforge.org Sent: Monday, October 15, 2007 2:00:20 PM Subject: [Mongrel] POST with huge HTTP body Hi, I found the following page describing how to stream data from the server to the client: http://api.rubyonrails.com/classes/ActionController/Streaming.html I want to do the opposite, streaming data from the client to the server, letting the controller saving the data while it's being received. In particular, I want to upload large files to the RailsDav (http://www.liverail.net/railsdav) plugin, without having to store the entire file in memory during the operation. This seems to be a Mongrel problem, so I started looking at this plugin: http://mongrel.rubyforge.org/docs/upload_progress.html How do I get Mongrel to store the incoming POST data in a tempfile, passing a handler to that file as the raw_post field in the Rails request? Is it even possible? How is the "request" parameter to the process() method related to the "request" object in the Rails controllers? /Daniel _______________________________________________ Mongrel-users mailing list Mongrel-users at rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users ____________________________________________________________________________________ Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 From kuijsten at yahoo.com Mon Oct 15 10:02:03 2007 From: kuijsten at yahoo.com (Tim Kuijsten) Date: Mon, 15 Oct 2007 07:02:03 -0700 (PDT) Subject: [Mongrel] POST with huge HTTP body Message-ID: <702678.58438.qm@web30908.mail.mud.yahoo.com> "... The standard way to use mongrel, with Rails or not, is to set up a few of them behind a reverse proxy like nginx or apache+mod_proxy_balancer. In those cases, the proxy will not forward the data to mongrel before it has received it all, and once it has all the data, the latency between nginx and mongrel is negligible. ..." My Apache 2.2 load balancing reverse proxy forwards all data immediately, without storing it in an "intermediate-file". I believe this is standard behavior. So this should not be the problem. I think the problem is in the fact that Mongrel stores the whole file-object before passing it through to Rails, right? Unfortunately I have no clue how to fix that. Tim ----- Original Message ---- From: David Vrensk To: mongrel-users at rubyforge.org Sent: Monday, October 15, 2007 2:49:27 PM Subject: Re: [Mongrel] POST with huge HTTP body On 10/15/07, Daniel Brahneborg wrote: I want to do the opposite, streaming data from the client to the server, letting the controller saving the data while it's being received. In particular, I want to upload large files to the RailsDav ( http://www.liverail.net/railsdav) plugin, without having to store the entire file in memory during the operation. This seems to be a Mongrel problem, [...] I don't have the solution to your problem, but I think you are looking in the wrong place. Unless you plan to have mongrel listening on a public port, this is not a mongrel problem. The standard way to use mongrel, with Rails or not, is to set up a few of them behind a reverse proxy like nginx or apache+mod_proxy_balancer. In those cases, the proxy will not forward the data to mongrel before it has received it all, and once it has all the data, the latency between nginx and mongrel is negligible. On the other hand, the reverse proxy (I'm only speaking from experience with nginx here) saves the data to file while it is receiving it. I think you should look for a solution that lets nginx pass the path to that file to mongrel rather than sending the data again. I believe I have read about such a solution on this very list a few months ago. So, not the help you wanted, but I hope it leads you in the right direction. Well, if you actually intend to have mongrel face the public, then just forget what I said. Good luck! /David ____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 From basic70 at gmail.com Mon Oct 15 10:10:06 2007 From: basic70 at gmail.com (Daniel Brahneborg) Date: Mon, 15 Oct 2007 16:10:06 +0200 Subject: [Mongrel] POST with huge HTTP body In-Reply-To: <445886.78918.qm@web30907.mail.mud.yahoo.com> References: <445886.78918.qm@web30907.mail.mud.yahoo.com> Message-ID: Thanks for the replies. The fact that Mongrel shouldn't be the first one to get the POST/PUT data was a good point that I hadn't thought of. However, even when talking directly to Mongrel, the memory consumption of the application increases until it crashes if too much data is sent. In my case, I was sending a 500MB file from a Webdav client. At some point all of it was loaded into RAM, which doesn't work. Are there any more productive alternatives than writing the entire thing from scratch in C? Please? :) /Daniel On 10/15/07, Tim Kuijsten wrote: > A while ago I wrote a plugin to limit uploads in Mongrel. Mongrel does save uploads to a tempfile on disk - if the upload is bigger than about 12 KB - using a Ruby TempFile-object. (which stores in the $TMPDIR, /tmp on most systems). > > > The request is handed over to Rails after it's fully received by Mongrel. > > > I'm not sure if this "saving to disk" works the same with chunked uploads (uploads without a Content-Length header). > > > > Maybe my plugin can help you: http://slasaus.netsend.nl/articles/show/7 (warning: it works, but is not very elegant). > > > Gl, > > > Tim > > ----- Original Message ---- > From: Daniel Brahneborg > To: mongrel-users at rubyforge.org > Sent: Monday, October 15, 2007 2:00:20 PM > Subject: [Mongrel] POST with huge HTTP body > > > Hi, > > I found the following page describing how to stream data from the > server to the client: > > http://api.rubyonrails.com/classes/ActionController/Streaming.html > > I want to do the opposite, streaming data from the client to the > server, > letting the controller saving the data while it's being received. > In particular, I want to upload large files to the RailsDav > (http://www.liverail.net/railsdav) plugin, without having to store > the entire file in memory during the operation. > > This seems to be a Mongrel problem, so I started looking at this > plugin: > > http://mongrel.rubyforge.org/docs/upload_progress.html > > How do I get Mongrel to store the incoming POST data in a tempfile, > passing a handler to that file as the raw_post field in the Rails > request? > Is it even possible? > How is the "request" parameter to the process() method related to the > "request" object in the Rails controllers? > > /Daniel > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > ____________________________________________________________________________________ > Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From kuijsten at yahoo.com Mon Oct 15 10:37:57 2007 From: kuijsten at yahoo.com (Tim Kuijsten) Date: Mon, 15 Oct 2007 07:37:57 -0700 (PDT) Subject: [Mongrel] POST with huge HTTP body Message-ID: <246083.40834.qm@web30912.mail.mud.yahoo.com> Since a vanilla Mongrel will store uploaded data on disk in a tempfile, maybe it has something to do with your Railsdav plugin? I just tested an 80 MB upload with my Apache 2.2.6 reverse proxy and Mongrel 1.0.1 cluster and it does save the object first to /tmp on disk and not in memory. The memory used by the mongrel process before I started uploading was 50 MB. While uploading it peaked at 57 MB but was mostly stable around 50-52 MB. And after the upload was done it was back again at 50 MB. Maybe your $TMPDIR is not writable for the user you are running mongrel under? Just before the upload was finished: $ ls -hl /tmp/ total 160288 -rw------- 1 mongrel wheel 78.2M Oct 15 16:31 mongrel.25.0 I would start looking in the Railsdav plugin you are using, seems like they changed the default of saving to disk, to memory. Cheers. ----- Original Message ---- From: Daniel Brahneborg To: mongrel-users at rubyforge.org Sent: Monday, October 15, 2007 4:10:06 PM Subject: Re: [Mongrel] POST with huge HTTP body Thanks for the replies. The fact that Mongrel shouldn't be the first one to get the POST/PUT data was a good point that I hadn't thought of. However, even when talking directly to Mongrel, the memory consumption of the application increases until it crashes if too much data is sent. In my case, I was sending a 500MB file from a Webdav client. At some point all of it was loaded into RAM, which doesn't work. Are there any more productive alternatives than writing the entire thing from scratch in C? Please? :) /Daniel On 10/15/07, Tim Kuijsten wrote: > A while ago I wrote a plugin to limit uploads in Mongrel. Mongrel does save uploads to a tempfile on disk - if the upload is bigger than about 12 KB - using a Ruby TempFile-object. (which stores in the $TMPDIR, /tmp on most systems). > > > The request is handed over to Rails after it's fully received by Mongrel. > > > I'm not sure if this "saving to disk" works the same with chunked uploads (uploads without a Content-Length header). > > > > Maybe my plugin can help you: http://slasaus.netsend.nl/articles/show/7 (warning: it works, but is not very elegant). > > > Gl, > > > Tim > > ----- Original Message ---- > From: Daniel Brahneborg > To: mongrel-users at rubyforge.org > Sent: Monday, October 15, 2007 2:00:20 PM > Subject: [Mongrel] POST with huge HTTP body > > > Hi, > > I found the following page describing how to stream data from the > server to the client: > > http://api.rubyonrails.com/classes/ActionController/Streaming.html > > I want to do the opposite, streaming data from the client to the > server, > letting the controller saving the data while it's being received. > In particular, I want to upload large files to the RailsDav > (http://www.liverail.net/railsdav) plugin, without having to store > the entire file in memory during the operation. > > This seems to be a Mongrel problem, so I started looking at this > plugin: > > http://mongrel.rubyforge.org/docs/upload_progress.html > > How do I get Mongrel to store the incoming POST data in a tempfile, > passing a handler to that file as the raw_post field in the Rails > request? > Is it even possible? > How is the "request" parameter to the process() method related to the > "request" object in the Rails controllers? > > /Daniel > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > ____________________________________________________________________________________ > Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > _______________________________________________ Mongrel-users mailing list Mongrel-users at rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC From evan at cloudbur.st Mon Oct 15 11:14:51 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 15 Oct 2007 11:14:51 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <47136912.6080107@robmela.com> References: <47136912.6080107@robmela.com> Message-ID: Mod_proxy_balancer is just a weighted round-robin, and doesn't consider actual worker load, so I don't think this will help you. Have you looked at Evented Mongrel? Evan On 10/15/07, Robert Mela wrote: > Rails instances themselves are almost always single-threaded, whereas > Mongrel, and it's acceptor, are multithreaded. > > In a situation with long-running Rails pages this presents a problem for > mod_proxy_balancer. > > If num_processors is greater than 1 ( default: 950 ), then Mongrel will > gladly accept incoming requests and queue them if its rails instance is > currently busy. So even though there are non-busy mongrel instances, > a busy one can accept a new request and queue it behind a long-running > request. > > I tried setting num_processors to 1. But it looks like this is less > than ideal -- I need to dig into mod_proxy_balancer to be sure. But at > first glance, it appears this replaces queuing problem with a proxy > error. That's because Mongrel still accepts the incoming request -- > only to close the new socket immediately if Rails is busy. > > Once again, I do need to set up a test and see exactly how > mod_proxy_balancer handles this... but... > > If I understand the problem correctly, then one solution might be moving > lines 721 thru 734 into a loop, possibly in its own method, which does > sth like this: > > def myaccept > while true > return @socket.accept if worker_list.length < num_processors ## > check first to see if we can handle the request. Let client worry about > connect timeouts. > while @num_processors < reap_dead_workers > sleep @loop_throttle > end > end > end > > > > 720 @acceptor = Thread.new do > 721 while true > 722 begin > * 723 client = @socket.accept > * 724 > 725 if $tcp_cork_opts > 726 client.setsockopt(*$tcp_cork_opts) rescue nil > 727 end > 728 > 729 worker_list = @workers.list > 730 > 731 if worker_list.length >= @num_processors > 732 STDERR.puts "Server overloaded with > #{worker_list.length} processors (#@num_processors max). > Dropping connection." > * 733 client.close rescue Object* > 734 reap_dead_workers("max processors") > 735 else > 736 thread = Thread.new(client) {|c| process_client(c) } > 737 thread[:started_on] = Time.now > 738 @workers.add(thread) > 739 > 740 sleep @timeout/100 if @timeout > 0 > 741 end > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > -- Evan Weaver Cloudburst, LLC From rob at robmela.com Mon Oct 15 12:39:10 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 15 Oct 2007 12:39:10 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: References: <47136912.6080107@robmela.com> Message-ID: <471397AE.2010402@robmela.com> But it is precisely because of mod_proxy_balancer's round-robin algorithm that I think the fix *would* work. If we give mod_proxy_balancer the option of timing out on connect, it will iterate to the next mongrel instance in the pool. Of course, I should look at Evented Mongrel, and swiftiply. But still, my original question remains. I think that Mongrel would play much more nicely with mod_proxy_balancer out-of-the-box if it refused to call accept() call accept until worker_list.length has been reduced. I personally prefer that to request queuing and certainly to "accept then drop without warning". The wildcard, of course, is what mod_proxy_balancer does in the drop without warning case -- if it gracefully moves on to the next Mongrel server in its balancer pool, then all is well, and I'm making a fuss about nothing. Here's an armchair scenario to better illustrate why I think a fix would work. Again, I need to test to insure that mod_proxy_balancer doesn't currently handle the situation gracefully -- Consider: - A pool of 10 mongrels behind mod_proxy_balancer. - One mongrel, say #5, gets a request that takes one minute to run ( e.g., complex report ) - System as a whole gets 10 processing requests per second What happens (I think) with the current code and mod_proxy_balancer - Mongrel instance #5 will continue receiving a new request every second. - Over the one minute period, 10% of requests will either be - queued and unnecessarily delayed (num_processors > 60 ) - be picked up and dropped without warning ( num_processors == 1 ) What should happen if mongrel does not invoke "accept" when all workers are busy: - Mongrel instance #5 will continue getting new *connection requests* every second - mod_proxy_balancer connect() will time out - mod_proxy_balancer will continue cycling through the pool till it finds an available Mongrel instance Again, if all is well under the current scenario -- Apache mod_proxy_balancer gracefully moves on to another Mongrel instance after the accept/drop, then I've just made a big fuss over a really dumb question... Evan Weaver wrote: > Mod_proxy_balancer is just a weighted round-robin, and doesn't > consider actual worker load, so I don't think this will help you. Have > you looked at Evented Mongrel? > > Evan > > On 10/15/07, Robert Mela wrote: > >> Rails instances themselves are almost always single-threaded, whereas >> Mongrel, and it's acceptor, are multithreaded. >> >> In a situation with long-running Rails pages this presents a problem for >> mod_proxy_balancer. >> >> If num_processors is greater than 1 ( default: 950 ), then Mongrel will >> gladly accept incoming requests and queue them if its rails instance is >> currently busy. So even though there are non-busy mongrel instances, >> a busy one can accept a new request and queue it behind a long-running >> request. >> >> I tried setting num_processors to 1. But it looks like this is less >> than ideal -- I need to dig into mod_proxy_balancer to be sure. But at >> first glance, it appears this replaces queuing problem with a proxy >> error. That's because Mongrel still accepts the incoming request -- >> only to close the new socket immediately if Rails is busy. >> >> Once again, I do need to set up a test and see exactly how >> mod_proxy_balancer handles this... but... >> >> If I understand the problem correctly, then one solution might be moving >> lines 721 thru 734 into a loop, possibly in its own method, which does >> sth like this: >> >> def myaccept >> while true >> return @socket.accept if worker_list.length < num_processors ## >> check first to see if we can handle the request. Let client worry about >> connect timeouts. >> while @num_processors < reap_dead_workers >> sleep @loop_throttle >> end >> end >> end >> >> >> >> 720 @acceptor = Thread.new do >> 721 while true >> 722 begin >> * 723 client = @socket.accept >> * 724 >> 725 if $tcp_cork_opts >> 726 client.setsockopt(*$tcp_cork_opts) rescue nil >> 727 end >> 728 >> 729 worker_list = @workers.list >> 730 >> 731 if worker_list.length >= @num_processors >> 732 STDERR.puts "Server overloaded with >> #{worker_list.length} processors (#@num_processors max). >> Dropping connection." >> * 733 client.close rescue Object* >> 734 reap_dead_workers("max processors") >> 735 else >> 736 thread = Thread.new(client) {|c| process_client(c) } >> 737 thread[:started_on] = Time.now >> 738 @workers.add(thread) >> 739 >> 740 sleep @timeout/100 if @timeout > 0 >> 741 end >> >> >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> >> >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071015/41c02f4a/attachment.vcf From evan at cloudbur.st Mon Oct 15 12:48:48 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 15 Oct 2007 12:48:48 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <471397AE.2010402@robmela.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> Message-ID: Oh, I misunderstood your code. I don't think mod_proxy_balancer gracefully moves on so perhaps you are right. On the other hand, I thought when a worker timed out it got removed from the pool permanently. I can't seem to verify that one way or the other in the Apache docs, though. Evan On 10/15/07, Robert Mela wrote: > But it is precisely because of mod_proxy_balancer's round-robin > algorithm that I think the fix *would* work. If we give > mod_proxy_balancer the option of timing out on connect, it will iterate > to the next mongrel instance in the pool. > > Of course, I should look at Evented Mongrel, and swiftiply. > > But still, my original question remains. I think that Mongrel would > play much more nicely with mod_proxy_balancer out-of-the-box if it > refused to call accept() call accept until worker_list.length has been > reduced. I personally prefer that to request queuing and certainly to > "accept then drop without warning". > > The wildcard, of course, is what mod_proxy_balancer does in the drop > without warning case -- if it gracefully moves on to the next Mongrel > server in its balancer pool, then all is well, and I'm making a fuss > about nothing. > > Here's an armchair scenario to better illustrate why I think a fix would > work. Again, I need to test to insure that mod_proxy_balancer doesn't > currently handle the situation gracefully -- > > Consider: > > - A pool of 10 mongrels behind mod_proxy_balancer. > - One mongrel, say #5, gets a request that takes one minute to run ( > e.g., complex report ) > - System as a whole gets 10 processing requests per second > > What happens (I think) with the current code and mod_proxy_balancer > > - Mongrel instance #5 will continue receiving a new request every second. > - Over the one minute period, 10% of requests will either be > - queued and unnecessarily delayed (num_processors > 60 ) > - be picked up and dropped without warning ( num_processors == 1 ) > > What should happen if mongrel does not invoke "accept" when all workers > are busy: > > - Mongrel instance #5 will continue getting new *connection requests* > every second > - mod_proxy_balancer connect() will time out > - mod_proxy_balancer will continue cycling through the pool till it > finds an available Mongrel instance > > > Again, if all is well under the current scenario -- Apache > mod_proxy_balancer gracefully moves on to another Mongrel instance after > the accept/drop, then I've just made a big fuss over a really dumb > question... > > > Evan Weaver wrote: > > Mod_proxy_balancer is just a weighted round-robin, and doesn't > > consider actual worker load, so I don't think this will help you. Have > > you looked at Evented Mongrel? > > > > Evan > > > > On 10/15/07, Robert Mela wrote: > > > >> Rails instances themselves are almost always single-threaded, whereas > >> Mongrel, and it's acceptor, are multithreaded. > >> > >> In a situation with long-running Rails pages this presents a problem for > >> mod_proxy_balancer. > >> > >> If num_processors is greater than 1 ( default: 950 ), then Mongrel will > >> gladly accept incoming requests and queue them if its rails instance is > >> currently busy. So even though there are non-busy mongrel instances, > >> a busy one can accept a new request and queue it behind a long-running > >> request. > >> > >> I tried setting num_processors to 1. But it looks like this is less > >> than ideal -- I need to dig into mod_proxy_balancer to be sure. But at > >> first glance, it appears this replaces queuing problem with a proxy > >> error. That's because Mongrel still accepts the incoming request -- > >> only to close the new socket immediately if Rails is busy. > >> > >> Once again, I do need to set up a test and see exactly how > >> mod_proxy_balancer handles this... but... > >> > >> If I understand the problem correctly, then one solution might be moving > >> lines 721 thru 734 into a loop, possibly in its own method, which does > >> sth like this: > >> > >> def myaccept > >> while true > >> return @socket.accept if worker_list.length < num_processors ## > >> check first to see if we can handle the request. Let client worry about > >> connect timeouts. > >> while @num_processors < reap_dead_workers > >> sleep @loop_throttle > >> end > >> end > >> end > >> > >> > >> > >> 720 @acceptor = Thread.new do > >> 721 while true > >> 722 begin > >> * 723 client = @socket.accept > >> * 724 > >> 725 if $tcp_cork_opts > >> 726 client.setsockopt(*$tcp_cork_opts) rescue nil > >> 727 end > >> 728 > >> 729 worker_list = @workers.list > >> 730 > >> 731 if worker_list.length >= @num_processors > >> 732 STDERR.puts "Server overloaded with > >> #{worker_list.length} processors (#@num_processors max). > >> Dropping connection." > >> * 733 client.close rescue Object* > >> 734 reap_dead_workers("max processors") > >> 735 else > >> 736 thread = Thread.new(client) {|c| process_client(c) } > >> 737 thread[:started_on] = Time.now > >> 738 @workers.add(thread) > >> 739 > >> 740 sleep @timeout/100 if @timeout > 0 > >> 741 end > >> > >> > >> _______________________________________________ > >> Mongrel-users mailing list > >> Mongrel-users at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/mongrel-users > >> > >> > >> > > > > > > > > > -- Evan Weaver Cloudburst, LLC From evan at cloudbur.st Mon Oct 15 12:51:47 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 15 Oct 2007 12:51:47 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> Message-ID: Ah, no, they are only marked operational until the retry timeout is elapsed. So I guess if you had extremely small timeouts in Apache and Mongrel both it would work ok. Someone else respond, because clearly I don't know what I'm talking about. :) Evan On 10/15/07, Evan Weaver wrote: > Oh, I misunderstood your code. > > I don't think mod_proxy_balancer gracefully moves on so perhaps you > are right. On the other hand, I thought when a worker timed out it got > removed from the pool permanently. I can't seem to verify that one way > or the other in the Apache docs, though. > > Evan > > On 10/15/07, Robert Mela wrote: > > But it is precisely because of mod_proxy_balancer's round-robin > > algorithm that I think the fix *would* work. If we give > > mod_proxy_balancer the option of timing out on connect, it will iterate > > to the next mongrel instance in the pool. > > > > Of course, I should look at Evented Mongrel, and swiftiply. > > > > But still, my original question remains. I think that Mongrel would > > play much more nicely with mod_proxy_balancer out-of-the-box if it > > refused to call accept() call accept until worker_list.length has been > > reduced. I personally prefer that to request queuing and certainly to > > "accept then drop without warning". > > > > The wildcard, of course, is what mod_proxy_balancer does in the drop > > without warning case -- if it gracefully moves on to the next Mongrel > > server in its balancer pool, then all is well, and I'm making a fuss > > about nothing. > > > > Here's an armchair scenario to better illustrate why I think a fix would > > work. Again, I need to test to insure that mod_proxy_balancer doesn't > > currently handle the situation gracefully -- > > > > Consider: > > > > - A pool of 10 mongrels behind mod_proxy_balancer. > > - One mongrel, say #5, gets a request that takes one minute to run ( > > e.g., complex report ) > > - System as a whole gets 10 processing requests per second > > > > What happens (I think) with the current code and mod_proxy_balancer > > > > - Mongrel instance #5 will continue receiving a new request every second. > > - Over the one minute period, 10% of requests will either be > > - queued and unnecessarily delayed (num_processors > 60 ) > > - be picked up and dropped without warning ( num_processors == 1 ) > > > > What should happen if mongrel does not invoke "accept" when all workers > > are busy: > > > > - Mongrel instance #5 will continue getting new *connection requests* > > every second > > - mod_proxy_balancer connect() will time out > > - mod_proxy_balancer will continue cycling through the pool till it > > finds an available Mongrel instance > > > > > > Again, if all is well under the current scenario -- Apache > > mod_proxy_balancer gracefully moves on to another Mongrel instance after > > the accept/drop, then I've just made a big fuss over a really dumb > > question... > > > > > > Evan Weaver wrote: > > > Mod_proxy_balancer is just a weighted round-robin, and doesn't > > > consider actual worker load, so I don't think this will help you. Have > > > you looked at Evented Mongrel? > > > > > > Evan > > > > > > On 10/15/07, Robert Mela wrote: > > > > > >> Rails instances themselves are almost always single-threaded, whereas > > >> Mongrel, and it's acceptor, are multithreaded. > > >> > > >> In a situation with long-running Rails pages this presents a problem for > > >> mod_proxy_balancer. > > >> > > >> If num_processors is greater than 1 ( default: 950 ), then Mongrel will > > >> gladly accept incoming requests and queue them if its rails instance is > > >> currently busy. So even though there are non-busy mongrel instances, > > >> a busy one can accept a new request and queue it behind a long-running > > >> request. > > >> > > >> I tried setting num_processors to 1. But it looks like this is less > > >> than ideal -- I need to dig into mod_proxy_balancer to be sure. But at > > >> first glance, it appears this replaces queuing problem with a proxy > > >> error. That's because Mongrel still accepts the incoming request -- > > >> only to close the new socket immediately if Rails is busy. > > >> > > >> Once again, I do need to set up a test and see exactly how > > >> mod_proxy_balancer handles this... but... > > >> > > >> If I understand the problem correctly, then one solution might be moving > > >> lines 721 thru 734 into a loop, possibly in its own method, which does > > >> sth like this: > > >> > > >> def myaccept > > >> while true > > >> return @socket.accept if worker_list.length < num_processors ## > > >> check first to see if we can handle the request. Let client worry about > > >> connect timeouts. > > >> while @num_processors < reap_dead_workers > > >> sleep @loop_throttle > > >> end > > >> end > > >> end > > >> > > >> > > >> > > >> 720 @acceptor = Thread.new do > > >> 721 while true > > >> 722 begin > > >> * 723 client = @socket.accept > > >> * 724 > > >> 725 if $tcp_cork_opts > > >> 726 client.setsockopt(*$tcp_cork_opts) rescue nil > > >> 727 end > > >> 728 > > >> 729 worker_list = @workers.list > > >> 730 > > >> 731 if worker_list.length >= @num_processors > > >> 732 STDERR.puts "Server overloaded with > > >> #{worker_list.length} processors (#@num_processors max). > > >> Dropping connection." > > >> * 733 client.close rescue Object* > > >> 734 reap_dead_workers("max processors") > > >> 735 else > > >> 736 thread = Thread.new(client) {|c| process_client(c) } > > >> 737 thread[:started_on] = Time.now > > >> 738 @workers.add(thread) > > >> 739 > > >> 740 sleep @timeout/100 if @timeout > 0 > > >> 741 end > > >> > > >> > > >> _______________________________________________ > > >> Mongrel-users mailing list > > >> Mongrel-users at rubyforge.org > > >> http://rubyforge.org/mailman/listinfo/mongrel-users > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > -- > Evan Weaver > Cloudburst, LLC > -- Evan Weaver Cloudburst, LLC From evan at cloudbur.st Mon Oct 15 15:12:54 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 15 Oct 2007 15:12:54 -0400 Subject: [Mongrel] 1.0.2 release candidates In-Reply-To: References: Message-ID: Hi all, The candidates have been updated with some bugfixes. Please uninstall and reinstall. $ sudo gem install mongrel --include-dependencies --source http://mongrel.rubyforge.org/releases/ -P HighSecurity Evan On 10/11/07, Evan Weaver wrote: > The CHANGELOG message for Mongrel is just: > > v1.0.2. Signed gem; various bugfixes and patches. > > There should be no breaking changes. If you're interested in a > specific bug, check the tracker and see what the resolution was. > > The detailed SVN log up to and including 1.0.2 is at > http://mongrel.rubyforge.org/releases/Changelog . > > Mongrel_cluster v1.0.3 includes Capistrano 2 recipes. That's probably > the most significant new feature. > > Evan > > On 10/11/07, Hunter Hillegas wrote: > > What's the word on the changes? > > > > On Oct 10, 2007, at 11:55 PM, Evan Weaver wrote: > > > > > Hello Mongrels, > > > > > > Release candidates for Mongrel 1.0.2 and its dependencies are now > > > available. Note that gems are now signed, so please add the Mongrel > > > public certificate via: > > > > > > $ wget http://rubyforge.org/frs/download.php/25325/mongrel- > > > public_cert.pem > > > $ gem cert --add mongrel-public_cert.pem > > > > > > Now you can verify and install the candidates via gem install: > > > > > > $ sudo gem install mongrel --include-dependencies --source > > > http://mongrel.rubyforge.org/releases/ -P HighSecurity > > > > > > Manual downloads are available from http://mongrel.rubyforge.org/ > > > releases/ . > > > > > > Please report problems on the Rubyforge tracker at > > > http://rubyforge.org/tracker/?group_id=1306 . We will finalize the > > > release in a week or two, barring unforeseen difficulties. > > > > > > Thanks, > > > > > > Evan, and the Mongrel Team > > > > > > > > > PS. If you really don't care about authenticity, and don't want to > > > install the public certificate, you can omit the '-P HighSecurity' > > > option in 'gem install'. > > > > > > -- > > > Evan Weaver > > > Cloudburst, LLC > > > _______________________________________________ > > > Mongrel-users mailing list > > > Mongrel-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > -- > Evan Weaver > Cloudburst, LLC > -- Evan Weaver Cloudburst, LLC From bassnode at gmail.com Mon Oct 15 15:23:53 2007 From: bassnode at gmail.com (Ed Hickey) Date: Mon, 15 Oct 2007 14:23:53 -0500 Subject: [Mongrel] 1.0.2 release candidates In-Reply-To: References: Message-ID: <733f56120710151223g575e03d0pb606aa73dceda73b@mail.gmail.com> I ran into an issue with upgrading to mongrel 1.0.2. This was last Friday, so this may be fixed now. The REMOTE_ADDR environment variable comes across in IPv6 format now, instead of IPv4 (as in 1.0.1). This caused some issues in a ruby library that didn't know how to handle IPv6 IPs. No huge deal, but thought I'd throw it out there... Ed On 10/15/07, Evan Weaver wrote: > Hi all, > > The candidates have been updated with some bugfixes. Please uninstall > and reinstall. > > $ sudo gem install mongrel --include-dependencies --source > http://mongrel.rubyforge.org/releases/ -P HighSecurity > > Evan > > On 10/11/07, Evan Weaver wrote: > > The CHANGELOG message for Mongrel is just: > > > > v1.0.2. Signed gem; various bugfixes and patches. > > > > There should be no breaking changes. If you're interested in a > > specific bug, check the tracker and see what the resolution was. > > > > The detailed SVN log up to and including 1.0.2 is at > > http://mongrel.rubyforge.org/releases/Changelog . > > > > Mongrel_cluster v1.0.3 includes Capistrano 2 recipes. That's probably > > the most significant new feature. > > > > Evan > > > > On 10/11/07, Hunter Hillegas wrote: > > > What's the word on the changes? > > > > > > On Oct 10, 2007, at 11:55 PM, Evan Weaver wrote: > > > > > > > Hello Mongrels, > > > > > > > > Release candidates for Mongrel 1.0.2 and its dependencies are now > > > > available. Note that gems are now signed, so please add the Mongrel > > > > public certificate via: > > > > > > > > $ wget http://rubyforge.org/frs/download.php/25325/mongrel- > > > > public_cert.pem > > > > $ gem cert --add mongrel-public_cert.pem > > > > > > > > Now you can verify and install the candidates via gem install: > > > > > > > > $ sudo gem install mongrel --include-dependencies --source > > > > http://mongrel.rubyforge.org/releases/ -P HighSecurity > > > > > > > > Manual downloads are available from http://mongrel.rubyforge.org/ > > > > releases/ . > > > > > > > > Please report problems on the Rubyforge tracker at > > > > http://rubyforge.org/tracker/?group_id=1306 . We will finalize the > > > > release in a week or two, barring unforeseen difficulties. > > > > > > > > Thanks, > > > > > > > > Evan, and the Mongrel Team > > > > > > > > > > > > PS. If you really don't care about authenticity, and don't want to > > > > install the public certificate, you can omit the '-P HighSecurity' > > > > option in 'gem install'. > > > > > > > > -- > > > > Evan Weaver > > > > Cloudburst, LLC > > > > _______________________________________________ > > > > Mongrel-users mailing list > > > > Mongrel-users at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > _______________________________________________ > > > Mongrel-users mailing list > > > Mongrel-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > > -- > > Evan Weaver > > Cloudburst, LLC > > > > > -- > Evan Weaver > Cloudburst, LLC > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From erik.hetzner at ucop.edu Mon Oct 15 15:13:22 2007 From: erik.hetzner at ucop.edu (Erik Hetzner) Date: Mon, 15 Oct 2007 12:13:22 -0700 Subject: [Mongrel] POST with huge HTTP body In-Reply-To: References: Message-ID: <87ir58ur71.wl%erik.hetzner@ucop.edu> At Mon, 15 Oct 2007 14:00:20 +0200, "Daniel Brahneborg" wrote: > > Hi, > > I found the following page describing how to stream data from the > server to the client: > > http://api.rubyonrails.com/classes/ActionController/Streaming.html > > I want to do the opposite, streaming data from the client to the > server, letting the controller saving the data while it's being > received. In particular, I want to upload large files to the > RailsDav (http://www.liverail.net/railsdav) plugin, without having > to store the entire file in memory during the operation. > > This seems to be a Mongrel problem, so I started looking at this plugin: > > http://mongrel.rubyforge.org/docs/upload_progress.html > > How do I get Mongrel to store the incoming POST data in a tempfile, > passing a handler to that file as the raw_post field in the Rails request? > Is it even possible? Hi Daniel, Mongrel is going to put a large POSTed body into a tempfile. Examine the mongrel.rb file around line 220. In this case your request.body is going to be a File object. Why do you think that there is a mongrel problem here? See also what Tim Kuijsten said in this thread. > How is the "request" parameter to the process() method related to > the "request" object in the Rails controllers? request in mongrel (as sent to process) is an instance of Mongrel::HttpRequest. In Rails it is an instance of ActionController::CgiRequest. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071015/b71fcda3/attachment.bin From evan at cloudbur.st Mon Oct 15 15:39:49 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 15 Oct 2007 15:39:49 -0400 Subject: [Mongrel] 1.0.2 release candidates In-Reply-To: <733f56120710151223g575e03d0pb606aa73dceda73b@mail.gmail.com> References: <733f56120710151223g575e03d0pb606aa73dceda73b@mail.gmail.com> Message-ID: Sounds like a bug; can you file a ticket? Ideally with a test? Evan On 10/15/07, Ed Hickey wrote: > I ran into an issue with upgrading to mongrel 1.0.2. This was last > Friday, so this may be fixed now. The REMOTE_ADDR environment > variable comes across in IPv6 format now, instead of IPv4 (as in > 1.0.1). > > This caused some issues in a ruby library that didn't know how to > handle IPv6 IPs. No huge deal, but thought I'd throw it out there... > > Ed > > On 10/15/07, Evan Weaver wrote: > > Hi all, > > > > The candidates have been updated with some bugfixes. Please uninstall > > and reinstall. > > > > $ sudo gem install mongrel --include-dependencies --source > > http://mongrel.rubyforge.org/releases/ -P HighSecurity > > > > Evan > > > > On 10/11/07, Evan Weaver wrote: > > > The CHANGELOG message for Mongrel is just: > > > > > > v1.0.2. Signed gem; various bugfixes and patches. > > > > > > There should be no breaking changes. If you're interested in a > > > specific bug, check the tracker and see what the resolution was. > > > > > > The detailed SVN log up to and including 1.0.2 is at > > > http://mongrel.rubyforge.org/releases/Changelog . > > > > > > Mongrel_cluster v1.0.3 includes Capistrano 2 recipes. That's probably > > > the most significant new feature. > > > > > > Evan > > > > > > On 10/11/07, Hunter Hillegas wrote: > > > > What's the word on the changes? > > > > > > > > On Oct 10, 2007, at 11:55 PM, Evan Weaver wrote: > > > > > > > > > Hello Mongrels, > > > > > > > > > > Release candidates for Mongrel 1.0.2 and its dependencies are now > > > > > available. Note that gems are now signed, so please add the Mongrel > > > > > public certificate via: > > > > > > > > > > $ wget http://rubyforge.org/frs/download.php/25325/mongrel- > > > > > public_cert.pem > > > > > $ gem cert --add mongrel-public_cert.pem > > > > > > > > > > Now you can verify and install the candidates via gem install: > > > > > > > > > > $ sudo gem install mongrel --include-dependencies --source > > > > > http://mongrel.rubyforge.org/releases/ -P HighSecurity > > > > > > > > > > Manual downloads are available from http://mongrel.rubyforge.org/ > > > > > releases/ . > > > > > > > > > > Please report problems on the Rubyforge tracker at > > > > > http://rubyforge.org/tracker/?group_id=1306 . We will finalize the > > > > > release in a week or two, barring unforeseen difficulties. > > > > > > > > > > Thanks, > > > > > > > > > > Evan, and the Mongrel Team > > > > > > > > > > > > > > > PS. If you really don't care about authenticity, and don't want to > > > > > install the public certificate, you can omit the '-P HighSecurity' > > > > > option in 'gem install'. > > > > > > > > > > -- > > > > > Evan Weaver > > > > > Cloudburst, LLC > > > > > _______________________________________________ > > > > > Mongrel-users mailing list > > > > > Mongrel-users at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > _______________________________________________ > > > > Mongrel-users mailing list > > > > Mongrel-users at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > > > > > > -- > > > Evan Weaver > > > Cloudburst, LLC > > > > > > > > > -- > > Evan Weaver > > Cloudburst, LLC > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From rob at robmela.com Mon Oct 15 16:52:27 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 15 Oct 2007 16:52:27 -0400 Subject: [Mongrel] Workaround found for request queuing vs. num_processors, accept/close In-Reply-To: References: <47136912.6080107@robmela.com> Message-ID: <4713D30B.3080109@robmela.com> I've discovered a setting in mod_proxy_balancer that prevents the Mongrel/Rails request queuing vs. accept/close problem from ever being reached. For each BalancerMember - max=1 -- this caps the maximum number of connections Apache will open a BalancerMember to '1' - acquire=N max amount of time (N seconds) to wait to acquire a connection to a balancer member So, at a minimum: BalancerMember http://foo max=1 acquire=1 and I'm using BalancerMember http://127.0.0.1:9000 max=1 keepalive=on acquire=1 timeout=1 ===== I experimented with three mongrel servers, and tied one up for 60 seconds at a time calling "sleep" in a handler. Without the "acquire" parameter mod_proxy_balancer's simple round-robin scheme blocked waiting when it reached a busy BalancerManager, effectively queuing the request. With "acquire" set the balancer stepped over the busy BalancerMember and continue searching through it's round-robin cycle. So, whether or not Mongrel's accept/close and request queuing are issues, there is a setting in mod_proxy_balancer that prevents either problem from being triggered. At a bare minimum, for a single-threaded process running in Mongrel BalancerMember http://127.0.0.1:9000 max=1 acquire=1 BalancerMember http://127.0.0.1:9001 max=1 acquire=1 ... With all BalancerMembers busy Apache returns a 503 Server Busy, which is a heck of a lot more appropriate than 502 proxy error. ====== It turns out that having Mongrel reap threads before calling accept both queueing in Mongrel and prevents Mongrel's accept/close behavior. But BalancerMembers in mod_proxy_balancer will still need "acquire" to be set -- otherwise proxy client threads will sit around waiting for Mongrel to call accept -- effectively queuing requests in Apache. Since max=1 acquire=1 steps around the queuing problem altogether, the reap-before-accept fix, though more correct, is of no practical benefit. ==== With the current Mongrel code, BalancerMember max > 1 and Mongrel num_processors > 1 triggers the accept/close bug. Likewise, BalancerMember max >1 with Mongrel num_processors > 1 runs into Mongrel's request queuing.... ==== Conclusion --- I'd like to see Mongrel return a 503 Server Busy when an incoming request hits the num_processor limit. For practical use, the fix to the problems is in configuring mod_proxy_balancer such that it shields against encountering either issue. -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071015/b4553556/attachment.vcf From rob at robmela.com Mon Oct 15 17:18:10 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 15 Oct 2007 17:18:10 -0400 Subject: [Mongrel] Workaround found for request queuing vs. num_processors, accept/close In-Reply-To: <4713D30B.3080109@robmela.com> References: <47136912.6080107@robmela.com> <4713D30B.3080109@robmela.com> Message-ID: <4713D912.3060700@robmela.com> Typo -- the following is incorrect: With the current Mongrel code, BalancerMember max > 1 and Mongrel num_processors > 1 triggers the accept/close bug. should be: With the current Mongrel code, BalancerMember max > 1 and Mongrel num_processors = 1 triggers the accept/close bug. ==== Robert Mela wrote: > I've discovered a setting in mod_proxy_balancer that prevents the > Mongrel/Rails request queuing vs. accept/close problem from ever being > reached. > > For each BalancerMember > > - max=1 -- this caps the maximum number of connections Apache will > open a BalancerMember to '1' > - acquire=N max amount of time (N seconds) to wait to acquire a > connection to a balancer member > > So, at a minimum: > > BalancerMember http://foo max=1 acquire=1 > > and I'm using > > BalancerMember http://127.0.0.1:9000 max=1 keepalive=on acquire=1 > timeout=1 > > ===== > > I experimented with three mongrel servers, and tied one up for 60 > seconds at a time calling "sleep" in a handler. > > Without the "acquire" parameter mod_proxy_balancer's simple > round-robin scheme blocked waiting when it reached a busy > BalancerManager, effectively queuing the request. With "acquire" set > the balancer stepped over the busy BalancerMember and continue > searching through it's round-robin cycle. > > So, whether or not Mongrel's accept/close and request queuing are > issues, there is a setting in mod_proxy_balancer that prevents either > problem from being triggered. > > At a bare minimum, for a single-threaded process running in Mongrel > > BalancerMember http://127.0.0.1:9000 max=1 acquire=1 > BalancerMember http://127.0.0.1:9001 max=1 acquire=1 > ... > > With all BalancerMembers busy Apache returns a 503 Server Busy, which > is a heck of a lot more appropriate than 502 proxy error. > > ====== > > It turns out that having Mongrel reap threads before calling accept > both queueing in Mongrel and prevents Mongrel's accept/close behavior. > > But BalancerMembers in mod_proxy_balancer will still need "acquire" to > be set -- otherwise proxy client threads will sit around waiting for > Mongrel to call accept -- effectively queuing requests in Apache. > > Since max=1 acquire=1 steps around the queuing problem altogether, the > reap-before-accept fix, though more correct, is of no practical benefit. > > ==== > > With the current Mongrel code, BalancerMember max > 1 and Mongrel > num_processors > 1 triggers the accept/close bug. > > Likewise, BalancerMember max >1 with Mongrel num_processors > 1 runs > into Mongrel's request queuing.... > > ==== > > Conclusion --- > > I'd like to see Mongrel return a 503 Server Busy when an incoming > request hits the num_processor limit. > > For practical use, the fix to the problems is in configuring > mod_proxy_balancer such that it shields against encountering either > issue. > > > > > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071015/e891aa75/attachment.vcf From evan at cloudbur.st Mon Oct 15 18:04:31 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 15 Oct 2007 18:04:31 -0400 Subject: [Mongrel] Workaround found for request queuing vs. num_processors, accept/close In-Reply-To: <4713D912.3060700@robmela.com> References: <47136912.6080107@robmela.com> <4713D30B.3080109@robmela.com> <4713D912.3060700@robmela.com> Message-ID: Very cool. Can you do a little performance testing to see if it's more efficient under various loads than the current way? I would expect it would have a small but significant difference when you're near CPU saturation point, but not much if you're below (enough free resources already) or above (requests will get piled up regardless). It may be worse in the overloaded situation because no one's request will get through--the queue might grow indefinitely instead of getting truncated. The 503 behavior seems reasonable. Evan On 10/15/07, Robert Mela wrote: > Typo -- the following is incorrect: > > With the current Mongrel code, BalancerMember max > 1 and Mongrel > num_processors > 1 triggers the accept/close bug. > > should be: > > With the current Mongrel code, BalancerMember max > 1 and Mongrel > num_processors = 1 triggers the accept/close bug. > > ==== > Robert Mela wrote: > > I've discovered a setting in mod_proxy_balancer that prevents the > > Mongrel/Rails request queuing vs. accept/close problem from ever being > > reached. > > > > For each BalancerMember > > > > - max=1 -- this caps the maximum number of connections Apache will > > open a BalancerMember to '1' > > - acquire=N max amount of time (N seconds) to wait to acquire a > > connection to a balancer member > > > > So, at a minimum: > > > > BalancerMember http://foo max=1 acquire=1 > > > > and I'm using > > > > BalancerMember http://127.0.0.1:9000 max=1 keepalive=on acquire=1 > > timeout=1 > > > > ===== > > > > I experimented with three mongrel servers, and tied one up for 60 > > seconds at a time calling "sleep" in a handler. > > > > Without the "acquire" parameter mod_proxy_balancer's simple > > round-robin scheme blocked waiting when it reached a busy > > BalancerManager, effectively queuing the request. With "acquire" set > > the balancer stepped over the busy BalancerMember and continue > > searching through it's round-robin cycle. > > > > So, whether or not Mongrel's accept/close and request queuing are > > issues, there is a setting in mod_proxy_balancer that prevents either > > problem from being triggered. > > > > At a bare minimum, for a single-threaded process running in Mongrel > > > > BalancerMember http://127.0.0.1:9000 max=1 acquire=1 > > BalancerMember http://127.0.0.1:9001 max=1 acquire=1 > > ... > > > > With all BalancerMembers busy Apache returns a 503 Server Busy, which > > is a heck of a lot more appropriate than 502 proxy error. > > > > ====== > > > > It turns out that having Mongrel reap threads before calling accept > > both queueing in Mongrel and prevents Mongrel's accept/close behavior. > > > > But BalancerMembers in mod_proxy_balancer will still need "acquire" to > > be set -- otherwise proxy client threads will sit around waiting for > > Mongrel to call accept -- effectively queuing requests in Apache. > > > > Since max=1 acquire=1 steps around the queuing problem altogether, the > > reap-before-accept fix, though more correct, is of no practical benefit. > > > > ==== > > > > With the current Mongrel code, BalancerMember max > 1 and Mongrel > > num_processors > 1 triggers the accept/close bug. > > > > Likewise, BalancerMember max >1 with Mongrel num_processors > 1 runs > > into Mongrel's request queuing.... > > > > ==== > > > > Conclusion --- > > > > I'd like to see Mongrel return a 503 Server Busy when an incoming > > request hits the num_processor limit. > > > > For practical use, the fix to the problems is in configuring > > mod_proxy_balancer such that it shields against encountering either > > issue. > > > > > > > > > > > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > -- Evan Weaver Cloudburst, LLC From bassnode at gmail.com Mon Oct 15 19:30:15 2007 From: bassnode at gmail.com (Ed Hickey) Date: Mon, 15 Oct 2007 18:30:15 -0500 Subject: [Mongrel] 1.0.2 release candidates In-Reply-To: References: <733f56120710151223g575e03d0pb606aa73dceda73b@mail.gmail.com> Message-ID: <733f56120710151630i6a8ba5a6l856fc90df41d1068@mail.gmail.com> Yeah, I can do that soon. On 10/15/07, Evan Weaver wrote: > Sounds like a bug; can you file a ticket? Ideally with a test? > > Evan > > On 10/15/07, Ed Hickey wrote: > > I ran into an issue with upgrading to mongrel 1.0.2. This was last > > Friday, so this may be fixed now. The REMOTE_ADDR environment > > variable comes across in IPv6 format now, instead of IPv4 (as in > > 1.0.1). > > > > This caused some issues in a ruby library that didn't know how to > > handle IPv6 IPs. No huge deal, but thought I'd throw it out there... > > > > Ed > > > > On 10/15/07, Evan Weaver wrote: > > > Hi all, > > > > > > The candidates have been updated with some bugfixes. Please uninstall > > > and reinstall. > > > > > > $ sudo gem install mongrel --include-dependencies --source > > > http://mongrel.rubyforge.org/releases/ -P HighSecurity > > > > > > Evan > > > > > > On 10/11/07, Evan Weaver wrote: > > > > The CHANGELOG message for Mongrel is just: > > > > > > > > v1.0.2. Signed gem; various bugfixes and patches. > > > > > > > > There should be no breaking changes. If you're interested in a > > > > specific bug, check the tracker and see what the resolution was. > > > > > > > > The detailed SVN log up to and including 1.0.2 is at > > > > http://mongrel.rubyforge.org/releases/Changelog . > > > > > > > > Mongrel_cluster v1.0.3 includes Capistrano 2 recipes. That's probably > > > > the most significant new feature. > > > > > > > > Evan > > > > > > > > On 10/11/07, Hunter Hillegas wrote: > > > > > What's the word on the changes? > > > > > > > > > > On Oct 10, 2007, at 11:55 PM, Evan Weaver wrote: > > > > > > > > > > > Hello Mongrels, > > > > > > > > > > > > Release candidates for Mongrel 1.0.2 and its dependencies are now > > > > > > available. Note that gems are now signed, so please add the Mongrel > > > > > > public certificate via: > > > > > > > > > > > > $ wget http://rubyforge.org/frs/download.php/25325/mongrel- > > > > > > public_cert.pem > > > > > > $ gem cert --add mongrel-public_cert.pem > > > > > > > > > > > > Now you can verify and install the candidates via gem install: > > > > > > > > > > > > $ sudo gem install mongrel --include-dependencies --source > > > > > > http://mongrel.rubyforge.org/releases/ -P HighSecurity > > > > > > > > > > > > Manual downloads are available from http://mongrel.rubyforge.org/ > > > > > > releases/ . > > > > > > > > > > > > Please report problems on the Rubyforge tracker at > > > > > > http://rubyforge.org/tracker/?group_id=1306 . We will finalize the > > > > > > release in a week or two, barring unforeseen difficulties. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Evan, and the Mongrel Team > > > > > > > > > > > > > > > > > > PS. If you really don't care about authenticity, and don't want to > > > > > > install the public certificate, you can omit the '-P HighSecurity' > > > > > > option in 'gem install'. > > > > > > > > > > > > -- > > > > > > Evan Weaver > > > > > > Cloudburst, LLC > > > > > > _______________________________________________ > > > > > > Mongrel-users mailing list > > > > > > Mongrel-users at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > > > _______________________________________________ > > > > > Mongrel-users mailing list > > > > > Mongrel-users at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > > > > > > > > > > -- > > > > Evan Weaver > > > > Cloudburst, LLC > > > > > > > > > > > > > -- > > > Evan Weaver > > > Cloudburst, LLC > > > _______________________________________________ > > > Mongrel-users mailing list > > > Mongrel-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > -- > Evan Weaver > Cloudburst, LLC > From bwillenator at gmail.com Mon Oct 15 19:43:34 2007 From: bwillenator at gmail.com (Brian Williams) Date: Mon, 15 Oct 2007 16:43:34 -0700 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> Message-ID: <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> We recently ran into exactly this issue. Some rails requests were making external requests that were taking 5 minutes (networking issues out of our control). If your request got queued behind one of these stuck mongrels, the experience was terrible. I experimented with adjusting the mod_proxy_balance settings to try to get it to fail over to the next mongrel (I had hoped that the min,max,smax could all be set to one, and force only one connection to a mongrel at a time) but this didn't seem to work. Solution - I stuck lighttpd in between. Lighttp has a proxying algorithm that does exactly this - round robin but to worker with lightest load. I'd love to hear that there's a way to use mod_proxy_balancer, but I couldn't get to work. --Brian On 10/15/07, Evan Weaver wrote: > > Ah, no, they are only marked operational until the retry timeout is > elapsed. So I guess if you had extremely small timeouts in Apache and > Mongrel both it would work ok. > > Someone else respond, because clearly I don't know what I'm talking about. > :) > > Evan > > On 10/15/07, Evan Weaver wrote: > > Oh, I misunderstood your code. > > > > I don't think mod_proxy_balancer gracefully moves on so perhaps you > > are right. On the other hand, I thought when a worker timed out it got > > removed from the pool permanently. I can't seem to verify that one way > > or the other in the Apache docs, though. > > > > Evan > > > > On 10/15/07, Robert Mela wrote: > > > But it is precisely because of mod_proxy_balancer's round-robin > > > algorithm that I think the fix *would* work. If we give > > > mod_proxy_balancer the option of timing out on connect, it will > iterate > > > to the next mongrel instance in the pool. > > > > > > Of course, I should look at Evented Mongrel, and swiftiply. > > > > > > But still, my original question remains. I think that Mongrel would > > > play much more nicely with mod_proxy_balancer out-of-the-box if it > > > refused to call accept() call accept until worker_list.length has > been > > > reduced. I personally prefer that to request queuing and certainly > to > > > "accept then drop without warning". > > > > > > The wildcard, of course, is what mod_proxy_balancer does in the drop > > > without warning case -- if it gracefully moves on to the next Mongrel > > > server in its balancer pool, then all is well, and I'm making a fuss > > > about nothing. > > > > > > Here's an armchair scenario to better illustrate why I think a fix > would > > > work. Again, I need to test to insure that mod_proxy_balancer doesn't > > > currently handle the situation gracefully -- > > > > > > Consider: > > > > > > - A pool of 10 mongrels behind mod_proxy_balancer. > > > - One mongrel, say #5, gets a request that takes one minute to run ( > > > e.g., complex report ) > > > - System as a whole gets 10 processing requests per second > > > > > > What happens (I think) with the current code and mod_proxy_balancer > > > > > > - Mongrel instance #5 will continue receiving a new request every > second. > > > - Over the one minute period, 10% of requests will either be > > > - queued and unnecessarily delayed (num_processors > 60 ) > > > - be picked up and dropped without warning ( num_processors == 1 > ) > > > > > > What should happen if mongrel does not invoke "accept" when all > workers > > > are busy: > > > > > > - Mongrel instance #5 will continue getting new *connection requests* > > > every second > > > - mod_proxy_balancer connect() will time out > > > - mod_proxy_balancer will continue cycling through the pool till it > > > finds an available Mongrel instance > > > > > > > > > Again, if all is well under the current scenario -- Apache > > > mod_proxy_balancer gracefully moves on to another Mongrel instance > after > > > the accept/drop, then I've just made a big fuss over a really dumb > > > question... > > > > > > > > > Evan Weaver wrote: > > > > Mod_proxy_balancer is just a weighted round-robin, and doesn't > > > > consider actual worker load, so I don't think this will help you. > Have > > > > you looked at Evented Mongrel? > > > > > > > > Evan > > > > > > > > On 10/15/07, Robert Mela wrote: > > > > > > > >> Rails instances themselves are almost always single-threaded, > whereas > > > >> Mongrel, and it's acceptor, are multithreaded. > > > >> > > > >> In a situation with long-running Rails pages this presents a > problem for > > > >> mod_proxy_balancer. > > > >> > > > >> If num_processors is greater than 1 ( default: 950 ), then Mongrel > will > > > >> gladly accept incoming requests and queue them if its rails > instance is > > > >> currently busy. So even though there are non-busy mongrel > instances, > > > >> a busy one can accept a new request and queue it behind a > long-running > > > >> request. > > > >> > > > >> I tried setting num_processors to 1. But it looks like this is > less > > > >> than ideal -- I need to dig into mod_proxy_balancer to be > sure. But at > > > >> first glance, it appears this replaces queuing problem with a proxy > > > >> error. That's because Mongrel still accepts the incoming request > -- > > > >> only to close the new socket immediately if Rails is busy. > > > >> > > > >> Once again, I do need to set up a test and see exactly how > > > >> mod_proxy_balancer handles this... but... > > > >> > > > >> If I understand the problem correctly, then one solution might be > moving > > > >> lines 721 thru 734 into a loop, possibly in its own method, which > does > > > >> sth like this: > > > >> > > > >> def myaccept > > > >> while true > > > >> return @socket.accept if worker_list.length < > num_processors ## > > > >> check first to see if we can handle the request. Let client worry > about > > > >> connect timeouts. > > > >> while @num_processors < reap_dead_workers > > > >> sleep @loop_throttle > > > >> end > > > >> end > > > >> end > > > >> > > > >> > > > >> > > > >> 720 @acceptor = Thread.new do > > > >> 721 while true > > > >> 722 begin > > > >> * 723 client = @socket.accept > > > >> * 724 > > > >> 725 if $tcp_cork_opts > > > >> 726 client.setsockopt(*$tcp_cork_opts) rescue nil > > > >> 727 end > > > >> 728 > > > >> 729 worker_list = @workers.list > > > >> 730 > > > >> 731 if worker_list.length >= @num_processors > > > >> 732 STDERR.puts "Server overloaded with > > > >> #{worker_list.length} processors (#@num_processors max). > > > >> Dropping connection." > > > >> * 733 client.close rescue Object* > > > >> 734 reap_dead_workers("max processors") > > > >> 735 else > > > >> 736 thread = Thread.new(client) {|c| > process_client(c) } > > > >> 737 thread[:started_on] = Time.now > > > >> 738 @workers.add(thread) > > > >> 739 > > > >> 740 sleep @timeout/100 if @timeout > 0 > > > >> 741 end > > > >> > > > >> > > > >> _______________________________________________ > > > >> Mongrel-users mailing list > > > >> Mongrel-users at rubyforge.org > > > >> http://rubyforge.org/mailman/listinfo/mongrel-users > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Evan Weaver > > Cloudburst, LLC > > > > > -- > Evan Weaver > Cloudburst, LLC > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071015/9bfd13cd/attachment.html From zedshaw at zedshaw.com Tue Oct 16 01:42:00 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 16 Oct 2007 01:42:00 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> Message-ID: <20071016014200.7e6bf42d.zedshaw@zedshaw.com> On Mon, 15 Oct 2007 12:51:47 -0400 "Evan Weaver" wrote: > Ah, no, they are only marked operational until the retry timeout is > elapsed. So I guess if you had extremely small timeouts in Apache and > Mongrel both it would work ok. > > Someone else respond, because clearly I don't know what I'm talking about. :) I'm confused, isn't the point of a balancer that it tries all available backends multiple times before giving up? If m_p_b is aborting on the first accept that's denied then it's broken. It should try every one, and possibly twice or three times before giving up. Otherwise it's not really a "balancer", but more of a "robinder". Also, the proposed solution probably won't work. If my crufty late night brain is right, this would mean that the backend will attempt a connect to a "sleeping" mongrel and either have to wait until the TCP timeout or just get blocked. Eventually you're back at the same problem that you have tons of requests piling up, they're just piled up in the OS tcp stack where no useful work can be done. At least piling them in mongrel means some IO is getting processed. And, it sounds like nobody is actually trying these proposed solutions. Anyone got some metrics? Tried Lucas Carlson's Dr. Proxy yet? Other solutions? Evented mongrel? -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From zedshaw at zedshaw.com Tue Oct 16 01:49:09 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 16 Oct 2007 01:49:09 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> Message-ID: <20071016014909.af20351b.zedshaw@zedshaw.com> On Mon, 15 Oct 2007 16:43:34 -0700 "Brian Williams" wrote: > We recently ran into exactly this issue. Some rails requests were making > external requests that were taking 5 minutes (networking issues out of our > control). Now that's a design flaw. If you're expecting the UI user to wait for a backend request that takes 5 minutes then you need to redesign the workflow and interface. Do it like asynchronous email where the use "sends a request", "awaits a reply", "reads the reply", and doesn't deal with the backend processing chain of events. If done right, you'll even get a performance boost and you can distribute the load of these requests out to other servers. It's also a model most users are familiar with from SMTP processing. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From zedshaw at zedshaw.com Tue Oct 16 01:52:00 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 16 Oct 2007 01:52:00 -0400 Subject: [Mongrel] POST with huge HTTP body In-Reply-To: References: <445886.78918.qm@web30907.mail.mud.yahoo.com> Message-ID: <20071016015200.44e2d7fd.zedshaw@zedshaw.com> On Mon, 15 Oct 2007 16:10:06 +0200 "Daniel Brahneborg" wrote: > Thanks for the replies. > > The fact that Mongrel shouldn't be the first one to get the POST/PUT data > was a good point that I hadn't thought of. However, even when talking > directly to Mongrel, the memory consumption of the application increases > until it crashes if too much data is sent. In my case, I was sending a 500MB > file from a Webdav client. At some point all of it was loaded into RAM, which > doesn't work. > > Are there any more productive alternatives than writing the entire thing > from scratch in C? Please? :) Daniel, Mongrel is a library. Not a server. I just wrote a server with the library. Look past mongrel_rails and into the heart of the RDoc. You will find your answer there. (Probably somewhere in the place where it mentions handlers and filters.) -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From zedshaw at zedshaw.com Tue Oct 16 01:57:56 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 16 Oct 2007 01:57:56 -0400 Subject: [Mongrel] POST with huge HTTP body In-Reply-To: <246083.40834.qm@web30912.mail.mud.yahoo.com> References: <246083.40834.qm@web30912.mail.mud.yahoo.com> Message-ID: <20071016015756.95c74c29.zedshaw@zedshaw.com> On Mon, 15 Oct 2007 07:37:57 -0700 (PDT) Tim Kuijsten wrote: > Since a vanilla Mongrel will store uploaded data on disk in a tempfile, maybe it has something to do with your Railsdav plugin? Yes, I believe this is true as well. Railsdav pretty much blows. My experience with it is that none of the windows clients work well (all three) and it did some stupid stuff like used send_file in rails and processed the whole file on input. Ehem, there's this company called Xythos. They make a really good WebDAV server and client. Their WebDAV server is written in Java but it's not insanely architected. Instead it's very well done and using Jakarta Slide you can JRuby yourself a little Ruby lib that looks like Fileutils in about an hour. It's also a very flexible server, and very conforming since most of the people who worked on the RFCs works for Xythos. It's possible with Xythos to swap out nearly everything as well. For example, if you need to use your crappy "rails acts_as_lamely_authenticated" authentication, then you can write your own auth filter for Xythos and it'll go and look in your database. If you need to do something special to the files then you can do a filter for that (it's got a sample that uses Clam to do AV). They also give you all the source to their (ugly) web front end for free so you can see how every operation is done, even the weirdo admin stuff. It's a good product, and if you're dumb enough to work with WebDAV (since obviously you like Microsoft raping you over a barrel), then go check it out. Good luck, I've seen WebDAV kill off nearly every Rails project that's come near it. Not sure what it is, but it's like the black hole with a cache of gold in the center. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From evan at cloudbur.st Tue Oct 16 01:55:05 2007 From: evan at cloudbur.st (Evan Weaver) Date: Tue, 16 Oct 2007 01:55:05 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <20071016014909.af20351b.zedshaw@zedshaw.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> <20071016014909.af20351b.zedshaw@zedshaw.com> Message-ID: > At least piling them in mongrel means some IO is getting processed. Ok, that's the real issue then. When you have a heavy queuing situation, Ruby can at least schedule the IO among the green threads whereas Apache has to keep them serialized waiting for a worker to open up. Evan On 10/16/07, Zed A. Shaw wrote: > On Mon, 15 Oct 2007 16:43:34 -0700 > "Brian Williams" wrote: > > > We recently ran into exactly this issue. Some rails requests were making > > external requests that were taking 5 minutes (networking issues out of our > > control). > > Now that's a design flaw. If you're expecting the UI user to wait for a backend request that takes 5 minutes then you need to redesign the workflow and interface. Do it like asynchronous email where the use "sends a request", "awaits a reply", "reads the reply", and doesn't deal with the backend processing chain of events. > > If done right, you'll even get a performance boost and you can distribute the load of these requests out to other servers. It's also a model most users are familiar with from SMTP processing. > > -- > Zed A. Shaw > - Hate: http://savingtheinternetwithhate.com/ > - Good: http://www.zedshaw.com/ > - Evil: http://yearofevil.com/ > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From alexey.verkhovsky at gmail.com Tue Oct 16 02:02:16 2007 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Tue, 16 Oct 2007 00:02:16 -0600 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <20071016014200.7e6bf42d.zedshaw@zedshaw.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <20071016014200.7e6bf42d.zedshaw@zedshaw.com> Message-ID: <3945c4270710152302r7ad8d7dek3180e3d877874e35@mail.gmail.com> On 10/15/07, Zed A. Shaw wrote: >Tried Lucas Carlson's Dr. Proxy yet? Other solutions? Evented mongrel? HAProxy (and some other proxies smarter than mod_proxy_balancer) solves this problem by allowing to set the maximum number of requests outstanding to any node in the cluster. Setting it to 1 means that it will only ask a Mongrel instance to serve a request when it's not already doing so. Which makes perfect sense with Rails (single-threaded), especially if you do have something else to serve static content in this setup. Setting num_processors to 1 is only possible when you have a proxy that can restrict itself from sending more than one request per Mongrel. Otherwise, if I remember correctly, you replace occasional delays with HTTP 503s. Not a good trade-off. Setting num_processors low has a positive side effect of restricting how far your Mongrel will grow in memory when put under strain even for a short period. It grows in memory by allocating RAM to new threads (that then pile up on a Rails mutex). With, say, 10 Mongrels and a default num_processors = 1024, allocating memory for 1024 * 10 threads means hundreds of Megabytes of RAM. I usually set num_processors to something a bit bigger than 1 (say, 5), just so that monitoring can hit it at the same time when load balancer does. -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From basic70 at gmail.com Tue Oct 16 04:02:36 2007 From: basic70 at gmail.com (Daniel Brahneborg) Date: Tue, 16 Oct 2007 10:02:36 +0200 Subject: [Mongrel] POST with huge HTTP body In-Reply-To: <246083.40834.qm@web30912.mail.mud.yahoo.com> References: <246083.40834.qm@web30912.mail.mud.yahoo.com> Message-ID: It looks like it's CGI::QueryExtension#read_body in ActionPack that is the first one to cause problems. When a PUT or POST request arrives, it reads the entire thing into memory. Even if that method is patched, there are tons of other methods that wants to mess around with the request body. According to the documentation, the CGI class is supposed to handle Tempfile objects, but obviously not in this case. Seems like the way to go is to just use Mongrel and write a HttpHandler as a standalone server without both Rails and Railsdav, at least for a first version. Lots of thanks for pointing me in the right direction. /Daniel On 10/15/07, Tim Kuijsten wrote: > Since a vanilla Mongrel will store uploaded data on disk in a tempfile, maybe it has something to do with your Railsdav plugin? > > > I just tested an 80 MB upload with my Apache 2.2.6 reverse proxy and Mongrel 1.0.1 cluster and it does save the object first to /tmp on disk and not in memory. The memory used by the mongrel process before I started uploading was 50 MB. While uploading it peaked at 57 MB but was mostly stable around 50-52 MB. And after the upload was done it was back again at 50 MB. > > > Maybe your $TMPDIR is not writable for the user you are running mongrel under? > > > Just before the upload was finished: > $ ls -hl /tmp/ > total 160288 > -rw------- 1 mongrel wheel 78.2M Oct 15 16:31 mongrel.25.0 > > > > > > I would start looking in the Railsdav plugin you are using, seems like they changed the default of saving to disk, to memory. > > > > Cheers. > > ----- Original Message ---- > From: Daniel Brahneborg > To: mongrel-users at rubyforge.org > Sent: Monday, October 15, 2007 4:10:06 PM > Subject: Re: [Mongrel] POST with huge HTTP body > > > Thanks for the replies. > > The fact that Mongrel shouldn't be the first one to get the POST/PUT > data > was a good point that I hadn't thought of. However, even when talking > directly to Mongrel, the memory consumption of the application > increases > until it crashes if too much data is sent. In my case, I was sending a > 500MB > file from a Webdav client. At some point all of it was loaded into RAM, > which > doesn't work. > > Are there any more productive alternatives than writing the entire > thing > from scratch in C? Please? :) > > /Daniel > > On 10/15/07, Tim Kuijsten wrote: > > A while ago I wrote a plugin to limit uploads in Mongrel. Mongrel > does save uploads to a tempfile on disk - if the upload is bigger than > about 12 KB - using a Ruby TempFile-object. (which stores in the $TMPDIR, > /tmp on most systems). > > > > > > The request is handed over to Rails after it's fully received by > Mongrel. > > > > > > I'm not sure if this "saving to disk" works the same with chunked > uploads (uploads without a Content-Length header). > > > > > > > > Maybe my plugin can help you: > http://slasaus.netsend.nl/articles/show/7 (warning: it works, but is > not very elegant). > > > > > > Gl, > > > > > > Tim > > > > ----- Original Message ---- > > From: Daniel Brahneborg > > To: mongrel-users at rubyforge.org > > Sent: Monday, October 15, 2007 2:00:20 PM > > Subject: [Mongrel] POST with huge HTTP body > > > > > > Hi, > > > > I found the following page describing how to stream data from the > > server to the client: > > > > http://api.rubyonrails.com/classes/ActionController/Streaming.html > > > > I want to do the opposite, streaming data from the client to the > > server, > > letting the controller saving the data while it's being received. > > In particular, I want to upload large files to the RailsDav > > (http://www.liverail.net/railsdav) plugin, without having to store > > the entire file in memory during the operation. > > > > This seems to be a Mongrel problem, so I started looking at this > > plugin: > > > > http://mongrel.rubyforge.org/docs/upload_progress.html > > > > How do I get Mongrel to store the incoming POST data in a tempfile, > > passing a handler to that file as the raw_post field in the Rails > > request? > > Is it even possible? > > How is the "request" parameter to the process() method related to the > > "request" object in the Rails controllers? > > > > /Daniel > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > > > > > > ____________________________________________________________________________________ > > Shape Yahoo! in your own image. Join our Network Research Panel > today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 > > > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > ____________________________________________________________________________________ > Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. > http://mobile.yahoo.com/go?refer=1GNXIC > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From paul at paulbutcher.com Tue Oct 16 07:35:56 2007 From: paul at paulbutcher.com (Paul Butcher) Date: Tue, 16 Oct 2007 12:35:56 +0100 Subject: [Mongrel] Workaround found for request queuing vs. num_processors, accept/close In-Reply-To: <4713D30B.3080109@robmela.com> References: <47136912.6080107@robmela.com> <4713D30B.3080109@robmela.com> Message-ID: <5382B822-6E70-4943-B8AE-0772FEDD7A0D@paulbutcher.com> On 15 Oct 2007, at 21:52, Robert Mela wrote: > I've discovered a setting in mod_proxy_balancer that prevents the > Mongrel/Rails request queuing vs. accept/close problem from ever > being reached. Thanks for that, Robert. We've hit exactly the same issue in the past, but have been unable to find a way to persuade mod_proxy_balancer to do the right thing. I posted about this issue here a year or so ago: > http://rubyforge.org/pipermail/mongrel-users/2006-September/ > 001653.html But was unable to get anyone to take it seriously :-( -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: https://www.linkedin.com/in/paulbutcher MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071016/6c458a67/attachment.html From paul at paulbutcher.com Tue Oct 16 07:49:51 2007 From: paul at paulbutcher.com (Paul Butcher) Date: Tue, 16 Oct 2007 12:49:51 +0100 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <20071016014909.af20351b.zedshaw@zedshaw.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> <20071016014909.af20351b.zedshaw@zedshaw.com> Message-ID: <7E34F893-CAED-47F8-A5F2-C929E4594160@paulbutcher.com> On 16 Oct 2007, at 06:49, Zed A. Shaw wrote: > On Mon, 15 Oct 2007 16:43:34 -0700 > "Brian Williams" wrote: > >> We recently ran into exactly this issue. Some rails requests were >> making >> external requests that were taking 5 minutes (networking issues >> out of our >> control). > > Now that's a design flaw. If you're expecting the UI user to wait > for a backend request that takes 5 minutes then you need to > redesign the workflow and interface. Do it like asynchronous email > where the use "sends a request", "awaits a reply", "reads the > reply", and doesn't deal with the backend processing chain of events. Zed, you're being obtuse. Of course that isn't what Brian means. What he's doing is giving a pathological example to illustrate just how badly the mod_proxy_balancer/mongrel/rails combination behaves when things go wrong. Yes, you can mask the problem to some extent by mucking about with your application (and in fact that's what we've done here), but that's missing the point. It is not unreasonable to expect that some actions performed by an application are "fast" and some are "slow". It's further not unreasonable to expect a very large difference between the fastest and the slowest actions (if one action takes 10ms and another takes 1s, that's not unreasonable - but it is a 2 order of magnitude difference). With the obvious setup, fast actions will be delayed behind slow actions. This is a Bad Thing. Furthermore, people are fallible. If I happen to accidentally introduce an action into my system which takes 10s, yes I've screwed up and should fix it. But is it reasonable for the fact that I have a single (possibly very rare) action which takes 10s to mean that all the other fast actions are affected? Even when most of my mongrels are idle? Of course, this isn't really a problem with Mongrel. It's a problem with Ruby (which doesn't know what the word "thread" means) and Rails (which doesn't even manage to successfully make use of the brain-dead version of threading which Ruby does support). -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: https://www.linkedin.com/in/paulbutcher MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher From rob at robmela.com Tue Oct 16 08:16:10 2007 From: rob at robmela.com (Robert Mela) Date: Tue, 16 Oct 2007 08:16:10 -0400 Subject: [Mongrel] Load testing methodologies/tools In-Reply-To: <20071016014200.7e6bf42d.zedshaw@zedshaw.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <20071016014200.7e6bf42d.zedshaw@zedshaw.com> Message-ID: <4714AB8A.8020308@robmela.com> What'r y'all usin' for load generation / perf metrics tools? This is a huge area and I wonder if you narrow down to certain things for smoke tests or such. -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071016/f9924783/attachment-0001.vcf From rob at robmela.com Tue Oct 16 08:18:08 2007 From: rob at robmela.com (Robert Mela) Date: Tue, 16 Oct 2007 08:18:08 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> Message-ID: <4714AC00.4060405@robmela.com> What settings did you use in m_p_b? The trick to making it work was "acquire", "max", and probably "timeout". Brian Williams wrote: > We recently ran into exactly this issue. Some rails requests were > making external requests that were taking 5 minutes (networking issues > out of our control). If your request got queued behind one of these > stuck mongrels, the experience was terrible. I experimented with > adjusting the mod_proxy_balance settings to try to get it to fail over > to the next mongrel (I had hoped that the min,max,smax could all be > set to one, and force only one connection to a mongrel at a time) but > this didn't seem to work. > > Solution - I stuck lighttpd in between. Lighttp has a proxying > algorithm that does exactly this - round robin but to worker with > lightest load. > > I'd love to hear that there's a way to use mod_proxy_balancer, but I > couldn't get to work. > > --Brian -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071016/9bf27ba6/attachment.vcf From rob at robmela.com Tue Oct 16 08:30:28 2007 From: rob at robmela.com (Robert Mela) Date: Tue, 16 Oct 2007 08:30:28 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <3945c4270710152302r7ad8d7dek3180e3d877874e35@mail.gmail.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <20071016014200.7e6bf42d.zedshaw@zedshaw.com> <3945c4270710152302r7ad8d7dek3180e3d877874e35@mail.gmail.com> Message-ID: <4714AEE4.9000507@robmela.com> Alexey Verkhovsky wrote: > On 10/15/07, Zed A. Shaw wrote: > >> Tried Lucas Carlson's Dr. Proxy yet? Other solutions? Evented mongrel? >> > > HAProxy (and some other proxies smarter than mod_proxy_balancer) > solves this problem by allowing to set the maximum number of requests > outstanding to any node in the cluster. But m_p_b is correct in this!!! It's the "max" attribute to BalancerMember. It's just a pain to discover the correct combination of parameters! > Setting it to 1 means that it > will only ask a Mongrel instance to serve a request when it's not > already doing so But mpb IS doing this correctly, as you specify! It's a matter of combining "max" and "acquire" attrs on BalancerMember. Perhaps the thing that needs changing is documentation, making this the default mpb behavior, or better documentation ( or all of the above! ) > . Which makes perfect sense with Rails > (single-threaded), especially if you do have something else to serve > static content in this setup. > > Setting num_processors to 1 is only possible when you have a proxy > that can restrict itself from sending more than one request per > Mongrel. Which we do in m_p_b, via the "max" attribute to BalancerMember > Otherwise, if I remember correctly, you replace occasional > delays with HTTP 503s. Not a good trade-off. > The 503s would only be generated in the case of incorrect mpb settings. A 503 "server busy" coming from the Mongrel back-end gives developers and admins a better idea of what's really happening. Consider: the back end has reached maximum capacity. Saying "Hey 503! I'm at max capacity" is better than the current action -- open and close with no indication of what's wrong. > Setting num_processors low has a positive side effect of restricting > how far your Mongrel will grow in memory when put under strain even > > > 5), just so that monitoring can hit it at the same time when load > balancer does. > > Excellent idea! -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071016/416806fd/attachment.vcf From zedshaw at zedshaw.com Tue Oct 16 08:45:50 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 16 Oct 2007 08:45:50 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <7E34F893-CAED-47F8-A5F2-C929E4594160@paulbutcher.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> <20071016014909.af20351b.zedshaw@zedshaw.com> <7E34F893-CAED-47F8-A5F2-C929E4594160@paulbutcher.com> Message-ID: <20071016084550.148395f7.zedshaw@zedshaw.com> On Tue, 16 Oct 2007 12:49:51 +0100 Paul Butcher wrote: > On 16 Oct 2007, at 06:49, Zed A. Shaw wrote: > > On Mon, 15 Oct 2007 16:43:34 -0700 > > "Brian Williams" wrote: > > > >> We recently ran into exactly this issue. Some rails requests were > >> making > >> external requests that were taking 5 minutes (networking issues > >> out of our > >> control). > > > > Now that's a design flaw. If you're expecting the UI user to wait > > for a backend request that takes 5 minutes then you need to > > redesign the workflow and interface. Do it like asynchronous email > > where the use "sends a request", "awaits a reply", "reads the > > reply", and doesn't deal with the backend processing chain of events. > > Zed, you're being obtuse. Of course that isn't what Brian means. What > he's doing is giving a pathological example to illustrate just how > badly the mod_proxy_balancer/mongrel/rails combination behaves when > things go wrong. > > Yes, you can mask the problem to some extent by mucking about with > your application (and in fact that's what we've done here), but > that's missing the point. No, as usual performance panic has set in and you're not looking at the problem in the best way to solve it. EVERYTHING takes time. No amount of super fast assembler based multiplexed evented code will get around that. In his example he also was relying on an external service. It is a *classic* mistake to make the user wait for a remote service and all of your backend processes to finish before they see the end of the HTTP request. What people constantly do though, is they assume that the boundary of their transactions must also match the single boundary of one HTTP request. If you break this so that presentation of the process is decoupled from the actual process then you don't have a problem of the user eating up a web server. But, I'm sure nobody will ever convince programmers of this. They love to run around "performance tuning" stuff instead of just redesigning the system to it appears fast. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From paul at paulbutcher.com Tue Oct 16 09:01:16 2007 From: paul at paulbutcher.com (Paul Butcher) Date: Tue, 16 Oct 2007 14:01:16 +0100 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <20071016084550.148395f7.zedshaw@zedshaw.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> <20071016014909.af20351b.zedshaw@zedshaw.com> <7E34F893-CAED-47F8-A5F2-C929E4594160@paulbutcher.com> <20071016084550.148395f7.zedshaw@zedshaw.com> Message-ID: <331FF308-5C7D-47A5-81A9-1E24747016D3@paulbutcher.com> On 16 Oct 2007, at 13:45, Zed A. Shaw wrote: > No, as usual performance panic has set in and you're not looking at > the problem in the best way to solve it. Sorry Zed, I have a great deal of respect for your work and your opinions on development. But you seem to have a blind spot here and I just don't understand why. This has nothing to do with optimisation. It has nothing to do with performance. It's got everything to do with resilience and reliability. Clearly what you say about waiting for remote services is true. Doing so is a Bad Thing and an application shouldn't do it. But you're missing the point. Your philosophy guarantees that your applications performance will be held hostage by the worst performing action within it. What if I screw up and accidentally roll out "bad" action. Should this mean that *every aspect* of my app now behaves terribly? Following your logic, it does. The whole point of a load balancer is that it should enable things to behave sensibly even if one of my backend servers is screwed up. But a mismatch between the expectations encoded within mod_proxy_balancer and Mongrel running Ruby on Rails means that this isn't the case. Similarly, if I write a quick and dirty reporting action which runs an SQL query which takes 10 seconds to complete, should that screw up my entire application? It seems unreasonable to me that I have to optimise an action like this (why should I care if a reporting action which is only used once a day takes 10 seconds to complete?). I *do* care if every time I run it, though, I cause all the 0.1 second actions to queue up behind it. -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: https://www.linkedin.com/in/paulbutcher MSN: paul at paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher From bwillenator at gmail.com Tue Oct 16 10:52:19 2007 From: bwillenator at gmail.com (Brian Williams) Date: Tue, 16 Oct 2007 07:52:19 -0700 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <20071016014909.af20351b.zedshaw@zedshaw.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> <20071016014909.af20351b.zedshaw@zedshaw.com> Message-ID: <6f314be40710160752ha57bce6h3acbcc880824815f@mail.gmail.com> On 10/15/07, Zed A. Shaw wrote: > > On Mon, 15 Oct 2007 16:43:34 -0700 > "Brian Williams" wrote: > > > We recently ran into exactly this issue. Some rails requests were > making > > external requests that were taking 5 minutes (networking issues out of > our > > control). > > Now that's a design flaw. If you're expecting the UI user to wait for a > backend request that takes 5 minutes then you need to redesign the workflow > and interface. Do it like asynchronous email where the use "sends a > request", "awaits a reply", "reads the reply", and doesn't deal with the > backend processing chain of events. > > If done right, you'll even get a performance boost and you can distribute > the load of these requests out to other servers. It's also a model most > users are familiar with from SMTP processing. Just to clarify, we were accessing a web service that typically returns results in < 1 second. But due to network issues out of our control, these requests were going into a black hole, and waiting for tcp timeouts. Admittedly, since this was to an external service, we could shift to a model where all updates are asynchronous, but this doesn't help in the cases that paul mentions, such as a slower reporting queries or programmer error slow actions which then end up degrading the experience for all users to the site. Assuming we did switch to an asynchronous model, I would think it would be more like - show me latest FOO, trigger backend update to get latest FOO, return last cached FOO. Or if you know what FOO is, you periodically update it, and don't bother triggering an update. The first request would then return something like 'Fetching results', right? --Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071016/7b31a927/attachment.html From rob at robmela.com Tue Oct 16 11:16:35 2007 From: rob at robmela.com (Robert Mela) Date: Tue, 16 Oct 2007 11:16:35 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> Message-ID: <4714D5D3.5080101@robmela.com> Brian Williams wrote: > We recently ran into exactly this issue. Some rails requests were > making external requests that were taking 5 minutes (networking issues > out of our control). If your request got queued behind one of these > stuck mongrels, the experience was terrible. I experimented with > adjusting the mod_proxy_balance settings to try to get it to fail over > to the next mongrel (I had hoped that the min,max,smax could all be > set to one, and force only one connection to a mongrel at a time) but > this didn't seem to work. > > Solution - I stuck lighttpd in between. Lighttp has a proxying > algorithm that does exactly this - round robin but to worker with > lightest load. > Were you on Apache 2.0 or 2.2? mod_proxy_balancer is 2.2 only. It has the same features as lighty's balancer, and many important ones that it doesn't. We had 2.0 <-> lighttpd <-> mongrel_cluster. I like 2.2/mod_proxy_balancer better. Lighty missed some features we needed and I wasn't prepared to implement. I made heavy use of the following logging features in Apache and m_p_b for diagnostics: -- request duration in microseconds ( lighty only offers seconds ... ugh ) -- client session cookie -- balancer member ( which load balancer member Apache sent the request to ) -- client socket status at end of request I should correct the Round Robin misperception. More accurately mod_proxy_balancer does request balancing. The module sends an equal number of requests to each back end, at least according to the docs. It has another mode where it balances by bytes transferred. The icing on the cake for me was mod_proxy_balancer's status page. It gives a live view of configured balancer pools and stats for each pool member. > I'd love to hear that there's a way to use mod_proxy_balancer, but I > couldn't get to work. > > --Brian -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071016/a48d8be0/attachment.vcf From public at misuse.org Tue Oct 16 11:40:35 2007 From: public at misuse.org (Steve Midgley) Date: Tue, 16 Oct 2007 08:40:35 -0700 Subject: [Mongrel] Load testing methodologies/tools In-Reply-To: References: Message-ID: <20071016160328.844C01858569@rubyforge.org> I tried a bunch of tools and ended up using Jakarta J-Meter b/c it works cross-platform (Unix/Windows in my situation) and has a gui which shallows the learning curve. I've been quite satisfied with it.. Search the archives on this list and you should be able to find some great info Zed and others wrote a while back on How to Load Test Correctly. I found that series of posts to be pretty helpful in testing Mongrel/Rails. IIRC, about this was about 10 months ago. Best, Steve At 05:16 AM 10/16/2007, mongrel-users-request at rubyforge.org wrote: >Message: 7 >Date: Tue, 16 Oct 2007 08:16:10 -0400 >From: Robert Mela >Subject: [Mongrel] Load testing methodologies/tools >To: mongrel-users at rubyforge.org >Message-ID: <4714AB8A.8020308 at robmela.com> >Content-Type: text/plain; charset="iso-8859-1" > >What'r y'all usin' for load generation / perf metrics tools? > >This is a huge area and I wonder if you narrow down to certain things >for smoke tests or such. From lists at ruby-forum.com Tue Oct 16 14:08:13 2007 From: lists at ruby-forum.com (James Bosworth) Date: Tue, 16 Oct 2007 20:08:13 +0200 Subject: [Mongrel] redirects with mongrel (dropping the www. from a url) Message-ID: <2fe71e2e14c5edb933feb8c929529d03@ruby-forum.com> Hi All, I have a rails app running on an apache virtual host with mongrel that i want to set up a redirect from www.someapp.com to someapp.com (dropping the www.) I have tried doing this in apache using a rewrite rule (below) which worked before when the app was written in php. Redirect http://www.soccertackle.com/ http://soccertackle.com RewriteEngine on RewriteCond %{HTTP_HOST} !^soccertackle\.com [NC] RewriteCond %{HTTP_HOST} !^$ RewriteRule ^/(.*) http://soccertackle.com/$1 [L,R] Now the app has been completely re written in rails using mongrel & apache (i don't really understand much about web servers but mongrel set up was nice and simple). However my redirect does not work any longer. I cant seem to find any information on the web (which would suggest i'm looking in the wrong places). can anyone suggest a solution to my problem or point me in the right direction? please be gentle, as i mentioned before servers are not my strong point. Thank you. -- Posted via http://www.ruby-forum.com/. From rob at robmela.com Tue Oct 16 14:58:33 2007 From: rob at robmela.com (Robert Mela) Date: Tue, 16 Oct 2007 14:58:33 -0400 Subject: [Mongrel] redirects with mongrel (dropping the www. from a url) In-Reply-To: <2fe71e2e14c5edb933feb8c929529d03@ruby-forum.com> References: <2fe71e2e14c5edb933feb8c929529d03@ruby-forum.com> Message-ID: <471509D9.9080205@robmela.com> Not enough info to debug here, and whether it's PHP vs. Mongrel shld be irrelevant. Short of that, here's something that works. If I state that the backend is Mongrel/Nitro will the moderator consider this on-topic? :) ServerName soccertackle.com ServerAlias www.soccertackle.com RewriteEngine On RewriteCond %{SERVER_NAME} www.sockertackle.com RewriteRule ^.*$ http://sockertackle.com$1 [L,R] James Bosworth wrote: > Hi All, > > I have a rails app running on an apache virtual host with mongrel that > i want to set up a redirect from www.someapp.com to someapp.com > (dropping > the www.) > > I have tried doing this in apache using a rewrite rule (below) which > worked before when the app was written in php. > > Redirect http://www.soccertackle.com/ http://soccertackle.com > RewriteEngine on > RewriteCond %{HTTP_HOST} !^soccertackle\.com [NC] > RewriteCond %{HTTP_HOST} !^$ > RewriteRule ^/(.*) http://soccertackle.com/$1 [L,R] > > Now the app has been completely re written in rails using mongrel & > apache (i don't really understand much about web servers but mongrel > set up was nice and simple). However my redirect does not work any > longer. I cant seem to find any information on the web (which would > suggest i'm looking in the wrong places). > > can anyone suggest a solution to my problem or point me in the right > direction? > please be gentle, as i mentioned before servers are not my strong > point. > > Thank you. > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071016/56265480/attachment.vcf From zedshaw at zedshaw.com Tue Oct 16 15:36:59 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 16 Oct 2007 15:36:59 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <6f314be40710160752ha57bce6h3acbcc880824815f@mail.gmail.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> <20071016014909.af20351b.zedshaw@zedshaw.com> <6f314be40710160752ha57bce6h3acbcc880824815f@mail.gmail.com> Message-ID: <20071016153659.6006974f.zedshaw@zedshaw.com> On Tue, 16 Oct 2007 07:52:19 -0700 "Brian Williams" wrote: > Just to clarify, we were accessing a web service that typically returns > results in < 1 second. But due to network issues out of our control, these > requests were going into a black hole, and waiting for tcp timeouts. > Admittedly, since this was to an external service, we could shift to a model > where all updates are asynchronous, but this doesn't help in the cases that > paul mentions, such as a slower reporting queries or programmer error slow > actions which then end up degrading the experience for all users to the > site. There's also an odd thing about performance: users perceive the range of response times as "slow" and not the mean. I have no idea why, but I've seen it over and over again. You'll take a system that has a mean perf of 2 seconds, but a range of .5 to 10 seconds and they think it's "slow". Tune the system so that it has 3 second mean perf, but only a range of 2 to 4 seconds and they think it's "fast as hell". But yes, if the service isn't under your control than you'll get hit by this over and over. It's better to setup an "async firewall" both in the service layer and in your UI so that they don't deal with things that are potentially variable. > Assuming we did switch to an asynchronous model, I would think it would be > more like - show me latest FOO, trigger backend update to get latest FOO, > return last cached FOO. Or if you know what FOO is, you periodically > update it, and don't bother triggering an update. There's a few general approaches you can try depending on the type of application you've got and what you can do with the UI. I like to generally categorize them into the "polling" or "inbox" methods. In polling, your controllers have four general actions to deal with the request: submit, poll, cancel, get. In this one, the user submits their request like normal, and you display a "Waiting for this to happen dude..." message. Your submit action builds the request and hands it to some service that does the real work (like backgroundrb) then returns the waiting message immediately. The waiting page then simply has a bit of ajaxy good javascript that hits the poll method to see if it's done yet, and updates a spinner or something. If you want a cancel link on the waiting page, then cancel would abort, tell the backgroundrb to stop, and shunt the user off to the end. Finally, when the poll method says it's done, you redirect to the "get" action to retrieve the final result. There's many variations on this depending on the type of tech you have, and typically works best for situations where the user will eventually see something, and they shouldn't go off doing other things. Such as in a strict biz process where they MUST complete this task before moving on (like in looking up a flight on a reservation system). In the "inbox" method (or email method) you just adopt the tried and true method of having an inbox and outbox. Users get a way to submit requests. That goes in the outbox. They can then see all the pending stuff. You then have your background processor just pull things out of people's outboxes, process them, and put the results in the inbox. Simple, and the UI for this means you have lots of chances to give them something else to do. The nice thing about this approach is the user doesn't have to care who's dealing with it, and they can even setup scheduled tasks that just get run and results are put in their inbox (which would mean no need for an outbox, but maybe a tasks folder). Canceling is simply a matter of removing it from their inbox. Really good uses for this are of course things like email and printing, but also having reports generated, conducting big number crunches, asking for analysis, etc. The trick is then to come up with a UI model that lets you use the inbox method whenever you can. Let's take the flight system as an example. Currently they have a polling method on most sites, but you could do an inbox method if the user interface was more conversational and based on secondary information about the user (like, they have Delta miles). In this model, the user puts in more information up front, or it's inferred, then says "tell me what you can find for me." The system uses all its power to go out and look for a flight potentially taking days, and simply putting status or results in the person's inbox for review or acceptance. The user would have to understand this UI approach and see an advantage to it, so if the results weren't better than just a quick query via polling it's pointless. A nice advantage of this is the user can train whatever engine you use the same way they train a Bayes classifier. Imagine if the above reservation system puts potential flights in your inbox, and you go in and just smack a "hell no/maybe so/more like this" button. This trains the flight reservation finding engine to give you better and better results until it finds what you want. Keep this information around and eventually the user will think your flight system is absolutely perfect. The test that you've got an "inbox" method right for a flight reservation system is if people can reserve flights they want via txt message off their phones over the course of a day. Another place for this would be in a movie site like Netflix. Instead of saying genres and exact movies, you go in and give demographic information as well as some movies you like. After this initial training, you put out requests for things like "Give me movies I might like that are sad." Netflix makes a "folder" for this called "movies that are sad" and starts to fill it what it thinks you might like. It actually doesn't know, but as the user classifies what is sad or not, netflix begins to learn more and gives better sad movie results. Eventually users are just getting movies that they've pre-classified and don't even bother searching. And as usual, I'll put my disclaimer that this isn't a boolean decision or that these are the only two solutions. In fact, combining the above for a flight reservation system would be a powerful metaphor if you could figure it out without confusing people. Hope that helps. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From zedshaw at zedshaw.com Tue Oct 16 16:01:38 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 16 Oct 2007 16:01:38 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <331FF308-5C7D-47A5-81A9-1E24747016D3@paulbutcher.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> <20071016014909.af20351b.zedshaw@zedshaw.com> <7E34F893-CAED-47F8-A5F2-C929E4594160@paulbutcher.com> <20071016084550.148395f7.zedshaw@zedshaw.com> <331FF308-5C7D-47A5-81A9-1E24747016D3@paulbutcher.com> Message-ID: <20071016160138.ba329264.zedshaw@zedshaw.com> On Tue, 16 Oct 2007 14:01:16 +0100 Paul Butcher wrote: > On 16 Oct 2007, at 13:45, Zed A. Shaw wrote: > > No, as usual performance panic has set in and you're not looking at > > the problem in the best way to solve it. > > Sorry Zed, I have a great deal of respect for your work and your > opinions on development. But you seem to have a blind spot here and I > just don't understand why. That's because you're reading my recommendation as "performance tuning vs. design to avoid". If you've read any of my work you'll understand I *never* advocate a boolean argument. Those are for computers. In my argument I'm saying that his problem can never be solved because he doesn't have control of the performance at all, and why should the user's HTTP REQUEST be held up for this? You get the distinction? Your HTTP request processing doesn't have to be coupled to your backend request processing. Break them apart and then you can ensure the user gets rapid feedback, you have fewer bottlnecks, you can push the processing out, and you can measure orthogonal pieces rather than one giant messy process. > This has nothing to do with optimisation. It has nothing to do with > performance. It's got everything to do with resilience and reliability. No, resilience and reliability are quantifiable metrics. Mean Time Between Failure to be exact. "Performance" is a subjective thing that's based on human perception. Yes, I know you can go get yourself a little graph of requests per second, but that won't tell you if the users think it is fast. If you can't make the computer fast, trick the people to think it's fast. > Your philosophy guarantees that your applications performance will be > held hostage by the worst performing action within it. Again, no, I'm not saying don't try to make it fast. What I'm saying is first thing programmers do is they run off with faulty statistics to "tune" their system, completely ignoring the fact that many times a simple redesign (or complex improvement) can just eliminate the problem entirely. See my most recent reply to Brian for many examples. > What if I screw up and accidentally roll out "bad" action. Should this mean > that *every aspect* of my app now behaves terribly? Following your > logic, it does. The whole point of a load balancer is that it should > enable things to behave sensibly even if one of my backend servers is > screwed up. But a mismatch between the expectations encoded within > mod_proxy_balancer and Mongrel running Ruby on Rails means that this > isn't the case. Well I didn't do a logic proof so you're inventing logic where there is none. My "logic" would be this: The fastest way to do something is to just not do it. Right? That basically gives you an infinite number of requests per second. :-) But ultimately, I've been doing this a long time, and the one thing I've realized is, no matter how fast you make something, there's always a bigger dumbass available to make it slow. Hell man, computers have blasted in capability and speed over the years, and still I have to wait for my damn email to render in the fastest email client I could find. No amount of making things fast will protect you against stupidity. > Similarly, if I write a quick and dirty reporting action which runs > an SQL query which takes 10 seconds to complete, should that screw up > my entire application? It seems unreasonable to me that I have to > optimise an action like this (why should I care if a reporting action > which is only used once a day takes 10 seconds to complete?). I *do* > care if every time I run it, though, I cause all the 0.1 second > actions to queue up behind it. I'd reword this: "I have SQL queries that take 10 seconds to complete and I'm stuck using Mongrel because nobody else has stepped up to fix the dumbass crap in Ruby's GC, IO, and Threads and even the JRuby guys can't solve their 'mystery' performance problem with Rails..." Option A: "... I'm totally screwed and should toss myself off a building because I keep banging my head on this thing and it doesn't go faster." Option B: "... I'm rich and will just put 1000 mongrels in the mix and solve the problem." Option C: "... I know queueing theory and can work up a queuing model that will help me figure out the minimum number of request processors to handle the queue at a 10 req/sec rate." Option D: "... I can analyze the performance of all my stuff and tune it as fast as possible, then try C and B." Option E: "... Well, let's try some stuff on the front end and see if we can just trick people into thinking how this goes so that there isn't a problem anymore." Any of them will work, but with Rails option E, D, C, and B work best (in that order). Please don't do A, it's not that big a deal. Epliogue (not just for Paul): A lot of people complain that rails should be thread safe. Well, Rails Core folks including DHH also complain that it should be thread safe. Under JRuby you can spin up a ton of real threads with entire Rails apps in each one, but that's suboptimal for memory usage (like Java cares). If all of you think that Rails shouldn't have a giant lock, then I have only one suggestion: Get off your damn ass and make it happen. David just made a big effort to make the process for submitting patches much more open and he's looking for people to solve this problem. I dare say he's admitted he was wrong about the locking issue and is ultra-keen (I won't say desperate) for someone to solve it. Nothing is in your way, and the reward will be the glory of making things fast. Worked for me, and I can say it's totally worth it. As a sweetener, I'll throw this out: I bet you can NOT make Rails threadsafe. The first person or group of people to finally get rid of the thread locking around Rails requests in Mongrel and make Rails performance match that of Merb or Nitro on average will get a real highschool style trophy from me. The trophy will have a bust of a dog on it and will be enscribed: "Official Mongrel Rails Threadify Ninja Destroyer 1st Place: Zed and DHH were wrong!". The runner-up will get the first set of MUDCRAP-CE certificates, and I'll hand them out at the next Rails or Ruby conference in person. Alright, I've ponied up my end of the bargain. Who's going to take me on? -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From rob at robmela.com Tue Oct 16 21:34:23 2007 From: rob at robmela.com (Robert Mela) Date: Tue, 16 Oct 2007 21:34:23 -0400 Subject: [Mongrel] Design flaw? - num_processors, accept/close In-Reply-To: <20071016160138.ba329264.zedshaw@zedshaw.com> References: <47136912.6080107@robmela.com> <471397AE.2010402@robmela.com> <6f314be40710151643l5f69edagc9ba6fb7a3d41ac5@mail.gmail.com> <20071016014909.af20351b.zedshaw@zedshaw.com> <7E34F893-CAED-47F8-A5F2-C929E4594160@paulbutcher.com> <20071016084550.148395f7.zedshaw@zedshaw.com> <331FF308-5C7D-47A5-81A9-1E24747016D3@paulbutcher.com> <20071016160138.ba329264.zedshaw@zedshaw.com> Message-ID: <4715669F.5030001@robmela.com> The query should not take 10 seconds. People should not steal. Still, they do, and I live with the workaround -- locking. So, while the 10-second query is a problem, and worth solving for its own sake, the mod_proxy_balancer solution prevents it from causing the secondary, request queuing problem. That might eliminate enough crisis meetings that someone actually has time to fix the underlying problem without working through the week end. Which in turn lessens the likelyhood of anyone choosing option A. > I'd reword this: "I have SQL queries that take 10 seconds to complete and I'm stuck using Mongrel because nobody else has stepped up to fix the dumbass crap in Ruby's GC, IO, and Threads and even the JRuby guys can't solve their 'mystery' performance problem with Rails..." > > Option A: > > "... I'm totally screwed and should toss myself off a building because I keep banging my head on this thing and it doesn't go faster." > > Option B: > > "... I'm rich and will just put 1000 mongrels in the mix and solve the problem." > > Option C: > > "... I know queueing theory and can work up a queuing model that will help me figure out the minimum number of request processors to handle the queue at a 10 req/sec rate." > > Option D: > > "... I can analyze the performance of all my stuff and tune it as fast as possible, then try C and B." > > Option E: > > "... Well, let's try some stuff on the front end and see if we can just trick people into thinking how this goes so that there isn't a problem anymore." > > Any of them will work, but with Rails option E, D, C, and B work best (in that order). Please don't do A, it's not that big a deal. > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071016/f3478dbd/attachment.vcf From rob at robmela.com Wed Oct 17 01:10:23 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 17 Oct 2007 01:10:23 -0400 Subject: [Mongrel] Load testing methodologies/tools In-Reply-To: References: Message-ID: <4715993F.1040303@robmela.com> Is this the thread you're remembering -- looks like it might be: http://rubyforge.org/pipermail/mongrel-users/2006-September/001349.html Thanks. Steve Midgley wrote: > I tried a bunch of tools and ended up using Jakarta J-Meter b/c it > works cross-platform (Unix/Windows in my situation) and has a gui > which shallows the learning curve. I've been quite satisfied with it.. > > Search the archives on this list and you should be able to find some > great info Zed and others wrote a while back on How to Load Test > Correctly. I found that series of posts to be pretty helpful in > testing Mongrel/Rails. IIRC, about this was about 10 months ago. > > Best, > > Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071017/9414190c/attachment.vcf From public at misuse.org Wed Oct 17 04:34:55 2007 From: public at misuse.org (Steve Midgley) Date: Wed, 17 Oct 2007 01:34:55 -0700 Subject: [Mongrel] Load testing methodologies/tools In-Reply-To: <4715993F.1040303@robmela.com> References: <4715993F.1040303@robmela.com> Message-ID: <20071017083542.5EF4018585C4@rubyforge.org> Ok, make me work. That's a good one but not the one I was thinking of. Digging, I find these two from Zed - the first one is the one I was thinking of, and the second refers to a screencast that will surely help you out too: http://rubyforge.org/pipermail/mongrel-users/2006-May/000200.html http://rubyforge.org/pipermail/mongrel-users/2007-March/003111.html Also don't miss this epic one from Ezra on how to figure out the right number of mongrels: http://rubyforge.org/pipermail/mongrel-users/2006-December/002591.html Summarizing, because that's all I'm good for on this list.. Steve p.s. Looks like my 10 month guess was actually pretty wrong :) At 10:10 PM 10/16/2007, Robert Mela wrote: >Is this the thread you're remembering -- looks like it might be: > > >http://rubyforge.org/pipermail/mongrel-users/2006-September/001349.html > >Thanks. > >Steve Midgley wrote: >>I tried a bunch of tools and ended up using Jakarta J-Meter b/c it >>works cross-platform (Unix/Windows in my situation) and has a gui >>which shallows the learning curve. I've been quite satisfied with it.. >> >>Search the archives on this list and you should be able to find some >>great info Zed and others wrote a while back on How to Load Test >>Correctly. I found that series of posts to be pretty helpful in >>testing Mongrel/Rails. IIRC, about this was about 10 months ago. >> >>Best, >> >>Steve > > > From lists at ruby-forum.com Wed Oct 17 04:45:08 2007 From: lists at ruby-forum.com (Jacobo Garcia) Date: Wed, 17 Oct 2007 10:45:08 +0200 Subject: [Mongrel] proxy errors with apache2.2.3 + mongrels Message-ID: <9df971d76ff82f2f315b7d4bc2f3f26a@ruby-forum.com> I've posted this to rails-deployment as well. I have to administer a medium size rails app (1'5 million requests each day), recently I've switched from lighttpd + fcgi to apache + mongrel. In the following lines I am going to describe the platform: All machines are running Debian Etch, with 4 gb ram and dual core intel32 processors. Web server runs debian's apache 2.2.3-4 mpm worker package and also NFS server, Two app servers runs 14 mongrels ach one. There is two db servers, master running mysql5 (debian package) with innodb and an slave server with myisam tables. This slave server has 8 gb ram and has a memcached with 4 gb reserved. We are experiencing problems in peak hours with timeout and slow navigation on pages, also there are problems with some file uploads. I'm investigating on improving quality of service on the site, and I've reached to some proxy errors in apache log, with more than 300 simultaneous stablished connections on the webserver[1]. There are 4 kinds of proxy errors: [Wed Oct 17 06:24:14 2007] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 192.168.10.154:21004 (bomer) failed [Tue Oct 16 23:28:01 2007] [error] [client 67.142.130.19] proxy: error reading status line from remote server bomber, referer: http://www.google.com/search?hl=es&q=tipos+de+herramintas++++&lr= [Wed Oct 17 07:14:11 2007] [error] (70007)The timeout specified has expired: proxy: prefetch request body failed to 192.168.10.154:21013 (kgb) from 200.66.13 3.30 () [Wed Oct 17 07:16:54 2007] [error] [client 201.141.199.86] proxy: Error reading from remote server returned by /myfiles/clubsx/Sin t?? tulo 007_0001(1).jpg, r eferer: http://www.espacioblog.com/clubsx/post/2006/06/04/los-archivos-chiwasnaked With slow or moderated traffic mongrels works well (they use cpu and appears in first lines of 'top' command) but with heavy traffic, mongrels go down. I am looking for help with solving this issues, I've been looking in google about proxy errors, but what I've found haven't helped, I can provide more details if they can help. Also I've been suggested to use nginx web server instead of apache, but I am reluctant to use it, unless proven better than apache, can anyone point me to technical argument for using nginx? [1] $ netstat -nat |grep ':80'| grep 'EST' | wc -l Thanks for your time. Jacobo Garc?a -- Posted via http://www.ruby-forum.com/. From rob at robmela.com Wed Oct 17 10:48:38 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 17 Oct 2007 10:48:38 -0400 Subject: [Mongrel] proxy errors with apache2.2.3 + mongrels In-Reply-To: <9df971d76ff82f2f315b7d4bc2f3f26a@ruby-forum.com> References: <9df971d76ff82f2f315b7d4bc2f3f26a@ruby-forum.com> Message-ID: <471620C6.2030300@robmela.com> "Error reading status line" means Mongrel closed the socket without sending any content back. IT WOULD BE REALLY HELPFUL IF MONGREL WOULD SEND BACK "503 Server Busy" WHEN IT'S BUSY. That way we would know immediately whether the num_processors limit had been reached or not. HUGE TIMESAVER FOR MONGREL USERS! ==== Next... Seeing your load balancer config, and mongrel_cluster.yml would help narrow things down & simplify the discussion. Also, add this to your log file config: %D ( request duration -) %{BALANCER_WORKER_NAME}e Request duration, in combination with start time and balancer_worker_name, is useful in finding cases where requests to a back end app server overlap. These numbers will also allow you to construct a histogram of concurrent requests each second. thanks. Jacobo Garcia wrote: > I've posted this to rails-deployment as well. > > I have to administer a medium size rails app (1'5 million requests > each day), recently I've switched from lighttpd + fcgi to apache + > mongrel. In the following lines I am going to describe the platform: > > All machines are running Debian Etch, with 4 gb ram and dual core > intel32 processors. Web server runs debian's apache 2.2.3-4 mpm worker > package and also NFS server, Two app servers runs 14 mongrels ach > one. There is two db servers, master running mysql5 (debian package) > with innodb and an slave server with myisam tables. This slave server > has 8 gb ram and has a memcached with 4 gb reserved. > > We are experiencing problems in peak hours with timeout and slow > navigation on pages, also there are problems with some file uploads. > I'm investigating on improving quality of service on the site, and > I've reached to some proxy errors in apache log, with more than 300 > simultaneous stablished connections on the webserver[1]. > > There are 4 kinds of proxy errors: > > [Wed Oct 17 06:24:14 2007] [error] (111)Connection refused: proxy: > HTTP: attempt to connect to 192.168.10.154:21004 (bomer) failed > > [Tue Oct 16 23:28:01 2007] [error] [client 67.142.130.19] proxy: error > reading status line from remote server bomber, referer: > http://www.google.com/search?hl=es&q=tipos+de+herramintas++++&lr= > > [Wed Oct 17 07:14:11 2007] [error] (70007)The timeout specified has > expired: proxy: prefetch request body failed to 192.168.10.154:21013 > (kgb) from 200.66.13 > 3.30 () > > [Wed Oct 17 07:16:54 2007] [error] [client 201.141.199.86] proxy: > Error reading from remote server returned by /myfiles/clubsx/Sin t?? > tulo 007_0001(1).jpg, r > eferer: > http://www.espacioblog.com/clubsx/post/2006/06/04/los-archivos-chiwasnaked > > With slow or moderated traffic mongrels works well (they use cpu and > appears in first lines of 'top' command) but with heavy traffic, > mongrels go down. > > I am looking for help with solving this issues, I've been looking in > google about proxy errors, but what I've found haven't helped, I can > provide more details if they can help. > > Also I've been suggested to use nginx web server instead of apache, > but I am reluctant to use it, unless proven better than apache, can > anyone point me to technical argument for using nginx? > > [1] $ netstat -nat |grep ':80'| grep 'EST' | wc -l > > Thanks for your time. > > Jacobo Garc?a > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 123 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071017/6aaf9e30/attachment.vcf From lists at ruby-forum.com Wed Oct 17 11:36:34 2007 From: lists at ruby-forum.com (Jacobo Garcia) Date: Wed, 17 Oct 2007 17:36:34 +0200 Subject: [Mongrel] proxy errors with apache2.2.3 + mongrels In-Reply-To: <471620C6.2030300@robmela.com> References: <9df971d76ff82f2f315b7d4bc2f3f26a@ruby-forum.com> <471620C6.2030300@robmela.com> Message-ID: mongrel_cluster.yml: --- port: "21000" docroot: /var/www/mysite/current/public/ cwd: /var/www/mysite/current pid_file: /var/www/mysite/tmp/pids/mongrel.pid log_file: /var/www/mysite/current/log/mongrel.log environment: production servers: 14 user: deploys group: www-data proxy balancer: ServerName my.ip.add.ress NameVirtualHost *:80 BalancerMember http://bomber:21000 keepalive=on max=1 retry=30 BalancerMember http://bomber:21001 keepalive=on max=1 retry=30 BalancerMember http://bomber:21002 keepalive=on max=1 retry=30 BalancerMember http://bomber:21003 keepalive=on max=1 retry=30 BalancerMember http://bomber:21004 keepalive=on max=1 retry=30 BalancerMember http://bomber:21005 keepalive=on max=1 retry=30 BalancerMember http://bomber:21006 keepalive=on max=1 retry=30 BalancerMember http://bomber:21007 keepalive=on max=1 retry=30 BalancerMember http://bomber:21008 keepalive=on max=1 retry=30 BalancerMember http://bomber:21009 keepalive=on max=1 retry=30 BalancerMember http://bomber:21010 keepalive=on max=1 retry=30 BalancerMember http://bomber:21011 keepalive=on max=1 retry=30 BalancerMember http://bomber:21012 keepalive=on max=1 retry=30 BalancerMember http://bomber:21013 keepalive=on max=1 retry=30 BalancerMember http://bomber:21014 keepalive=on max=1 retry=30 BalancerMember http://bomber:21015 keepalive=on max=1 retry=30 BalancerMember http://bomber:21016 keepalive=on max=1 retry=30 BalancerMember http://bomber:21017 keepalive=on max=1 retry=30 BalancerMember http://bomber:21018 keepalive=on max=1 retry=30 BalancerMember http://bomber:21019 keepalive=on max=1 retry=30 BalancerMember http://bomber:21020 keepalive=on max=1 retry=30 BalancerMember http://bomber:21021 keepalive=on max=1 retry=30 BalancerMember http://bomber:21022 keepalive=on max=1 retry=30 BalancerMember http://bomber:21023 keepalive=on max=1 retry=30 BalancerMember http://bomber:21024 keepalive=on max=1 retry=30 BalancerMember http://bomber:21025 keepalive=on max=1 retry=30 BalancerMember http://bomber:21026 keepalive=on max=1 retry=30 BalancerMember http://bomber:21027 keepalive=on max=1 retry=30 BalancerMember http://bomber:21028 keepalive=on max=1 retry=30 BalancerMember http://bomber:21029 keepalive=on max=1 retry=30 BalancerMember http://kgb:21000 keepalive=on max=1 retry=30 BalancerMember http://kgb:21001 keepalive=on max=1 retry=30 BalancerMember http://kgb:21002 keepalive=on max=1 retry=30 BalancerMember http://kgb:21003 keepalive=on max=1 retry=30 BalancerMember http://kgb:21004 keepalive=on max=1 retry=30 BalancerMember http://kgb:21005 keepalive=on max=1 retry=30 BalancerMember http://kgb:21006 keepalive=on max=1 retry=30 BalancerMember http://kgb:21007 keepalive=on max=1 retry=30 BalancerMember http://kgb:21008 keepalive=on max=1 retry=30 BalancerMember http://kgb:21009 keepalive=on max=1 retry=30 BalancerMember http://kgb:21010 keepalive=on max=1 retry=30 BalancerMember http://kgb:21011 keepalive=on max=1 retry=30 BalancerMember http://kgb:21012 keepalive=on max=1 retry=30 BalancerMember http://kgb:21013 keepalive=on max=1 retry=30 BalancerMember http://kgb:21014 keepalive=on max=1 retry=30 BalancerMember http://kgb:21015 keepalive=on max=1 retry=30 BalancerMember http://kgb:21016 keepalive=on max=1 retry=30 BalancerMember http://kgb:21017 keepalive=on max=1 retry=30 BalancerMember http://kgb:21018 keepalive=on max=1 retry=30 BalancerMember http://kgb:21019 keepalive=on max=1 retry=30 BalancerMember http://kgb:21020 keepalive=on max=1 retry=30 BalancerMember http://kgb:21021 keepalive=on max=1 retry=30 BalancerMember http://kgb:21022 keepalive=on max=1 retry=30 BalancerMember http://kgb:21023 keepalive=on max=1 retry=30 BalancerMember http://kgb:21024 keepalive=on max=1 retry=30 BalancerMember http://kgb:21025 keepalive=on max=1 retry=30 BalancerMember http://kgb:21026 keepalive=on max=1 retry=30 BalancerMember http://kgb:21027 keepalive=on max=1 retry=30 BalancerMember http://kgb:21028 keepalive=on max=1 retry=30 BalancerMember http://kgb:21029 keepalive=on max=1 retry=30 I've been added the log parameters you've suggested to apache, i'll put em in a future messages. thanks Robert Mela wrote: > "Error reading status line" means Mongrel closed the socket without > sending any content back. > > IT WOULD BE REALLY HELPFUL IF MONGREL WOULD SEND BACK "503 Server Busy" > WHEN IT'S BUSY. That way we would know immediately whether the > num_processors limit had been reached or not. HUGE TIMESAVER FOR > MONGREL USERS! > > ==== > > Next... > > Seeing your load balancer config, and mongrel_cluster.yml would help > narrow things down & simplify the discussion. > > Also, add this to your log file config: > > %D ( request duration -) > %{BALANCER_WORKER_NAME}e > > > Request duration, in combination with start time and > balancer_worker_name, is useful in finding cases where requests to a > back end app server overlap. These numbers will also allow you to > construct a histogram of concurrent requests each second. > > thanks. -- Posted via http://www.ruby-forum.com/. From rob at robmela.com Wed Oct 17 12:27:00 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 17 Oct 2007 12:27:00 -0400 Subject: [Mongrel] proxy errors with apache2.2.3 + mongrels In-Reply-To: References: <9df971d76ff82f2f315b7d4bc2f3f26a@ruby-forum.com> <471620C6.2030300@robmela.com> Message-ID: <471637D4.70100@robmela.com> Another avenue to consider is everything in order on the systems involved? If Rails is chewing up lots of RAM you could be swapping... here's some diagnostics I usually run ( caveat: I'm not a sysadmin, nor do I play one on TV ): sar -rB 1 0 sar 1 0 sar -n EDEV 1 0 (network IO incl. errors) sar -d 1 0 ( look for excessive block device IO )? What sorts of things do other folks on this list look at? Jacobo Garcia wrote: > mongrel_cluster.yml: > > --- > port: "21000" > docroot: /var/www/mysite/current/public/ > cwd: /var/www/mysite/current > pid_file: /var/www/mysite/tmp/pids/mongrel.pid > log_file: /var/www/mysite/current/log/mongrel.log > environment: production > servers: 14 > user: deploys > group: www-data > > > proxy balancer: > ServerName my.ip.add.ress > NameVirtualHost *:80 > > BalancerMember http://bomber:21000 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21001 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21002 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21003 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21004 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21005 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21006 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21007 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21008 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21009 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21010 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21011 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21012 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21013 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21014 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21015 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21016 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21017 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21018 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21019 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21020 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21021 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21022 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21023 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21024 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21025 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21026 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21027 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21028 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21029 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21000 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21001 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21002 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21003 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21004 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21005 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21006 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21007 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21008 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21009 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21010 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21011 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21012 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21013 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21014 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21015 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21016 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21017 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21018 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21019 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21020 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21021 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21022 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21023 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21024 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21025 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21026 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21027 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21028 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21029 keepalive=on max=1 retry=30 > > > I've been added the log parameters you've suggested to apache, i'll put > em in a future messages. > > thanks > > Robert Mela wrote: > >> "Error reading status line" means Mongrel closed the socket without >> sending any content back. >> >> IT WOULD BE REALLY HELPFUL IF MONGREL WOULD SEND BACK "503 Server Busy" >> WHEN IT'S BUSY. That way we would know immediately whether the >> num_processors limit had been reached or not. HUGE TIMESAVER FOR >> MONGREL USERS! >> >> ==== >> >> Next... >> >> Seeing your load balancer config, and mongrel_cluster.yml would help >> narrow things down & simplify the discussion. >> >> Also, add this to your log file config: >> >> %D ( request duration -) >> %{BALANCER_WORKER_NAME}e >> >> >> Request duration, in combination with start time and >> balancer_worker_name, is useful in finding cases where requests to a >> back end app server overlap. These numbers will also allow you to >> construct a histogram of concurrent requests each second. >> >> thanks. >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071017/f4c37bf9/attachment.vcf From lists at ruby-forum.com Wed Oct 17 12:50:20 2007 From: lists at ruby-forum.com (Jacobo Garcia) Date: Wed, 17 Oct 2007 18:50:20 +0200 Subject: [Mongrel] proxy errors with apache2.2.3 + mongrels In-Reply-To: <471637D4.70100@robmela.com> References: <9df971d76ff82f2f315b7d4bc2f3f26a@ruby-forum.com> <471620C6.2030300@robmela.com> <471637D4.70100@robmela.com> Message-ID: I use munin to monitor machines and all of them are in excelent shape :) Robert Mela wrote: > Another avenue to consider is everything in order on the systems > involved? If Rails is chewing up lots of RAM you could be swapping... > here's some diagnostics I usually run ( caveat: I'm not a sysadmin, nor > do I play one on TV ): > > sar -rB 1 0 > sar 1 0 > sar -n EDEV 1 0 (network IO incl. errors) > sar -d 1 0 ( look for excessive block device IO )? > > What sorts of things do other folks on this list look at? -- Posted via http://www.ruby-forum.com/. From rgo at aspgems.com Wed Oct 17 19:19:39 2007 From: rgo at aspgems.com (Rafael G.) Date: Thu, 18 Oct 2007 01:19:39 +0200 Subject: [Mongrel] proxy errors with apache2.2.3 + mongrels In-Reply-To: <9df971d76ff82f2f315b7d4bc2f3f26a@ruby-forum.com> References: <9df971d76ff82f2f315b7d4bc2f3f26a@ruby-forum.com> Message-ID: <4716988B.5020904@aspgems.com> Jacobo Garcia escribi?: > [Tue Oct 16 23:28:01 2007] [error] [client 67.142.130.19] proxy: error > reading status line from remote server bomber, referer: > http://www.google.com/search?hl=es&q=tipos+de+herramintas++++&lr= > > We had this problem and solved it adding the following lines in our apache conf: #Fix for Apache bug 39499 SetEnv force-proxy-request-1.0 1 SetEnv proxy-nokeepalive 1 Regards! -------------- next part -------------- A non-text attachment was scrubbed... Name: rgo.vcf Type: text/x-vcard Size: 251 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071018/159b6c99/attachment.vcf From lists at ruby-forum.com Wed Oct 17 19:36:06 2007 From: lists at ruby-forum.com (Jacobo Garcia) Date: Thu, 18 Oct 2007 01:36:06 +0200 Subject: [Mongrel] proxy errors with apache2.2.3 + mongrels In-Reply-To: <4716988B.5020904@aspgems.com> References: <9df971d76ff82f2f315b7d4bc2f3f26a@ruby-forum.com> <4716988B.5020904@aspgems.com> Message-ID: <738edce460e31ff51a7d538f592e0c94@ruby-forum.com> Rafael Garc?a wrote: > Jacobo Garcia escribi?: >> [Tue Oct 16 23:28:01 2007] [error] [client 67.142.130.19] proxy: error >> reading status line from remote server bomber, referer: >> http://www.google.com/search?hl=es&q=tipos+de+herramintas++++&lr= >> >> > We had this problem and solved it adding the following lines in our > apache conf: > > #Fix for Apache bug 39499 > SetEnv force-proxy-request-1.0 1 > SetEnv proxy-nokeepalive 1 > > > Regards! I've already has this lines (in virtual host conf) that is different than proxy conf, should I put them in proxy conf? -- Posted via http://www.ruby-forum.com/. From rgo at aspgems.com Wed Oct 17 20:21:10 2007 From: rgo at aspgems.com (Rafael G.) Date: Thu, 18 Oct 2007 02:21:10 +0200 Subject: [Mongrel] proxy errors with apache2.2.3 + mongrels In-Reply-To: <738edce460e31ff51a7d538f592e0c94@ruby-forum.com> References: <9df971d76ff82f2f315b7d4bc2f3f26a@ruby-forum.com> <4716988B.5020904@aspgems.com> <738edce460e31ff51a7d538f592e0c94@ruby-forum.com> Message-ID: <4716A6F6.10403@aspgems.com> Jacobo Garcia escribi?: > Rafael Garc?a wrote: > >> Jacobo Garcia escribi?: >> >>> [Tue Oct 16 23:28:01 2007] [error] [client 67.142.130.19] proxy: error >>> reading status line from remote server bomber, referer: >>> http://www.google.com/search?hl=es&q=tipos+de+herramintas++++&lr= >>> >>> >>> >> We had this problem and solved it adding the following lines in our >> apache conf: >> >> #Fix for Apache bug 39499 >> SetEnv force-proxy-request-1.0 1 >> SetEnv proxy-nokeepalive 1 >> >> >> Regards! >> > > > I've already has this lines (in virtual host conf) that is different > than proxy conf, should I put them in proxy conf? > I have it in virtualhost conf, not in proxy conf. Maybe reading this post find the solution: http://www.overset.com/2007/04/03/mod_proxy-and-internet-explorer-problems/ -------------- next part -------------- A non-text attachment was scrubbed... Name: rgo.vcf Type: text/x-vcard Size: 251 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071018/5ce98d98/attachment.vcf From adrian.boughey at gmx.net Thu Oct 18 05:05:45 2007 From: adrian.boughey at gmx.net (Adrian Boughey) Date: Thu, 18 Oct 2007 11:05:45 +0200 Subject: [Mongrel] Mongrel-users Digest, Vol 21, Issue 16 In-Reply-To: Message-ID: <20071018090906.8E5DD18585BE@rubyforge.org> According to the mongrel_cluster.yml file you provided, you're starting only 14 mongrels, but in your proxy balancer config you have 30 mongrels listed on ports 21000 - 21029. In this scenario, if apache tries to proxy to any ports higher than 21014 then you'll get a proxy error as a mongrel doesn't exist on that port. Or am I missing something? -----Original Message----- From: mongrel-users-bounces at rubyforge.org [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of mongrel-users-request at rubyforge.org Sent: 18 October 2007 01:36 To: mongrel-users at rubyforge.org Subject: Mongrel-users Digest, Vol 21, Issue 16 Send Mongrel-users mailing list submissions to mongrel-users at rubyforge.org To subscribe or unsubscribe via the World Wide Web, visit http://rubyforge.org/mailman/listinfo/mongrel-users or, via email, send a message with subject or body 'help' to mongrel-users-request at rubyforge.org You can reach the person managing the list at mongrel-users-owner at rubyforge.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Mongrel-users digest..." Today's Topics: 1. proxy errors with apache2.2.3 + mongrels (Jacobo Garcia) 2. Re: proxy errors with apache2.2.3 + mongrels (Robert Mela) 3. Re: proxy errors with apache2.2.3 + mongrels (Jacobo Garcia) 4. Re: proxy errors with apache2.2.3 + mongrels (Robert Mela) 5. Re: proxy errors with apache2.2.3 + mongrels (Jacobo Garcia) 6. Re: proxy errors with apache2.2.3 + mongrels (Rafael G.) 7. Re: proxy errors with apache2.2.3 + mongrels (Jacobo Garcia) ---------------------------------------------------------------------- Message: 1 Date: Wed, 17 Oct 2007 10:45:08 +0200 From: Jacobo Garcia Subject: [Mongrel] proxy errors with apache2.2.3 + mongrels To: mongrel-users at rubyforge.org Message-ID: <9df971d76ff82f2f315b7d4bc2f3f26a at ruby-forum.com> Content-Type: text/plain; charset=utf-8 I've posted this to rails-deployment as well. I have to administer a medium size rails app (1'5 million requests each day), recently I've switched from lighttpd + fcgi to apache + mongrel. In the following lines I am going to describe the platform: All machines are running Debian Etch, with 4 gb ram and dual core intel32 processors. Web server runs debian's apache 2.2.3-4 mpm worker package and also NFS server, Two app servers runs 14 mongrels ach one. There is two db servers, master running mysql5 (debian package) with innodb and an slave server with myisam tables. This slave server has 8 gb ram and has a memcached with 4 gb reserved. We are experiencing problems in peak hours with timeout and slow navigation on pages, also there are problems with some file uploads. I'm investigating on improving quality of service on the site, and I've reached to some proxy errors in apache log, with more than 300 simultaneous stablished connections on the webserver[1]. There are 4 kinds of proxy errors: [Wed Oct 17 06:24:14 2007] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 192.168.10.154:21004 (bomer) failed [Tue Oct 16 23:28:01 2007] [error] [client 67.142.130.19] proxy: error reading status line from remote server bomber, referer: http://www.google.com/search?hl=es&q=tipos+de+herramintas++++&lr= [Wed Oct 17 07:14:11 2007] [error] (70007)The timeout specified has expired: proxy: prefetch request body failed to 192.168.10.154:21013 (kgb) from 200.66.13 3.30 () [Wed Oct 17 07:16:54 2007] [error] [client 201.141.199.86] proxy: Error reading from remote server returned by /myfiles/clubsx/Sin t?? tulo 007_0001(1).jpg, r eferer: http://www.espacioblog.com/clubsx/post/2006/06/04/los-archivos-chiwasnaked With slow or moderated traffic mongrels works well (they use cpu and appears in first lines of 'top' command) but with heavy traffic, mongrels go down. I am looking for help with solving this issues, I've been looking in google about proxy errors, but what I've found haven't helped, I can provide more details if they can help. Also I've been suggested to use nginx web server instead of apache, but I am reluctant to use it, unless proven better than apache, can anyone point me to technical argument for using nginx? [1] $ netstat -nat |grep ':80'| grep 'EST' | wc -l Thanks for your time. Jacobo Garc?a -- Posted via http://www.ruby-forum.com/. ------------------------------ Message: 2 Date: Wed, 17 Oct 2007 10:48:38 -0400 From: Robert Mela Subject: Re: [Mongrel] proxy errors with apache2.2.3 + mongrels To: mongrel-users at rubyforge.org Message-ID: <471620C6.2030300 at robmela.com> Content-Type: text/plain; charset="utf-8" "Error reading status line" means Mongrel closed the socket without sending any content back. IT WOULD BE REALLY HELPFUL IF MONGREL WOULD SEND BACK "503 Server Busy" WHEN IT'S BUSY. That way we would know immediately whether the num_processors limit had been reached or not. HUGE TIMESAVER FOR MONGREL USERS! ==== Next... Seeing your load balancer config, and mongrel_cluster.yml would help narrow things down & simplify the discussion. Also, add this to your log file config: %D ( request duration -) %{BALANCER_WORKER_NAME}e Request duration, in combination with start time and balancer_worker_name, is useful in finding cases where requests to a back end app server overlap. These numbers will also allow you to construct a histogram of concurrent requests each second. thanks. Jacobo Garcia wrote: > I've posted this to rails-deployment as well. > > I have to administer a medium size rails app (1'5 million requests > each day), recently I've switched from lighttpd + fcgi to apache + > mongrel. In the following lines I am going to describe the platform: > > All machines are running Debian Etch, with 4 gb ram and dual core > intel32 processors. Web server runs debian's apache 2.2.3-4 mpm worker > package and also NFS server, Two app servers runs 14 mongrels ach > one. There is two db servers, master running mysql5 (debian package) > with innodb and an slave server with myisam tables. This slave server > has 8 gb ram and has a memcached with 4 gb reserved. > > We are experiencing problems in peak hours with timeout and slow > navigation on pages, also there are problems with some file uploads. > I'm investigating on improving quality of service on the site, and > I've reached to some proxy errors in apache log, with more than 300 > simultaneous stablished connections on the webserver[1]. > > There are 4 kinds of proxy errors: > > [Wed Oct 17 06:24:14 2007] [error] (111)Connection refused: proxy: > HTTP: attempt to connect to 192.168.10.154:21004 (bomer) failed > > [Tue Oct 16 23:28:01 2007] [error] [client 67.142.130.19] proxy: error > reading status line from remote server bomber, referer: > http://www.google.com/search?hl=es&q=tipos+de+herramintas++++&lr= > > [Wed Oct 17 07:14:11 2007] [error] (70007)The timeout specified has > expired: proxy: prefetch request body failed to 192.168.10.154:21013 > (kgb) from 200.66.13 > 3.30 () > > [Wed Oct 17 07:16:54 2007] [error] [client 201.141.199.86] proxy: > Error reading from remote server returned by /myfiles/clubsx/Sin t?? > tulo 007_0001(1).jpg, r > eferer: > http://www.espacioblog.com/clubsx/post/2006/06/04/los-archivos-chiwasnaked > > With slow or moderated traffic mongrels works well (they use cpu and > appears in first lines of 'top' command) but with heavy traffic, > mongrels go down. > > I am looking for help with solving this issues, I've been looking in > google about proxy errors, but what I've found haven't helped, I can > provide more details if they can help. > > Also I've been suggested to use nginx web server instead of apache, > but I am reluctant to use it, unless proven better than apache, can > anyone point me to technical argument for using nginx? > > [1] $ netstat -nat |grep ':80'| grep 'EST' | wc -l > > Thanks for your time. > > Jacobo Garc?a > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 123 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071017/6aaf9e30/a ttachment-0001.vcf ------------------------------ Message: 3 Date: Wed, 17 Oct 2007 17:36:34 +0200 From: Jacobo Garcia Subject: Re: [Mongrel] proxy errors with apache2.2.3 + mongrels To: mongrel-users at rubyforge.org Message-ID: Content-Type: text/plain; charset=utf-8 mongrel_cluster.yml: --- port: "21000" docroot: /var/www/mysite/current/public/ cwd: /var/www/mysite/current pid_file: /var/www/mysite/tmp/pids/mongrel.pid log_file: /var/www/mysite/current/log/mongrel.log environment: production servers: 14 user: deploys group: www-data proxy balancer: ServerName my.ip.add.ress NameVirtualHost *:80 BalancerMember http://bomber:21000 keepalive=on max=1 retry=30 BalancerMember http://bomber:21001 keepalive=on max=1 retry=30 BalancerMember http://bomber:21002 keepalive=on max=1 retry=30 BalancerMember http://bomber:21003 keepalive=on max=1 retry=30 BalancerMember http://bomber:21004 keepalive=on max=1 retry=30 BalancerMember http://bomber:21005 keepalive=on max=1 retry=30 BalancerMember http://bomber:21006 keepalive=on max=1 retry=30 BalancerMember http://bomber:21007 keepalive=on max=1 retry=30 BalancerMember http://bomber:21008 keepalive=on max=1 retry=30 BalancerMember http://bomber:21009 keepalive=on max=1 retry=30 BalancerMember http://bomber:21010 keepalive=on max=1 retry=30 BalancerMember http://bomber:21011 keepalive=on max=1 retry=30 BalancerMember http://bomber:21012 keepalive=on max=1 retry=30 BalancerMember http://bomber:21013 keepalive=on max=1 retry=30 BalancerMember http://bomber:21014 keepalive=on max=1 retry=30 BalancerMember http://bomber:21015 keepalive=on max=1 retry=30 BalancerMember http://bomber:21016 keepalive=on max=1 retry=30 BalancerMember http://bomber:21017 keepalive=on max=1 retry=30 BalancerMember http://bomber:21018 keepalive=on max=1 retry=30 BalancerMember http://bomber:21019 keepalive=on max=1 retry=30 BalancerMember http://bomber:21020 keepalive=on max=1 retry=30 BalancerMember http://bomber:21021 keepalive=on max=1 retry=30 BalancerMember http://bomber:21022 keepalive=on max=1 retry=30 BalancerMember http://bomber:21023 keepalive=on max=1 retry=30 BalancerMember http://bomber:21024 keepalive=on max=1 retry=30 BalancerMember http://bomber:21025 keepalive=on max=1 retry=30 BalancerMember http://bomber:21026 keepalive=on max=1 retry=30 BalancerMember http://bomber:21027 keepalive=on max=1 retry=30 BalancerMember http://bomber:21028 keepalive=on max=1 retry=30 BalancerMember http://bomber:21029 keepalive=on max=1 retry=30 BalancerMember http://kgb:21000 keepalive=on max=1 retry=30 BalancerMember http://kgb:21001 keepalive=on max=1 retry=30 BalancerMember http://kgb:21002 keepalive=on max=1 retry=30 BalancerMember http://kgb:21003 keepalive=on max=1 retry=30 BalancerMember http://kgb:21004 keepalive=on max=1 retry=30 BalancerMember http://kgb:21005 keepalive=on max=1 retry=30 BalancerMember http://kgb:21006 keepalive=on max=1 retry=30 BalancerMember http://kgb:21007 keepalive=on max=1 retry=30 BalancerMember http://kgb:21008 keepalive=on max=1 retry=30 BalancerMember http://kgb:21009 keepalive=on max=1 retry=30 BalancerMember http://kgb:21010 keepalive=on max=1 retry=30 BalancerMember http://kgb:21011 keepalive=on max=1 retry=30 BalancerMember http://kgb:21012 keepalive=on max=1 retry=30 BalancerMember http://kgb:21013 keepalive=on max=1 retry=30 BalancerMember http://kgb:21014 keepalive=on max=1 retry=30 BalancerMember http://kgb:21015 keepalive=on max=1 retry=30 BalancerMember http://kgb:21016 keepalive=on max=1 retry=30 BalancerMember http://kgb:21017 keepalive=on max=1 retry=30 BalancerMember http://kgb:21018 keepalive=on max=1 retry=30 BalancerMember http://kgb:21019 keepalive=on max=1 retry=30 BalancerMember http://kgb:21020 keepalive=on max=1 retry=30 BalancerMember http://kgb:21021 keepalive=on max=1 retry=30 BalancerMember http://kgb:21022 keepalive=on max=1 retry=30 BalancerMember http://kgb:21023 keepalive=on max=1 retry=30 BalancerMember http://kgb:21024 keepalive=on max=1 retry=30 BalancerMember http://kgb:21025 keepalive=on max=1 retry=30 BalancerMember http://kgb:21026 keepalive=on max=1 retry=30 BalancerMember http://kgb:21027 keepalive=on max=1 retry=30 BalancerMember http://kgb:21028 keepalive=on max=1 retry=30 BalancerMember http://kgb:21029 keepalive=on max=1 retry=30 I've been added the log parameters you've suggested to apache, i'll put em in a future messages. thanks Robert Mela wrote: > "Error reading status line" means Mongrel closed the socket without > sending any content back. > > IT WOULD BE REALLY HELPFUL IF MONGREL WOULD SEND BACK "503 Server Busy" > WHEN IT'S BUSY. That way we would know immediately whether the > num_processors limit had been reached or not. HUGE TIMESAVER FOR > MONGREL USERS! > > ==== > > Next... > > Seeing your load balancer config, and mongrel_cluster.yml would help > narrow things down & simplify the discussion. > > Also, add this to your log file config: > > %D ( request duration -) > %{BALANCER_WORKER_NAME}e > > > Request duration, in combination with start time and > balancer_worker_name, is useful in finding cases where requests to a > back end app server overlap. These numbers will also allow you to > construct a histogram of concurrent requests each second. > > thanks. -- Posted via http://www.ruby-forum.com/. ------------------------------ Message: 4 Date: Wed, 17 Oct 2007 12:27:00 -0400 From: Robert Mela Subject: Re: [Mongrel] proxy errors with apache2.2.3 + mongrels To: mongrel-users at rubyforge.org Message-ID: <471637D4.70100 at robmela.com> Content-Type: text/plain; charset="iso-8859-1" Another avenue to consider is everything in order on the systems involved? If Rails is chewing up lots of RAM you could be swapping... here's some diagnostics I usually run ( caveat: I'm not a sysadmin, nor do I play one on TV ): sar -rB 1 0 sar 1 0 sar -n EDEV 1 0 (network IO incl. errors) sar -d 1 0 ( look for excessive block device IO )? What sorts of things do other folks on this list look at? Jacobo Garcia wrote: > mongrel_cluster.yml: > > --- > port: "21000" > docroot: /var/www/mysite/current/public/ > cwd: /var/www/mysite/current > pid_file: /var/www/mysite/tmp/pids/mongrel.pid > log_file: /var/www/mysite/current/log/mongrel.log > environment: production > servers: 14 > user: deploys > group: www-data > > > proxy balancer: > ServerName my.ip.add.ress > NameVirtualHost *:80 > > BalancerMember http://bomber:21000 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21001 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21002 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21003 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21004 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21005 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21006 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21007 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21008 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21009 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21010 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21011 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21012 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21013 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21014 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21015 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21016 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21017 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21018 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21019 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21020 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21021 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21022 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21023 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21024 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21025 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21026 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21027 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21028 keepalive=on max=1 retry=30 > BalancerMember http://bomber:21029 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21000 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21001 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21002 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21003 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21004 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21005 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21006 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21007 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21008 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21009 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21010 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21011 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21012 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21013 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21014 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21015 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21016 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21017 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21018 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21019 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21020 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21021 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21022 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21023 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21024 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21025 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21026 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21027 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21028 keepalive=on max=1 retry=30 > BalancerMember http://kgb:21029 keepalive=on max=1 retry=30 > > > I've been added the log parameters you've suggested to apache, i'll put > em in a future messages. > > thanks > > Robert Mela wrote: > >> "Error reading status line" means Mongrel closed the socket without >> sending any content back. >> >> IT WOULD BE REALLY HELPFUL IF MONGREL WOULD SEND BACK "503 Server Busy" >> WHEN IT'S BUSY. That way we would know immediately whether the >> num_processors limit had been reached or not. HUGE TIMESAVER FOR >> MONGREL USERS! >> >> ==== >> >> Next... >> >> Seeing your load balancer config, and mongrel_cluster.yml would help >> narrow things down & simplify the discussion. >> >> Also, add this to your log file config: >> >> %D ( request duration -) >> %{BALANCER_WORKER_NAME}e >> >> >> Request duration, in combination with start time and >> balancer_worker_name, is useful in finding cases where requests to a >> back end app server overlap. These numbers will also allow you to >> construct a histogram of concurrent requests each second. >> >> thanks. >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071017/f4c37bf9/a ttachment-0001.vcf ------------------------------ Message: 5 Date: Wed, 17 Oct 2007 18:50:20 +0200 From: Jacobo Garcia Subject: Re: [Mongrel] proxy errors with apache2.2.3 + mongrels To: mongrel-users at rubyforge.org Message-ID: Content-Type: text/plain; charset=utf-8 I use munin to monitor machines and all of them are in excelent shape :) Robert Mela wrote: > Another avenue to consider is everything in order on the systems > involved? If Rails is chewing up lots of RAM you could be swapping... > here's some diagnostics I usually run ( caveat: I'm not a sysadmin, nor > do I play one on TV ): > > sar -rB 1 0 > sar 1 0 > sar -n EDEV 1 0 (network IO incl. errors) > sar -d 1 0 ( look for excessive block device IO )? > > What sorts of things do other folks on this list look at? -- Posted via http://www.ruby-forum.com/. ------------------------------ Message: 6 Date: Thu, 18 Oct 2007 01:19:39 +0200 From: "Rafael G." Subject: Re: [Mongrel] proxy errors with apache2.2.3 + mongrels To: mongrel-users at rubyforge.org Message-ID: <4716988B.5020904 at aspgems.com> Content-Type: text/plain; charset="utf-8" Jacobo Garcia escribi?: > [Tue Oct 16 23:28:01 2007] [error] [client 67.142.130.19] proxy: error > reading status line from remote server bomber, referer: > http://www.google.com/search?hl=es&q=tipos+de+herramintas++++&lr= > > We had this problem and solved it adding the following lines in our apache conf: #Fix for Apache bug 39499 SetEnv force-proxy-request-1.0 1 SetEnv proxy-nokeepalive 1 Regards! -------------- next part -------------- A non-text attachment was scrubbed... Name: rgo.vcf Type: text/x-vcard Size: 251 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071018/159b6c99/a ttachment-0001.vcf ------------------------------ Message: 7 Date: Thu, 18 Oct 2007 01:36:06 +0200 From: Jacobo Garcia Subject: Re: [Mongrel] proxy errors with apache2.2.3 + mongrels To: mongrel-users at rubyforge.org Message-ID: <738edce460e31ff51a7d538f592e0c94 at ruby-forum.com> Content-Type: text/plain; charset=utf-8 Rafael Garc?a wrote: > Jacobo Garcia escribi?: >> [Tue Oct 16 23:28:01 2007] [error] [client 67.142.130.19] proxy: error >> reading status line from remote server bomber, referer: >> http://www.google.com/search?hl=es&q=tipos+de+herramintas++++&lr= >> >> > We had this problem and solved it adding the following lines in our > apache conf: > > #Fix for Apache bug 39499 > SetEnv force-proxy-request-1.0 1 > SetEnv proxy-nokeepalive 1 > > > Regards! I've already has this lines (in virtual host conf) that is different than proxy conf, should I put them in proxy conf? -- Posted via http://www.ruby-forum.com/. ------------------------------ _______________________________________________ Mongrel-users mailing list Mongrel-users at rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users End of Mongrel-users Digest, Vol 21, Issue 16 ********************************************* From lists at ruby-forum.com Thu Oct 18 09:03:29 2007 From: lists at ruby-forum.com (Jacobo Garcia) Date: Thu, 18 Oct 2007 15:03:29 +0200 Subject: [Mongrel] proxy errors with apache2.2.3 + mongrels In-Reply-To: <4716A6F6.10403@aspgems.com> References: <9df971d76ff82f2f315b7d4bc2f3f26a@ruby-forum.com> <4716988B.5020904@aspgems.com> <738edce460e31ff51a7d538f592e0c94@ruby-forum.com> <4716A6F6.10403@aspgems.com> Message-ID: Rafael Garc?a wrote: > Jacobo Garcia escribi?: >>> We had this problem and solved it adding the following lines in our >> >> I've already has this lines (in virtual host conf) that is different >> than proxy conf, should I put them in proxy conf? >> > I have it in virtualhost conf, not in proxy conf. > > Maybe reading this post find the solution: > http://www.overset.com/2007/04/03/mod_proxy-and-internet-explorer-problems/ With the fixed proposed in the article and some tweaks in balancermember settings (retry=5) no max, no keepalive=on I've been able to reduce proxy errors, but still having some "Connection refused: proxy: HTTP: attempt to connect to 192.168.10.153:21000 (bomber) failed" I am not sure how this setup will behave under heavy load, i'm going to test it this evening, and see what hapens. I have been testing nginx as well and has been running flawlessly, consuming very little memory, I think it is worth a try. -- Posted via http://www.ruby-forum.com/. From rob at robmela.com Thu Oct 18 09:30:57 2007 From: rob at robmela.com (Robert Mela) Date: Thu, 18 Oct 2007 09:30:57 -0400 Subject: [Mongrel] proxy errors with apache2.2.3 + mongrels In-Reply-To: <4716988B.5020904@aspgems.com> References: <9df971d76ff82f2f315b7d4bc2f3f26a@ruby-forum.com> <4716988B.5020904@aspgems.com> Message-ID: <47176011.3010307@robmela.com> What I'm not seeing in those bug reports is "Connection Refused" errors. As an aside, I bet that as of Apache 2.2.4 "SetEnv proxy-nokeepalive 1 " is no longer needed. One cause of the "error reading headers" error was that up until 2.2.4 mod_proxy wasn't checking to see whether a previously used socket was still good or not before using it for the next request. The fix is in 2.2.4. It makes sense that turning keepalives off for proxy connections works. It probably makes Apache reconnect for each request: a blank slate. That's a practical option if you've got a few dozen to a hundred requests per second. So two possible causes of error reading response headers are: 1) Mongrel has hit 950 workers ( or whatever num_processors is ) -- unlikely, I suppose, unless there's a bug in Mongrel's tracking of worker list length. 2) Apache attempted to read/write to a bad socket The no-keepalives probably addresses the second case. I'm not sure what it does in the first case. The way mod_proxy checks is to read a zero byte buffer off the socket. If Mongrel just closes right away I'm not sure what state the socket's in at the client ( mod_proxy ) side of things -- whether it's in close_wait or whatever -- and what a zero-byte read would return. This is one reason why returning a 503 from Mongrel would be helpful -- it'd be nice to rule out the num_processors accept/close right off the bat, however unlikely it may be deemed. It might be worth upgrading to Apache 2.2.6 and seeing whether that fixes the issue. It's a crap shoot, done without fully understanding the problem, but if it works, what the heck -- it makes your day better. Anyhow, I'm really interested in the outcome of this -- we rely on mod_proxy_balancer, and I want to be sure I understand it. Rafael G. wrote: > Jacobo Garcia escribi?: >> [Tue Oct 16 23:28:01 2007] [error] [client 67.142.130.19] proxy: error >> reading status line from remote server bomber, referer: >> http://www.google.com/search?hl=es&q=tipos+de+herramintas++++&lr= >> >> > We had this problem and solved it adding the following lines in our > apache conf: > > #Fix for Apache bug 39499 > SetEnv force-proxy-request-1.0 1 > SetEnv proxy-nokeepalive 1 > > > Regards! > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 123 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071018/b737e6c3/attachment.vcf From donald.ball at nashville.gov Fri Oct 19 12:42:26 2007 From: donald.ball at nashville.gov (Ball, Donald A Jr (Library)) Date: Fri, 19 Oct 2007 11:42:26 -0500 Subject: [Mongrel] Error messages when running mongrel on win32 Message-ID: <918A0DD3EFA7F248BFBF447187F8A9323A905A@HOBVSISMS01.nashville.org> Hi folks. I'm running mongrel (1.0) on a win32 box (2k3 iirc). I'm using a Google Mini to index the contents of my rails (1.2.4) webapp. I've been noticing that when I run a search, I get lots of these messages in my mongrel console: ERROR: An established connection was aborted by the software in your host machine These errors seem to be coming in response to HEAD requests being issued by the Google Mini. When searching protected content, the Mini asks for the users credentials and issues HEAD requests for all of the resources which would end up in the search results, in order to eliminate those items to which the user does not have access. Presumably it's discarding everything that doesn't have a 2xx response. My webapp isn't doing anything special in response to HEAD requests, aside for not logging the read requests as "real" read requests for the purpose of tracking hits. I suppose I could tell it to not send_file and the like in the case of HEAD requests, though I was under the impression that rails silently discards the response body, so it's really superfluous. These error messages don't _seem_ to be causing anything bad to happen, but I haven't yet spent much time debugging. Still, I noted that Zed had been looking for folks that could reliably duplicate the situation a while back, so thought I'd post it in case y'all want to use me as guinea pig. - donald From ekolve at adready.com Sun Oct 21 13:04:58 2007 From: ekolve at adready.com (Eric Kolve) Date: Sun, 21 Oct 2007 10:04:58 -0700 Subject: [Mongrel] Reliable cluster::restart Message-ID: <1f068a630710211004y5f127c54m364bfa85664c2b4b@mail.gmail.com> I run into a problem every so often while doing a cluster::restart where a child sleeps after receiving the KILL, but does not get restarted. This is caused by mongrel not shutting down until either all the requests have completed or 60 seconds have passed. The problem is that when the subsequent start command is issued it comes before the child has exited, so it never gets restarted. This is pretty dangerous because I could have say 5 mongrels, all doing something at the time of the restart and would all end up stopping and not starting back up. I created the attached restarter in the style of the Cluster::Restart class in mongrel_cluster. It iterates through each port in the cluster, attempting to stop in nicely, checking if it still exists, then killing it with force (after sleeping for a bit), then starting it back up. The thing I like most about this is that it works really well with mod_proxy_balancer. By default, balancer is configured to make one fail-over attempt. As you take down each of these processes, Apache will inevitably run into one that you have stopped, but not started back up. In this case, it will just attempt another mongrel. The odds are good that Apache will find mongrel process that hasn't been stopped yet since, for it to fail, it would have to randomly select the next process to the stopped and that process would have to get stopped in the time it takes to start up the one that originally failed. Currently, cluster::restart stops all the mongrels and when apache attempts to fail-over, it has a pretty good chance of finding another stopped mongrel. The end user then gets a proxy error. Any chance of getting this folded into the mongrel_cluster gem in some form? thanks, eric -------------- next part -------------- A non-text attachment was scrubbed... Name: serial_restart.rb Type: application/octet-stream Size: 765 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071021/7a329549/attachment.obj From evan at cloudbur.st Mon Oct 22 03:31:10 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 22 Oct 2007 03:31:10 -0400 Subject: [Mongrel] Reliable cluster::restart In-Reply-To: <1f068a630710211004y5f127c54m364bfa85664c2b4b@mail.gmail.com> References: <1f068a630710211004y5f127c54m364bfa85664c2b4b@mail.gmail.com> Message-ID: Should the regular stop command behave in this way? That is, if @force is enabled, it would send the soft kill, then sleep the amount of your original shutdown timeout (default 60 seconds), plus a few seconds more, and then send the hard kill. If @force is not enabled, the behavior would stay the same as now. I know people have strong opinions on how to kill mongrels... Evan On 10/21/07, Eric Kolve wrote: > I run into a problem every so often while doing a cluster::restart > where a child sleeps after receiving the KILL, but does not get > restarted. This is caused by mongrel not shutting down until either > all the requests have completed or 60 seconds have passed. The problem > is that when the subsequent start command is issued it comes before > the child has exited, so it never gets restarted. This is pretty > dangerous because I could have say 5 mongrels, all doing something at > the time of the restart and would all end up stopping and not starting > back up. > > I created the attached restarter in the style of the Cluster::Restart > class in mongrel_cluster. It iterates through each port in the > cluster, attempting to stop in nicely, checking if it still exists, > then killing it with force (after sleeping for a bit), then starting > it back up. The thing I like most about this is that it works really > well with mod_proxy_balancer. By default, balancer is configured to > make one fail-over attempt. As you take down each of these processes, > Apache will inevitably run into one that you have stopped, but not > started back up. In this case, it will just attempt another mongrel. > The odds are good that Apache will find mongrel process that hasn't > been stopped yet since, for it to fail, it would have to randomly > select the next process to the stopped and that process would have to > get stopped in the time it takes to start up the one that originally > failed. > > Currently, cluster::restart stops all the mongrels and when apache > attempts to fail-over, it has a pretty good chance of finding another > stopped mongrel. The end user then gets a proxy error. > > Any chance of getting this folded into the mongrel_cluster gem in some form? > > thanks, > eric > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > -- Evan Weaver Cloudburst, LLC From bostjan at idejaplus.si Mon Oct 22 03:28:22 2007 From: bostjan at idejaplus.si (Bostjan Potocnik) Date: Mon, 22 Oct 2007 09:28:22 +0200 Subject: [Mongrel] weird error - stream closed Message-ID: <1193038102.1075.8.camel@brain.netio.si> Hi all, few days ago mongrel start crashing on one of my sites, i upgraded to latest version (1.0.1) but problem still exists. When i try to load page in browser random elements are missing or page is blank (empty html). In mongrel.log i'm getting: Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed Mon Oct 22 01:10:47 +0200 2007: ERROR: closed stream Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed Error sending file /usr/local/www/ibn/public/javascripts/dragdrop.js: closed stream and most interesting one: !!!!!! UNHANDLED EXCEPTION! Invalid argument. TELL ZED HE'S A MORON. any ideas what is causing that ? Thanks and best regards, Bostjan From evan at cloudbur.st Mon Oct 22 04:31:40 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 22 Oct 2007 04:31:40 -0400 Subject: [Mongrel] weird error - stream closed In-Reply-To: <1193038102.1075.8.camel@brain.netio.si> References: <1193038102.1075.8.camel@brain.netio.si> Message-ID: Hi Bostjan, Can you upgrade your Mongrel to the RC from http://mongrel.rubyforge.org/releases/ and then report back? It has better error logging. Evan On 10/22/07, Bostjan Potocnik wrote: > Hi all, > > few days ago mongrel start crashing on one of my sites, i upgraded to > latest version (1.0.1) but problem still exists. > > When i try to load page in browser random elements are missing or page > is blank (empty html). In mongrel.log i'm getting: > > Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed > Mon Oct 22 01:10:47 +0200 2007: ERROR: closed stream > Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed > Error sending file /usr/local/www/ibn/public/javascripts/dragdrop.js: > closed stream > > and most interesting one: > !!!!!! UNHANDLED EXCEPTION! Invalid argument. TELL ZED HE'S A MORON. > > any ideas what is causing that ? > > Thanks and best regards, > Bostjan > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From bostjan at idejaplus.si Mon Oct 22 08:02:30 2007 From: bostjan at idejaplus.si (Bostjan Potocnik) Date: Mon, 22 Oct 2007 14:02:30 +0200 Subject: [Mongrel] weird error - stream closed In-Reply-To: References: <1193038102.1075.8.camel@brain.netio.si> Message-ID: <1193054550.1026.2.camel@brain.netio.si> Hi, i upgraded to mongrel 1.0.2 and it doesn't start. I run it like: mongrel_rails start -B ** Starting Mongrel listening at :3000 ** Installing debugging prefixed filters. Look in log/mongrel_debug for the files. ** Starting Rails with development environment... it creates files in debug dir, but no mongrel.log or mongrel.pid. I also noticed that it doesn't start listening on specified port. any ideas ? Regards, Bostjan On Mon, 2007-10-22 at 04:31 -0400, Evan Weaver wrote: > Hi Bostjan, > > Can you upgrade your Mongrel to the RC from > http://mongrel.rubyforge.org/releases/ and then report back? It has > better error logging. > > Evan > > On 10/22/07, Bostjan Potocnik wrote: > > Hi all, > > > > few days ago mongrel start crashing on one of my sites, i upgraded to > > latest version (1.0.1) but problem still exists. > > > > When i try to load page in browser random elements are missing or page > > is blank (empty html). In mongrel.log i'm getting: > > > > Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed > > Mon Oct 22 01:10:47 +0200 2007: ERROR: closed stream > > Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed > > Error sending file /usr/local/www/ibn/public/javascripts/dragdrop.js: > > closed stream > > > > and most interesting one: > > !!!!!! UNHANDLED EXCEPTION! Invalid argument. TELL ZED HE'S A MORON. > > > > any ideas what is causing that ? > > > > Thanks and best regards, > > Bostjan > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > From bostjan at idejaplus.si Mon Oct 22 08:30:27 2007 From: bostjan at idejaplus.si (Bostjan Potocnik) Date: Mon, 22 Oct 2007 14:30:27 +0200 Subject: [Mongrel] weird error - stream closed In-Reply-To: References: <1193038102.1075.8.camel@brain.netio.si> Message-ID: <1193056227.1026.10.camel@brain.netio.si> After a lot of errors those errors i get: Mon Oct 22 14:33:55 +0200 2007: ERROR: stream closed /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:580: [BUG] Segmentation fault ruby 1.8.6 (2007-03-13) [i386-freebsd6] maybe that helps On Mon, 2007-10-22 at 04:31 -0400, Evan Weaver wrote: > Hi Bostjan, > > Can you upgrade your Mongrel to the RC from > http://mongrel.rubyforge.org/releases/ and then report back? It has > better error logging. > > Evan > > On 10/22/07, Bostjan Potocnik wrote: > > Hi all, > > > > few days ago mongrel start crashing on one of my sites, i upgraded to > > latest version (1.0.1) but problem still exists. > > > > When i try to load page in browser random elements are missing or page > > is blank (empty html). In mongrel.log i'm getting: > > > > Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed > > Mon Oct 22 01:10:47 +0200 2007: ERROR: closed stream > > Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed > > Error sending file /usr/local/www/ibn/public/javascripts/dragdrop.js: > > closed stream > > > > and most interesting one: > > !!!!!! UNHANDLED EXCEPTION! Invalid argument. TELL ZED HE'S A MORON. > > > > any ideas what is causing that ? > > > > Thanks and best regards, > > Bostjan > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > From evan at cloudbur.st Mon Oct 22 10:05:59 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 22 Oct 2007 10:05:59 -0400 Subject: [Mongrel] weird error - stream closed In-Reply-To: <1193054550.1026.2.camel@brain.netio.si> References: <1193038102.1075.8.camel@brain.netio.si> <1193054550.1026.2.camel@brain.netio.si> Message-ID: Does it work without -B? Evan On 10/22/07, Bostjan Potocnik wrote: > Hi, > > i upgraded to mongrel 1.0.2 and it doesn't start. I run it like: > mongrel_rails start -B > ** Starting Mongrel listening at :3000 > ** Installing debugging prefixed filters. Look in log/mongrel_debug for > the files. > ** Starting Rails with development environment... > > it creates files in debug dir, but no mongrel.log or mongrel.pid. I also > noticed that it doesn't start listening on specified port. > > any ideas ? > > Regards, > Bostjan > > On Mon, 2007-10-22 at 04:31 -0400, Evan Weaver wrote: > > Hi Bostjan, > > > > Can you upgrade your Mongrel to the RC from > > http://mongrel.rubyforge.org/releases/ and then report back? It has > > better error logging. > > > > Evan > > > > On 10/22/07, Bostjan Potocnik wrote: > > > Hi all, > > > > > > few days ago mongrel start crashing on one of my sites, i upgraded to > > > latest version (1.0.1) but problem still exists. > > > > > > When i try to load page in browser random elements are missing or page > > > is blank (empty html). In mongrel.log i'm getting: > > > > > > Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed > > > Mon Oct 22 01:10:47 +0200 2007: ERROR: closed stream > > > Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed > > > Error sending file /usr/local/www/ibn/public/javascripts/dragdrop.js: > > > closed stream > > > > > > and most interesting one: > > > !!!!!! UNHANDLED EXCEPTION! Invalid argument. TELL ZED HE'S A MORON. > > > > > > any ideas what is causing that ? > > > > > > Thanks and best regards, > > > Bostjan > > > > > > _______________________________________________ > > > Mongrel-users mailing list > > > Mongrel-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From bostjan at idejaplus.si Mon Oct 22 10:05:48 2007 From: bostjan at idejaplus.si (Bostjan Potocnik) Date: Mon, 22 Oct 2007 16:05:48 +0200 Subject: [Mongrel] weird error - stream closed In-Reply-To: References: <1193038102.1075.8.camel@brain.netio.si> <1193054550.1026.2.camel@brain.netio.si> Message-ID: <1193061948.1026.12.camel@brain.netio.si> no it doesn't funny thing is, mongrel_cluster works fine, so i'll stick to it for now :) regards, bostjan On Mon, 2007-10-22 at 10:05 -0400, Evan Weaver wrote: > Does it work without -B? > > Evan > > On 10/22/07, Bostjan Potocnik wrote: > > Hi, > > > > i upgraded to mongrel 1.0.2 and it doesn't start. I run it like: > > mongrel_rails start -B > > ** Starting Mongrel listening at :3000 > > ** Installing debugging prefixed filters. Look in log/mongrel_debug for > > the files. > > ** Starting Rails with development environment... > > > > it creates files in debug dir, but no mongrel.log or mongrel.pid. I also > > noticed that it doesn't start listening on specified port. > > > > any ideas ? > > > > Regards, > > Bostjan > > > > On Mon, 2007-10-22 at 04:31 -0400, Evan Weaver wrote: > > > Hi Bostjan, > > > > > > Can you upgrade your Mongrel to the RC from > > > http://mongrel.rubyforge.org/releases/ and then report back? It has > > > better error logging. > > > > > > Evan > > > > > > On 10/22/07, Bostjan Potocnik wrote: > > > > Hi all, > > > > > > > > few days ago mongrel start crashing on one of my sites, i upgraded to > > > > latest version (1.0.1) but problem still exists. > > > > > > > > When i try to load page in browser random elements are missing or page > > > > is blank (empty html). In mongrel.log i'm getting: > > > > > > > > Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed > > > > Mon Oct 22 01:10:47 +0200 2007: ERROR: closed stream > > > > Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed > > > > Error sending file /usr/local/www/ibn/public/javascripts/dragdrop.js: > > > > closed stream > > > > > > > > and most interesting one: > > > > !!!!!! UNHANDLED EXCEPTION! Invalid argument. TELL ZED HE'S A MORON. > > > > > > > > any ideas what is causing that ? > > > > > > > > Thanks and best regards, > > > > Bostjan > > > > > > > > _______________________________________________ > > > > Mongrel-users mailing list > > > > Mongrel-users at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > > > > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > From evan at cloudbur.st Mon Oct 22 10:14:07 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 22 Oct 2007 10:14:07 -0400 Subject: [Mongrel] weird error - stream closed In-Reply-To: <1193061948.1026.12.camel@brain.netio.si> References: <1193038102.1075.8.camel@brain.netio.si> <1193054550.1026.2.camel@brain.netio.si> <1193061948.1026.12.camel@brain.netio.si> Message-ID: Maybe I broke it. For Mongrel 1.0.2, if you go into the gem directory and run "ruby test/test_ws.rb", do the tests pass? What do you mean by "mongrel_cluster" works fine? What version of mongrel? What output do you get compared to "mongrel_rails"? Evan On 10/22/07, Bostjan Potocnik wrote: > no it doesn't > > funny thing is, mongrel_cluster works fine, so i'll stick to it for > now :) > > regards, > bostjan > > On Mon, 2007-10-22 at 10:05 -0400, Evan Weaver wrote: > > Does it work without -B? > > > > Evan > > > > On 10/22/07, Bostjan Potocnik wrote: > > > Hi, > > > > > > i upgraded to mongrel 1.0.2 and it doesn't start. I run it like: > > > mongrel_rails start -B > > > ** Starting Mongrel listening at :3000 > > > ** Installing debugging prefixed filters. Look in log/mongrel_debug for > > > the files. > > > ** Starting Rails with development environment... > > > > > > it creates files in debug dir, but no mongrel.log or mongrel.pid. I also > > > noticed that it doesn't start listening on specified port. > > > > > > any ideas ? > > > > > > Regards, > > > Bostjan > > > > > > On Mon, 2007-10-22 at 04:31 -0400, Evan Weaver wrote: > > > > Hi Bostjan, > > > > > > > > Can you upgrade your Mongrel to the RC from > > > > http://mongrel.rubyforge.org/releases/ and then report back? It has > > > > better error logging. > > > > > > > > Evan > > > > > > > > On 10/22/07, Bostjan Potocnik wrote: > > > > > Hi all, > > > > > > > > > > few days ago mongrel start crashing on one of my sites, i upgraded to > > > > > latest version (1.0.1) but problem still exists. > > > > > > > > > > When i try to load page in browser random elements are missing or page > > > > > is blank (empty html). In mongrel.log i'm getting: > > > > > > > > > > Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed > > > > > Mon Oct 22 01:10:47 +0200 2007: ERROR: closed stream > > > > > Mon Oct 22 01:10:47 +0200 2007: ERROR: stream closed > > > > > Error sending file /usr/local/www/ibn/public/javascripts/dragdrop.js: > > > > > closed stream > > > > > > > > > > and most interesting one: > > > > > !!!!!! UNHANDLED EXCEPTION! Invalid argument. TELL ZED HE'S A MORON. > > > > > > > > > > any ideas what is causing that ? > > > > > > > > > > Thanks and best regards, > > > > > Bostjan > > > > > > > > > > _______________________________________________ > > > > > Mongrel-users mailing list > > > > > Mongrel-users at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Mongrel-users mailing list > > > Mongrel-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From jeremy at ibexinternet.co.uk Mon Oct 22 11:57:41 2007 From: jeremy at ibexinternet.co.uk (Jeremy Wilkins) Date: Mon, 22 Oct 2007 16:57:41 +0100 Subject: [Mongrel] Automatic Scaling Message-ID: <0B24FE11-B64C-4328-80DC-9E4885D8CF2C@ibexinternet.co.uk> Hi, I've got an app which will only be dealing with a few requests a minute for most of the time, then will shoot up to a continuous 20 req/s for an hour at a time. We'll potentially be running a lot of instances of this app on the same server. Is there any way to have additional instances of Mongrel be started when the existing instance(s) stopping being able to handle the volume of traffic. I could preload adequate instances to cope with peak traffic but that will result in a lot of instances sitting idle for the majority of the time. Does anyone have any experience of SCGI? I know that FastCGI will start loading additional app instances after a certain threshold - does SCGI behave the same. Thanks Jeremy From wyhaines at gmail.com Mon Oct 22 12:45:30 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 22 Oct 2007 09:45:30 -0700 Subject: [Mongrel] Automatic Scaling In-Reply-To: <0B24FE11-B64C-4328-80DC-9E4885D8CF2C@ibexinternet.co.uk> References: <0B24FE11-B64C-4328-80DC-9E4885D8CF2C@ibexinternet.co.uk> Message-ID: On 10/22/07, Jeremy Wilkins wrote: > I've got an app which will only be dealing with a few requests a > minute for most of the time, then will shoot up to a continuous 20 > req/s for an hour at a time. We'll potentially be running a lot of > instances of this app on the same server. How fast is your app? How many mongrels do you figure you need to handle that volume? > Is there any way to have additional instances of Mongrel be started > when the existing instance(s) stopping being able to handle the > volume of traffic. I could preload adequate instances to cope with > peak traffic but that will result in a lot of instances sitting idle > for the majority of the time. I am working on something that will do exactly that. It's not ready for public consumption, but it will permit one to have a mongrel cluster that self adjusts to the load it is receiving, with real time reporting of cluster status. Kirk Haines From jeremy at ibexinternet.co.uk Tue Oct 23 06:59:42 2007 From: jeremy at ibexinternet.co.uk (Jeremy Wilkins) Date: Tue, 23 Oct 2007 11:59:42 +0100 Subject: [Mongrel] Automatic Scaling In-Reply-To: References: <0B24FE11-B64C-4328-80DC-9E4885D8CF2C@ibexinternet.co.uk> Message-ID: On 22 Oct 2007, at 17:45, Kirk Haines wrote: > On 10/22/07, Jeremy Wilkins wrote: > >> I've got an app which will only be dealing with a few requests a >> minute for most of the time, then will shoot up to a continuous 20 >> req/s for an hour at a time. We'll potentially be running a lot of >> instances of this app on the same server. > > How fast is your app? How many mongrels do you figure you need to > handle that volume? Hopefully very fast - I'm aiming to get it down to 1 or 2 database queries per (ajax) request, with just a small amount to text being sent back. We're currently planning this part of the so don't have any stats yet. My concern is that it will probably be being hosted on our existing (heavily loaded) PHP server till the clients needs enough instances to justify their own server. > >> Is there any way to have additional instances of Mongrel be started >> when the existing instance(s) stopping being able to handle the >> volume of traffic. I could preload adequate instances to cope with >> peak traffic but that will result in a lot of instances sitting idle >> for the majority of the time. > > I am working on something that will do exactly that. It's not ready > for public consumption, but it will permit one to have a mongrel > cluster that self adjusts to the load it is receiving, with real time > reporting of cluster status. > Sounds very interesting - I'm pretty new to all this but this seems to be one area where FastCGI (and I presume SCGI) has significant advantage over the mongrel cluster approach. How long do you anticipate it will take to develop your solution (just curious - I know its a when its done thing). Thanks jebw > > Kirk Haines > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From rob at robmela.com Tue Oct 23 12:28:32 2007 From: rob at robmela.com (Robert Mela) Date: Tue, 23 Oct 2007 12:28:32 -0400 Subject: [Mongrel] Shared listening sockets In-Reply-To: References: <0B24FE11-B64C-4328-80DC-9E4885D8CF2C@ibexinternet.co.uk> Message-ID: <471E2130.20004@robmela.com> Several years back I accidentally discovered that multiple processes can listen on the same TCP/IP socket. The trick of course is that all the processes are in the same process group, and the socket is opened by a shared parent. The OS somehow was managing queuing up the various calls to accept() on that socket. Since the watchdog parent / multiple child servers is a common, this was a workable solution on the versions of Linux we were using. IIRC, the OS gracefully queued several processes' calls to accept(), requiring no additional synchronization. But, even if that weren't the case, there is still the option of puting an acceptor in a parent and dispatching the client socket to available child servers. Anyhow -- The application I wrote has a watchdog process in C that opens up a server socket before forking child server processes. The children get passed the descriptor number for that server socket as an argument on their command lines. All child server processes then enter an accept loop. They all call accept() on that same, shared descriptor . Each child, btw, opened up its own "private" admin socket on a port that was an offset of the main, shared service port ( and optionally on a different interface as well ). Within a pool then processes are somewhat self-balancing -- a process only calls accept() when it's got threads available and ready to handle a reqeust. Clients, or a client load balancer, don't have to keep track of traffic or request counts between individual server processes. They also don't have to try back-end app servers individually before finding a "thread" that's free -- if any process in a pool is available, it's already sitting in accept() on that shared socket ( likely with others queued up behind it in their accept() calls). If Mongrel's suitable as an Internet-facing front-end, then there might be, for many applications, no need for a load balancing proxy. Simply fire up a pool of mongrels at port 80, and they'll sort it all out among themselves. Even for applications requiring multiple machines a scheme like this would simplify load balancer proxy configurations (100 mongrels in a pool? No problem -- all one port!) I'm sure the folks who wrote Mongrel thought of this and either tried it or rejected it beforehand for good reason. And I had the luxury of coding for just one platform. Perhaps others impose hurdles that make this impractical. But even there, isn't there the Apache model of a parent acceptor() passing client sockets to ready children? Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071023/f7c43ca1/attachment.vcf From zach at plugthegap.co.uk Tue Oct 23 21:30:55 2007 From: zach at plugthegap.co.uk (Zachary Powell) Date: Tue, 23 Oct 2007 21:30:55 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors Message-ID: In May I had problem with mongrels suddenly consuming huge cpu resources for a minute or two and then returning to normal (load average spikes up to 3.8and then back down to a regular 0.2 over the course of 5 minutes, then again 1/2 hour later. or 4 hours later, no predictable rhythm). I posted to Litespeed forums because I thought the problem was there but didn't get far. And a week later migrated hosting companies and the problem was gone. Now its returned. We make a lot of changes, but I've gone over the repo for the last few weeks and can't see anything structural that should effect it. It only happens with our main front end app (the other two are fine), but happens at all times of day(/night) so doesn't seem triggered by a heavy load. Basically a mongrel gets stuck on one or two cached files for a few minutes (but still functions fine for other requests, I can ping specific rails pages on all mongrels during this period). strace -e read,write,close produces this repeatedly the whole time (short excerpt of 1000s of lines): close(5) = -1 EBADF (Bad file descriptor) read(5, "GET /flower_delivery/florists_in_covehithe_suffolk_england_uk HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) = 473 close(5) = 0 close(5) = -1 EBADF (Bad file descriptor) read(5, "GET /flower_delivery/florists_in_rowde_wiltshire_england_uk HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/p"..., 16384) = 471 close(5) = 0 close(5) = -1 EBADF (Bad file descriptor) read(5, "GET /flower_delivery/florists_in_cove_south_suffolk_england_uk HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, imag"..., 16384) = 474 close(5) = 0 close(5) = -1 EBADF (Bad file descriptor) read(5, "GET /flower_delivery/florists_in_covehithe_suffolk_england_uk HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) = 473 close(5) = 0 close(5) = -1 EBADF (Bad file descriptor) read(5, "GET /flower_delivery/florists_in_rowde_wiltshire_england_uk HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/p"..., 16384) = 471 close(5) = 0 close(5) = -1 EBADF (Bad file descriptor) read(5, "GET /flower_delivery/florists_in_cove_south_suffolk_england_uk HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, imag"..., 16384) = 474 close(5) = 0 close(5) = -1 EBADF (Bad file descriptor) read(5, "GET /flower_delivery/florists_in_covehithe_suffolk_england_uk HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) = 473 close(5) = 0 close(5) = -1 EBADF (Bad file descriptor) read(5, "GET /flower_delivery/florists_in_rowde_wiltshire_england_uk HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/p"..., 16384) = 471 close(5) = 0 close(5) = -1 EBADF (Bad file descriptor) read(5, "GET /flower_delivery/florists_in_cove_south_suffolk_england_uk HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, imag"..., 16384) = 474 close(5) = 0 close(5) = -1 EBADF (Bad file descriptor) read(5, "GET /flower_delivery/florists_in_covehithe_suffolk_england_uk HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) = 473 close(5) = 0 close(5) = -1 EBADF (Bad file descriptor) read(5, "GET /flower_delivery/florists_in_rowde_wiltshire_england_uk HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/p"..., 16384) = 471 close(5) = 0 close(5) = -1 EBADF (Bad file descriptor) read(5, "GET /flower_delivery/florists_in_cove_south_suffolk_england_uk HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, imag"..., 16384) = 474 close(5) = 0 close(5) = -1 EBADF (Bad file descriptor) read(5, "GET /flower_delivery/florists_in_covehithe_suffolk_england_uk HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) = 473 close(5) = 0 close(5) = -1 EBADF (Bad file descriptor) the file its trying to get is page cached, and exists/is fine (can even go to url while this is going on). Could it still be a problem with Litespeed (actually requesting this file many times?). Litespeeds cpu usuage does go up during this period, but stracing it doesn't give anything useful. thanks for any tips/directions. Zach -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071023/63837d95/attachment-0001.html From evan at cloudbur.st Tue Oct 23 22:05:51 2007 From: evan at cloudbur.st (Evan Weaver) Date: Tue, 23 Oct 2007 22:05:51 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: Message-ID: What system architecture are you using? Evan On 10/23/07, Zachary Powell wrote: > In May I had problem with mongrels suddenly consuming huge cpu resources for > a minute or two and then returning to normal (load average spikes up to 3.8 > and then back down to a regular 0.2 over the course of 5 minutes, then again > 1/2 hour later. or 4 hours later, no predictable rhythm). > > > I posted to Litespeed forums because I thought the problem was there but > didn't get far. And a week later migrated hosting companies and the problem > was gone. Now its returned. We make a lot of changes, but I've gone over the > repo for the last few weeks and can't see anything structural that should > effect it. It only happens with our main front end app (the other two are > fine), but happens at all times of day(/night) so doesn't seem triggered by > a heavy load. Basically a mongrel gets stuck on one or two cached files for > a few minutes (but still functions fine for other requests, I can ping > specific rails pages on all mongrels during this period). > > > strace -e read,write,close produces this repeatedly the whole time (short > excerpt of 1000s of lines): > > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET > /flower_delivery/florists_in_covehithe_suffolk_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) > = 473 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET > /flower_delivery/florists_in_rowde_wiltshire_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/p"..., > 16384) = 471 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET > /flower_delivery/florists_in_cove_south_suffolk_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, imag"..., 16384) = > 474 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET > /flower_delivery/florists_in_covehithe_suffolk_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) > = 473 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET > /flower_delivery/florists_in_rowde_wiltshire_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/p"..., > 16384) = 471 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET > /flower_delivery/florists_in_cove_south_suffolk_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, imag"..., 16384) = > 474 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET > /flower_delivery/florists_in_covehithe_suffolk_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) > = 473 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET > /flower_delivery/florists_in_rowde_wiltshire_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/p"..., > 16384) = 471 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET > /flower_delivery/florists_in_cove_south_suffolk_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, imag"..., 16384) = > 474 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET > /flower_delivery/florists_in_covehithe_suffolk_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) > = 473 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET > /flower_delivery/florists_in_rowde_wiltshire_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/p"..., > 16384) = 471 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET > /flower_delivery/florists_in_cove_south_suffolk_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, imag"..., 16384) = > 474 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET > /flower_delivery/florists_in_covehithe_suffolk_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) > = 473 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > > > the file its trying to get is page cached, and exists/is fine (can even go > to url while this is going on). > > > Could it still be a problem with Litespeed (actually requesting this file > many times?). Litespeeds cpu usuage does go up during this period, but > stracing it doesn't give anything useful. > > thanks for any tips/directions. > > Zach > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From wayneeseguin at gmail.com Tue Oct 23 23:03:03 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Tue, 23 Oct 2007 23:03:03 -0400 Subject: [Mongrel] Shared listening sockets In-Reply-To: <471E2130.20004@robmela.com> References: <0B24FE11-B64C-4328-80DC-9E4885D8CF2C@ibexinternet.co.uk> <471E2130.20004@robmela.com> Message-ID: On 10/23/07, Robert Mela wrote: > > Several years back I accidentally discovered that multiple processes can > listen on the same TCP/IP socket. The trick of course is that all the > processes are in the same process group, and the socket is opened by a > shared parent. The OS somehow was managing queuing up the various > calls to accept() on that socket. Since the watchdog parent / multiple > child servers is a common, this was a workable solution on the versions > of Linux we were using. > > IIRC, the OS gracefully queued several processes' calls to accept(), > requiring no additional synchronization. But, even if that weren't the > case, there is still the option of puting an acceptor in a parent and > dispatching the client socket to available child servers. > > Anyhow -- > > The application I wrote has a watchdog process in C that opens up a > server socket before forking child server processes. The children get > passed the descriptor number for that server socket as an argument on > their command lines. > > All child server processes then enter an accept loop. They all call > accept() on that same, shared descriptor . Each child, btw, opened up > its own "private" admin socket on a port that was an offset of the main, > shared service port ( and optionally on a different interface as well ). > > Within a pool then processes are somewhat self-balancing -- a process > only calls accept() when it's got threads available and ready to handle > a reqeust. Clients, or a client load balancer, don't have to keep > track of traffic or request counts between individual server processes. > They also don't have to try back-end app servers individually before > finding a "thread" that's free -- if any process in a pool is > available, it's already sitting in accept() on that shared socket ( > likely with others queued up behind it in their accept() calls). > > If Mongrel's suitable as an Internet-facing front-end, then there might > be, for many applications, no need for a load balancing proxy. Simply > fire up a pool of mongrels at port 80, and they'll sort it all out among > themselves. Even for applications requiring multiple machines a scheme > like this would simplify load balancer proxy configurations (100 > mongrels in a pool? No problem -- all one port!) > > I'm sure the folks who wrote Mongrel thought of this and either tried it > or rejected it beforehand for good reason. And I had the luxury of > coding for just one platform. Perhaps others impose hurdles that make > this impractical. But even there, isn't there the Apache model of a > parent acceptor() passing client sockets to ready children? > > > Thoughts? > I believe that the main issue here is on the win32 platform, Luis? We do have something similar in the works for a future release, however I am unsure as to how your suggestion ties in at the moment. It appears to be well worth investigation for what we have planned. Thank you kindly for this, ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071023/3ad50a03/attachment.html From wayneeseguin at gmail.com Tue Oct 23 23:10:13 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Tue, 23 Oct 2007 23:10:13 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: Message-ID: On 10/23/07, Zachary Powell wrote: > > In May I had problem with mongrels suddenly consuming huge cpu resources > for a minute or two and then returning to normal (load average spikes up to > 3.8 and then back down to a regular 0.2 over the course of 5 minutes, then > again 1/2 hour later. or 4 hours later, no predictable rhythm). > > > I posted to Litespeed forums because I thought the problem was there but > didn't get far. And a week later migrated hosting companies and the problem > was gone. Now its returned. We make a lot of changes, but I've gone over the > repo for the last few weeks and can't see anything structural that should > effect it. It only happens with our main front end app (the other two are > fine), but happens at all times of day(/night) so doesn't seem triggered by > a heavy load. Basically a mongrel gets stuck on one or two cached files for > a few minutes (but still functions fine for other requests, I can ping > specific rails pages on all mongrels during this period). > > > strace -e read,write,close produces this repeatedly the whole time (short > excerpt of 1000s of lines): > > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET /flower_delivery/florists_in_covehithe_suffolk_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) > = 473 > > It appears that the file is either being prematurely closed, doesn't exist or some other file related error is occurring. Please give us the details of your setup and architecture. The first thing I would check is your open file limit. If this process is opening more files than the user it is running as is allowed to open, then the OS will begin denying the process files it tries to open. This can be caused either by bad code not closing files or perhaps your app simply has to open that many files due to application design and load. Either way, check the limit and compare to how many files the process has open at the time you see this occurring. I hope that this helps, ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071023/eea455c7/attachment.html From dave at cheney.net Tue Oct 23 23:33:52 2007 From: dave at cheney.net (Dave Cheney) Date: Wed, 24 Oct 2007 13:33:52 +1000 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: Message-ID: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> Are you using a web server in front of your mongrels ? It should be picking up the page cached file before even considering handing the request to a mongrel. Cheers Dave On 24/10/2007, at 11:30 AM, Zachary Powell wrote: > close(5) = 0 > close(5) = -1 EBADF (Bad file > descriptor) > read(5, "GET /flower_delivery/ > florists_in_covehithe_suffolk_england_uk HTTP/1.1\nAccept: image/ > gif, image/x-xbitmap, image/jpeg, image"..., 16384) = 473 > close(5) = 0 > close(5) = -1 EBADF (Bad file > descriptor) > > > the file its trying to get is page cached, and exists/is fine (can > even go to url while this is going on). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071024/a802717a/attachment.html From zach at plugthegap.co.uk Wed Oct 24 08:09:03 2007 From: zach at plugthegap.co.uk (Zachary Powell) Date: Wed, 24 Oct 2007 08:09:03 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> Message-ID: Hi Guys, I'm using latest Litespeed 3.2.4 (just upgraded), Mongrel 1.0.1, and Ruby 1.8.6, running Red Hat Enterprise Linux ES 4. We have Web/Mysql/Mail server: # RAID Configuration: RAID 1 (73GBx2) # HP Memory: 2 GB HP RAM # HP DL385 G2 Processor: Dual Socket Dual Core Opteron 2214 2.2 GHz (runs between 0.10 - 0.20, mostly MySql, but spikes up when issue occurs with litespeed taking ~30% cpu) and App Server: # RAID Configuration: RAID 1 (146GBx2) # HP Memory: 4 GB HP RAM # HP DL385 G2 Processor: Dual Socket Dual Core Opteron 2214 2.2 GHz (usually 0.20 - 0.60 with legitimate spikes up to 1.8 for backend processes. Spikes up to 2-4 when it happens, depending on how many mongrels get the problem (sometimes 2)) And these are the mongrels running: MONGREL CPU MEM VIR RES DATE TIME PID 8010:hq 3.2 3.4 145 138 Oct23 43:13 20409 8011:hq 0.6 3.0 132 125 Oct23 8:15 20412 8012:hq 0.1 1.8 81 74 Oct23 1:28 20415 8015:dhq 0.0 1.0 50 44 02:41 0:08 4775 8016:dhq 0.0 0.7 34 30 02:41 0:01 4778 8017:dhq 0.0 0.7 36 30 02:41 0:01 4781 8020:af 9.0 3.3 143 137 Oct23 114:41 26600 8021:af 5.6 2.0 90 84 Oct23 71:56 26607 8022:af 2.4 1.8 80 74 Oct23 30:37 26578 8025:daf 0.0 1.0 49 42 02:41 0:04 4842 8026:daf 0.0 0.7 34 30 02:41 0:02 4845 8027:daf 0.0 0.7 36 30 02:41 0:02 4848 8030:pr 0.1 1.5 67 61 Oct23 1:50 16528 8031:pr 0.0 0.9 47 40 Oct23 0:17 16532 8032:pr 0.0 0.9 44 38 Oct23 0:13 16536 8035:dpr 0.2 0.7 36 30 12:30 0:02 22335 8036:dpr 0.2 0.7 35 30 12:30 0:02 22338 8037:dpr 0.2 0.7 35 30 12:30 0:02 22341 (the ones starting with D are in dev mode, will try turning them off tonight, I hadn't considered this a spill over issue, but it happened just now and turning them off didn't ease it. We had alot less when the problem was occurring before, but also a 1 box set-up). Its the 8020-8022 ones that have trouble. It is indeed picking up the page cache, and while its happening I can go to one of those pages in question, or cat it in SSH with no problems. I've monitored the rails log while it was happening and haven't seen any EBADF spilling over. Though its conceivable that a spike of hits from Google crawl could cause a problem, I could try siege/ab tonight. Not familiar with checking file limits, but this is what I get from googling a command: cat /proc/sys/fs/file-nr: 2920 0 372880 ulimit -a: core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 1024 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 77823 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Will post the ls -l /proc/{mongrel.pid}/fd/, next time it happens, and see how close its getting to 1024. (Though again it seems strange that it could be having a max open problem when the other non-cached pages on that pid that are definitely opening files work fine). Thanks again, Zach On 10/23/07, Dave Cheney wrote: > > Are you using a web server in front of your mongrels ? It should be > picking up the page cached file before even considering handing the request > to a mongrel. > > Cheers > > > Dave > > On 24/10/2007, at 11:30 AM, Zachary Powell wrote: > > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > read(5, "GET /flower_delivery/florists_in_covehithe_suffolk_england_uk > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) > = 473 > close(5) = 0 > close(5) = -1 EBADF (Bad file descriptor) > > > the file its trying to get is page cached, and exists/is fine (can even go > to url while this is going on). > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071024/dc52362d/attachment-0001.html From zach at plugthegap.co.uk Wed Oct 24 09:14:58 2007 From: zach at plugthegap.co.uk (Zachary Powell) Date: Wed, 24 Oct 2007 09:14:58 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> Message-ID: Hi, short follow up. I did lsof -p 27787 | grep mongrel -c => 64 files open while it was spiking, so it doesn't look like a max file issue. Looking thorough the list, the only thing of note was mongrel_r 27787 rails 5w unknown /proc/27787/fd/5 (readlink: No such file or directory) 5 was likely the id of the file getting EBADF (usually 4-6). I didn't catch which file it was before it the problem ended (running lsof was very slow, took 20 secs while problem was occuring), but previously when I've checked its always been there and accessable from web. Also, the dir in question is full of files, so it hasn't been sweeped recently (couldn't have been cache-expiry while reading or anything weird like that). Zach On 10/24/07, Zachary Powell wrote: > > Hi Guys, > > I'm using latest Litespeed 3.2.4 (just upgraded), Mongrel 1.0.1, and Ruby > 1.8.6, running Red Hat Enterprise Linux ES 4 . We have > > > Web/Mysql/Mail server: > > # RAID Configuration: RAID 1 (73GBx2) > > # HP Memory: 2 GB HP RAM > > # HP DL385 G2 Processor: Dual Socket Dual Core Opteron 2214 2.2 GHz > > > (runs between 0.10 - 0.20, mostly MySql, but spikes up when issue occurs > with litespeed taking ~30% cpu) > > > and App Server: > > > # RAID Configuration: RAID 1 (146GBx2) > > # HP Memory: 4 GB HP RAM > > # HP DL385 G2 Processor: Dual Socket Dual Core Opteron 2214 2.2 GHz > > > (usually 0.20 - 0.60 with legitimate spikes up to 1.8 for backend > processes. Spikes up to 2-4 when it happens, depending on how many mongrels > get the problem (sometimes 2)) > > > And these are the mongrels running: > > > MONGREL CPU MEM VIR RES DATE TIME PID > 8010:hq 3.2 3.4 145 138 Oct23 43:13 20409 > 8011:hq 0.6 3.0 132 125 Oct23 8:15 20412 > 8012:hq 0.1 1.8 81 74 Oct23 1:28 20415 > 8015:dhq 0.0 1.0 50 44 02:41 0:08 4775 > 8016:dhq 0.0 0.7 34 30 02:41 0:01 4778 > 8017:dhq 0.0 0.7 36 30 02:41 0:01 4781 > 8020:af 9.0 3.3 143 137 Oct23 114:41 26600 > 8021:af 5.6 2.0 90 84 Oct23 71:56 26607 > 8022:af 2.4 1.8 80 74 Oct23 30:37 26578 > 8025:daf 0.0 1.0 49 42 02:41 0:04 4842 > 8026:daf 0.0 0.7 34 30 02:41 0:02 4845 > 8027:daf 0.0 0.7 36 30 02:41 0:02 4848 > 8030:pr 0.1 1.5 67 61 Oct23 1:50 16528 > 8031:pr 0.0 0.9 47 40 Oct23 0:17 16532 > 8032:pr 0.0 0.9 44 38 Oct23 0:13 16536 > 8035:dpr 0.2 0.7 36 30 12:30 0:02 22335 > 8036:dpr 0.2 0.7 35 30 12:30 0:02 22338 > 8037:dpr 0.2 0.7 35 30 12:30 0:02 22341 > > > (the ones starting with D are in dev mode, will try turning them off > tonight, I hadn't considered this a spill over issue, but it happened just > now and turning them off didn't ease it. We had alot less when the problem > was occurring before, but also a 1 box set-up). > > > Its the 8020-8022 ones that have trouble. It is indeed picking up the page > cache, and while its happening I can go to one of those pages in question, > or cat it in SSH with no problems. I've monitored the rails log while it was > happening and haven't seen any EBADF spilling over. Though > its conceivable that a spike of hits from Google crawl could cause a > problem, I could try siege/ab tonight. > > > Not familiar with checking file limits, but this is what I get from > googling a command: > > > cat /proc/sys/fs/file-nr: > 2920 0 372880 > > > ulimit -a: > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > file size (blocks, -f) unlimited > pending signals (-i) 1024 > max locked memory (kbytes, -l) 32 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > stack size (kbytes, -s) 10240 > cpu time (seconds, -t) unlimited > max user processes (-u) 77823 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > > > > Will post the ls -l /proc/{mongrel.pid}/fd/, next time it happens, and see > how close its getting to 1024. (Though again it seems strange that it could > be having a max open problem when the other non-cached pages on that pid > that are definitely opening files work fine). > > > Thanks again, > > > Zach > > > > On 10/23/07, Dave Cheney wrote: > > > > Are you using a web server in front of your mongrels ? It should be > > picking up the page cached file before even considering handing the request > > to a mongrel. > > > > Cheers > > > > > > Dave > > > > On 24/10/2007, at 11:30 AM, Zachary Powell wrote: > > > > close(5) = 0 > > close(5) = -1 EBADF (Bad file descriptor) > > read(5, "GET /flower_delivery/florists_in_covehithe_suffolk_england_uk > > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) > > = 473 > > close(5) = 0 > > close(5) = -1 EBADF (Bad file descriptor) > > > > > > the file its trying to get is page cached, and exists/is fine (can even > > go to url while this is going on). > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071024/5924e636/attachment.html From public at misuse.org Wed Oct 24 11:04:51 2007 From: public at misuse.org (Steve Midgley) Date: Wed, 24 Oct 2007 08:04:51 -0700 Subject: [Mongrel] Shared listening sockets In-Reply-To: References: Message-ID: <20071024150457.24A1B1858617@rubyforge.org> On 10/23/07, Robert Mela wrote: > Several years back I accidentally discovered that multiple processes can > listen on the same TCP/IP socket. The trick of course is that all the > processes are in the same process group, and the socket is opened by a > shared parent. The OS somehow was managing queuing up the various > calls to accept() on that socket. Since the watchdog parent / multiple > child servers is a common, this was a workable solution on the versions > of Linux we were using. [snip] At 05:09 AM 10/24/2007, Wayne wrote: >I believe that the main issue here is on the win32 platform, Luis? > >We do have something similar in the works for a future release, >however I am >unsure as to how your suggestion ties in at the moment. It appears to >be >well worth investigation for what we have planned. > >Thank you kindly for this, > > ~Wayne Hi, I thought I'd chime in as a Windows developer. I'm running Windows in development mode and deploying to Linux (Ezra's rig at EngineYard actually). If this idea actually works, it's super appealing for me as a simple solution to the "slow returning mongrel" load balancing challenge. (i.e. the problems where mongrels are loaded up with requests irrespective of their availability, leaving some mongrels idle and some overloaded.) I'll give you a simple example: we have to build admin tools periodically. It's possible to make these tools spin off background processes but that's more time consuming to build and debug. Since these tools are just basic admin utilities that we want to invest as little time as possible in them: their initial functionality is 95% of their overall value. So for example one of these tools lets us bulk manage photos and can take 10 seconds to return. Because of mongrel/nginx/load balance architecture, we can run into performance trouble if we aren't careful at what time of day we use the tool. You can complain about my sloppy software architecture but I'll complain that I'm running a business and need to invest most in what returns the most value to our customers. But I'd prefer to just agree not to start that discussion. [smile] If I understand what's being discussed (not a given) the system Robert is proposing would mean that a mongrel would only get requests from port 80 when it was ready to call "receive()" again from the IP stack. So mongrels would consume what they can off a common stack. This would mean that I don't have to balance all my Rails processes to keep them returning results at roughly equal intervals. If my servers are heavily loaded now, it seems like a slow returning mongrel can cause havoc even if it's just slow by a couple of seconds.. So given the mongrels a common pool of requests to consume from and using such a low level pool such as an IP port seems great, and I'd vote for it. The fact that my development box doesn't run against the same code is totally ok. I'm sure Windows people who run in production will have other opinions but this idea, if it's practical, seems very elegant and useful. +1 Steve From jjhogue at sbcglobal.net Wed Oct 24 11:07:52 2007 From: jjhogue at sbcglobal.net (Jim Hogue) Date: Wed, 24 Oct 2007 11:07:52 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> Message-ID: <005801c8164f$a67b8740$0400a8c0@DEN2> Assuming you have access to a root shell on your hosting service, then when you are watching a slow system, you can start up a root shell and renice that shell to a value of -1. This will give the shell a higher priority and your command will be much quicker. For example. bash #: su Password: root #: ps PID TTY TIME CMD 1443 pts/2 00:00:00 bash 1447 pts/2 00:00:00 ps root #: renice -1 1443 root #: suspend bash #: Use the suspend to leave the root job around and then foreground it when you have the problem and use it. If you don't have a root shell, but have sudo, then use sudo nice -1 ps of -p 27787 etc. - Jim Hogue ----- Original Message ----- From: "Zachary Powell" Cc: Sent: Wednesday, October 24, 2007 9:14 AM Subject: Re: [Mongrel] random cpu spikes, EBADF errors > Hi, short follow up. I did > lsof -p 27787 | grep mongrel -c > => 64 files open > > while it was spiking, so it doesn't look like a max file issue. > Looking > thorough the list, the only thing of note was > > mongrel_r 27787 rails 5w unknown > /proc/27787/fd/5 (readlink: No such file or directory) > > 5 was likely the id of the file getting EBADF (usually 4-6). I > didn't catch > which file it was before it the problem ended (running lsof was very > slow, > took 20 secs while problem was occuring), but previously when I've > checked > its always been there and accessable from web. Also, the dir in > question is > full of files, so it hasn't been sweeped recently (couldn't have > been > cache-expiry while reading or anything weird like that). > > Zach > > > > On 10/24/07, Zachary Powell wrote: >> >> Hi Guys, >> >> I'm using latest Litespeed 3.2.4 (just upgraded), Mongrel 1.0.1, >> and Ruby >> 1.8.6, running Red Hat Enterprise Linux ES 4 . We have >> >> >> Web/Mysql/Mail server: >> >> # RAID Configuration: RAID 1 (73GBx2) >> >> # HP Memory: 2 GB HP RAM >> >> # HP DL385 G2 Processor: Dual Socket Dual Core Opteron 2214 2.2 GHz >> >> >> (runs between 0.10 - 0.20, mostly MySql, but spikes up when issue >> occurs >> with litespeed taking ~30% cpu) >> >> >> and App Server: >> >> >> # RAID Configuration: RAID 1 (146GBx2) >> >> # HP Memory: 4 GB HP RAM >> >> # HP DL385 G2 Processor: Dual Socket Dual Core Opteron 2214 2.2 GHz >> >> >> (usually 0.20 - 0.60 with legitimate spikes up to 1.8 for backend >> processes. Spikes up to 2-4 when it happens, depending on how many >> mongrels >> get the problem (sometimes 2)) >> >> >> And these are the mongrels running: >> >> >> MONGREL CPU MEM VIR RES DATE TIME PID >> 8010:hq 3.2 3.4 145 138 Oct23 43:13 20409 >> 8011:hq 0.6 3.0 132 125 Oct23 8:15 20412 >> 8012:hq 0.1 1.8 81 74 Oct23 1:28 20415 >> 8015:dhq 0.0 1.0 50 44 02:41 0:08 4775 >> 8016:dhq 0.0 0.7 34 30 02:41 0:01 4778 >> 8017:dhq 0.0 0.7 36 30 02:41 0:01 4781 >> 8020:af 9.0 3.3 143 137 Oct23 114:41 26600 >> 8021:af 5.6 2.0 90 84 Oct23 71:56 26607 >> 8022:af 2.4 1.8 80 74 Oct23 30:37 26578 >> 8025:daf 0.0 1.0 49 42 02:41 0:04 4842 >> 8026:daf 0.0 0.7 34 30 02:41 0:02 4845 >> 8027:daf 0.0 0.7 36 30 02:41 0:02 4848 >> 8030:pr 0.1 1.5 67 61 Oct23 1:50 16528 >> 8031:pr 0.0 0.9 47 40 Oct23 0:17 16532 >> 8032:pr 0.0 0.9 44 38 Oct23 0:13 16536 >> 8035:dpr 0.2 0.7 36 30 12:30 0:02 22335 >> 8036:dpr 0.2 0.7 35 30 12:30 0:02 22338 >> 8037:dpr 0.2 0.7 35 30 12:30 0:02 22341 >> >> >> (the ones starting with D are in dev mode, will try turning them >> off >> tonight, I hadn't considered this a spill over issue, but it >> happened just >> now and turning them off didn't ease it. We had alot less when the >> problem >> was occurring before, but also a 1 box set-up). >> >> >> Its the 8020-8022 ones that have trouble. It is indeed picking up >> the page >> cache, and while its happening I can go to one of those pages in >> question, >> or cat it in SSH with no problems. I've monitored the rails log >> while it was >> happening and haven't seen any EBADF spilling over. Though >> its conceivable that a spike of hits from Google crawl could cause >> a >> problem, I could try siege/ab tonight. >> >> >> Not familiar with checking file limits, but this is what I get from >> googling a command: >> >> >> cat /proc/sys/fs/file-nr: >> 2920 0 372880 >> >> >> ulimit -a: >> core file size (blocks, -c) 0 >> data seg size (kbytes, -d) unlimited >> file size (blocks, -f) unlimited >> pending signals (-i) 1024 >> max locked memory (kbytes, -l) 32 >> max memory size (kbytes, -m) unlimited >> open files (-n) 1024 >> pipe size (512 bytes, -p) 8 >> POSIX message queues (bytes, -q) 819200 >> stack size (kbytes, -s) 10240 >> cpu time (seconds, -t) unlimited >> max user processes (-u) 77823 >> virtual memory (kbytes, -v) unlimited >> file locks (-x) unlimited >> >> >> >> >> Will post the ls -l /proc/{mongrel.pid}/fd/, next time it happens, >> and see >> how close its getting to 1024. (Though again it seems strange that >> it could >> be having a max open problem when the other non-cached pages on >> that pid >> that are definitely opening files work fine). >> >> >> Thanks again, >> >> >> Zach >> >> >> >> On 10/23/07, Dave Cheney wrote: >> > >> > Are you using a web server in front of your mongrels ? It should >> > be >> > picking up the page cached file before even considering handing >> > the request >> > to a mongrel. >> > >> > Cheers >> > >> > >> > Dave >> > >> > On 24/10/2007, at 11:30 AM, Zachary Powell wrote: >> > >> > close(5) = 0 >> > close(5) = -1 EBADF (Bad file >> > descriptor) >> > read(5, "GET >> > /flower_delivery/florists_in_covehithe_suffolk_england_uk >> > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, >> > image"..., 16384) >> > = 473 >> > close(5) = 0 >> > close(5) = -1 EBADF (Bad file >> > descriptor) >> > >> > >> > the file its trying to get is page cached, and exists/is fine >> > (can even >> > go to url while this is going on). >> > >> > >> > >> > >> > >> > >> >> >> > -------------------------------------------------------------------------------- > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From jjhogue at sbcglobal.net Wed Oct 24 11:21:59 2007 From: jjhogue at sbcglobal.net (Jim Hogue) Date: Wed, 24 Oct 2007 11:21:59 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <005801c8164f$a67b8740$0400a8c0@DEN2> Message-ID: <007f01c81651$9f912230$0400a8c0@DEN2> Whoops, that nice command needs a --1 as in sudo nice --1 ps of -p 27787 - Jim ----- Original Message ----- From: "Jim Hogue" To: ; Sent: Wednesday, October 24, 2007 11:07 AM Subject: Re: [Mongrel] random cpu spikes, EBADF errors > Assuming you have access to a root shell on your hosting service, > then > when you are watching a slow system, you can start up a root shell > and > renice that shell to a value of -1. This will give the shell a > higher > priority and your command will be much quicker. For example. > > bash #: su > Password: > root #: ps > PID TTY TIME CMD > 1443 pts/2 00:00:00 bash > 1447 pts/2 00:00:00 ps > root #: renice -1 1443 > root #: suspend > bash #: > > Use the suspend to leave the root job around and then foreground it > when you have the problem and use it. > > If you don't have a root shell, but have sudo, then use > > sudo nice -1 ps of -p 27787 > etc. > > - Jim Hogue > > ----- Original Message ----- > From: "Zachary Powell" > Cc: > Sent: Wednesday, October 24, 2007 9:14 AM > Subject: Re: [Mongrel] random cpu spikes, EBADF errors > > >> Hi, short follow up. I did >> lsof -p 27787 | grep mongrel -c >> => 64 files open >> >> while it was spiking, so it doesn't look like a max file issue. >> Looking >> thorough the list, the only thing of note was >> >> mongrel_r 27787 rails 5w unknown >> /proc/27787/fd/5 (readlink: No such file or directory) >> >> 5 was likely the id of the file getting EBADF (usually 4-6). I >> didn't catch >> which file it was before it the problem ended (running lsof was >> very >> slow, >> took 20 secs while problem was occuring), but previously when I've >> checked >> its always been there and accessable from web. Also, the dir in >> question is >> full of files, so it hasn't been sweeped recently (couldn't have >> been >> cache-expiry while reading or anything weird like that). >> >> Zach >> >> >> >> On 10/24/07, Zachary Powell wrote: >>> >>> Hi Guys, >>> >>> I'm using latest Litespeed 3.2.4 (just upgraded), Mongrel 1.0.1, >>> and Ruby >>> 1.8.6, running Red Hat Enterprise Linux ES 4 . We have >>> >>> >>> Web/Mysql/Mail server: >>> >>> # RAID Configuration: RAID 1 (73GBx2) >>> >>> # HP Memory: 2 GB HP RAM >>> >>> # HP DL385 G2 Processor: Dual Socket Dual Core Opteron 2214 2.2 >>> GHz >>> >>> >>> (runs between 0.10 - 0.20, mostly MySql, but spikes up when issue >>> occurs >>> with litespeed taking ~30% cpu) >>> >>> >>> and App Server: >>> >>> >>> # RAID Configuration: RAID 1 (146GBx2) >>> >>> # HP Memory: 4 GB HP RAM >>> >>> # HP DL385 G2 Processor: Dual Socket Dual Core Opteron 2214 2.2 >>> GHz >>> >>> >>> (usually 0.20 - 0.60 with legitimate spikes up to 1.8 for backend >>> processes. Spikes up to 2-4 when it happens, depending on how many >>> mongrels >>> get the problem (sometimes 2)) >>> >>> >>> And these are the mongrels running: >>> >>> >>> MONGREL CPU MEM VIR RES DATE TIME PID >>> 8010:hq 3.2 3.4 145 138 Oct23 43:13 20409 >>> 8011:hq 0.6 3.0 132 125 Oct23 8:15 20412 >>> 8012:hq 0.1 1.8 81 74 Oct23 1:28 20415 >>> 8015:dhq 0.0 1.0 50 44 02:41 0:08 4775 >>> 8016:dhq 0.0 0.7 34 30 02:41 0:01 4778 >>> 8017:dhq 0.0 0.7 36 30 02:41 0:01 4781 >>> 8020:af 9.0 3.3 143 137 Oct23 114:41 26600 >>> 8021:af 5.6 2.0 90 84 Oct23 71:56 26607 >>> 8022:af 2.4 1.8 80 74 Oct23 30:37 26578 >>> 8025:daf 0.0 1.0 49 42 02:41 0:04 4842 >>> 8026:daf 0.0 0.7 34 30 02:41 0:02 4845 >>> 8027:daf 0.0 0.7 36 30 02:41 0:02 4848 >>> 8030:pr 0.1 1.5 67 61 Oct23 1:50 16528 >>> 8031:pr 0.0 0.9 47 40 Oct23 0:17 16532 >>> 8032:pr 0.0 0.9 44 38 Oct23 0:13 16536 >>> 8035:dpr 0.2 0.7 36 30 12:30 0:02 22335 >>> 8036:dpr 0.2 0.7 35 30 12:30 0:02 22338 >>> 8037:dpr 0.2 0.7 35 30 12:30 0:02 22341 >>> >>> >>> (the ones starting with D are in dev mode, will try turning them >>> off >>> tonight, I hadn't considered this a spill over issue, but it >>> happened just >>> now and turning them off didn't ease it. We had alot less when the >>> problem >>> was occurring before, but also a 1 box set-up). >>> >>> >>> Its the 8020-8022 ones that have trouble. It is indeed picking up >>> the page >>> cache, and while its happening I can go to one of those pages in >>> question, >>> or cat it in SSH with no problems. I've monitored the rails log >>> while it was >>> happening and haven't seen any EBADF spilling over. Though >>> its conceivable that a spike of hits from Google crawl could cause >>> a >>> problem, I could try siege/ab tonight. >>> >>> >>> Not familiar with checking file limits, but this is what I get >>> from >>> googling a command: >>> >>> >>> cat /proc/sys/fs/file-nr: >>> 2920 0 372880 >>> >>> >>> ulimit -a: >>> core file size (blocks, -c) 0 >>> data seg size (kbytes, -d) unlimited >>> file size (blocks, -f) unlimited >>> pending signals (-i) 1024 >>> max locked memory (kbytes, -l) 32 >>> max memory size (kbytes, -m) unlimited >>> open files (-n) 1024 >>> pipe size (512 bytes, -p) 8 >>> POSIX message queues (bytes, -q) 819200 >>> stack size (kbytes, -s) 10240 >>> cpu time (seconds, -t) unlimited >>> max user processes (-u) 77823 >>> virtual memory (kbytes, -v) unlimited >>> file locks (-x) unlimited >>> >>> >>> >>> >>> Will post the ls -l /proc/{mongrel.pid}/fd/, next time it happens, >>> and see >>> how close its getting to 1024. (Though again it seems strange that >>> it could >>> be having a max open problem when the other non-cached pages on >>> that pid >>> that are definitely opening files work fine). >>> >>> >>> Thanks again, >>> >>> >>> Zach >>> >>> >>> >>> On 10/23/07, Dave Cheney wrote: >>> > >>> > Are you using a web server in front of your mongrels ? It should >>> > be >>> > picking up the page cached file before even considering handing >>> > the request >>> > to a mongrel. >>> > >>> > Cheers >>> > >>> > >>> > Dave >>> > >>> > On 24/10/2007, at 11:30 AM, Zachary Powell wrote: >>> > >>> > close(5) = 0 >>> > close(5) = -1 EBADF (Bad file >>> > descriptor) >>> > read(5, "GET >>> > /flower_delivery/florists_in_covehithe_suffolk_england_uk >>> > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, >>> > image"..., 16384) >>> > = 473 >>> > close(5) = 0 >>> > close(5) = -1 EBADF (Bad file >>> > descriptor) >>> > >>> > >>> > the file its trying to get is page cached, and exists/is fine >>> > (can even >>> > go to url while this is going on). >>> > >>> > >>> > >>> > >>> > >>> > >>> >>> >>> >> > > > -------------------------------------------------------------------------------- > > >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From rob at robmela.com Wed Oct 24 12:00:11 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 24 Oct 2007 12:00:11 -0400 Subject: [Mongrel] Shared listening sockets In-Reply-To: <20071024150457.24A1B1858617@rubyforge.org> References: <20071024150457.24A1B1858617@rubyforge.org> Message-ID: <471F6C0B.6030200@robmela.com> Steve Midgley wrote: > > Hi, > > I thought I'd chime in as a Windows developer. I'm running Windows in > development mode and deploying to Linux (Ezra's rig at EngineYard > actually). > > If this idea actually works, it's super appealing for me as a simple > solution to the "slow returning mongrel" load balancing challenge. > (i.e. the problems where mongrels are loaded up with requests > irrespective of their availability, leaving some mongrels idle and some > overloaded.) > > If you are using mod_proxy_balancer then I'm fairly sure that "the slow returning mongrel" challenge has been solved using "max" and "acquire" parameters to BalancerMember. It's working for me, and I tested using a pool of Nitro servers using controller method that sleeps. I was hoping that Rafael G. would report back with his results on this with is issue ( though with "conn refused" I think his issue may be a little different ). Here's the product of my devinations and experiments: # no trailing slash BalancerMember http://192.168.10.10:10000 keepalive=on max=1 lbset=0 acquire=1 timeout=1 BalancerMember http://192.168.10.10:10001 keepalive=on max=1 lbset=1 acquire=1 timeout=1 BalancerMember http://192.168.10.10:10002 keepalive=on max=1 lbset=0 acquire=1 timeout=1 > If I understand what's being discussed (not a given) the system Robert > is proposing would mean that a mongrel would only get requests from > port 80 when it was ready to call "receive()" again from the IP stack. > So mongrels would consume what they can off a common stack. > > Yes. Minor nit -- each process is in an accept() loop. Accept a connection, process the request (it's in processing that the read occurs). After processing and then closing the socket to the client, enter accept() to wait for another request. > This would mean that I don't have to balance all my Rails processes to > keep them returning results at roughly equal intervals. If my servers > are heavily loaded now, it seems like a slow returning mongrel can > cause havoc even if it's just slow by a couple of seconds.. > > Servers within the pool would auto-balance. You'd still have to balance across pools if they're running on multiple hosts. But even so, yes, this is an improvement. Swiftiply as I understand it also addresses the Mongrel/Rails request queuing problem -- I haven't researched it yet. The max/acquire settings are working for us, and I experimented with a sleeping controller method to verify that it works. > So given the mongrels a common pool of requests to consume from and > using such a low level pool such as an IP port seems great, and I'd > vote for it. The fact that my development box doesn't run against the > same code is totally ok. > > Is there a cheap or demo version of Visual Studio I could try this on? I've got XP Home Edition running under VMWare, and could code a simple test to see if this works there. While I'm at it, I could verify that this works on Mac OSX as well.. > I'm sure Windows people who run in production will have other opinions > but this idea, if it's practical, seems very elegant and useful. +1 > > Steve > > It may be a horrendous hack for reasons I'm unaware of. But it worked, and in a pretty demanding scenario, essentially unchanged for eight years and counting ( ZDNet, then CNET ad servers ) so I didn't research it too deeply. I looked for problems like immediate error returns from accept(), deadlocks, delays with growing queues of accept() callers, but didn't find any. I keep meaning to read through Linux' TCP/IP stack to find out why it was so. Maybe there's a non-standard quirk in there that makes it all just dumb luck... darn... now I need to know... > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071024/cc998c48/attachment.vcf From rob at robmela.com Wed Oct 24 22:17:43 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 24 Oct 2007 22:17:43 -0400 Subject: [Mongrel] Shared listening sockets In-Reply-To: <20071024150457.24A1B1858617@rubyforge.org> References: <20071024150457.24A1B1858617@rubyforge.org> Message-ID: <471FFCC7.9000208@robmela.com> Steve Midgley wrote: > Hi, > > I thought I'd chime in as a Windows developer. I'm running Windows in > development mode and deploying to Linux (Ezra's rig at EngineYard > actually). > > If this idea actually works, it's super appealing for me as a simple > solution to the "slow returning mongrel" load balancing challenge. > (i.e. the problems where mongrels are loaded up with requests > irrespective of their availability, leaving some mongrels idle and some > overloaded.) > I found out why it works on Linux 2.6.20. In net/ipv4/tcp_ipv4.c accept is mapped to inet_csk_accept in net/ipv4/inet_connection_sock.c. That csk accept calls inet_csk_wait_for_connect to wait for a connection. That wait for connect function locks the socket so that if multiple processes are calling accept() on that socket, only one process at a time will be awaken when a connection request arrives. This wil require some change in Mongrel's request loop. Mongrel currently reenters accept even if it's got a worker locking Rails. If Mongrels in the pool are calling accept while still locking Rals then we're right back to square one, request queing. Mongrel would need to either poll for worker list length == 0 before calling accept, or have a "single-worker" mode in which it joins a worker thread as soon as it's started, and only calls accept() after returning from that join. -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071024/489dfca1/attachment.vcf From clifford.heath at gmail.com Wed Oct 24 23:03:30 2007 From: clifford.heath at gmail.com (Clifford Heath) Date: Thu, 25 Oct 2007 13:03:30 +1000 Subject: [Mongrel] Patch for X-SendFile on Windows Message-ID: A new TRAC entry with patch has been added (initially for Camping) to allow X-SendFile on Windows to use DirHandler to send files on drives other than the current drive, if the DirHandler base path is "/" (which is the way Camping uses DirHandler). As it was, "/" gets expanded to "C:/", and then you can't serve files on any other drive, which I needed to do recently. And, in fact, you can't serve any files with absolute paths, because the C:/ gets prepended to your path, giving C:/C:/path/to/my/file... broken :-). It's about four lines of changed code - see the TRAC entry for the patch: Clifford Heath, Data Constellation. From wayneeseguin at gmail.com Thu Oct 25 17:08:17 2007 From: wayneeseguin at gmail.com (Wayne E. Seguin) Date: Thu, 25 Oct 2007 17:08:17 -0400 Subject: [Mongrel] Patch for X-SendFile on Windows In-Reply-To: References: Message-ID: On 10/24/07, Clifford Heath wrote: > > A new TRAC entry with patch has been added (initially for Camping) > to allow X-SendFile on Windows to use DirHandler to send files on > drives other than the current drive, if the DirHandler base path is "/" > (which is the way Camping uses DirHandler). > > As it was, "/" gets expanded to "C:/", and then you can't serve files > on any other drive, which I needed to do recently. And, in fact, you > can't serve any files with absolute paths, because the C:/ gets > prepended to your path, giving C:/C:/path/to/my/file... broken :-). > > It's about four lines of changed code - see the TRAC entry for the > patch: > func=detail&aid=15009&group_id=1306&atid=5145> > > Clifford Heath, Data Constellation.' Thank you for the patch Clifford, we will review as soon as possible. Thanks again, ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071025/855a2a59/attachment.html From evan at cloudbur.st Thu Oct 25 17:18:25 2007 From: evan at cloudbur.st (Evan Weaver) Date: Thu, 25 Oct 2007 17:18:25 -0400 Subject: [Mongrel] Patch for X-SendFile on Windows In-Reply-To: References: Message-ID: I'm already on it. Evan On 10/25/07, Wayne E. Seguin wrote: > On 10/24/07, Clifford Heath wrote: > > A new TRAC entry with patch has been added (initially for Camping) > > to allow X-SendFile on Windows to use DirHandler to send files on > > drives other than the current drive, if the DirHandler base path is "/" > > (which is the way Camping uses DirHandler). > > > > As it was, "/" gets expanded to "C:/", and then you can't serve files > > on any other drive, which I needed to do recently. And, in fact, you > > can't serve any files with absolute paths, because the C:/ gets > > prepended to your path, giving C:/C:/path/to/my/file... broken :-). > > > > It's about four lines of changed code - see the TRAC entry for the > > patch: > > > func=detail&aid=15009&group_id=1306&atid=5145> > > > > Clifford Heath, Data Constellation.' > > Thank you for the patch Clifford, we will review as soon as possible. > > Thanks again, > ~Wayne > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From gwcoffey at gmail.com Thu Oct 25 22:48:39 2007 From: gwcoffey at gmail.com (Geoff Coffey) Date: Thu, 25 Oct 2007 19:48:39 -0700 Subject: [Mongrel] --prefix, url_for and image_tag Message-ID: <1D59A42D-7F69-4A77-A952-5C39F41A339A@gmail.com> First time here, so I hope this isn't a FAQ (although I did check *the* faq). I'm using mongrel_cluster with --prefix, and it is very slick. Thanks for that. But I had one problem. At one point in my little app, I have something like this: image_tag(url_for(:action => 'picture', :id => 1), :size => "160x200") In this scenario, the modified prefix behavior causes the prefix to be added twice. I get this output: http://mysite/my-prefix/my-prefix/picture/1 I may be doing this wrong. It does work properly without --prefix in the mix, and i can see how both these methods might add the prefix, causing this problem. Is this a bug? Known problem? Limitation of -- prefix? Or just a confused poster? Thanks! Geoff ? Geoff Coffey | 602.384.1804 9 Tips for FileMaker 9 http://sixfriedrice.com/wp/category/filemaker-9-tips/ From jgeiger at gmail.com Fri Oct 26 09:22:03 2007 From: jgeiger at gmail.com (Joey Geiger) Date: Fri, 26 Oct 2007 08:22:03 -0500 Subject: [Mongrel] --prefix, url_for and image_tag In-Reply-To: <1D59A42D-7F69-4A77-A952-5C39F41A339A@gmail.com> References: <1D59A42D-7F69-4A77-A952-5C39F41A339A@gmail.com> Message-ID: <466af3440710260622t10195112w43f8e29ecca6a67e@mail.gmail.com> I had to modify image_tag and add in a "nostrip" attribute. If there's a better way, please post it up. def image_tag(source, options = {}) options.symbolize_keys! source = source+".png" unless source =~ /\.[gif|jpg|png]/ if options.has_key?(:nostrip) options[:src] = image_path(source) else options[:src] = image_path(source).gsub(/\/myPrefix/,'') end options[:alt] ||= File.basename(options[:src], '.*').split('.').first.capitalize if options[:size] options[:width], options[:height] = options[:size].split("x") options.delete :size end tag("img", options) end On 10/25/07, Geoff Coffey wrote: > First time here, so I hope this isn't a FAQ (although I did check > *the* faq). > > I'm using mongrel_cluster with --prefix, and it is very slick. Thanks > for that. But I had one problem. At one point in my little app, I > have something like this: > > image_tag(url_for(:action => 'picture', :id => 1), :size => > "160x200") > > In this scenario, the modified prefix behavior causes the prefix to > be added twice. I get this output: > > http://mysite/my-prefix/my-prefix/picture/1 > > I may be doing this wrong. It does work properly without --prefix in > the mix, and i can see how both these methods might add the prefix, > causing this problem. Is this a bug? Known problem? Limitation of -- > prefix? Or just a confused poster? > > Thanks! > > Geoff > > > ? > Geoff Coffey | 602.384.1804 > 9 Tips for FileMaker 9 > http://sixfriedrice.com/wp/category/filemaker-9-tips/ > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From gwcoffey at gmail.com Fri Oct 26 11:27:03 2007 From: gwcoffey at gmail.com (Geoff Coffey) Date: Fri, 26 Oct 2007 08:27:03 -0700 Subject: [Mongrel] --prefix, url_for and image_tag In-Reply-To: <466af3440710260622t10195112w43f8e29ecca6a67e@mail.gmail.com> References: <1D59A42D-7F69-4A77-A952-5C39F41A339A@gmail.com> <466af3440710260622t10195112w43f8e29ecca6a67e@mail.gmail.com> Message-ID: <7EFF2A55-2277-41DD-B4BA-02E7B4DF0DFB@gmail.com> On Oct 26, 2007, at 6:22 AM, Joey Geiger wrote: > I had to modify image_tag and add in a "nostrip" attribute. If there's > a better way, please post it up. Would it be reasonable to check if source already begins with the prefix, and not prepend it in that case? I realize this would fail in some rare cases, but my guess is it would be the *right* behavior a majority of the time, and when it isn't you could work around it, perhaps with a "force" attribute or something similar, or simply by hard-coding the url. As it is now, you need a workaround for a typical case. With this change, I think you would need a workaround for an atypical case. Does that make sense? I can patch it if there's some consensus that it would be a worthwhile patch. Thanks! Geoff ? Geoff Coffey | 602.384.1804 9 Tips for FileMaker 9 http://sixfriedrice.com/wp/category/filemaker-9-tips/ From jgeiger at gmail.com Fri Oct 26 12:21:05 2007 From: jgeiger at gmail.com (Joey Geiger) Date: Fri, 26 Oct 2007 11:21:05 -0500 Subject: [Mongrel] --prefix, url_for and image_tag In-Reply-To: <7EFF2A55-2277-41DD-B4BA-02E7B4DF0DFB@gmail.com> References: <1D59A42D-7F69-4A77-A952-5C39F41A339A@gmail.com> <466af3440710260622t10195112w43f8e29ecca6a67e@mail.gmail.com> <7EFF2A55-2277-41DD-B4BA-02E7B4DF0DFB@gmail.com> Message-ID: <466af3440710260921p59413f8t42c795531bc690e4@mail.gmail.com> actually I thought this was on a different list. My solution solves a rails issue that I had, and isn't really meant for mongrel specifically, so as I said, there may be something better. I was actually fixing the rails problem of using the incorrect path since my rails application is tacked onto an existing server. I needed to serve images from within the rails app and from the root of the server using image_tag, which my solution allows. # Enable serving of images, stylesheets, and javascripts from an asset server config.action_controller.asset_host = "http://dev.website.com" On 10/26/07, Geoff Coffey wrote: > On Oct 26, 2007, at 6:22 AM, Joey Geiger wrote: > > > I had to modify image_tag and add in a "nostrip" attribute. If there's > > a better way, please post it up. > > Would it be reasonable to check if source already begins with the > prefix, and not prepend it in that case? I realize this would fail in > some rare cases, but my guess is it would be the *right* behavior a > majority of the time, and when it isn't you could work around it, > perhaps with a "force" attribute or something similar, or simply by > hard-coding the url. > > As it is now, you need a workaround for a typical case. With this > change, I think you would need a workaround for an atypical case. > > Does that make sense? I can patch it if there's some consensus that > it would be a worthwhile patch. > > Thanks! > > Geoff > > ? > Geoff Coffey | 602.384.1804 > 9 Tips for FileMaker 9 > http://sixfriedrice.com/wp/category/filemaker-9-tips/ > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From lists at ruby-forum.com Fri Oct 26 12:35:24 2007 From: lists at ruby-forum.com (Advait Bellur) Date: Fri, 26 Oct 2007 18:35:24 +0200 Subject: [Mongrel] Working or mongrel Message-ID: <33dc4eaefc8d5500f7afd96918c14ed0@ruby-forum.com> Hello, I have started newly working on ruby on rails platform and making use of mongrel server.......I would like to know how does mongrel communicate with seagull database. I could not find any reverent links only for mongrel or the combined ..... Kindly do help me Thank You Advait -- Posted via http://www.ruby-forum.com/. From wyhaines at gmail.com Fri Oct 26 12:48:03 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Fri, 26 Oct 2007 09:48:03 -0700 Subject: [Mongrel] Working or mongrel In-Reply-To: <33dc4eaefc8d5500f7afd96918c14ed0@ruby-forum.com> References: <33dc4eaefc8d5500f7afd96918c14ed0@ruby-forum.com> Message-ID: On 10/26/07, Advait Bellur wrote: > Hello, > > I have started newly working on ruby on rails platform and making use of > mongrel server.......I would like to know how does mongrel communicate > with seagull database. Mongrel provides the application container for your Rails application. It receives an HTTP request, parses it, and passes that parsed request into the Mongrel handler that invokes Rails. Your application does whatever it does, and then Rails, via its Mongrel handler, passes a response back to Mongrel. Mongrel generates an HTTP response and sends it back to the browser. Mongrel doesn't do anything with databases. That is the purview of your application. Check with an appropriate Rails forum to see if anyone knows how to use Seagull with a Rails app. Kirk Haines From andrew at geni.com Fri Oct 26 20:24:35 2007 From: andrew at geni.com (Andrew Arrow) Date: Fri, 26 Oct 2007 17:24:35 -0700 Subject: [Mongrel] load balancers and mongrel Message-ID: <2D13ADB7-4128-4665-B285-7DF21AFF5E16@geni.com> We have a load balancer sending requests to one of X boxes and one of N mongrel processes on that box. Since each mongrel processes is multi-threaded but it has a mutex around the section that calls rails, we end up with several requests queued up waiting when they could have gone to another box with a free process. For example, boxA, and boxB. boxA has mongrels 1 through 10 boxB has mongrels 11 through 20 Load balancer sends a request to boxA mongrel 5. Load balancer sends a request to boxB mongrel 12. Load balancer sends a request to boxA mongrel 5 again. It has to wait for the 1st request still running on boxA mongrel 5. How can we help the load balancer know it should have sent the request to any number of other free mongrels vs. queuing up threads that have to wait? Thanks. From luislavena at gmail.com Fri Oct 26 20:46:59 2007 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 26 Oct 2007 21:46:59 -0300 Subject: [Mongrel] load balancers and mongrel In-Reply-To: <2D13ADB7-4128-4665-B285-7DF21AFF5E16@geni.com> References: <2D13ADB7-4128-4665-B285-7DF21AFF5E16@geni.com> Message-ID: <71166b3b0710261746q12cb7eal8499315877233046@mail.gmail.com> On 10/26/07, Andrew Arrow wrote: > We have a load balancer sending requests to one of X boxes and one of > N mongrel processes on that box. > > Since each mongrel processes is multi-threaded but it has a mutex > around the section that calls rails, we end up with several requests > queued up waiting when they could have gone to another box with a > free process. > > For example, boxA, and boxB. > > boxA has mongrels 1 through 10 > boxB has mongrels 11 through 20 > > Load balancer sends a request to boxA mongrel 5. > Load balancer sends a request to boxB mongrel 12. > Load balancer sends a request to boxA mongrel 5 again. > It has to wait for the 1st request still running on boxA mongrel 5. > > How can we help the load balancer know it should have sent the > request to any number of other free mongrels vs. queuing up threads > that have to wait? > That's the bad logic of your balancer. If it's a hardware one, check if there are some algorithms you can tweak. For a software-based one, check the configuration file if there is some param about spreading / distributing the requests. Also, could be helpful if you mix the box A and box B list of members for the cluster: A: 192.168.0.15 B: 192.168.0.16 A-mongrel1 B-mongrel11 A-mongrel2 B-mongrel12 etc... -- 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 From rob at robmela.com Fri Oct 26 21:53:32 2007 From: rob at robmela.com (Robert Mela) Date: Fri, 26 Oct 2007 21:53:32 -0400 Subject: [Mongrel] load balancers and mongrel In-Reply-To: <2D13ADB7-4128-4665-B285-7DF21AFF5E16@geni.com> References: <2D13ADB7-4128-4665-B285-7DF21AFF5E16@geni.com> Message-ID: <47229A1C.9070506@robmela.com> You're coming in just after a discussion about this -- the problem of request queuing in Mongrel. It occurs when a round-robin style load balancer cycles back to a Mongrel that still hasn't finished processing the request that the load balancer had sent in its previous cycle through the pool. If you're running Apache's mod_proxy_balancer then see this: http://rubyforge.org/pipermail/mongrel-users/2007-October/004145.html and a correction here: http://rubyforge.org/pipermail/mongrel-users/2007-October/004146.html Andrew Arrow wrote: > We have a load balancer sending requests to one of X boxes and one of > N mongrel processes on that box. > > Since each mongrel processes is multi-threaded but it has a mutex > around the section that calls rails, we end up with several requests > queued up waiting when they could have gone to another box with a > free process. > > For example, boxA, and boxB. > > boxA has mongrels 1 through 10 > boxB has mongrels 11 through 20 > > Load balancer sends a request to boxA mongrel 5. > Load balancer sends a request to boxB mongrel 12. > Load balancer sends a request to boxA mongrel 5 again. > It has to wait for the 1st request still running on boxA mongrel 5. > > How can we help the load balancer know it should have sent the > request to any number of other free mongrels vs. queuing up threads > that have to wait? > > Thanks. > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071026/c3b5ffcd/attachment.vcf From lists at ruby-forum.com Sat Oct 27 08:40:03 2007 From: lists at ruby-forum.com (Luca Reghellin) Date: Sat, 27 Oct 2007 14:40:03 +0200 Subject: [Mongrel] problems with 'localization simplified' Message-ID: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> Hi you all! I've got Mongrel saying this when I use the localization simplified plug-in: any idea? ** Loading any Rails specific GemPlugins Exiting /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:92:in `load_specification': /Users/stratboy/Documents/05_SAMPLES/RAILS/newser/vendor/plugins/l10n-simplified-0.8/lib/localization_simplified.rb:13:in `gsub!': can't convert nil into String (TypeError) from /Users/stratboy/Documents/05_SAMPLES/RAILS/newser/vendor/plugins/l10n-simplified-0.8/lib/localization_simplified.rb:13:in `localize_strftime' from /Users/stratboy/Documents/05_SAMPLES/RAILS/newser/vendor/plugins/l10n-simplified-0.8/lib/localization_simplified.rb:191:in `strftime' from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:13:in `today' from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:314:in `date=' from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:416:in `send' from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:416:in `initialize' from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:412:in `each' from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:412:in `initialize' ... 31 levels... from /opt/local/lib/ruby/gems/1.8/gems/rails-1.2.4/lib/commands/server.rb:39 from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `require' from script/server:3 -- Posted via http://www.ruby-forum.com/. From freebsd at akavia.ru Sat Oct 27 10:08:02 2007 From: freebsd at akavia.ru (Alexander Logvinov) Date: Sun, 28 Oct 2007 00:08:02 +1000 Subject: [Mongrel] mongrel 1.0.3 Message-ID: <1951301968.20071028000802@akavia.ru> Hello! Run problems after upgrading to mongrel 1.0.3 from 1.0.1: # uname -sr FreeBSD 7.0-BETA1 # mongrel_rails start ** Starting Mongrel listening at :3000 ** Starting Rails with development environment... ** Rails loaded. ** Loading any Rails specific GemPlugins ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). ** Rails signals registered. HUP => reload (without restart). It might not work well. ** Mongrel available at 0.0.0.0:3000 ** Use CTRL-C to stop. # telnet 127.0.0.1 3000 Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused telnet: Unable to connect to remote host # telnet localhost 3000 Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused Trying ::1... Connected to localhost.host. Escape character is '^]'. # sockstat | grep 3000 root ruby18 14834 3 tcp6 *:3000 *:* Why only tcp6? -- WBR From freebsd at akavia.ru Sat Oct 27 12:04:19 2007 From: freebsd at akavia.ru (Alexander Logvinov) Date: Sun, 28 Oct 2007 02:04:19 +1000 Subject: [Mongrel] mongrel 1.0.3 Message-ID: <1194634301.20071028020419@akavia.ru> Hello! # /usr/local/bin/ruby18 /usr/local/bin/mongrel_rails start -d -e development -a 10.164.28.7 -c /var/www/data/site/ --user root --group wheel -p 8080 -P log/mongrel.8080.pid -l log/mongrel.8080.log Mongrel 1.0.1: ** Starting Mongrel listening at 10.164.28.7:8080 ^^^^^^^^^^^^^^^^ ** Changing group to wheel. ** Changing user to root. ** Starting Rails with development environment... ** Rails loaded. ** Loading any Rails specific GemPlugins ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). ** Rails signals registered. HUP => reload (without restart). It might not work well. ** Mongrel available at 10.164.28.7:8080 ** Writing PID file to log/mongrel.8080.pid Mongrel 1.0.3: ** Starting Mongrel listening at :8080 ^^^^^ ??? ** Starting Rails with development environment... ** Rails loaded. ** Loading any Rails specific GemPlugins ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). ** Rails signals registered. HUP => reload (without restart). It might not work well. ** Mongrel available at 10.164.28.7:8080 ** Writing PID file to log/mongrel.8080.pid -- WBR From evan at cloudbur.st Sat Oct 27 12:37:04 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 27 Oct 2007 12:37:04 -0400 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> Message-ID: What version of Rubygems do you have? Evan On 10/27/07, Luca Reghellin wrote: > > Hi you all! I've got Mongrel saying this when I use the localization > simplified plug-in: any idea? > > ** Loading any Rails specific GemPlugins > Exiting > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:92:in > `load_specification': > /Users/stratboy/Documents/05_SAMPLES/RAILS/newser/vendor/plugins/l10n-simplified-0.8/lib/localization_simplified.rb:13:in > `gsub!': can't convert nil into String (TypeError) > from > /Users/stratboy/Documents/05_SAMPLES/RAILS/newser/vendor/plugins/l10n-simplified-0.8/lib/localization_simplified.rb:13:in > `localize_strftime' > from > /Users/stratboy/Documents/05_SAMPLES/RAILS/newser/vendor/plugins/l10n-simplified-0.8/lib/localization_simplified.rb:191:in > `strftime' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:13:in > `today' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:314:in > `date=' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:416:in > `send' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:416:in > `initialize' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:412:in > `each' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:412:in > `initialize' > ... 31 levels... > from > /opt/local/lib/ruby/gems/1.8/gems/rails-1.2.4/lib/commands/server.rb:39 > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from script/server:3 > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From lists at ruby-forum.com Sat Oct 27 13:09:27 2007 From: lists at ruby-forum.com (Luca Reghellin) Date: Sat, 27 Oct 2007 19:09:27 +0200 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> Message-ID: <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> Hi! I don't how to find it. I can say that I'm running rails 1.2.4 on ruby 1.8.6 (2007-03-13 patchlevel 0) Evan Weaver wrote: > What version of Rubygems do you have? > > Evan -- Posted via http://www.ruby-forum.com/. From luislavena at gmail.com Sat Oct 27 13:24:12 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 27 Oct 2007 14:24:12 -0300 Subject: [Mongrel] mongrel 1.0.3 In-Reply-To: <1194634301.20071028020419@akavia.ru> References: <1194634301.20071028020419@akavia.ru> Message-ID: <71166b3b0710271024o278b8d6etd3a163e466f065b3@mail.gmail.com> On 10/27/07, Alexander Logvinov wrote: > Hello! > > # /usr/local/bin/ruby18 /usr/local/bin/mongrel_rails start -d -e development -a 10.164.28.7 -c /var/www/data/site/ --user root --group wheel -p 8080 -P log/mongrel.8080.pid -l log/mongrel.8080.log > > Mongrel 1.0.1: > > ** Starting Mongrel listening at 10.164.28.7:8080 > ^^^^^^^^^^^^^^^^ > ** Changing group to wheel. > ** Changing user to root. > ** Starting Rails with development environment... > ** Rails loaded. > ** Loading any Rails specific GemPlugins > ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). > ** Rails signals registered. HUP => reload (without restart). It might not work well. > ** Mongrel available at 10.164.28.7:8080 > ** Writing PID file to log/mongrel.8080.pid > > Mongrel 1.0.3: > > ** Starting Mongrel listening at :8080 > ^^^^^ ??? > ** Starting Rails with development environment... > ** Rails loaded. > ** Loading any Rails specific GemPlugins > ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). > ** Rails signals registered. HUP => reload (without restart). It might not work well. > ** Mongrel available at 10.164.28.7:8080 > ** Writing PID file to log/mongrel.8080.pid > > It seems is not handling the IP binding... Could you try the following in a IRB console? require 'rubygems' require 'mongrel' s = Mongrel::HttpServer.new("127.0.0.1", 8081) puts "Host: #{s.host}, Port: #{s.port}" It's using a TCPServer inside, so it should work, unless mongrel_rails is doing something else with the address (host) passed by. -- 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 From luislavena at gmail.com Sat Oct 27 13:26:36 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 27 Oct 2007 14:26:36 -0300 Subject: [Mongrel] mongrel 1.0.3 In-Reply-To: <71166b3b0710271024o278b8d6etd3a163e466f065b3@mail.gmail.com> References: <1194634301.20071028020419@akavia.ru> <71166b3b0710271024o278b8d6etd3a163e466f065b3@mail.gmail.com> Message-ID: <71166b3b0710271026u33cfb579o5907da5c3a38c96a@mail.gmail.com> On 10/27/07, Luis Lavena wrote: > > It seems is not handling the IP binding... > > Could you try the following in a IRB console? > > require 'rubygems' > require 'mongrel' > s = Mongrel::HttpServer.new("127.0.0.1", 8081) > puts "Host: #{s.host}, Port: #{s.port}" > > It's using a TCPServer inside, so it should work, unless mongrel_rails > is doing something else with the address (host) passed by. > Also, you indicate was using FreeBSD, there is a exception for HTTP handling in Mongrel::HttpServer#configure_socket_options Maybe that is affecting the result? wasn't present in 1.0.1 AFAIK. -- 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 From evan at cloudbur.st Sat Oct 27 13:43:30 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 27 Oct 2007 13:43:30 -0400 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> Message-ID: $ gem --version Evan On 10/27/07, Luca Reghellin wrote: > > Hi! I don't how to find it. I can say that I'm running rails 1.2.4 on > ruby 1.8.6 (2007-03-13 patchlevel 0) > > > > > Evan Weaver wrote: > > What version of Rubygems do you have? > > > > Evan > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From evan at cloudbur.st Sat Oct 27 13:50:42 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 27 Oct 2007 13:50:42 -0400 Subject: [Mongrel] mongrel 1.0.3 In-Reply-To: <71166b3b0710271026u33cfb579o5907da5c3a38c96a@mail.gmail.com> References: <1194634301.20071028020419@akavia.ru> <71166b3b0710271024o278b8d6etd3a163e466f065b3@mail.gmail.com> <71166b3b0710271026u33cfb579o5907da5c3a38c96a@mail.gmail.com> Message-ID: Regarding the listening port, there was a bug in bin/mongrel_rails. I fixed it in trunk, and I'll backport it to 1.0.4 in a day or so, giving time for more bugs to come in. Patch is below. > Also, you indicate was using FreeBSD, there is a exception for HTTP > handling in Mongrel::HttpServer#configure_socket_options I think is the correct triage for the IP6 bug. Not having FreeBSD, maybe someone else can figure what it's supposed to be? Not many people were using the RC's except the team; in the future we'll just continue to push point releases. Evan ------- Index: bin/mongrel_rails =================================================================== --- bin/mongrel_rails (revision 806) +++ bin/mongrel_rails (revision 807) @@ -174,15 +178,14 @@ def config_keys @config_keys ||= - %w(host port cwd log_file pid_file environment docroot mime_map daemon debug includes config_script - num_processors timeout throttle user group prefix) + %w(address host port cwd log_file pid_file environment docroot mime_map daemon debug includes config_script num_processors timeout throttle user group prefix) end def settings config_keys.inject({}) do |hash, key| value = self.instance_variable_get("@#{key}") key = 'host' if key == 'address' - hash[key.to_sym] = value + hash[key.to_sym] ||= value hash end end On 10/27/07, Luis Lavena wrote: > On 10/27/07, Luis Lavena wrote: > > > > It seems is not handling the IP binding... > > > > Could you try the following in a IRB console? > > > > require 'rubygems' > > require 'mongrel' > > s = Mongrel::HttpServer.new("127.0.0.1", 8081) > > puts "Host: #{s.host}, Port: #{s.port}" > > > > It's using a TCPServer inside, so it should work, unless mongrel_rails > > is doing something else with the address (host) passed by. > > > > Also, you indicate was using FreeBSD, there is a exception for HTTP > handling in Mongrel::HttpServer#configure_socket_options > > Maybe that is affecting the result? wasn't present in 1.0.1 AFAIK. > > -- > 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 > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From lists at ruby-forum.com Sat Oct 27 13:52:22 2007 From: lists at ruby-forum.com (Luca Reghellin) Date: Sat, 27 Oct 2007 19:52:22 +0200 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> Message-ID: <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> ok thanks, 0.9.4 :) Evan Weaver wrote: > $ gem --version > > Evan -- Posted via http://www.ruby-forum.com/. From evan at cloudbur.st Sat Oct 27 13:53:49 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 27 Oct 2007 13:53:49 -0400 Subject: [Mongrel] mongrel 1.0.3 In-Reply-To: References: <1194634301.20071028020419@akavia.ru> <71166b3b0710271024o278b8d6etd3a163e466f065b3@mail.gmail.com> <71166b3b0710271026u33cfb579o5907da5c3a38c96a@mail.gmail.com> Message-ID: The FreeBSD code is as so: when /freebsd/ # Use the HTTP accept filter if available. # The struct made by pack() is defined in /usr/include/sys/socket.h as accept_filter_arg unless `/sbin/sysctl -nq net.inet.accf.http`.empty? $tcp_defer_accept_opts = [Socket::SOL_SOCKET, Socket::SO_ACCEPTFILTER, ['httpready', nil].pack('a16a240')] end Something there must be IP6 specific. Evan On 10/27/07, Evan Weaver wrote: > Regarding the listening port, there was a bug in bin/mongrel_rails. I > fixed it in trunk, and I'll backport it to 1.0.4 in a day or so, > giving time for more bugs to come in. Patch is below. > > > Also, you indicate was using FreeBSD, there is a exception for HTTP > > handling in Mongrel::HttpServer#configure_socket_options > > I think is the correct triage for the IP6 bug. Not having FreeBSD, > maybe someone else can figure what it's supposed to be? > > Not many people were using the RC's except the team; in the future > we'll just continue to push point releases. > > Evan > > ------- > > Index: bin/mongrel_rails > =================================================================== > --- bin/mongrel_rails (revision 806) > +++ bin/mongrel_rails (revision 807) > @@ -174,15 +178,14 @@ > > def config_keys > @config_keys ||= > - %w(host port cwd log_file pid_file environment docroot > mime_map daemon debug includes config_script > - num_processors timeout throttle user group prefix) > + %w(address host port cwd log_file pid_file environment > docroot mime_map daemon debug includes config_script num_processors > timeout throttle user group prefix) > end > > def settings > config_keys.inject({}) do |hash, key| > value = self.instance_variable_get("@#{key}") > key = 'host' if key == 'address' > - hash[key.to_sym] = value > + hash[key.to_sym] ||= value > hash > end > end > > > On 10/27/07, Luis Lavena wrote: > > On 10/27/07, Luis Lavena wrote: > > > > > > It seems is not handling the IP binding... > > > > > > Could you try the following in a IRB console? > > > > > > require 'rubygems' > > > require 'mongrel' > > > s = Mongrel::HttpServer.new("127.0.0.1", 8081) > > > puts "Host: #{s.host}, Port: #{s.port}" > > > > > > It's using a TCPServer inside, so it should work, unless mongrel_rails > > > is doing something else with the address (host) passed by. > > > > > > > Also, you indicate was using FreeBSD, there is a exception for HTTP > > handling in Mongrel::HttpServer#configure_socket_options > > > > Maybe that is affecting the result? wasn't present in 1.0.1 AFAIK. > > > > -- > > 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 > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > -- > Evan Weaver > Cloudburst, LLC > -- Evan Weaver Cloudburst, LLC From evan at cloudbur.st Sat Oct 27 14:19:43 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 27 Oct 2007 14:19:43 -0400 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> Message-ID: Can you try it with the Rubygems beta? Run: $ gem update --system --source http://segment7.net/ I could't reproduce your issue using the beta so perhaps it was a gem problem that is already fixed. Evan On 10/27/07, Luca Reghellin wrote: > ok thanks, 0.9.4 :) > > > Evan Weaver wrote: > > $ gem --version > > > > Evan > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From lists at ruby-forum.com Sat Oct 27 14:31:41 2007 From: lists at ruby-forum.com (Luca Reghellin) Date: Sat, 27 Oct 2007 20:31:41 +0200 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> Message-ID: <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> Yes I can try, but excuse me, I'm not an expert, so I'm quite afraid of running that command: can that update run my mac or rails installation into some kind of trouble if something goes wrong? By the way, I've used macports to install ruby and rails. Evan Weaver wrote: > Can you try it with the Rubygems beta? Run: > > $ gem update --system --source http://segment7.net/ > > I could't reproduce your issue using the beta so perhaps it was a gem > problem that is already fixed. > > Evan -- Posted via http://www.ruby-forum.com/. From evan at cloudbur.st Sat Oct 27 14:37:49 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 27 Oct 2007 14:37:49 -0400 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> Message-ID: I haven't had any trouble with 0.9.5.6, but it's a valid concern. What version of Mongrel are you using? Did the plugin work before, and now is broken, or did it never work? Evan On 10/27/07, Luca Reghellin wrote: > > Yes I can try, but excuse me, I'm not an expert, so I'm quite afraid of > running that command: can that update run my mac or rails installation > into some kind of trouble if something goes wrong? By the way, I've used > macports to install ruby and rails. > > > Evan Weaver wrote: > > Can you try it with the Rubygems beta? Run: > > > > $ gem update --system --source http://segment7.net/ > > > > I could't reproduce your issue using the beta so perhaps it was a gem > > problem that is already fixed. > > > > Evan > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From lists at ruby-forum.com Sat Oct 27 14:41:49 2007 From: lists at ruby-forum.com (Luca Reghellin) Date: Sat, 27 Oct 2007 20:41:49 +0200 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> Message-ID: <9b7550593c2bcc46016b2509647a1084@ruby-forum.com> It worked before, than suddenly stopped... :( Evan Weaver wrote: > I haven't had any trouble with 0.9.5.6, but it's a valid concern. > > What version of Mongrel are you using? Did the plugin work before, and > now is broken, or did it never work? > > Evan -- Posted via http://www.ruby-forum.com/. From evan at cloudbur.st Sat Oct 27 14:45:34 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 27 Oct 2007 14:45:34 -0400 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: <9b7550593c2bcc46016b2509647a1084@ruby-forum.com> References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> <9b7550593c2bcc46016b2509647a1084@ruby-forum.com> Message-ID: Did it stop after you upgraded Mongrel? Or did you not upgrade. On 10/27/07, Luca Reghellin wrote: > > It worked before, than suddenly stopped... :( > > Evan Weaver wrote: > > I haven't had any trouble with 0.9.5.6, but it's a valid concern. > > > > What version of Mongrel are you using? Did the plugin work before, and > > now is broken, or did it never work? > > > > Evan > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From lists at ruby-forum.com Sat Oct 27 14:52:53 2007 From: lists at ruby-forum.com (Luca Reghellin) Date: Sat, 27 Oct 2007 20:52:53 +0200 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> <9b7550593c2bcc46016b2509647a1084@ruby-forum.com> Message-ID: <7501d8dd24a12dc9ee6e64da871f568a@ruby-forum.com> I'm sorry I was upgrading the gems while you're writing. I've just upgraded rails to 1.2.5 too. Now, if I run rails -v, I've got this error :( /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:367:in `report_activate_error': RubyGem version error: activesupport(1.4.1 not = 1.4.4) (Gem::LoadError) from /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:299:in `activate' from /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:325:in `activate' from /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:324:in `each' from /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:324:in `activate' from /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:76:in `active_gem_with_options' from /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:50:in `gem' from /opt/local/bin/rails:18 Evan Weaver wrote: > Did it stop after you upgraded Mongrel? Or did you not upgrade. -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Sat Oct 27 14:53:55 2007 From: lists at ruby-forum.com (Luca Reghellin) Date: Sat, 27 Oct 2007 20:53:55 +0200 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: <7501d8dd24a12dc9ee6e64da871f568a@ruby-forum.com> References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> <9b7550593c2bcc46016b2509647a1084@ruby-forum.com> <7501d8dd24a12dc9ee6e64da871f568a@ruby-forum.com> Message-ID: <637bf5f5c6abec93a4c18b43e946a0e0@ruby-forum.com> p.s. I did not upgraded mongrel. At least I don't think so. -- Posted via http://www.ruby-forum.com/. From luislavena at gmail.com Sat Oct 27 14:58:10 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 27 Oct 2007 15:58:10 -0300 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: <7501d8dd24a12dc9ee6e64da871f568a@ruby-forum.com> References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> <9b7550593c2bcc46016b2509647a1084@ruby-forum.com> <7501d8dd24a12dc9ee6e64da871f568a@ruby-forum.com> Message-ID: <71166b3b0710271158s5d9ce71rf763a8f44f7852a1@mail.gmail.com> On 10/27/07, Luca Reghellin wrote: > I'm sorry I was upgrading the gems while you're writing. I've just > upgraded rails to 1.2.5 too. Now, if I run rails -v, I've got this error > :( > > /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:367:in > `report_activate_error': RubyGem version error: activesupport(1.4.1 not > = 1.4.4) (Gem::LoadError) That seems to be a issue with the versions of activesupport and rails installed. could you list the gems you have? gem list rails gem list activesupport gem deps rails -v '1.2.5' The last command should list you what gems of activesupport, actionpack and activerecord is using, but I guess all is related to that. Also, did you updated the config/environment.rb to match the new installed gems *prior* doing the rake rails:update in your application? (That is documented in the Ruby on Rails weblog about the upgrade procedure. -- 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 From lists at ruby-forum.com Sat Oct 27 15:09:38 2007 From: lists at ruby-forum.com (Luca Reghellin) Date: Sat, 27 Oct 2007 21:09:38 +0200 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: <71166b3b0710271158s5d9ce71rf763a8f44f7852a1@mail.gmail.com> References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> <9b7550593c2bcc46016b2509647a1084@ruby-forum.com> <7501d8dd24a12dc9ee6e64da871f568a@ruby-forum.com> <71166b3b0710271158s5d9ce71rf763a8f44f7852a1@mail.gmail.com> Message-ID: <21d46e7f46de7532119d985777ab9018@ruby-forum.com> > gem list rails rails (1.2.5, 1.2.4, 1.2.3, 1.2.2) > gem list activesupport activesupport (1.4.3, 1.4.2, 1.4.1) > gem deps rails -v '1.2.5' ERROR: While executing gem ... (RuntimeError) Unknown command deps --------------------- > Also, did you updated the config/environment.rb to match the new > installed gems *prior* doing the rake rails:update in your > application? Well, no... I updated rail via "sudo gem update rails -y" and did nothing else. I've just read the weblog, but since I've not used `gem install rails`, what should I do now? -- Posted via http://www.ruby-forum.com/. From evan at cloudbur.st Sat Oct 27 15:25:00 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 27 Oct 2007 15:25:00 -0400 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: <21d46e7f46de7532119d985777ab9018@ruby-forum.com> References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> <9b7550593c2bcc46016b2509647a1084@ruby-forum.com> <7501d8dd24a12dc9ee6e64da871f568a@ruby-forum.com> <71166b3b0710271158s5d9ce71rf763a8f44f7852a1@mail.gmail.com> <21d46e7f46de7532119d985777ab9018@ruby-forum.com> Message-ID: Best way to proceed is to uninstall all gem versions of Rails, ActiveSupport, ActionPack, ActiveRecord, ActionMailer, and ActionWebService from your system, and then run 'gem install rails' again. This makes sure that the only available versions of Rails are the latest ones, and avoids activation conflicts. Evan On 10/27/07, Luca Reghellin wrote: > > > gem list rails > > rails (1.2.5, 1.2.4, 1.2.3, 1.2.2) > > > gem list activesupport > > activesupport (1.4.3, 1.4.2, 1.4.1) > > > gem deps rails -v '1.2.5' > > ERROR: While executing gem ... (RuntimeError) > Unknown command deps > > > --------------------- > > > Also, did you updated the config/environment.rb to match the new > > installed gems *prior* doing the rake rails:update in your > > application? > > Well, no... > I updated rail via "sudo gem update rails -y" and did nothing else. > > I've just read the weblog, but since I've not used `gem install rails`, > what should I do now? > > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From lists at ruby-forum.com Sat Oct 27 15:26:40 2007 From: lists at ruby-forum.com (Luca Reghellin) Date: Sat, 27 Oct 2007 21:26:40 +0200 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: <21d46e7f46de7532119d985777ab9018@ruby-forum.com> References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> <9b7550593c2bcc46016b2509647a1084@ruby-forum.com> <7501d8dd24a12dc9ee6e64da871f568a@ruby-forum.com> <71166b3b0710271158s5d9ce71rf763a8f44f7852a1@mail.gmail.com> <21d46e7f46de7532119d985777ab9018@ruby-forum.com> Message-ID: <94b1fcb4c9dc3ae1db7cefff656d0d93@ruby-forum.com> Maybe I've updated to 1.2.4 the wrong way too... -- Posted via http://www.ruby-forum.com/. From evan at cloudbur.st Sat Oct 27 15:47:33 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 27 Oct 2007 15:47:33 -0400 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: <94b1fcb4c9dc3ae1db7cefff656d0d93@ruby-forum.com> References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> <9b7550593c2bcc46016b2509647a1084@ruby-forum.com> <7501d8dd24a12dc9ee6e64da871f568a@ruby-forum.com> <71166b3b0710271158s5d9ce71rf763a8f44f7852a1@mail.gmail.com> <21d46e7f46de7532119d985777ab9018@ruby-forum.com> <94b1fcb4c9dc3ae1db7cefff656d0d93@ruby-forum.com> Message-ID: Theoretically you should be able to keep multiple versions at a time, but it doesn't really work so well for Rails in practice because its dependency tree is deep. Many people export the repository release tags into /vendor/rails instead of using the gems. This guarantees that each app uses only its individual version of Rails. Evan On 10/27/07, Luca Reghellin wrote: > > Maybe I've updated to 1.2.4 the wrong way too... > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From lists at ruby-forum.com Sat Oct 27 16:20:49 2007 From: lists at ruby-forum.com (Luca Reghellin) Date: Sat, 27 Oct 2007 22:20:49 +0200 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> <9b7550593c2bcc46016b2509647a1084@ruby-forum.com> <7501d8dd24a12dc9ee6e64da871f568a@ruby-forum.com> <71166b3b0710271158s5d9ce71rf763a8f44f7852a1@mail.gmail.com> <21d46e7f46de7532119d985777ab9018@ruby-forum.com> <94b1fcb4c9dc3ae1db7cefff656d0d93@ruby-forum.com> Message-ID: Ok thank you. I'll try and let you know. Really thank you for your support! Luca Evan Weaver wrote: > Theoretically you should be able to keep multiple versions at a time, > but it doesn't really work so well for Rails in practice because its > dependency tree is deep. > > Many people export the repository release tags into /vendor/rails > instead of using the gems. This guarantees that each app uses only its > individual version of Rails. > > Evan -- Posted via http://www.ruby-forum.com/. From nertzy at gmail.com Sat Oct 27 17:09:43 2007 From: nertzy at gmail.com (Grant Hutchins) Date: Sat, 27 Oct 2007 16:09:43 -0500 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> Message-ID: Time#today was removed from RubyGems, so the suggestion on this blog post might fix your problem: http://blog.segment7.net/articles/2007/10/08/time-today-going-away On 10/27/07, Luca Reghellin wrote: > > Hi you all! I've got Mongrel saying this when I use the localization > simplified plug-in: any idea? > > ** Loading any Rails specific GemPlugins > Exiting > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/source_index.rb:92:in > `load_specification': > /Users/stratboy/Documents/05_SAMPLES/RAILS/newser/vendor/plugins/l10n-simplified-0.8/lib/localization_simplified.rb:13:in > `gsub!': can't convert nil into String (TypeError) > from > /Users/stratboy/Documents/05_SAMPLES/RAILS/newser/vendor/plugins/l10n-simplified-0.8/lib/localization_simplified.rb:13:in > `localize_strftime' > from > /Users/stratboy/Documents/05_SAMPLES/RAILS/newser/vendor/plugins/l10n-simplified-0.8/lib/localization_simplified.rb:191:in > `strftime' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:13:in > `today' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:314:in > `date=' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:416:in > `send' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:416:in > `initialize' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:412:in > `each' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/specification.rb:412:in > `initialize' > ... 31 levels... > from > /opt/local/lib/ruby/gems/1.8/gems/rails-1.2.4/lib/commands/server.rb:39 > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require' > from > /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from script/server:3 > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Grant Hutchins nertzy at gmail.com From andrei at andreimaxim.ro Sat Oct 27 19:18:22 2007 From: andrei at andreimaxim.ro (Andrei Maxim) Date: Sun, 28 Oct 2007 01:18:22 +0200 Subject: [Mongrel] Mongrel 1.0.2 on Ubuntu Feisty Message-ID: Hi everybody, I've been trying to setup a Ruby on Rails application on a Ubuntu Feisty machine and I've spent a lot of time trying to figure out why Nginx and mongrel_cluster weren't working. The setup was correct (based on some tutorials found on the internet), but there weren't any pid files for the mongrels started. In case anybody else has experienced the same problem, it seems that `gem install mongrel` will install version 1.0.2 (which is rather strange since there isn't such a version on Rubyforge, it's either 1.0.1 or 1.0.3) which is broken. I found a typo in configurator.rb on line 63 where instead of target_gid it was just target_id. Forcing version 1.0.3 fixes the problem. However, I'm wondering why v. 1.0.2 gets installed. Any ideas? -- Andrei Maxim http://andreimaxim.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071028/c21ce038/attachment.html From evan at cloudbur.st Sat Oct 27 19:43:08 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sat, 27 Oct 2007 19:43:08 -0400 Subject: [Mongrel] Mongrel 1.0.2 on Ubuntu Feisty In-Reply-To: References: Message-ID: There's been some problems with the Rubyforge gem index recently; Tom Copeland is working on the issue I think. Evan On 10/27/07, Andrei Maxim wrote: > Hi everybody, > > I've been trying to setup a Ruby on Rails application on a Ubuntu Feisty > machine and I've spent a lot of time trying to figure out why Nginx and > mongrel_cluster weren't working. The setup was correct (based on some > tutorials found on the internet), but there weren't any pid files for the > mongrels started. > > In case anybody else has experienced the same problem, it seems that `gem > install mongrel` will install version 1.0.2 (which is rather strange since > there isn't such a version on Rubyforge, it's either 1.0.1 or 1.0.3) which > is broken. I found a typo in configurator.rb on line 63 where instead of > target_gid it was just target_id. Forcing version 1.0.3 fixes the problem. > > However, I'm wondering why v. 1.0.2 gets installed. Any ideas? > > -- > Andrei Maxim > http://andreimaxim.ro > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From andrew at avit.ca Sat Oct 27 20:40:01 2007 From: andrew at avit.ca (Andrew Vit) Date: Sat, 27 Oct 2007 17:40:01 -0700 Subject: [Mongrel] cluster::restart doesn't wait for stop before starting Message-ID: Hi, I'm calling restart from my Capistrano task. I have this in my deploy.rb file: # until mongrel_cluster updates to cap2... namespace :deploy do task :start, :roles => :app do start_mongrel_cluster end task :stop, :roles => :app do stop_mongrel_cluster end task :restart, :roles => :app do restart_mongrel_cluster end end (What's the scoop on mongrel_cluster with Capistrano 2 by the way?) The command that's executed with a restart is: sudo mongrel_rails cluster::restart -C /etc/mongrel_cluster/staging.yml ** [out :: 208.75.84.228] stopping port 8010 ** [out :: 208.75.84.228] already started port 8010 At this point the server is not running -- I conclude that it has been stopped successfully. Now if I call on "start" it starts properly without an "already started" warning. This happens intermittently. Sometimes it restarts fine. If I call stop/start manually, it works because I guess I'm leaving enough time in between for it to shut down. Any thoughts on this? capistrano 2.0.0 mongrel 1.0.1 mongrel_rails 1.0.2 --Andrew Vit From freebsd at akavia.ru Sat Oct 27 21:20:34 2007 From: freebsd at akavia.ru (Alexander Logvinov) Date: Sun, 28 Oct 2007 10:20:34 +0900 Subject: [Mongrel] mongrel 1.0.3 In-Reply-To: <71166b3b0710271024o278b8d6etd3a163e466f065b3@mail.gmail.com> References: <1194634301.20071028020419@akavia.ru> <71166b3b0710271024o278b8d6etd3a163e466f065b3@mail.gmail.com> Message-ID: <1423086347.20071028102034@akavia.ru> Hello, Luis. >> ** Starting Rails with development environment... >> ** Rails loaded. >> ** Loading any Rails specific GemPlugins >> ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). >> ** Rails signals registered. HUP => reload (without restart). It might not work well. >> ** Mongrel available at 10.164.28.7:8080 >> ** Writing PID file to log/mongrel.8080.pid > It seems is not handling the IP binding... > Could you try the following in a IRB console? > require 'rubygems' > require 'mongrel' > s = Mongrel::HttpServer.new("127.0.0.1", 8081) > puts "Host: #{s.host}, Port: #{s.port}" > It's using a TCPServer inside, so it should work, unless mongrel_rails > is doing something else with the address (host) passed by. Here is: >> require 'rubygems' => [] >> require 'mongrel' => [] >> s = Mongrel::HttpServer.new("127.0.0.1", 8081) => #, @port=8081, @workers=#, @classifier={}, @host="127.0.0.1", @death_time=60> >> puts "Host: #{s.host}, Port: #{s.port}" Host: 127.0.0.1, Port: 8081 => nil -- WBR From freebsd at akavia.ru Sat Oct 27 21:24:02 2007 From: freebsd at akavia.ru (Alexander Logvinov) Date: Sun, 28 Oct 2007 10:24:02 +0900 Subject: [Mongrel] mongrel 1.0.3 In-Reply-To: References: <1194634301.20071028020419@akavia.ru> <71166b3b0710271024o278b8d6etd3a163e466f065b3@mail.gmail.com> <71166b3b0710271026u33cfb579o5907da5c3a38c96a@mail.gmail.com> Message-ID: <1831181512.20071028102402@akavia.ru> Hello. > Regarding the listening port, there was a bug in bin/mongrel_rails. I > fixed it in trunk, and I'll backport it to 1.0.4 in a day or so, > giving time for more bugs to come in. Patch is below. It works, thanks! BTW: # mongrel_rails --version Mongrel Web Server 1.0.2 ^^^^^ >> Also, you indicate was using FreeBSD, there is a exception for HTTP >> handling in Mongrel::HttpServer#configure_socket_options > I think is the correct triage for the IP6 bug. Not having FreeBSD, > maybe someone else can figure what it's supposed to be? I'll watch on this today. -- WBR From evan at cloudbur.st Sun Oct 28 01:20:11 2007 From: evan at cloudbur.st (Evan Weaver) Date: Sun, 28 Oct 2007 01:20:11 -0400 Subject: [Mongrel] mongrel 1.0.3 In-Reply-To: <1831181512.20071028102402@akavia.ru> References: <1194634301.20071028020419@akavia.ru> <71166b3b0710271024o278b8d6etd3a163e466f065b3@mail.gmail.com> <71166b3b0710271026u33cfb579o5907da5c3a38c96a@mail.gmail.com> <1831181512.20071028102402@akavia.ru> Message-ID: Yeah, the version string was hardcoded here and there, which I missed. We'll fix this for 1.1, possibly for 1.0.4. Thanks Evan On 10/27/07, Alexander Logvinov wrote: > Hello. > > > > Regarding the listening port, there was a bug in bin/mongrel_rails. I > > fixed it in trunk, and I'll backport it to 1.0.4 in a day or so, > > giving time for more bugs to come in. Patch is below. > It works, thanks! BTW: > > # mongrel_rails --version > Mongrel Web Server 1.0.2 > ^^^^^ > >> Also, you indicate was using FreeBSD, there is a exception for HTTP > >> handling in Mongrel::HttpServer#configure_socket_options > > I think is the correct triage for the IP6 bug. Not having FreeBSD, > > maybe someone else can figure what it's supposed to be? > I'll watch on this today. > > -- > WBR > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From lists at ruby-forum.com Sun Oct 28 05:11:05 2007 From: lists at ruby-forum.com (Luca Reghellin) Date: Sun, 28 Oct 2007 10:11:05 +0100 Subject: [Mongrel] problems with 'localization simplified' In-Reply-To: References: <0a3360c51f5a17cb6df1c71c550fff73@ruby-forum.com> <6b846bb847b3a0ce12606ff413113932@ruby-forum.com> <744e5f0a54e3ef8acad8ae41bcc89644@ruby-forum.com> <3543c3b0586d92fc04c5407f6832ffe7@ruby-forum.com> <9b7550593c2bcc46016b2509647a1084@ruby-forum.com> <7501d8dd24a12dc9ee6e64da871f568a@ruby-forum.com> <71166b3b0710271158s5d9ce71rf763a8f44f7852a1@mail.gmail.com> <21d46e7f46de7532119d985777ab9018@ruby-forum.com> <94b1fcb4c9dc3ae1db7cefff656d0d93@ruby-forum.com> Message-ID: <165de7f932e0f8370a50760441764a68@ruby-forum.com> Done. Now all is running perfect. THANK YOU ALL, VERY MUCH!!!! :):):) > Evan Weaver wrote: >> Theoretically you should be able to keep multiple versions at a time, >> but it doesn't really work so well for Rails in practice because its >> dependency tree is deep. >> >> Many people export the repository release tags into /vendor/rails >> instead of using the gems. This guarantees that each app uses only its >> individual version of Rails. >> >> Evan -- Posted via http://www.ruby-forum.com/. From dave at cheney.net Sun Oct 28 09:22:01 2007 From: dave at cheney.net (Dave Cheney) Date: Mon, 29 Oct 2007 00:22:01 +1100 Subject: [Mongrel] load balancers and mongrel In-Reply-To: <71166b3b0710261746q12cb7eal8499315877233046@mail.gmail.com> References: <2D13ADB7-4128-4665-B285-7DF21AFF5E16@geni.com> <71166b3b0710261746q12cb7eal8499315877233046@mail.gmail.com> Message-ID: <13D58345-9344-4BFF-BAEE-715F6ABD552B@cheney.net> We've also found it beneficial to partition parts of the mongrel cluster into separate functional groups. For example we run 3 sets of mongrels. The first handle dynamic pages generated by the app and are as fast as the db can find and serve the information, the 2nd generate images from thumbnails we store on disk and have a higher cpu cost, but are also constrained by the time taken to send_file the resulting data back to the client (don't forget this has to happen before the rails lock is released). The third mongrel group handle image uploads from our members and can take a very long time to process images if they were large or poorly formed. This separation allowed us to channel requests that had similar resource usage requirements into different pools. Using a smarter web front end like nginx also allows queuing of the request at the web server rather than nginx, which means when the upload requests for the 100mb tiff blows up, it doesn't take 20 other requests that are sitting on the same mongrels queue with it. We found Apaches mod_balancer to be useless in handling proper distribution of requests even after we had segregated the mongrels. My advice is to switch to nginx or some smart hardware if you can afford it. Cheers Dave On 27/10/2007, at 10:46 AM, Luis Lavena wrote: > On 10/26/07, Andrew Arrow wrote: >> We have a load balancer sending requests to one of X boxes and one of >> N mongrel processes on that box. >> >> Since each mongrel processes is multi-threaded but it has a mutex >> around the section that calls rails, we end up with several requests >> queued up waiting when they could have gone to another box with a >> free process. >> >> For example, boxA, and boxB. >> >> boxA has mongrels 1 through 10 >> boxB has mongrels 11 through 20 >> >> Load balancer sends a request to boxA mongrel 5. >> Load balancer sends a request to boxB mongrel 12. >> Load balancer sends a request to boxA mongrel 5 again. >> It has to wait for the 1st request still running on boxA mongrel 5. >> >> How can we help the load balancer know it should have sent the >> request to any number of other free mongrels vs. queuing up threads >> that have to wait? >> > > That's the bad logic of your balancer. > > If it's a hardware one, check if there are some algorithms you can > tweak. > > For a software-based one, check the configuration file if there is > some param about spreading / distributing the requests. > > Also, could be helpful if you mix the box A and box B list of members > for the cluster: > > A: 192.168.0.15 > B: 192.168.0.16 > > A-mongrel1 > B-mongrel11 > A-mongrel2 > B-mongrel12 > > etc... > > -- > 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 > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From dave at cheney.net Sun Oct 28 09:35:16 2007 From: dave at cheney.net (Dave Cheney) Date: Mon, 29 Oct 2007 00:35:16 +1100 Subject: [Mongrel] load balancers and mongrel In-Reply-To: <71166b3b0710261746q12cb7eal8499315877233046@mail.gmail.com> References: <2D13ADB7-4128-4665-B285-7DF21AFF5E16@geni.com> <71166b3b0710261746q12cb7eal8499315877233046@mail.gmail.com> Message-ID: We've also found it beneficial to partition parts of the mongrel cluster into separate functional groups. For example we run 3 sets of mongrels. The first handle dynamic pages generated by the app and are as fast as the db can find and serve the information, the 2nd generate images from thumbnails we store on disk and have a higher cpu cost, but are also constrained by the time taken to send_file the resulting data back to the client (don't forget this has to happen before the rails lock is released). The third mongrel group handle image uploads from our members and can take a very long time to process images if they were large or poorly formed. This separation allowed us to channel requests that had similar resource usage requirements into different pools. Using a smarter web front end like nginx also allows queuing of the request at the web server rather than nginx, which means when the upload requests for the 100mb tiff blows up, it doesn't take 20 other requests that are sitting on the same mongrels queue with it. We found Apaches mod_balancer to be useless in handling proper distribution of requests even after we had segregated the mongrels. My advice is to switch to nginx or some smart hardware if you can afford it. Cheers Dave On 27/10/2007, at 10:46 AM, Luis Lavena wrote: > On 10/26/07, Andrew Arrow wrote: >> We have a load balancer sending requests to one of X boxes and one of >> N mongrel processes on that box. >> >> Since each mongrel processes is multi-threaded but it has a mutex >> around the section that calls rails, we end up with several requests >> queued up waiting when they could have gone to another box with a >> free process. >> >> For example, boxA, and boxB. >> >> boxA has mongrels 1 through 10 >> boxB has mongrels 11 through 20 >> >> Load balancer sends a request to boxA mongrel 5. >> Load balancer sends a request to boxB mongrel 12. >> Load balancer sends a request to boxA mongrel 5 again. >> It has to wait for the 1st request still running on boxA mongrel 5. >> >> How can we help the load balancer know it should have sent the >> request to any number of other free mongrels vs. queuing up threads >> that have to wait? >> > > That's the bad logic of your balancer. > > If it's a hardware one, check if there are some algorithms you can > tweak. > > For a software-based one, check the configuration file if there is > some param about spreading / distributing the requests. > > Also, could be helpful if you mix the box A and box B list of members > for the cluster: > > A: 192.168.0.15 > B: 192.168.0.16 > > A-mongrel1 > B-mongrel11 > A-mongrel2 > B-mongrel12 > > etc... > > -- > 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 > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From andrei at andreimaxim.ro Sun Oct 28 09:39:33 2007 From: andrei at andreimaxim.ro (Andrei Maxim) Date: Sun, 28 Oct 2007 15:39:33 +0200 Subject: [Mongrel] load balancers and mongrel In-Reply-To: <13D58345-9344-4BFF-BAEE-715F6ABD552B@cheney.net> References: <2D13ADB7-4128-4665-B285-7DF21AFF5E16@geni.com> <71166b3b0710261746q12cb7eal8499315877233046@mail.gmail.com> <13D58345-9344-4BFF-BAEE-715F6ABD552B@cheney.net> Message-ID: Hi Dave, On 10/28/07, Dave Cheney wrote: > We've also found it beneficial to partition parts of the mongrel > cluster into separate functional groups. For example we run 3 sets of > mongrels. I'm still learning a lot in terms of system administration and deployment for Ruby on Rails applications, however I'm puzzled how you could divide the mongrels in 3 sets based on function (dynamic pages, thumbnails and image uploads). Could you please shed some light? -- Andrei Maxim http://andreimaxim.ro From zach at plugthegap.co.uk Sun Oct 28 09:50:32 2007 From: zach at plugthegap.co.uk (Zachary Powell) Date: Sun, 28 Oct 2007 09:50:32 -0400 Subject: [Mongrel] cluster::restart doesn't wait for stop before starting In-Reply-To: References: Message-ID: It would be good if it were redesigned to listen for the mongrel to finish before starting it again, every time I stop our front end mongrels one or two of them don't stop quick enough (there are a lot of 1/2-1 sec pages) and i'm pressing up/enter/up/enter/up/enter to start them up again as fast as possible. (anyway, what i meant to add was its not a Capistrano issue alone) On 10/27/07, Andrew Vit wrote: > > Hi, > > I'm calling restart from my Capistrano task. I have this in my deploy.rbfile: > > # until mongrel_cluster updates to cap2... > namespace :deploy do > task :start, :roles => :app do start_mongrel_cluster end > task :stop, :roles => :app do stop_mongrel_cluster end > task :restart, :roles => :app do restart_mongrel_cluster end > end > > (What's the scoop on mongrel_cluster with Capistrano 2 by the way?) > > The command that's executed with a restart is: > > sudo mongrel_rails cluster::restart -C /etc/mongrel_cluster/staging.yml > > ** [out :: 208.75.84.228] stopping port 8010 > ** [out :: 208.75.84.228] already started port 8010 > > > At this point the server is not running -- I conclude that it has been > stopped successfully. Now if I call on "start" it starts properly > without an "already started" warning. > > This happens intermittently. Sometimes it restarts fine. If I call > stop/start manually, it works because I guess I'm leaving enough time > in between for it to shut down. > > Any thoughts on this? > > capistrano 2.0.0 > mongrel 1.0.1 > mongrel_rails 1.0.2 > > --Andrew Vit > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071028/ff6d79a0/attachment.html From dave at cheney.net Sun Oct 28 09:51:18 2007 From: dave at cheney.net (Dave Cheney) Date: Mon, 29 Oct 2007 00:51:18 +1100 Subject: [Mongrel] load balancers and mongrel In-Reply-To: References: <2D13ADB7-4128-4665-B285-7DF21AFF5E16@geni.com> <71166b3b0710261746q12cb7eal8499315877233046@mail.gmail.com> <13D58345-9344-4BFF-BAEE-715F6ABD552B@cheney.net> Message-ID: <208936CF-A6F7-4E2F-A37D-CB5448728ED6@cheney.net> We do it based on the URL. We know from the URL which controller we expect the resource to land on, so using the url and the method, nginx can redirect the request to a particular mongrel group. Cheers Dave On 29/10/2007, at 12:39 AM, Andrei Maxim wrote: > Hi Dave, > > On 10/28/07, Dave Cheney wrote: >> We've also found it beneficial to partition parts of the mongrel >> cluster into separate functional groups. For example we run 3 sets of >> mongrels. > > I'm still learning a lot in terms of system administration and > deployment for Ruby on Rails applications, however I'm puzzled how you > could divide the mongrels in 3 sets based on function (dynamic pages, > thumbnails and image uploads). > > Could you please shed some light? > > -- > Andrei Maxim > http://andreimaxim.ro > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From dave at cheney.net Sun Oct 28 09:57:18 2007 From: dave at cheney.net (Dave Cheney) Date: Mon, 29 Oct 2007 00:57:18 +1100 Subject: [Mongrel] cluster::restart doesn't wait for stop before starting In-Reply-To: References: Message-ID: <82ED1589-64BD-4088-A217-A88A2B2059FC@cheney.net> We notice this a lot in our environment because some mongrels in the cluster are assigned to handle image magick tasks and can take a while to acknowledge the TERM signal. From my understanding mongrel_rails cluster::restart sends a TERM to each mongel, which causes it to wait for the currently processing request to finish, then closes the connections of the other requests outstanding. If this doesn't happen straight away then you'll get the already started message. The solution to me would seam to give cluster::restart an optional delay parameter so those slow mongrels can catch up. Cheers Dave On 28/10/2007, at 11:40 AM, Andrew Vit wrote: > Hi, > > I'm calling restart from my Capistrano task. I have this in my > deploy.rb file: > > # until mongrel_cluster updates to cap2... > namespace :deploy do > task :start, :roles => :app do start_mongrel_cluster end > task :stop, :roles => :app do stop_mongrel_cluster end > task :restart, :roles => :app do restart_mongrel_cluster end > end > > (What's the scoop on mongrel_cluster with Capistrano 2 by the way?) > > The command that's executed with a restart is: > > sudo mongrel_rails cluster::restart -C /etc/mongrel_cluster/ > staging.yml > > ** [out :: 208.75.84.228] stopping port 8010 > ** [out :: 208.75.84.228] already started port 8010 > > > At this point the server is not running -- I conclude that it has been > stopped successfully. Now if I call on "start" it starts properly > without an "already started" warning. > > This happens intermittently. Sometimes it restarts fine. If I call > stop/start manually, it works because I guess I'm leaving enough time > in between for it to shut down. > > Any thoughts on this? > > capistrano 2.0.0 > mongrel 1.0.1 > mongrel_rails 1.0.2 > > --Andrew Vit > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From andrei at andreimaxim.ro Sun Oct 28 09:59:38 2007 From: andrei at andreimaxim.ro (Andrei Maxim) Date: Sun, 28 Oct 2007 15:59:38 +0200 Subject: [Mongrel] load balancers and mongrel In-Reply-To: <208936CF-A6F7-4E2F-A37D-CB5448728ED6@cheney.net> References: <2D13ADB7-4128-4665-B285-7DF21AFF5E16@geni.com> <71166b3b0710261746q12cb7eal8499315877233046@mail.gmail.com> <13D58345-9344-4BFF-BAEE-715F6ABD552B@cheney.net> <208936CF-A6F7-4E2F-A37D-CB5448728ED6@cheney.net> Message-ID: Thank you. Simple solutions are always beautiful. On 10/28/07, Dave Cheney wrote: > > We do it based on the URL. We know from the URL which controller we > expect the resource to land on, so using the url and the method, nginx > can redirect the request to a particular mongrel group. > > Cheers > > Dave > > On 29/10/2007, at 12:39 AM, Andrei Maxim wrote: > > > Hi Dave, > > > > On 10/28/07, Dave Cheney wrote: > >> We've also found it beneficial to partition parts of the mongrel > >> cluster into separate functional groups. For example we run 3 sets of > >> mongrels. > > > > I'm still learning a lot in terms of system administration and > > deployment for Ruby on Rails applications, however I'm puzzled how you > > could divide the mongrels in 3 sets based on function (dynamic pages, > > thumbnails and image uploads). > > > > Could you please shed some light? > -- Andrei Maxim http://andreimaxim.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071028/3b1e494d/attachment.html From dncastilho at gmail.com Sun Oct 28 10:59:25 2007 From: dncastilho at gmail.com (Danilo Castilho) Date: Sun, 28 Oct 2007 12:59:25 -0200 Subject: [Mongrel] high cpu load Message-ID: <26f1ede40710280759q6320b3b2kc8a358edd43537a@mail.gmail.com> Hi all, My mongrel server (1.0.3), with a very low usage, is taking more than 10% of cpu usage all the time (no background tasks were defined by me). This is very annoying and it is preventing me from being able to thing about good cluster configuration. Any idea on why this is happening? cheers and regards, Danilo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071028/93352401/attachment.html From mikeisgreat at gmail.com Sun Oct 28 13:05:22 2007 From: mikeisgreat at gmail.com (Michael Steinfeld) Date: Sun, 28 Oct 2007 13:05:22 -0400 Subject: [Mongrel] high cpu load In-Reply-To: <26f1ede40710280759q6320b3b2kc8a358edd43537a@mail.gmail.com> References: <26f1ede40710280759q6320b3b2kc8a358edd43537a@mail.gmail.com> Message-ID: <3d5db09e0710281005y352d4231reeea3b5a370407a9@mail.gmail.com> How is it possible for us to offer any insight at all without knowing your application, your server config, database, your logs, your hardware etc... people are pretty darn helpful on this list but by no means that means they are psychics. try to be as verbose as possible when posting questions to any list if you expect to get help. On 10/28/07, Danilo Castilho wrote: > Hi all, > > My mongrel server (1.0.3), with a very low usage, is taking more than 10% of > cpu usage all the time (no background tasks were defined by me). This is > very annoying and it is preventing me from being able to thing about good > cluster configuration. Any idea on why this is happening? > > cheers and regards, > Danilo > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Michael Steinfeld Linux Admin/Developer AIM: mikesteinfeld GTALK: mikeisgreat at gmail.com From dncastilho at gmail.com Sun Oct 28 21:55:11 2007 From: dncastilho at gmail.com (Danilo Castilho) Date: Sun, 28 Oct 2007 22:55:11 -0300 Subject: [Mongrel] high cpu load In-Reply-To: <3d5db09e0710281005y352d4231reeea3b5a370407a9@mail.gmail.com> References: <26f1ede40710280759q6320b3b2kc8a358edd43537a@mail.gmail.com> <3d5db09e0710281005y352d4231reeea3b5a370407a9@mail.gmail.com> Message-ID: <000601c819ce$c08b4850$41a1d8f0$@com> Ok, let me clarify the terms I have used and add more information to the question. Very low usage = no user accessing it. Plus, my application doesn't have any "background" operations. Thus, the log is empty. The rails version is 1.2.5 and ruby is 1.8.6. Other than that, my server is running on a linux box, this is the uname -a command for it: Linux localhost 2.6.9-42.0.3.ELsmp #1 SMP Mon Sep 25 17:28:02 EDT 2006 i686 i686 i386 GNU/Linux Moreover, I am running a mongrel cluster (1.0.2) with 1 (one) instance, so it is almost the same as running mongrel alone. This instance is not proxied, balanced or accessed thru any other software (apache, for example). My server configuration is pretty standard, the only plugins I have are redcloth and WhiteListHelper. My app database is Mysql (4.1), where I use an UTF-8 database. I hope this is enough info to start a discussion. Thanks and regards, Danilo. -----Original Message----- From: mongrel-users-bounces at rubyforge.org [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Michael Steinfeld Sent: Sunday, October 28, 2007 2:05 PM To: mongrel-users at rubyforge.org Subject: Re: [Mongrel] high cpu load How is it possible for us to offer any insight at all without knowing your application, your server config, database, your logs, your hardware etc... people are pretty darn helpful on this list but by no means that means they are psychics. try to be as verbose as possible when posting questions to any list if you expect to get help. On 10/28/07, Danilo Castilho wrote: > Hi all, > > My mongrel server (1.0.3), with a very low usage, is taking more than 10% of > cpu usage all the time (no background tasks were defined by me). This is > very annoying and it is preventing me from being able to thing about good > cluster configuration. Any idea on why this is happening? > > cheers and regards, > Danilo > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Michael Steinfeld Linux Admin/Developer AIM: mikesteinfeld GTALK: mikeisgreat at gmail.com _______________________________________________ Mongrel-users mailing list Mongrel-users at rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users From luislavena at gmail.com Sun Oct 28 21:00:58 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 28 Oct 2007 22:00:58 -0300 Subject: [Mongrel] high cpu load In-Reply-To: <26f1ede40710280759q6320b3b2kc8a358edd43537a@mail.gmail.com> References: <26f1ede40710280759q6320b3b2kc8a358edd43537a@mail.gmail.com> Message-ID: <71166b3b0710281800m240668d0h202df8528a4c5402@mail.gmail.com> On 10/28/07, Danilo Castilho wrote: > Hi all, > > My mongrel server (1.0.3), with a very low usage, is taking more than 10% of > cpu usage all the time (no background tasks were defined by me). This is > very annoying and it is preventing me from being able to thing about good > cluster configuration. Any idea on why this is happening? > Danilo, did you checked with ps that Mongrel is the service eating your CPU? Also, what happens if you run plain mongrel_rails without daemonize or cluster options? is the rails application run on production or development mode? Asking this because sometimes a lot of users (including myself) miss it in the global picture. Which patchlevel of ruby you're using? Also, what is the result if you revert to 1.0.1 version? Did this happens with a clean, empty rails application too? We should try other options to see what could be creating the high CPU use you're getting. -- 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 From mikeisgreat at gmail.com Sun Oct 28 22:45:49 2007 From: mikeisgreat at gmail.com (Michael Steinfeld) Date: Sun, 28 Oct 2007 22:45:49 -0400 Subject: [Mongrel] high cpu load In-Reply-To: <000601c819ce$c08b4850$41a1d8f0$@com> References: <26f1ede40710280759q6320b3b2kc8a358edd43537a@mail.gmail.com> <3d5db09e0710281005y352d4231reeea3b5a370407a9@mail.gmail.com> <000601c819ce$c08b4850$41a1d8f0$@com> Message-ID: Manu issues with load and mysql 4 and rails, i can't emphasize enough that you should upgrade to mysql 5 asap from personal experience. Sent from my iPhone ================= M: 941.504.6344 Aim: mikesteinfeld On Oct 28, 2007, at 9:55 PM, "Danilo Castilho" wrote: > Ok, let me clarify the terms I have used and add more information to > the > question. > > Very low usage = no user accessing it. Plus, my application doesn't > have any > "background" operations. Thus, the log is empty. The rails version > is 1.2.5 > and ruby is 1.8.6. > > Other than that, my server is running on a linux box, this is the > uname -a > command for it: > > Linux localhost 2.6.9-42.0.3.ELsmp #1 SMP Mon Sep 25 17:28:02 EDT > 2006 i686 > i686 i386 GNU/Linux > > Moreover, I am running a mongrel cluster (1.0.2) with 1 (one) > instance, so > it is almost the same as running mongrel alone. This instance is not > proxied, balanced or accessed thru any other software (apache, for > example). > My server configuration is pretty standard, the only plugins I have > are > redcloth and WhiteListHelper. > > My app database is Mysql (4.1), where I use an UTF-8 database. > > I hope this is enough info to start a discussion. > > Thanks and regards, > Danilo. > > -----Original Message----- > From: mongrel-users-bounces at rubyforge.org > [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Michael > Steinfeld > Sent: Sunday, October 28, 2007 2:05 PM > To: mongrel-users at rubyforge.org > Subject: Re: [Mongrel] high cpu load > > How is it possible for us to offer any insight at all without knowing > your application, your server config, database, your logs, your > hardware etc... > > people are pretty darn helpful on this list but by no means that means > they are psychics. > > try to be as verbose as possible when posting questions to any list if > you expect to get help. > > On 10/28/07, Danilo Castilho wrote: >> Hi all, >> >> My mongrel server (1.0.3), with a very low usage, is taking more >> than 10% > of >> cpu usage all the time (no background tasks were defined by me). >> This is >> very annoying and it is preventing me from being able to thing >> about good >> cluster configuration. Any idea on why this is happening? >> >> cheers and regards, >> Danilo >> >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> > > > -- > Michael Steinfeld > Linux Admin/Developer > AIM: mikesteinfeld > GTALK: mikeisgreat at gmail.com > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users From rob at robmela.com Sun Oct 28 22:55:34 2007 From: rob at robmela.com (Robert Mela) Date: Sun, 28 Oct 2007 22:55:34 -0400 Subject: [Mongrel] high cpu load In-Reply-To: <000601c819ce$c08b4850$41a1d8f0$@com> References: <26f1ede40710280759q6320b3b2kc8a358edd43537a@mail.gmail.com> <3d5db09e0710281005y352d4231reeea3b5a370407a9@mail.gmail.com> <000601c819ce$c08b4850$41a1d8f0$@com> Message-ID: <47254BA6.5030704@robmela.com> I would try pointing strace and/or gdb at it to see where it's looping. Danilo Castilho wrote: > Ok, let me clarify the terms I have used and add more information to the > question. > > Very low usage = no user accessing it. Plus, my application doesn't have any > "background" operations. Thus, the log is empty. The rails version is 1.2.5 > and ruby is 1.8.6. > > Other than that, my server is running on a linux box, this is the uname -a > command for it: > > Linux localhost 2.6.9-42.0.3.ELsmp #1 SMP Mon Sep 25 17:28:02 EDT 2006 i686 > i686 i386 GNU/Linux > > Moreover, I am running a mongrel cluster (1.0.2) with 1 (one) instance, so > it is almost the same as running mongrel alone. This instance is not > proxied, balanced or accessed thru any other software (apache, for example). > My server configuration is pretty standard, the only plugins I have are > redcloth and WhiteListHelper. > > My app database is Mysql (4.1), where I use an UTF-8 database. > > I hope this is enough info to start a discussion. > > Thanks and regards, > Danilo. -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071028/487f8961/attachment.vcf From dncastilho at gmail.com Mon Oct 29 00:32:13 2007 From: dncastilho at gmail.com (Danilo Castilho) Date: Mon, 29 Oct 2007 01:32:13 -0300 Subject: [Mongrel] high cpu load In-Reply-To: <71166b3b0710281800m240668d0h202df8528a4c5402@mail.gmail.com> References: <26f1ede40710280759q6320b3b2kc8a358edd43537a@mail.gmail.com> <71166b3b0710281800m240668d0h202df8528a4c5402@mail.gmail.com> Message-ID: <000001c819e4$b460a690$1d21f3b0$@com> Luis, Yes, I monitor the cpu usage using ps aux, since my host doesn?t have "top". My server runs on production mode and I am using ruby 1.8.6. Everything started using 1.0.1 (mongrel) and the cpu usage improved a little bit when I upgraded to 1.0.3. But I think I?ve found the major problem. When I changed my mongrel_cluster config file to include the fullpath for the pid and log files, the cpu usage dropped to less than 1%. I don?t understand exactly why, because somehow those files were generated before, using the relative path. I will continue to monitor the cpu usage and let you guys know if this have really solved my problem. Thanks, Danilo. -----Original Message----- From: mongrel-users-bounces at rubyforge.org [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Luis Lavena Sent: Sunday, October 28, 2007 10:01 PM To: mongrel-users at rubyforge.org Subject: Re: [Mongrel] high cpu load On 10/28/07, Danilo Castilho wrote: > Hi all, > > My mongrel server (1.0.3), with a very low usage, is taking more than 10% of > cpu usage all the time (no background tasks were defined by me). This is > very annoying and it is preventing me from being able to thing about good > cluster configuration. Any idea on why this is happening? > Danilo, did you checked with ps that Mongrel is the service eating your CPU? Also, what happens if you run plain mongrel_rails without daemonize or cluster options? is the rails application run on production or development mode? Asking this because sometimes a lot of users (including myself) miss it in the global picture. Which patchlevel of ruby you're using? Also, what is the result if you revert to 1.0.1 version? Did this happens with a clean, empty rails application too? We should try other options to see what could be creating the high CPU use you're getting. -- 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 _______________________________________________ Mongrel-users mailing list Mongrel-users at rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users From eden at mojiti.com Sun Oct 28 23:50:35 2007 From: eden at mojiti.com (Eden Li) Date: Mon, 29 Oct 2007 11:50:35 +0800 Subject: [Mongrel] evented mongrel dies on USR2 Message-ID: <1dd361e10710282050h303aff3au964bf912c856c434@mail.gmail.com> Sorry if this is the wrong place to ask, but when I run mongrel evented using swiftiply and then send it the USR2 signal to restart it, it dies. Without eventing, USR2 restarts mongrel as expected. Anyone else seen this? Here's a dump: $ EVENT=1 mongrel_rails start -d -P /tmp/m.pid -p 4321 Using Evented Mongrel ** Ruby version is up-to-date; cgi_multipart_eof_fix was not loaded $ kill -USR2 `cat /tmp/m.pid` $ cat log/mongrel.log ** Daemonized, any open files are closed. Look at /tmp/m.pid and log/mongrel.log for info. ** Starting Mongrel listening at 0.0.0.0:4321 ** Starting Rails with development environment... ** Rails loaded. ** Loading any Rails specific GemPlugins ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). ** Rails signals registered. HUP => reload (without restart). It might not work well. ** Mongrel available at 0.0.0.0:4321 ** Writing PID file to /tmp/m.pid ** USR2 signal received. /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb:800:in `run': Mongrel::StopServer (Mongrel::StopServer) from /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:293:in `join' from /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:293:in `join' from /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:293:in `each' from /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/configurator.rb:293:in `join' from /opt/local/lib/ruby/gems/1.8/gems/swiftiply-0.6.1/bin/mongrel_rails:145:in `run' from /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/command.rb:211:in `run' from /opt/local/lib/ruby/gems/1.8/gems/swiftiply-0.6.1/bin/mongrel_rails:252 from /opt/local/bin/mongrel_rails:16:in `load' from /opt/local/bin/mongrel_rails:16 From luislavena at gmail.com Mon Oct 29 00:18:45 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 29 Oct 2007 01:18:45 -0300 Subject: [Mongrel] evented mongrel dies on USR2 In-Reply-To: <1dd361e10710282050h303aff3au964bf912c856c434@mail.gmail.com> References: <1dd361e10710282050h303aff3au964bf912c856c434@mail.gmail.com> Message-ID: <71166b3b0710282118g1320e16csd14a9dde46949892@mail.gmail.com> On 10/29/07, Eden Li wrote: > Sorry if this is the wrong place to ask, but when I run mongrel > evented using swiftiply and then send it the USR2 signal to restart > it, it dies. Without eventing, USR2 restarts mongrel as expected. > 50/50, since evented_mongrel is a live patch of what mongrel is supposed to do. Even that is mongrel in the back running, the people who created Evented (Kirk?) should came with a solution for this. Maybe that was one of the things that remain unpatched? -- 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 From zach at plugthegap.co.uk Mon Oct 29 16:09:17 2007 From: zach at plugthegap.co.uk (Zachary Powell) Date: Mon, 29 Oct 2007 16:09:17 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> Message-ID: Hi All, Follow up to the CPU/EBADF issue I was having with lsws: http://www.litespeedtech.com/support/forum/showthread.php?t=1012&goto=newpost Here is the message that has just been posted: *************** The problem is on mongrel side. As shown in the strace output, file handle 5 is the reverse proxy connection from LSWS to mongrel. Mongrel read the request, then it closed the connection immediately without sending back anything, then try to close it again with result EBADF, because the file descriptor has been closed already. When mongrel was working, it should send the reply back to LSWS before closing the socket. The root cause of the problem is on Mongrel side, however, LSWS should fail the request after a few retries. We will implement that in our 3.3 release. *************** Zach On 10/24/07, Zachary Powell wrote: > > Hi, short follow up. I did > > lsof -p 27787 | grep mongrel -c > => 64 files open > > > while it was spiking, so it doesn't look like a max file issue. Looking > thorough the list, the only thing of note was > > > mongrel_r 27787 rails 5w unknown > /proc/27787/fd/5 (readlink: No such file or directory) > > 5 was likely the id of the file getting EBADF (usually 4-6). I didn't > catch which file it was before it the problem ended (running lsof was very > slow, took 20 secs while problem was occuring), but previously when I've > checked its always been there and accessable from web. Also, the dir in > question is full of files, so it hasn't been sweeped recently (couldn't have > been cache-expiry while reading or anything weird like that). > > > Zach > > > > > On 10/24/07, Zachary Powell wrote: > > > > Hi Guys, > > > > I'm using latest Litespeed 3.2.4 (just upgraded), Mongrel 1.0.1, and > > Ruby 1.8.6, running Red Hat Enterprise Linux ES 4 . We have > > > > > > Web/Mysql/Mail server: > > > > # RAID Configuration: RAID 1 (73GBx2) > > > > # HP Memory: 2 GB HP RAM > > > > # HP DL385 G2 Processor: Dual Socket Dual Core Opteron 2214 2.2 GHz > > > > > > (runs between 0.10 - 0.20, mostly MySql, but spikes up when issue occurs > > with litespeed taking ~30% cpu) > > > > > > and App Server: > > > > > > # RAID Configuration: RAID 1 (146GBx2) > > > > # HP Memory: 4 GB HP RAM > > > > # HP DL385 G2 Processor: Dual Socket Dual Core Opteron 2214 2.2 GHz > > > > > > (usually 0.20 - 0.60 with legitimate spikes up to 1.8 for backend > > processes. Spikes up to 2-4 when it happens, depending on how many mongrels > > get the problem (sometimes 2)) > > > > > > And these are the mongrels running: > > > > > > MONGREL CPU MEM VIR RES DATE TIME PID > > 8010:hq 3.2 3.4 145 138 Oct23 43:13 20409 > > 8011:hq 0.6 3.0 132 125 Oct23 8:15 20412 > > 8012:hq 0.1 1.8 81 74 Oct23 1:28 20415 > > 8015:dhq 0.0 1.0 50 44 02:41 0:08 4775 > > 8016:dhq 0.0 0.7 34 30 02:41 0:01 4778 > > 8017:dhq 0.0 0.7 36 30 02:41 0:01 4781 > > 8020:af 9.0 3.3 143 137 Oct23 114:41 26600 > > 8021:af 5.6 2.0 90 84 Oct23 71:56 26607 > > 8022:af 2.4 1.8 80 74 Oct23 30:37 26578 > > 8025:daf 0.0 1.0 49 42 02:41 0:04 4842 > > 8026:daf 0.0 0.7 34 30 02:41 0:02 4845 > > 8027:daf 0.0 0.7 36 30 02:41 0:02 4848 > > 8030:pr 0.1 1.5 67 61 Oct23 1:50 16528 > > 8031:pr 0.0 0.9 47 40 Oct23 0:17 16532 > > 8032:pr 0.0 0.9 44 38 Oct23 0:13 16536 > > 8035:dpr 0.2 0.7 36 30 12:30 0:02 22335 > > 8036:dpr 0.2 0.7 35 30 12:30 0:02 22338 > > 8037:dpr 0.2 0.7 35 30 12:30 0:02 22341 > > > > > > (the ones starting with D are in dev mode, will try turning them off > > tonight, I hadn't considered this a spill over issue, but it happened just > > now and turning them off didn't ease it. We had alot less when the problem > > was occurring before, but also a 1 box set-up). > > > > > > Its the 8020-8022 ones that have trouble. It is indeed picking up the > > page cache, and while its happening I can go to one of those pages in > > question, or cat it in SSH with no problems. I've monitored the rails log > > while it was happening and haven't seen any EBADF spilling over. Though > > its conceivable that a spike of hits from Google crawl could cause a > > problem, I could try siege/ab tonight. > > > > > > Not familiar with checking file limits, but this is what I get from > > googling a command: > > > > > > cat /proc/sys/fs/file-nr: > > 2920 0 372880 > > > > > > ulimit -a: > > core file size (blocks, -c) 0 > > data seg size (kbytes, -d) unlimited > > file size (blocks, -f) unlimited > > pending signals (-i) 1024 > > max locked memory (kbytes, -l) 32 > > max memory size (kbytes, -m) unlimited > > open files (-n) 1024 > > pipe size (512 bytes, -p) 8 > > POSIX message queues (bytes, -q) 819200 > > stack size (kbytes, -s) 10240 > > cpu time (seconds, -t) unlimited > > max user processes (-u) 77823 > > virtual memory (kbytes, -v) unlimited > > file locks (-x) unlimited > > > > > > > > > > Will post the ls -l /proc/{mongrel.pid}/fd/, next time it happens, and > > see how close its getting to 1024. (Though again it seems strange that it > > could be having a max open problem when the other non-cached pages on that > > pid that are definitely opening files work fine). > > > > > > Thanks again, > > > > > > Zach > > > > > > > > On 10/23/07, Dave Cheney wrote: > > > > > > Are you using a web server in front of your mongrels ? It should be > > > picking up the page cached file before even considering handing the request > > > to a mongrel. > > > > > > Cheers > > > > > > > > > Dave > > > > > > On 24/10/2007, at 11:30 AM, Zachary Powell wrote: > > > > > > close(5) = 0 > > > close(5) = -1 EBADF (Bad file > > > descriptor) > > > read(5, "GET /flower_delivery/florists_in_covehithe_suffolk_england_uk > > > HTTP/1.1\nAccept: image/gif, image/x-xbitmap, image/jpeg, image"..., 16384) > > > = 473 > > > close(5) = 0 > > > close(5) = -1 EBADF (Bad file > > > descriptor) > > > > > > > > > the file its trying to get is page cached, and exists/is fine (can > > > even go to url while this is going on). > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071029/2bd0205e/attachment-0001.html From rob at robmela.com Mon Oct 29 16:27:49 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 29 Oct 2007 16:27:49 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> Message-ID: <47264245.4050706@robmela.com> > When mongrel was working, it should send the reply back to LSWS before closing the socket. There's a string prepared for the purpose in mongre.rb ERROR_503_RESPONSE="HTTP/1.1 503 Service Unavailable\r\n\r\nBUSY".freeze It's a one-liner to send that to the socket before calling close. Zachary Powell wrote: > Hi All, > > Follow up to the CPU/EBADF issue I was having with lsws: > > > http://www.litespeedtech.com/support/forum/showthread.php?t=1012&goto=newpost > > Here is the message that has just been posted: > *************** > The problem is on mongrel side. As shown in the strace output, file > handle 5 is the reverse proxy connection from LSWS to mongrel. Mongrel > read the request, then it closed the connection immediately without > sending back anything, then try to close it again with result EBADF, > because the file descriptor has been closed already. > > When mongrel was working, it should send the reply back to LSWS before > closing the socket. > > The root cause of the problem is on Mongrel side, however, LSWS should > fail the request after a few retries. We will implement that in our > 3.3 release. > *************** > > > Zach -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071029/194db8f5/attachment.vcf From evan at cloudbur.st Mon Oct 29 17:43:59 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 29 Oct 2007 17:43:59 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: <47264245.4050706@robmela.com> References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <47264245.4050706@robmela.com> Message-ID: Perhaps you are exhausting the number of worker threads in the queue available to mongrel (default 900ish I think). If your cached files are very big, maybe they aren't being served quickly enough by the DirHandler and your queue becomes clogged. Should mongrel definitely send 503 after this state, or not? I think there was some debate recently about the same issue and the resolution was inconclusive. Does Litespeed support x-sendfile? Maybe the DirHandler should be updated to take advantage of that. Evan On Oct 29, 2007 4:27 PM, Robert Mela wrote: > > When mongrel was working, it should send the reply back to LSWS > before closing the socket. > > There's a string prepared for the purpose in mongre.rb > > ERROR_503_RESPONSE="HTTP/1.1 503 Service Unavailable\r\n\r\nBUSY".freeze > > It's a one-liner to send that to the socket before calling close. > > > Zachary Powell wrote: > > Hi All, > > > > Follow up to the CPU/EBADF issue I was having with lsws: > > > > > > http://www.litespeedtech.com/support/forum/showthread.php?t=1012&goto=newpost > > > > Here is the message that has just been posted: > > *************** > > The problem is on mongrel side. As shown in the strace output, file > > handle 5 is the reverse proxy connection from LSWS to mongrel. Mongrel > > read the request, then it closed the connection immediately without > > sending back anything, then try to close it again with result EBADF, > > because the file descriptor has been closed already. > > > > When mongrel was working, it should send the reply back to LSWS before > > closing the socket. > > > > The root cause of the problem is on Mongrel side, however, LSWS should > > fail the request after a few retries. We will implement that in our > > 3.3 release. > > *************** > > > > > > Zach > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From skan.gryphon at gmail.com Mon Oct 29 18:17:57 2007 From: skan.gryphon at gmail.com (Michael Graff) Date: Mon, 29 Oct 2007 17:17:57 -0500 Subject: [Mongrel] Problems with mongrel on NetBSD Message-ID: <4787b24d0710291517o5aac1f05r349ae1f5e207270d@mail.gmail.com> I seem to have a (recent) problem with mongrel on NetBSD. I'm running a development release of NetBSD (called NetBSD-current 4.99.34). When I start mongrel, it listens on the IPv6 wildcard address, but not on the IPv4 wildcard: => Booting Mongrel (use 'script/server webrick' to force WEBrick) => Rails application starting on http://0.0.0.0:3000 => Call with -d to detach => Ctrl-C to shutdown server ** Starting Mongrel listening at :3000 ** Starting Rails with development environment... ** Rails loaded. ** Loading any Rails specific GemPlugins ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). ** Rails signals registered. HUP => reload (without restart). It might not work well. ** Mongrel available at 0.0.0.0:3000 ** Use CTRL-C to stop. speedy# telnet -4 not.flame.org 3000 Trying 68.97.48.147... telnet: Unable to connect to remote host: Connection refused speedy# telnet not.flame.org 3000 Trying 2001:4f8:fff9::1... Connected to not.flame.org. Escape character is '^]'. ^] This is a fairly new problem. Any ideas on what to fix? --Michael From evan at cloudbur.st Mon Oct 29 18:58:25 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 29 Oct 2007 18:58:25 -0400 Subject: [Mongrel] Problems with mongrel on NetBSD In-Reply-To: <4787b24d0710291517o5aac1f05r349ae1f5e207270d@mail.gmail.com> References: <4787b24d0710291517o5aac1f05r349ae1f5e207270d@mail.gmail.com> Message-ID: For now, revert to Mongrel 1.0.1, and see if that works ok. There's an IP filter in 1.0.2+ which has some problem on FreeBSD. It's this code: when /freebsd(([1-4]\..{1,2})|5\.[0-4])/ # Do nothing, just closing a bug when freebsd <= 5.4 when /freebsd/ # Use the HTTP accept filter if available. # The struct made by pack() is defined in /usr/include/sys/socket.h as accept_filter_arg unless `/sbin/sysctl -nq net.inet.accf.http`.empty? $tcp_defer_accept_opts = [Socket::SOL_SOCKET, Socket::SO_ACCEPTFILTER, ['httpready', nil].pack('a16a240')] end Maybe you can suggest how to fix it? Evan On Oct 29, 2007 6:17 PM, Michael Graff wrote: > I seem to have a (recent) problem with mongrel on NetBSD. I'm running > a development release of NetBSD (called NetBSD-current 4.99.34). > > When I start mongrel, it listens on the IPv6 wildcard address, but not > on the IPv4 wildcard: > > => Booting Mongrel (use 'script/server webrick' to force WEBrick) > => Rails application starting on http://0.0.0.0:3000 > => Call with -d to detach > => Ctrl-C to shutdown server > ** Starting Mongrel listening at :3000 > ** Starting Rails with development environment... > ** Rails loaded. > ** Loading any Rails specific GemPlugins > ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). > ** Rails signals registered. HUP => reload (without restart). It > might not work well. > ** Mongrel available at 0.0.0.0:3000 > ** Use CTRL-C to stop. > > > speedy# telnet -4 not.flame.org 3000 > Trying 68.97.48.147... > telnet: Unable to connect to remote host: Connection refused > > > speedy# telnet not.flame.org 3000 > Trying 2001:4f8:fff9::1... > Connected to not.flame.org. > Escape character is '^]'. > ^] > > This is a fairly new problem. Any ideas on what to fix? > > --Michael > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From will at hotgazpacho.com Mon Oct 29 19:18:59 2007 From: will at hotgazpacho.com (Will Green) Date: Mon, 29 Oct 2007 19:18:59 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <47264245.4050706@robmela.com> Message-ID: <47266A63.5020600@hotgazpacho.com> I disagree. As soon as you start putting code specific to other web servers in the core Mongrel, you'll either have to start adding it for other servers as well (thus bloating the code!), or take a stance on which other servers to support. I think this goes completely against Zed's originally vision. Zed has written several times about how easy it is to create your own handler (I believe as a Gem plugin), and to configure Mongrel to use it. Plus, if you bundle it as a plugin, you can distribute it separately from the Mongrel core, so those of us who don't need it won't have to load code for program we choose not to run. == Will Green Evan Weaver wrote: > Perhaps you are exhausting the number of worker threads in the queue > available to mongrel (default 900ish I think). If your cached files > are very big, maybe they aren't being served quickly enough by the > DirHandler and your queue becomes clogged. > > Should mongrel definitely send 503 after this state, or not? I think > there was some debate recently about the same issue and the resolution > was inconclusive. > > Does Litespeed support x-sendfile? Maybe the DirHandler should be > updated to take advantage of that. > > Evan > > On Oct 29, 2007 4:27 PM, Robert Mela wrote: >> > When mongrel was working, it should send the reply back to LSWS >> before closing the socket. >> >> There's a string prepared for the purpose in mongre.rb >> >> ERROR_503_RESPONSE="HTTP/1.1 503 Service Unavailable\r\n\r\nBUSY".freeze >> >> It's a one-liner to send that to the socket before calling close. >> >> >> Zachary Powell wrote: >>> Hi All, >>> >>> Follow up to the CPU/EBADF issue I was having with lsws: >>> >>> >>> http://www.litespeedtech.com/support/forum/showthread.php?t=1012&goto=newpost >>> >>> Here is the message that has just been posted: >>> *************** >>> The problem is on mongrel side. As shown in the strace output, file >>> handle 5 is the reverse proxy connection from LSWS to mongrel. Mongrel >>> read the request, then it closed the connection immediately without >>> sending back anything, then try to close it again with result EBADF, >>> because the file descriptor has been closed already. >>> >>> When mongrel was working, it should send the reply back to LSWS before >>> closing the socket. >>> >>> The root cause of the problem is on Mongrel side, however, LSWS should >>> fail the request after a few retries. We will implement that in our >>> 3.3 release. >>> *************** >>> >>> >>> Zach >> >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> > > > From evan at cloudbur.st Mon Oct 29 19:47:29 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 29 Oct 2007 19:47:29 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: <47266A63.5020600@hotgazpacho.com> References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <47264245.4050706@robmela.com> <47266A63.5020600@hotgazpacho.com> Message-ID: The Camping handler already has in-Mongrel support for X-SENDFILE. It would make sense to add a configurable option to the DirHandler and Rails handler as well as the Camping handler to actually pass the header along to webservers that support it, so it does what it's supposed to instead of faking it. Also, X-SENDFILE was actually invented by lighttp, so it's not a super-proprietary thing if you're concerned about that. On the other hand, if the webserver doesn't have a superset of permissions the mongrel does, it could blow up, and if it does, it could possibly be a vector for security breaches. However the X-SENDFILE code in the Camping handler should probably be moved into core somewhere instead of the handler, it's kind of a weird place to have it. Just saying. I definitely understand your concerns. Really the issue is whether we should return any response when closing a connection due to resource overloading, I think. Evan On Oct 29, 2007 7:18 PM, Will Green wrote: > I disagree. As soon as you start putting code specific to other web servers in the core Mongrel, > you'll either have to start adding it for other servers as well (thus bloating the code!), or take a > stance on which other servers to support. I think this goes completely against Zed's originally vision. > > Zed has written several times about how easy it is to create your own handler (I believe as a Gem > plugin), and to configure Mongrel to use it. Plus, if you bundle it as a plugin, you can distribute > it separately from the Mongrel core, so those of us who don't need it won't have to load code for > program we choose not to run. > > == > Will Green > > > Evan Weaver wrote: > > Perhaps you are exhausting the number of worker threads in the queue > > available to mongrel (default 900ish I think). If your cached files > > are very big, maybe they aren't being served quickly enough by the > > DirHandler and your queue becomes clogged. > > > > Should mongrel definitely send 503 after this state, or not? I think > > there was some debate recently about the same issue and the resolution > > was inconclusive. > > > > Does Litespeed support x-sendfile? Maybe the DirHandler should be > > updated to take advantage of that. > > > > Evan > > > > On Oct 29, 2007 4:27 PM, Robert Mela wrote: > >> > When mongrel was working, it should send the reply back to LSWS > >> before closing the socket. > >> > >> There's a string prepared for the purpose in mongre.rb > >> > >> ERROR_503_RESPONSE="HTTP/1.1 503 Service Unavailable\r\n\r\nBUSY".freeze > >> > >> It's a one-liner to send that to the socket before calling close. > >> > >> > >> Zachary Powell wrote: > >>> Hi All, > >>> > >>> Follow up to the CPU/EBADF issue I was having with lsws: > >>> > >>> > >>> http://www.litespeedtech.com/support/forum/showthread.php?t=1012&goto=newpost > >>> > >>> Here is the message that has just been posted: > >>> *************** > >>> The problem is on mongrel side. As shown in the strace output, file > >>> handle 5 is the reverse proxy connection from LSWS to mongrel. Mongrel > >>> read the request, then it closed the connection immediately without > >>> sending back anything, then try to close it again with result EBADF, > >>> because the file descriptor has been closed already. > >>> > >>> When mongrel was working, it should send the reply back to LSWS before > >>> closing the socket. > >>> > >>> The root cause of the problem is on Mongrel side, however, LSWS should > >>> fail the request after a few retries. We will implement that in our > >>> 3.3 release. > >>> *************** > >>> > >>> > >>> Zach > >> > >> _______________________________________________ > >> Mongrel-users mailing list > >> Mongrel-users at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/mongrel-users > >> > > > > > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From clifford.heath at gmail.com Mon Oct 29 19:53:29 2007 From: clifford.heath at gmail.com (Clifford Heath) Date: Tue, 30 Oct 2007 10:53:29 +1100 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: <47266A63.5020600@hotgazpacho.com> References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <47264245.4050706@robmela.com> <47266A63.5020600@hotgazpacho.com> Message-ID: <8EFBA4B1-CB2E-47A4-AA4C-933D02DF3082@gmail.com> Surely it's preferable to just delay the accept() until there's a thread to assign it to? That way the client sees a slow connection-establishment and can draw their own conclusions, including deciding how long to wait or whether to retry. Clifford Heath, Data Constellation. > Evan Weaver wrote: >> Perhaps you are exhausting the number of worker threads in the queue >> available to mongrel (default 900ish I think). If your cached files >> are very big, maybe they aren't being served quickly enough by the >> DirHandler and your queue becomes clogged. >> >> Should mongrel definitely send 503 after this state, or not? I think >> there was some debate recently about the same issue and the >> resolution >> was inconclusive. From will at hotgazpacho.com Mon Oct 29 19:55:40 2007 From: will at hotgazpacho.com (Will Green) Date: Mon, 29 Oct 2007 19:55:40 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <47264245.4050706@robmela.com> <47266A63.5020600@hotgazpacho.com> Message-ID: <472672FC.4090001@hotgazpacho.com> Evan, I hear you! I know you have the best interests of Mongrel in mind. X-SendFile is just a header, right? If so, yeah, it could be moved to core. If we're talking the Ruby Sendfile, then I think that should NOT be in core. I recall many people having issues (i.e. it doesn't work) with that. Regarding the closing of the socket without notice, is that something that Ruby does, or is it that a resource limit was reached, and this handle was chosen by the OS to be closed? If the form, a HTTP 503 response is appropriate. If the latter, seems to me that another Mongrel should be employed in a cluster configuration, or the app code examined to see if it might be the source of the problem. == Will Green From evan at cloudbur.st Mon Oct 29 20:02:32 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 29 Oct 2007 20:02:32 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: <472672FC.4090001@hotgazpacho.com> References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <47264245.4050706@robmela.com> <47266A63.5020600@hotgazpacho.com> <472672FC.4090001@hotgazpacho.com> Message-ID: It's a Mongrel-configured limit to avoid queuing an impossibly long number of requests in an overloaded situation. So we can return whatever we want. I think the issue might be, if you can only handle 500 requests p/s, and you are getting 600, if Mongrel closes the connection, at least those 500 will get served, but if Mongrel returns 503, the web server will say "hey, error" and try on the next mongrel, which won't help clear the request queue. The requests will still queue, just at a higher level, and noone will end up getting a request served in a sane amount of time. Evan On Oct 29, 2007 7:55 PM, Will Green wrote: > Evan, I hear you! I know you have the best interests of Mongrel in mind. > > X-SendFile is just a header, right? If so, yeah, it could be moved to core. > > If we're talking the Ruby Sendfile, then I think that should NOT be in core. I recall many people > having issues (i.e. it doesn't work) with that. > > Regarding the closing of the socket without notice, is that something that Ruby does, or is it that > a resource limit was reached, and this handle was chosen by the OS to be closed? If the form, a HTTP > 503 response is appropriate. If the latter, seems to me that another Mongrel should be employed in a > cluster configuration, or the app code examined to see if it might be the source of the problem. > > == > Will Green > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From luislavena at gmail.com Mon Oct 29 20:03:08 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 29 Oct 2007 21:03:08 -0300 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: <472672FC.4090001@hotgazpacho.com> References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <47264245.4050706@robmela.com> <47266A63.5020600@hotgazpacho.com> <472672FC.4090001@hotgazpacho.com> Message-ID: <71166b3b0710291703q47aa3590p37def60a3f626a7c@mail.gmail.com> On 10/29/07, Will Green wrote: > Evan, I hear you! I know you have the best interests of Mongrel in mind. > > X-SendFile is just a header, right? If so, yeah, it could be moved to core. > Yeah, he was talking about X-SendFile. > If we're talking the Ruby Sendfile, then I think that should NOT be in core. I recall many people > having issues (i.e. it doesn't work) with that. Also, send_file is broken on Windows too, besides it eats all your memory and hang you process. Nice, don't you think? -- 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 From evan at cloudbur.st Mon Oct 29 20:03:17 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 29 Oct 2007 20:03:17 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: <47264245.4050706@robmela.com> <47266A63.5020600@hotgazpacho.com> <472672FC.4090001@hotgazpacho.com> Message-ID: Note that there is no guarantee that this is actually the issue discussed with the above configuration. It's just an issue that has been raised before that might be related. Evan On Oct 29, 2007 8:02 PM, Evan Weaver wrote: > It's a Mongrel-configured limit to avoid queuing an impossibly long > number of requests in an overloaded situation. So we can return > whatever we want. > > I think the issue might be, if you can only handle 500 requests p/s, > and you are getting 600, if Mongrel closes the connection, at least > those 500 will get served, but if Mongrel returns 503, the web server > will say "hey, error" and try on the next mongrel, which won't help > clear the request queue. The requests will still queue, just at a > higher level, and noone will end up getting a request served in a sane > amount of time. > > Evan > > > On Oct 29, 2007 7:55 PM, Will Green wrote: > > Evan, I hear you! I know you have the best interests of Mongrel in mind. > > > > X-SendFile is just a header, right? If so, yeah, it could be moved to core. > > > > If we're talking the Ruby Sendfile, then I think that should NOT be in core. I recall many people > > having issues (i.e. it doesn't work) with that. > > > > Regarding the closing of the socket without notice, is that something that Ruby does, or is it that > > a resource limit was reached, and this handle was chosen by the OS to be closed? If the form, a HTTP > > 503 response is appropriate. If the latter, seems to me that another Mongrel should be employed in a > > cluster configuration, or the app code examined to see if it might be the source of the problem. > > > > == > > Will Green > > > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > -- > Evan Weaver > Cloudburst, LLC > -- Evan Weaver Cloudburst, LLC From skan.gryphon at gmail.com Mon Oct 29 20:09:34 2007 From: skan.gryphon at gmail.com (Michael Graff) Date: Mon, 29 Oct 2007 19:09:34 -0500 Subject: [Mongrel] Problems with mongrel on NetBSD In-Reply-To: References: <4787b24d0710291517o5aac1f05r349ae1f5e207270d@mail.gmail.com> Message-ID: <4787b24d0710291709r76f70b4cv769666faa78b38e1@mail.gmail.com> That doesn't look like it's related. The snippit you sent is specific to FreeBSD, in that it is asking the kernel to do additional filtering. To me, this is an optimization. --Michael On 10/29/07, Evan Weaver wrote: > For now, revert to Mongrel 1.0.1, and see if that works ok. There's an > IP filter in 1.0.2+ which has some problem on FreeBSD. It's this code: > > when /freebsd(([1-4]\..{1,2})|5\.[0-4])/ > # Do nothing, just closing a bug when freebsd <= 5.4 > when /freebsd/ > # Use the HTTP accept filter if available. > # The struct made by pack() is defined in > /usr/include/sys/socket.h as accept_filter_arg > unless `/sbin/sysctl -nq net.inet.accf.http`.empty? > $tcp_defer_accept_opts = [Socket::SOL_SOCKET, > Socket::SO_ACCEPTFILTER, ['httpready', nil].pack('a16a240')] > end > > Maybe you can suggest how to fix it? > > Evan > > On Oct 29, 2007 6:17 PM, Michael Graff wrote: > > I seem to have a (recent) problem with mongrel on NetBSD. I'm running > > a development release of NetBSD (called NetBSD-current 4.99.34). > > > > When I start mongrel, it listens on the IPv6 wildcard address, but not > > on the IPv4 wildcard: > > > > => Booting Mongrel (use 'script/server webrick' to force WEBrick) > > => Rails application starting on http://0.0.0.0:3000 > > => Call with -d to detach > > => Ctrl-C to shutdown server > > ** Starting Mongrel listening at :3000 > > ** Starting Rails with development environment... > > ** Rails loaded. > > ** Loading any Rails specific GemPlugins > > ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). > > ** Rails signals registered. HUP => reload (without restart). It > > might not work well. > > ** Mongrel available at 0.0.0.0:3000 > > ** Use CTRL-C to stop. > > > > > > speedy# telnet -4 not.flame.org 3000 > > Trying 68.97.48.147... > > telnet: Unable to connect to remote host: Connection refused > > > > > > speedy# telnet not.flame.org 3000 > > Trying 2001:4f8:fff9::1... > > Connected to not.flame.org. > > Escape character is '^]'. > > ^] > > > > This is a fairly new problem. Any ideas on what to fix? > > > > --Michael > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > -- > Evan Weaver > Cloudburst, LLC > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From evan at cloudbur.st Mon Oct 29 20:12:19 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 29 Oct 2007 20:12:19 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: <71166b3b0710291703q47aa3590p37def60a3f626a7c@mail.gmail.com> References: <47264245.4050706@robmela.com> <47266A63.5020600@hotgazpacho.com> <472672FC.4090001@hotgazpacho.com> <71166b3b0710291703q47aa3590p37def60a3f626a7c@mail.gmail.com> Message-ID: See, if we used real X-Sendfile, the webserver maintainers would have to worry about Windows problems, not Mongrel ;) . For now we'll just leave the X-Sendfile behavior alone. Evan On Oct 29, 2007 8:03 PM, Luis Lavena wrote: > On 10/29/07, Will Green wrote: > > Evan, I hear you! I know you have the best interests of Mongrel in mind. > > > > X-SendFile is just a header, right? If so, yeah, it could be moved to core. > > > > Yeah, he was talking about X-SendFile. > > > If we're talking the Ruby Sendfile, then I think that should NOT be in core. I recall many people > > having issues (i.e. it doesn't work) with that. > > Also, send_file is broken on Windows too, besides it eats all your > memory and hang you process. > > Nice, don't you think? > > -- > 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 > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From evan at cloudbur.st Mon Oct 29 20:29:08 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 29 Oct 2007 20:29:08 -0400 Subject: [Mongrel] Problems with mongrel on NetBSD In-Reply-To: <4787b24d0710291709r76f70b4cv769666faa78b38e1@mail.gmail.com> References: <4787b24d0710291517o5aac1f05r349ae1f5e207270d@mail.gmail.com> <4787b24d0710291709r76f70b4cv769666faa78b38e1@mail.gmail.com> Message-ID: Oops, I misread your original post, and thought you were on FreeBSD. There are a couple related issues that were raised on the list in the last couple weeks but we never reached a resolution on them. I'm not familiar with any BSD so I need someone else to take charge of this. Evan On Oct 29, 2007 8:09 PM, Michael Graff wrote: > That doesn't look like it's related. The snippit you sent is specific > to FreeBSD, in that it is asking the kernel to do additional > filtering. To me, this is an optimization. > > --Michael > > > > On 10/29/07, Evan Weaver wrote: > > For now, revert to Mongrel 1.0.1, and see if that works ok. There's an > > IP filter in 1.0.2+ which has some problem on FreeBSD. It's this code: > > > > when /freebsd(([1-4]\..{1,2})|5\.[0-4])/ > > # Do nothing, just closing a bug when freebsd <= 5.4 > > when /freebsd/ > > # Use the HTTP accept filter if available. > > # The struct made by pack() is defined in > > /usr/include/sys/socket.h as accept_filter_arg > > unless `/sbin/sysctl -nq net.inet.accf.http`.empty? > > $tcp_defer_accept_opts = [Socket::SOL_SOCKET, > > Socket::SO_ACCEPTFILTER, ['httpready', nil].pack('a16a240')] > > end > > > > Maybe you can suggest how to fix it? > > > > Evan > > > > On Oct 29, 2007 6:17 PM, Michael Graff wrote: > > > I seem to have a (recent) problem with mongrel on NetBSD. I'm running > > > a development release of NetBSD (called NetBSD-current 4.99.34). > > > > > > When I start mongrel, it listens on the IPv6 wildcard address, but not > > > on the IPv4 wildcard: > > > > > > => Booting Mongrel (use 'script/server webrick' to force WEBrick) > > > => Rails application starting on http://0.0.0.0:3000 > > > => Call with -d to detach > > > => Ctrl-C to shutdown server > > > ** Starting Mongrel listening at :3000 > > > ** Starting Rails with development environment... > > > ** Rails loaded. > > > ** Loading any Rails specific GemPlugins > > > ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). > > > ** Rails signals registered. HUP => reload (without restart). It > > > might not work well. > > > ** Mongrel available at 0.0.0.0:3000 > > > ** Use CTRL-C to stop. > > > > > > > > > speedy# telnet -4 not.flame.org 3000 > > > Trying 68.97.48.147... > > > telnet: Unable to connect to remote host: Connection refused > > > > > > > > > speedy# telnet not.flame.org 3000 > > > Trying 2001:4f8:fff9::1... > > > Connected to not.flame.org. > > > Escape character is '^]'. > > > ^] > > > > > > This is a fairly new problem. Any ideas on what to fix? > > > > > > --Michael > > > _______________________________________________ > > > Mongrel-users mailing list > > > Mongrel-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > > > > -- > > Evan Weaver > > Cloudburst, LLC > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From rob at robmela.com Mon Oct 29 21:20:12 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 29 Oct 2007 21:20:12 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: <8EFBA4B1-CB2E-47A4-AA4C-933D02DF3082@gmail.com> References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <47264245.4050706@robmela.com> <47266A63.5020600@hotgazpacho.com> <8EFBA4B1-CB2E-47A4-AA4C-933D02DF3082@gmail.com> Message-ID: <472686CC.4020702@robmela.com> Already covered in this thread: http://rubyforge.org/pipermail/mongrel-users/2007-October/004132.html Delaying the accept() would be more helpful for load balancers which, after a timeout for connect, cycle to another load balancer in the pool. Failing that, a 503 would be reasonable, and it offers a hint to users as to what's really happening. The open/close does not. According to the http/1.1 spec the 503 and refuse-to-accept are both correct ( http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-03.txt ) 10.5.4. 503 Service Unavailable The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response. Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection. Anyhow, I suggested one means for doing that in a previous thread ( entitled num_threads or accept/close or sth like that ) Clifford Heath wrote: > Surely it's preferable to just delay the accept() until there's a > thread to > assign it to? That way the client sees a slow connection-establishment > and can draw their own conclusions, including deciding how long to > wait or whether to retry. > > Clifford Heath, Data Constellation. -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071029/0d1dce2c/attachment.vcf From evan at cloudbur.st Mon Oct 29 21:27:52 2007 From: evan at cloudbur.st (Evan Weaver) Date: Mon, 29 Oct 2007 21:27:52 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: <472686CC.4020702@robmela.com> References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <47264245.4050706@robmela.com> <47266A63.5020600@hotgazpacho.com> <8EFBA4B1-CB2E-47A4-AA4C-933D02DF3082@gmail.com> <472686CC.4020702@robmela.com> Message-ID: I think currently it accepts the connection and then immediately closes it, which is not consistent with the spec. Evan On Oct 29, 2007 9:20 PM, Robert Mela wrote: > Already covered in this thread: > http://rubyforge.org/pipermail/mongrel-users/2007-October/004132.html > > Delaying the accept() would be more helpful for load balancers which, > after a timeout for connect, cycle to another load balancer in the > pool. Failing that, a 503 would be reasonable, and it offers a hint to > users as to what's really happening. The open/close does not. > > According to the http/1.1 spec the 503 and refuse-to-accept are both > correct ( > http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-03.txt > ) > > 10.5.4. 503 Service Unavailable > > The server is currently unable to handle the request due to a > temporary overloading or maintenance of the server. The implication > is that this is a temporary condition which will be alleviated after > some delay. If known, the length of the delay MAY be indicated in a > Retry-After header. If no Retry-After is given, the client SHOULD > handle the response as it would for a 500 response. > > Note: The existence of the 503 status code does not imply that a > server must use it when becoming overloaded. Some servers may > wish to simply refuse the connection. > > > > Anyhow, I suggested one means for doing that in a previous thread ( > entitled num_threads or accept/close or sth like that ) > > Clifford Heath wrote: > > Surely it's preferable to just delay the accept() until there's a > > thread to > > assign it to? That way the client sees a slow connection-establishment > > and can draw their own conclusions, including deciding how long to > > wait or whether to retry. > > > > Clifford Heath, Data Constellation. > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From public at misuse.org Mon Oct 29 22:34:40 2007 From: public at misuse.org (Steve Midgley) Date: Mon, 29 Oct 2007 19:34:40 -0700 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: Message-ID: <20071030023453.1788218585B2@rubyforge.org> Hi Evan, You are doing a really great job supporting so many people on this list - thank you! I'm learning a lot just listening. I've been considering that what you're asking below (and what Robert Mela has been pushing everyone on) is essentially identifying that there might need to be at least two modes to approaching Mongrel queuing: 1) Mongrel queues all requests (current model) 2) Load balancer / webserver (or even IP stack) queues most requests I think Mongrel right now is designed solely for the case where Mongrel is supposed to queue all requests? Robert Mela seems to want an environment where Mongrel queues only some or no requests b/c he seems to have a way to get Apache + mod_proxy_magic_bullet to queue and re-try failed requests from mongrels. I wonder if it makes sense to create a mode for Mongrel where it queues only a few (or no) requests and the load balancer or webserver (or even ip stack) is designed to queue the majority of backlogged requests? Could this be a user-configurable setting (:queue_length => 2.requests or whatever)? In the event that the queue length grows bigger than this limit, Mongrel responds with a 503. If the calling agent understands 503, it be able to try other mongrels in the cluster until it finds one that is free. If they are all busy it would just keep knocking on doors until one frees up. This approach could make things worse in extreme load environments b/c now you have backed up mongrels and a pile of re-requests hammering on the door to all the mongrels as well. But that's a worst case scenario (e.g. slashdotting) that is going to break SOMETHING SOMEWHERE anyway. So why not have it melt-down at the interface between the webservers and the mongrel cluster instead of inside the mongrels (what's the difference)? The benefit of this alternate mode of operation would be that free mongrels get called more often and overloaded mongrels get skipped more often, which creates a much smoother user experience on the front-end, generally speaking (this approach improve performance of moderately loaded websites at the expense of punishing heavily loaded ones - who should probably add more mongrels/hardware anyway). The only changes to Mongrel code would be to allow a configurable queue length on a per-mongrel basis (maybe already in there?) and a setting to cause Mongrels to accept and return 503 instead of accepting and closing the connection? Defaults would remain the same as they now.. Would such a dual mode of operation for mongrels make sense for some users or am I just completely barking up the wrong tree here? Apologies if this is a distraction from the real issue you are discussing. Best, Steve At 06:27 PM 10/29/2007, you wrote: >Date: Mon, 29 Oct 2007 20:02:32 -0400 >From: "Evan Weaver" >Subject: Re: [Mongrel] random cpu spikes, EBADF errors >To: mongrel-users at rubyforge.org >Message-ID: > >Content-Type: text/plain; charset=ISO-8859-1 > >It's a Mongrel-configured limit to avoid queuing an impossibly long >number of requests in an overloaded situation. So we can return >whatever we want. > >I think the issue might be, if you can only handle 500 requests p/s, >and you are getting 600, if Mongrel closes the connection, at least >those 500 will get served, but if Mongrel returns 503, the web server >will say "hey, error" and try on the next mongrel, which won't help >clear the request queue. The requests will still queue, just at a >higher level, and noone will end up getting a request served in a sane >amount of time. > >Evan >On Oct 29, 2007 7:55 PM, Will Green wrote: > > Evan, I hear you! I know you have the best interests of Mongrel in > mind. > > > > X-SendFile is just a header, right? If so, yeah, it could be moved > to core. > > > > If we're talking the Ruby Sendfile, then I think that should NOT be > in core. I recall many people > > having issues (i.e. it doesn't work) with that. > > > > Regarding the closing of the socket without notice, is that > something that Ruby does, or is it that > > a resource limit was reached, and this handle was chosen by the OS > to be closed? If the form, a HTTP > > 503 response is appropriate. If the latter, seems to me that > another Mongrel should be employed in a > > cluster configuration, or the app code examined to see if it might > be the source of the problem. > > From skan.gryphon at gmail.com Tue Oct 30 04:12:50 2007 From: skan.gryphon at gmail.com (Michael Graff) Date: Tue, 30 Oct 2007 03:12:50 -0500 Subject: [Mongrel] Problems with mongrel on NetBSD In-Reply-To: References: <4787b24d0710291517o5aac1f05r349ae1f5e207270d@mail.gmail.com> <4787b24d0710291709r76f70b4cv769666faa78b38e1@mail.gmail.com> Message-ID: <4787b24d0710300112k56775acck688ad09575eaa6de@mail.gmail.com> I don't know if it is BSD specific or not here. >From what I can tell, mongrel_rails is ignoring the -a option: > mongrel_rails start -a 10.42.94.253 ** Starting Mongrel listening at :3000 ---------------------------------127.0.0.1 ---------------------------------3000 -------------------------127.0.0.1:3000 ** Starting Rails with development environment... ** Rails loaded. ** Loading any Rails specific GemPlugins ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). ** Rails signals registered. HUP => reload (without restart). It might not work well. ** Mongrel available at 10.42.94.253:3000 ** Use CTRL-C to stop. The code I have running above has two changes. One, to print out the host and port along the way, and two, to set ops[:host] ||= "127.0.0.1" in configurator.rb#listener. The first two lines come from lib/mongrel.rb inside the HttpServer.new method, and the second one comes from the listener method inside the Confiurator class. So, I do not know why it is doing what it's doing, but I also don't know if it is BSD specific or not. --Michael On 10/29/07, Evan Weaver wrote: > Oops, I misread your original post, and thought you were on FreeBSD. > There are a couple related issues that were raised on the list in the > last couple weeks but we never reached a resolution on them. > > I'm not familiar with any BSD so I need someone else to take charge of this. > > Evan > > On Oct 29, 2007 8:09 PM, Michael Graff wrote: > > That doesn't look like it's related. The snippit you sent is specific > > to FreeBSD, in that it is asking the kernel to do additional > > filtering. To me, this is an optimization. > > > > --Michael > > > > > > > > On 10/29/07, Evan Weaver wrote: > > > For now, revert to Mongrel 1.0.1, and see if that works ok. There's an > > > IP filter in 1.0.2+ which has some problem on FreeBSD. It's this code: > > > > > > when /freebsd(([1-4]\..{1,2})|5\.[0-4])/ > > > # Do nothing, just closing a bug when freebsd <= 5.4 > > > when /freebsd/ > > > # Use the HTTP accept filter if available. > > > # The struct made by pack() is defined in > > > /usr/include/sys/socket.h as accept_filter_arg > > > unless `/sbin/sysctl -nq net.inet.accf.http`.empty? > > > $tcp_defer_accept_opts = [Socket::SOL_SOCKET, > > > Socket::SO_ACCEPTFILTER, ['httpready', nil].pack('a16a240')] > > > end > > > > > > Maybe you can suggest how to fix it? > > > > > > Evan > > > > > > On Oct 29, 2007 6:17 PM, Michael Graff wrote: > > > > I seem to have a (recent) problem with mongrel on NetBSD. I'm running > > > > a development release of NetBSD (called NetBSD-current 4.99.34). > > > > > > > > When I start mongrel, it listens on the IPv6 wildcard address, but not > > > > on the IPv4 wildcard: > > > > > > > > => Booting Mongrel (use 'script/server webrick' to force WEBrick) > > > > => Rails application starting on http://0.0.0.0:3000 > > > > => Call with -d to detach > > > > => Ctrl-C to shutdown server > > > > ** Starting Mongrel listening at :3000 > > > > ** Starting Rails with development environment... > > > > ** Rails loaded. > > > > ** Loading any Rails specific GemPlugins > > > > ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). > > > > ** Rails signals registered. HUP => reload (without restart). It > > > > might not work well. > > > > ** Mongrel available at 0.0.0.0:3000 > > > > ** Use CTRL-C to stop. > > > > > > > > > > > > speedy# telnet -4 not.flame.org 3000 > > > > Trying 68.97.48.147... > > > > telnet: Unable to connect to remote host: Connection refused > > > > > > > > > > > > speedy# telnet not.flame.org 3000 > > > > Trying 2001:4f8:fff9::1... > > > > Connected to not.flame.org. > > > > Escape character is '^]'. > > > > ^] > > > > > > > > This is a fairly new problem. Any ideas on what to fix? > > > > > > > > --Michael > > > > _______________________________________________ > > > > Mongrel-users mailing list > > > > Mongrel-users at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > > > > > > > > > -- > > > Evan Weaver > > > Cloudburst, LLC > > > _______________________________________________ > > > Mongrel-users mailing list > > > Mongrel-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > -- > Evan Weaver > Cloudburst, LLC > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > From skan.gryphon at gmail.com Tue Oct 30 04:33:51 2007 From: skan.gryphon at gmail.com (Michael Graff) Date: Tue, 30 Oct 2007 03:33:51 -0500 Subject: [Mongrel] Problems with mongrel on NetBSD In-Reply-To: <4787b24d0710300112k56775acck688ad09575eaa6de@mail.gmail.com> References: <4787b24d0710291517o5aac1f05r349ae1f5e207270d@mail.gmail.com> <4787b24d0710291709r76f70b4cv769666faa78b38e1@mail.gmail.com> <4787b24d0710300112k56775acck688ad09575eaa6de@mail.gmail.com> Message-ID: <4787b24d0710300133o46f632d4o519a38a812490672@mail.gmail.com> And it seems 1.0.4 works again. Whatever was fixed, it made NetBSD at least bind to IPv4 when passed 0.0.0.0 or 127.0.0.1 as an IP address. Does Mongrel do IPv6 well? --Michael From zedshaw at zedshaw.com Tue Oct 30 08:34:19 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 30 Oct 2007 08:34:19 -0400 Subject: [Mongrel] Problems with mongrel on NetBSD In-Reply-To: <4787b24d0710300133o46f632d4o519a38a812490672@mail.gmail.com> References: <4787b24d0710291517o5aac1f05r349ae1f5e207270d@mail.gmail.com> <4787b24d0710291709r76f70b4cv769666faa78b38e1@mail.gmail.com> <4787b24d0710300112k56775acck688ad09575eaa6de@mail.gmail.com> <4787b24d0710300133o46f632d4o519a38a812490672@mail.gmail.com> Message-ID: <20071030083419.48f521ff.zedshaw@zedshaw.com> On Tue, 30 Oct 2007 03:33:51 -0500 "Michael Graff" wrote: > And it seems 1.0.4 works again. Whatever was fixed, it made NetBSD at > least bind to IPv4 when passed 0.0.0.0 or 127.0.0.1 as an IP address. > > Does Mongrel do IPv6 well? Mongrel does whatever Ruby supports, nothing fancy or any special tricks on binding for NetBSD. I think there might have been an overzealous change to the *BSD camp that's enabled ipv6 by default and ruby has yet to catch up. Do you know of any NetBSD posts related to ipv6 and required socket code changes? -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From zedshaw at zedshaw.com Tue Oct 30 08:42:19 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 30 Oct 2007 08:42:19 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> Message-ID: <20071030084219.d9b272d1.zedshaw@zedshaw.com> On Mon, 29 Oct 2007 16:09:17 -0400 "Zachary Powell" wrote: > Hi All, > Follow up to the CPU/EBADF issue I was having with lsws: > > > http://www.litespeedtech.com/support/forum/showthread.php?t=1012&goto=newpost > Here is the message that has just been posted: > *************** > The problem is on mongrel side. As shown in the strace output, file handle 5 > is the reverse proxy connection from LSWS to mongrel. Mongrel read the > request, then it closed the connection immediately without sending back > anything, then try to close it again with result EBADF, because the file > descriptor has been closed already. Take a look in the mongel.log with debugging on as there might be a complaint about LSWS's interpretation of the HTTP protocol which is causing mongrel to close the connection due to a malformed request. Normally, the only time that Mongrel will abort a connection is when the client (LSWS in this case) sends a malformed request according to the HTTP grammar. When Mongrel reports what caused the close it tells you the full request that was bad. The error is usually BAD CLIENT. Also go use ethereal to get a packet trace of the traffic between the two servers to see what is being sent. You'll probably find that LSWS is doing something that no other web server does, or at least some clue as to what is making Mongrel barf. One thing to watch for is that some web servers acting as a proxy don't honor the Connection:close header on responses and try to keep the socket forced open, which also violates the RFC. Finally, a stack trace of where the EBADF shows up would let the Mongrel team just not close it if it's already closed (again). Ultimately Ruby shouldn't be throwing these errnos as separate exceptions since it means having to compensate for every platform's interpretation of the sockets API and what should be thrown when. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From zedshaw at zedshaw.com Tue Oct 30 08:46:32 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 30 Oct 2007 08:46:32 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: <47264245.4050706@robmela.com> References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <47264245.4050706@robmela.com> Message-ID: <20071030084632.3314e3af.zedshaw@zedshaw.com> On Mon, 29 Oct 2007 16:27:49 -0400 Robert Mela wrote: > > When mongrel was working, it should send the reply back to LSWS > before closing the socket. > > There's a string prepared for the purpose in mongre.rb > > ERROR_503_RESPONSE="HTTP/1.1 503 Service Unavailable\r\n\r\nBUSY".freeze > > It's a one-liner to send that to the socket before calling close. No, that's not the best way to do this. Think for a minute. Mongrel is overloaded. It's having a hard time sending data. Now you want it to waste more time sending data? The general practice that works best is when a server is overloaded it aborts connections it can't handle in order to get some free time to service more requests. This way existing pending requests get some service and in a load balancing situation the server can move on to the next available backend. The alternative in trying to handle all requests, even with small responses, will mean that nobody gets service. In reality, I bet that LSWS doesn't try to move on to the next backend when the connection is aborted. If you think about this also, it means that when LSWS is behaving as a proxy, and one of your backends goes down, then LSWS won't adapt and will instead complain to the user. A properly functioning proxy server that is behaving as a load balancer should try all servers possible several times until it either gets a response or has to give up because everything is down and/or it is overloaded as well. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From zedshaw at zedshaw.com Tue Oct 30 08:48:44 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 30 Oct 2007 08:48:44 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <47264245.4050706@robmela.com> Message-ID: <20071030084844.b3f69292.zedshaw@zedshaw.com> On Mon, 29 Oct 2007 17:43:59 -0400 "Evan Weaver" wrote: > Does Litespeed support x-sendfile? Maybe the DirHandler should be > updated to take advantage of that. Uh, wait, **Mongrel** is serving files? Nobody sees the problem with that? This isn't a best practice at all, so first quit doing that and then see if the problem persists. There's nothing Mongrel can do if you overload the Ruby interpreter with simple file requests that LSWS could handle. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From zedshaw at zedshaw.com Tue Oct 30 08:50:15 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 30 Oct 2007 08:50:15 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: <8EFBA4B1-CB2E-47A4-AA4C-933D02DF3082@gmail.com> References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <47264245.4050706@robmela.com> <47266A63.5020600@hotgazpacho.com> <8EFBA4B1-CB2E-47A4-AA4C-933D02DF3082@gmail.com> Message-ID: <20071030085015.b88715ab.zedshaw@zedshaw.com> On Tue, 30 Oct 2007 10:53:29 +1100 Clifford Heath wrote: > Surely it's preferable to just delay the accept() until there's a > thread to > assign it to? That way the client sees a slow connection-establishment > and can draw their own conclusions, including deciding how long to > wait or whether to retry. No, then the load balancer gets bound waiting for a response from a backend that can't respond. This causes the load balancer to get a ton of dead sockets. The LB should take the closed connection to mean "backend screwed, try again" and move to the next one. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From zedshaw at zedshaw.com Tue Oct 30 08:52:11 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 30 Oct 2007 08:52:11 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: <836F8EDF-C144-4738-AEDE-5C3B387BF00C@cheney.net> <47264245.4050706@robmela.com> <47266A63.5020600@hotgazpacho.com> <8EFBA4B1-CB2E-47A4-AA4C-933D02DF3082@gmail.com> <472686CC.4020702@robmela.com> Message-ID: <20071030085211.049436d5.zedshaw@zedshaw.com> On Mon, 29 Oct 2007 21:27:52 -0400 "Evan Weaver" wrote: > I think currently it accepts the connection and then immediately > closes it, which is not consistent with the spec. It can't close a connection it hasn't accepted yet, and in practice you find that your LB gets overloaded if you don't close it right away. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From zach at plugthegap.co.uk Tue Oct 30 09:19:24 2007 From: zach at plugthegap.co.uk (Zachary Powell) Date: Tue, 30 Oct 2007 09:19:24 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: <20071030085211.049436d5.zedshaw@zedshaw.com> References: <47264245.4050706@robmela.com> <47266A63.5020600@hotgazpacho.com> <8EFBA4B1-CB2E-47A4-AA4C-933D02DF3082@gmail.com> <472686CC.4020702@robmela.com> <20071030085211.049436d5.zedshaw@zedshaw.com> Message-ID: Wow, triggered a whole discussion there (most of which was over my head, at least at this hour). I've bumped it up to four mongrels to see if that solves the problem (temporarily) and I'll turn the mongrel.log debug on and see what I can find. Thanks all, Zach On 10/30/07, Zed A. Shaw wrote: > > On Mon, 29 Oct 2007 21:27:52 -0400 > "Evan Weaver" wrote: > > > I think currently it accepts the connection and then immediately > > closes it, which is not consistent with the spec. > > It can't close a connection it hasn't accepted yet, and in practice you > find that your LB gets overloaded if you don't close it right away. > > -- > Zed A. Shaw > - Hate: http://savingtheinternetwithhate.com/ > - Good: http://www.zedshaw.com/ > - Evil: http://yearofevil.com/ > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071030/43112226/attachment.html From flujan at gmail.com Tue Oct 30 12:46:40 2007 From: flujan at gmail.com (Fernando Lujan) Date: Tue, 30 Oct 2007 14:46:40 -0200 Subject: [Mongrel] WebDav Support. Message-ID: <631837390710300946t133ce46bif10d1fd945a59f6f@mail.gmail.com> Hi guys, I read that mongrel supports the webdav protocol. I need to "create" the webdav files and allow a third party app access it just for read purposes. What do you recommend? -- Fernando Lujan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20071030/1527bd35/attachment.html From erik.hetzner at ucop.edu Tue Oct 30 13:44:08 2007 From: erik.hetzner at ucop.edu (Erik Hetzner) Date: Tue, 30 Oct 2007 10:44:08 -0700 Subject: [Mongrel] WebDav Support. In-Reply-To: <631837390710300946t133ce46bif10d1fd945a59f6f@mail.gmail.com> References: <631837390710300946t133ce46bif10d1fd945a59f6f@mail.gmail.com> Message-ID: <87ir4oijkn.wl%erik.hetzner@ucop.edu> At Tue, 30 Oct 2007 14:46:40 -0200, "Fernando Lujan" wrote: > Hi guys, > > I read that mongrel supports the webdav protocol. I need to "create" the > webdav files and allow a third party app access it just for read purposes. > > What do you recommend? Hi Fernando. Unfortunately, you are incorrect. Mongrel is a web server for Ruby, and does not provide an implementation of the WebDAV protocol. You could of course write a WebDAV server for Mongrel, but that would take some effort. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071030/610f7361/attachment.bin From evan at cloudbur.st Tue Oct 30 14:42:11 2007 From: evan at cloudbur.st (Evan Weaver) Date: Tue, 30 Oct 2007 14:42:11 -0400 Subject: [Mongrel] Problems with mongrel on NetBSD In-Reply-To: <20071030083419.48f521ff.zedshaw@zedshaw.com> References: <4787b24d0710291517o5aac1f05r349ae1f5e207270d@mail.gmail.com> <4787b24d0710291709r76f70b4cv769666faa78b38e1@mail.gmail.com> <4787b24d0710300112k56775acck688ad09575eaa6de@mail.gmail.com> <4787b24d0710300133o46f632d4o519a38a812490672@mail.gmail.com> <20071030083419.48f521ff.zedshaw@zedshaw.com> Message-ID: If 1.0.4 fixed the problem, then that suggests that BSD binds to IP6 only by default for new TCPSockets, which seems like an odd decision. Evan On Oct 30, 2007 8:34 AM, Zed A. Shaw wrote: > On Tue, 30 Oct 2007 03:33:51 -0500 > "Michael Graff" wrote: > > > And it seems 1.0.4 works again. Whatever was fixed, it made NetBSD at > > least bind to IPv4 when passed 0.0.0.0 or 127.0.0.1 as an IP address. > > > > Does Mongrel do IPv6 well? > > Mongrel does whatever Ruby supports, nothing fancy or any special tricks on binding for NetBSD. > > I think there might have been an overzealous change to the *BSD camp that's enabled ipv6 by default and ruby has yet to catch up. Do you know of any NetBSD posts related to ipv6 and required socket code changes? > > -- > Zed A. Shaw > - Hate: http://savingtheinternetwithhate.com/ > - Good: http://www.zedshaw.com/ > - Evil: http://yearofevil.com/ > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC From mrueckert at suse.de Tue Oct 30 15:25:49 2007 From: mrueckert at suse.de (Marcus Rueckert) Date: Tue, 30 Oct 2007 20:25:49 +0100 Subject: [Mongrel] Problems with mongrel on NetBSD In-Reply-To: References: <4787b24d0710291517o5aac1f05r349ae1f5e207270d@mail.gmail.com> <4787b24d0710291709r76f70b4cv769666faa78b38e1@mail.gmail.com> <4787b24d0710300112k56775acck688ad09575eaa6de@mail.gmail.com> <4787b24d0710300133o46f632d4o519a38a812490672@mail.gmail.com> <20071030083419.48f521ff.zedshaw@zedshaw.com> Message-ID: <20071030192549.GD5865@suse.de> On 2007-10-30 14:42:11 -0400, Evan Weaver wrote: > If 1.0.4 fixed the problem, then that suggests that BSD binds to IP6 > only by default for new TCPSockets, which seems like an odd decision. the issue might be that tcpsocket in ruby binds to ipv6 by default. which is no problem on e.g. linux as it by default has enabled ipv4 in ipv6 mapping. on bsd it is off by default. maybe you run into that issue. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From neongrau at gmail.com Tue Oct 30 15:50:05 2007 From: neongrau at gmail.com (Ralf Vitasek) Date: Tue, 30 Oct 2007 20:50:05 +0100 Subject: [Mongrel] WebDav Support. In-Reply-To: <87ir4oijkn.wl%erik.hetzner@ucop.edu> References: <631837390710300946t133ce46bif10d1fd945a59f6f@mail.gmail.com> <87ir4oijkn.wl%erik.hetzner@ucop.edu> Message-ID: <7adba8e60710301250k309f5e59j648f4202a271d94e@mail.gmail.com> have a look at http://wiki.rubyonrails.org/rails/pages/WebDAV On 10/30/07, Erik Hetzner wrote: > At Tue, 30 Oct 2007 14:46:40 -0200, > "Fernando Lujan" wrote: > > Hi guys, > > > > I read that mongrel supports the webdav protocol. I need to "create" the > > webdav files and allow a third party app access it just for read purposes. > > > > What do you recommend? > > Hi Fernando. > > Unfortunately, you are incorrect. Mongrel is a web server for Ruby, > and does not provide an implementation of the WebDAV protocol. You > could of course write a WebDAV server for Mongrel, but that would take > some effort. > > best, > Erik Hetzner > ;; Erik Hetzner, California Digital Library > ;; gnupg key id: 1024D/01DB07E3 > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > > From zedshaw at zedshaw.com Tue Oct 30 21:06:53 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Tue, 30 Oct 2007 21:06:53 -0400 Subject: [Mongrel] random cpu spikes, EBADF errors In-Reply-To: References: <47264245.4050706@robmela.com> <47266A63.5020600@hotgazpacho.com> <8EFBA4B1-CB2E-47A4-AA4C-933D02DF3082@gmail.com> <472686CC.4020702@robmela.com> <20071030085211.049436d5.zedshaw@zedshaw.com> Message-ID: <20071030210653.fa65c1be.zedshaw@zedshaw.com> On Tue, 30 Oct 2007 09:19:24 -0400 "Zachary Powell" wrote: > Wow, triggered a whole discussion there (most of which was over my head, at > least at this hour). I've bumped it up to four mongrels to see if that > solves the problem (temporarily) and I'll turn the mongrel.log debug on and > see what I can find. It is a common issue though with the HTTP RFC and what load balancers should be doing. Effectively, the RFC describes a web server, proxy, and client, but not really an LB of any kind. When people follow the RFC they get some dumb behaviors from their web server that shouldn't apply to an LB. For example, many web servers will take the 503 responses from the backends and then show them to the end user, which if you read the RFC is kind of right but really wrong (it should try again). Others will take the RFC literally and make a connection to a backend then hang out, which is wrong in a practical sense since that means a mis-configured backend can cripple the LB. Imagine if the LB had to wait for the "official" TCP timeout of anywhere from 60 seconds to 200,000 days depending on the operating system. (Yes pedants, that's exagerated.) There's also practical considerations when dealing with heavy loaded network servers in general. I believe that the HTTP people got this one all wrong in that they require a response, but logically if your server is overloaded, you can't give a response. So yes, you started a useful conversation since people are going to keep hitting this over and over. The solution of course is the following: ** The HTTP RFC doesn't cover load balancers (or even proxy servers) in any sufficient detail to be useful. ** That's the gist of it really. Let us know what comes of your changes. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/ From wallenberg at gmail.com Wed Oct 31 10:21:11 2007 From: wallenberg at gmail.com (Squeak Smalltalk) Date: Wed, 31 Oct 2007 15:21:11 +0100 Subject: [Mongrel] Is it possible to ? Message-ID: Hi, Can I use mongrel for ? Preprocessing an url ? What I need todo is : 1- When a user connect to an Specific url. 2- Connect to a site an other site with login 3- And redirect this user to the site on step 2 Any advice will be nice ;) W. From filipe at icewall.org Tue Oct 30 07:25:28 2007 From: filipe at icewall.org (Filipe) Date: Tue, 30 Oct 2007 09:25:28 -0200 (BRST) Subject: [Mongrel] Problems with mongrel on NetBSD In-Reply-To: <4787b24d0710300133o46f632d4o519a38a812490672@mail.gmail.com> References: <4787b24d0710291517o5aac1f05r349ae1f5e207270d@mail.gmail.com> <4787b24d0710291709r76f70b4cv769666faa78b38e1@mail.gmail.com> <4787b24d0710300112k56775acck688ad09575eaa6de@mail.gmail.com> <4787b24d0710300133o46f632d4o519a38a812490672@mail.gmail.com> Message-ID: On Tue, 30 Oct 2007, Michael Graff wrote: > And it seems 1.0.4 works again. Whatever was fixed, it made NetBSD at > least bind to IPv4 when passed 0.0.0.0 or 127.0.0.1 as an IP address. > > Does Mongrel do IPv6 well? I hope so. if it is doing ipv6 when we DON'T want, just imagine what mongrel will do when we WANT it to do it :D Is like when you throw a ball to a mongrel and he brings it back to you, even without you teaching him ;) Good mongrel, good. filipe { @ icewall.org GPG 1024D/A6BA423E Jabber lautert at jabber.ru }