Tag Archive - ruby

a bit technical ; nginx, passenger, 4gb seg fixup

Lets dwell into the technical world that had me captive for a couples hours, last week:

The installation of NGINX & Phusion Passenger should be very straight forward and no cause for a blog post. Except, and the fun start here, if you are compiling both from source, inside Amazon AWS, on a small EC2 instance (32 bits) and your dom0 is 64bits (no way of knowing, but most should) and Amazon gave you a slice of memory over the 4gb of normally addressable slot (small windows of opportunity, but still). How bad can it get ? Well, you will be flooded by the dreaded “4gb seg fixup” error message in your log files and your ruby process will drop to an almost standstill speed.

Your god, Google, will advice you to do stuff (which you should have already tried):

apt-get install libc6-xen

echo ‘hwcap 0 nosegneg’ > /etc/ld.so.conf.d/libc6-xen.conf ; ldconfig

mv /lib/tls /lib/tls.disabled

And this is where you will start to despair, because, of the 26 200 Google results for “4gb seg fixup“, 26 000 are either linking to a post asking the same question or answering with one of those two answers and 200 are for 4gb usb key. Neither of which will help the message to go away from your syslog and bring it back NGINX/Ruby to decent speed.

So. At this point, where you are starting to think about wiping everything and starting back from scratch (which won’t help), try this little procedure. The principle is to remove the passenger gem from your system, reinstall it (which will only download the source), modify the makefile, recompile NGINX (which in turn automatically compile the Phusion Passenger module) and take a beer while your system serve ruby pages without (systems) errors.

#> gem uninstall passenger
#> gem install passenger

We have a valid passenger gem source code in /var/lib/gems/1.8/gems/passenger-2.2.4 - version can vary and location is valid for Ubuntu/Debian, but could change on others distro. We will be modifying the optimization flags given to the compiler. Since Phusion Passenger does not accept command line argument and variables declarations, we have no other choices than to modify the rake file pre-compilation.

#> sed ‘s/EXTRA_CXXFLAGS = “-Wall #{OPTIMIZATION_FLAGS}”/EXTRA_CXXFLAGS = “-Wall -mno-tls-direct-seg-refs #{OPTIMIZATION_FLAGS}”/g’ /tmp/rakefile

#> mv /tmp/rakefile /var/lib/gems/1.8/gems/passenger-2.2.4/Rakefile

This being done, we will start an NGINX compilation process which will, in turn, start passenger-2.2.4 compilation. Using the -mno-tls-direct-seg-refs will allows us to work arround the 4gb seg fixup error.

#> CFLAGS=”-mno-tls-direct-seg-refs” CXXFLAGS=”-mno-tls-direct-seg-refs” ./configure –prefix=’/usr/local/nginx-0.7.61′ –add-module=’/var/lib/gems/1.8/gems/passenger-2.2.4/ext/nginx’ –with-http_ssl_module –with-http_stub_status_module

There you go.

RubyGems management

RubyGems management

fire0# gem list | wc -l
36

This is not one of those “big” servers with hundred of applications: There are only three of them and those 36 gems are dependencies to keep everything running. I am not even counting their multiple installed versions. This is a normal situation that happen quite often when developing new applications – gems get tested, accepted, refused, modified, re-installed, updated… but rarely uninstalled.

So, how do we manage them ? Here is 3 systems I use:

1. Using your own gem repository.

It is really easier to maintain a ‘clean’ list of gems on your production servers if you only have one source, which is under your direct control. It is also a good incentive to do some QA, before putting new libraries into production. Here is an example deployement of a ‘home’ repository to distribute the tmm1-amqp gem:

fire0# mkdir -p /var/www/gems_repository/gems
fire0# cd !$
fire0# gem fetch tmm1-ampq -s http://gems.github.com
fire0# cd ..
fire0# gem generate_index
fire0# gem server &

Note: If a web server is installed (apache, nginx, …), create a new vhost and you won’t need the “gem server” command, since the repository communicate through standard http protocol. While you can add as many gems you want in /var/ww/gems_repostory/gems, don’t forget to run the “gem generate_index” (in /var/www/gems_repository) to keep your index up to date. You can also fetch specific gems version using the “-v” flag to the fetch command.

On your servers (or localhost if you have only one environment), adding your new gems repository as a permanent sources can be accomplished with this command:

air0# gem sources -a http://your_gems_server:8088

or you can install specific gems by mentioning the correct source :

air0# gem install tmm1-amqp -s http://your_gems_server:8088

2. Using “gem stale”

This is a new command I’ve discovered in the ‘gem help commands’ output. It give the last access date of every installed gems. This info is version specific… hence it shows dependencies on specifics, old version, gems or unused one. Try it:

fire0# gem stale

note: this command was added RubyGems >= 1.2.0, you might need to update to use it.

3. Using “gem outdate”

This command will dump a list of the gems for which you have available update (through your sources).

Une section de ma vie

A partir de hier:

    – Dans le jour : Benchmark d’application Ruby & des nouveaux services d’Amazon (ip statique et zone d’availability).
    – En soire : Mise en production d’un cloud.
    – En fin de soire : Ecriture d’un article pour un magazine europeen.
    – dodo
    – Ce matin ; deploiement de STP.   
  
J’adore ma vie ;-)

-

Edit:
HUMMMFFF… je viens de voir que googleDocs possede maintenant une nouvelle fonction : Dans un docs, faire File -> "New Airplane".  Ce n’est pas MON poisson d’avril, jure!