Using Phusion Passenger (a.k.a. mod_rails)

The Brightbox Gem supports using Phusion Passenger by default, mongrel based configurations are still supported but no longer the default.

We have apt packages available for Ruby Enterprise Edition and there is more information on setting your Brightbox up to use Ruby Enterprise Edition with Passenger over on the Ruby Enterprise Packages page.

Configuring a fresh deployment to use passenger

The Brightbox gem has an option to specify either “passenger” or “mongrel” based on your preference. If no option is specified then Passenger is used by default.

  brightbox -i -a passenger .

This will create the file config/deploy.rb containing the details needed to deploy your application. Edit this file and change the settings as required.

Passenger Deployment options

set :passenger_restart_strategy, :hard

By default, restarting passenger requires creating a file called “restart.txt” which signals the application to gracefully restart. The old passenger processes then time out after 10 minutes of inactivity. Unfortunately this results in stale database connections using up your Brightbox MySQL connection allowance so by default we perform a more immediate “kill” of the passenger processes before starting new ones. Should you have enough database connections or experience problems with the default you can change the above option to :soft to restart in the normal manner.

Controlling the number of Passenger processes

Passenger, by default, is configured to spawn up to six ruby processes to handle incoming requests. If you are using Ruby on Rails, each ruby process can be between 50 and 100Mb in size - and this can cause Out of Memory errors on smaller boxes. These manifest as 500 errors, “broken pipe” messages or, in the worst cases, Apache or the ssh daemon shutting down (requiring a reboot).

In order to limit the number of processes that Passenger creates, there are two directives that can be applied. We normally create an extra configuration file in /etc/apache2/conf.d/passenger.conf (this needs to be created as root) with the following contents:

PassengerMaxPoolSize 4
PassengerMaxInstancesPerApp 2
PassengerPoolIdleTime 300

(Phusion recommend that PassengerMaxPoolSize should be no more than 2 for a 256Mb box, although the actual memory usage of your application will govern the optimum value)

You will then need to reload Apache to tell it to pick up the new settings.

The configuration above means that Passenger will create up to two ruby processes for each application on that box, with no more than four ruby processes in action at any one time. If a ruby process is left idle for more than 300 seconds it will be killed, releasing its memory.

Converting from mongrel to passenger

There is no automated way to move from mongrel to passenger at this time, instead you will have to follow the steps below to setup your existing application to use passenger. This process will cause some downtime for you application while things are swapped over.

On your Brightbox
  1. Ensure you are running at least Ubuntu Hardy 8.04 (cat /etc/lsb-release)
  2. Issue the command sudo monit -g <yourapp> stop all
  3. Delete the /etc/monit/conf.d/rails-<yourapp>.monitrc file
  4. Issue the command sudo monit reload
On your development machine
  1. Copy your deploy.rb over to a backup cp config/deploy.rb config/deploy.rb.old
  2. Re-run the brightbox command as detailed for a new customer using passenger
  3. Copy any custom command from your deploy.rb.old over to your new deploy file
  4. Run cap deploy:initial to run the installation procedure from scratch
  5. Your Brightbox should now be setup to run your application using passenger
docs/gemv2/passenger.txt · Last modified: 2012/04/10 17:49 by johnleach

UK Cloud Server Hosting & Cloud Hosting Providers - Brightbox Cloud

Simple and flexible UK cloud hosting for teams that insist on 100% uptime. Everything you need to deliver fast and highly available apps that delight your customers.

Get started now risk-free with £20 free credit.

Trusted by developers, big brands and people like you

512MB @brightbox cloud instance snapshotted, loaded onto new 2gb instance and cloud ip remapped. All without anyone noticing. ;)

Latest blog posts

Building a scaleable filesystem with S3QL and Orbit

All our Cloud Servers come with resilient local permanent disks, stored on SSDs in a RAID configuration. For periodic backups, you can use our server snapsho...

Read blog post

NixOS on Brightbox Cloud

NixOS is a Linux distribution that is configured using a functional language in a declarative way. I’ve been using it here at Brightbox as my main developme...

Read blog post

Scheduled snapshots for Cloud SQL

We’ve just added a new scheduled snapshots feature to Cloud SQL, our hassle-free MySQL cloud database service. Cloud SQL has always supported manually takin...

Read blog post

More blog posts...

Get started with Brightbox Sign up takes just two minutes...