<h3>Perl 便利情報・足りないライブラリを自動でインストールする</h3>
<p>岐阜さんの lib::xi つかうと良いらしい</p>
<ul>
<li><a href="http://d.hatena.ne.jp/gfx/20110318/1300419163">http://d.hatena.ne.jp/gfx/20110318/1300419163</a></li>
</ul>
<p>OS 標準の Perl 使ってる Perl 情弱の僕は</p>
<pre><code>perl -Mlib::xi=--force,--sudo,--notest ./app.pl
</code></pre>
<p>的な実行で何も考えず全部かんたんに突っ込みました便利!!</p>
<p>美顔器さんに教えて貰いました。</p>
<pre><code>13:58 ^2ndlife: いま perl って、モジュール足りないときいろいろがーっといれてくれる良い仕組みってあるんだっけ
13:58 ^2ndlife: Can't locale ライブラリ時にがつがついれてくれるとかそういう
13:58 motemen: git clone して cpanm --installdeps . とかでちゃんとはいるはずですが、だめなら
13:58 motemen: lib::xi というのがあって
13:58 motemen: perl -Mlib::xi hogehoge.pl
13:58 motemen: でがっとやってくれます
13:59 ^2ndlife: まじっすかかっっこいい
</code></pre>

Perl 便利情報・足りないライブラリを自動でインストールする岐阜さんの lib::xi つかうと良いらしいhttp://d.hatena.ne.jp/gfx/20110318/1300419163OS 標準の Perl 使ってる Perl 情弱の僕はperl -Mlib::xi=--force,--sudo,--notest ./app.pl的な実行で何も考えず全部かんたんに突っ込みました便利!!美顔器さんに教えて貰いました。13:58 ^2ndlife: いま perl って、モジュール足りないときいろいろがーっといれてくれる良い仕組みってあるんだっけ
13:58 ^2ndlife: Can't locale ライブラリ時にがつがついれてくれるとかそういう
13:58 motemen: git clone して cpanm --installdeps . とかでちゃんとはいるはずですが

Perl 便利情報・足りないライブラリを自動でインストールする岐阜さんの lib::xi つかうと良いらしいhttp://d.hatena.ne.jp/gfx/20110318/1300419163OS 標準の Perl 使ってる Perl 情弱の僕はperl -Mlib::xi=--force,--sudo,--notest ./app.pl的な実行で何も考えず全部かんたんに突っ込みました便利!!美顔器さんに教えて貰いました。13:58 ^2ndlife: いま perl って、モジュール足りないときいろいろがーっといれてくれる良い仕組みってあるんだっけ
13:58 ^2ndlife: Can't locale ライブラリ時にがつがついれてくれるとかそういう
13:58 motemen: git clone して cpanm --installdeps . とかでちゃんとはいるはずですが、だめなら
13:58 motemen: lib::xi というのがあって
13:58 motemen: perl -Mlib::xi hogehoge.pl
13:58 motemen: でがっとやってくれます
13:59 ^2ndlife: まじっすかかっっこいい

Perl 便利情報・足りないライブラリを自動でインストールする

<h3>Ruby で並列実行処理を簡単に書く</h3>
<p>Ruby は 1.8 だとグリーンスレッドだし、1.9 でも Giant VM lock のためネイティブスレッドの実行は一つのため、マルチコアを生かした処理をかんたんに書くのがいささか面倒だったりしますね。</p>
<p>で、 parallel というライブラリを使うと fork を使って抽象化してくれるのですごく簡単にかける。</p>
<ul>
<li><a href="https://github.com/grosser/parallel">https://github.com/grosser/parallel</a></li>
</ul>
<p>ふつうに Parallel#each/map の中で並列処理させたいコードを書くだけ。戻り値が #map なら取得できる。 以下は zlib で gzip 圧縮させた結果。</p>
<pre><code>require 'rubygems'
require 'parallel'
require 'pathname'
require 'benchmark'
require 'zlib'

compress_files = lambda {|file|
  Zlib::GzipWriter.open(file.realpath.to_s + '.gz') {|gz| gz.puts file.read }
}

puts "#{Parallel.processor_count} procesor(s)"

files = Pathname.glob('*.log')

Benchmark.bm do |x|
  x.report('normal') { 
    files.each &#x26;compress_files
  }
  x.report('thread') { 
    Parallel.each(files, :in_threads => Parallel.processor_count, &#x26;compress_files)
  }
  x.report('fork') { 
    Parallel.each(files, &#x26;compress_files)
  }
end
</code></pre>
<p>CPU が i7 の環境(2コア・仮想4スレッド)では</p>
<pre><code>4 procesor(s)
      user     system      total        real
normal 16.740000   2.100000  18.840000 ( 19.154235)
thread 19.550000   2.350000  22.050000 ( 24.297111)
fork  0.010000   0.040000  27.890000 ( 12.871694)
</code></pre>
<p>と、19秒強 -> 13秒弱と簡単に速度を上げることができた。みんな大好き parallel_test も内部では parallel を利用している。べんり。</p>
<p>あと Thread での並列処理も抽象化も簡単に書けるので、select で IO 待ちするような処理も直感的に書いてスピードアップできる。</p>
<pre><code>require 'rubygems'
require 'parallel'
require 'open-uri'

urls = (1..10).map {|i| "http://example.com/?query=#{i}" }
results = Parallel.map(urls, :in_threads => 10) {|url|
  puts "download: #{url}"
  body = open(url).read
  puts "downloaded: #{url}"
  body
}
</code></pre>
<p>Thread で 10並列でダウンロードで全部結果が帰ってきたら次、みたいな。</p>
<pre><code>download: http://example.com/?query=1
download: http://example.com/?query=2
download: http://example.com/?query=3
download: http://example.com/?query=4
download: http://example.com/?query=5
download: http://example.com/?query=6
download: http://example.com/?query=7
download: http://example.com/?query=8
download: http://example.com/?query=9
download: http://example.com/?query=10
downloaded: http://example.com/?query=2
downloaded: http://example.com/?query=5
downloaded: http://example.com/?query=4
downloaded: http://example.com/?query=1
downloaded: http://example.com/?query=9
downloaded: http://example.com/?query=7
downloaded: http://example.com/?query=3
downloaded: http://example.com/?query=8
downloaded: http://example.com/?query=10
downloaded: http://example.com/?query=6
</code></pre>

Ruby で並列実行処理を簡単に書くRuby は 1.8 だとグリーンスレッドだし、1.9 でも Giant VM lock のためネイティブスレッドの実行は一つのため、マルチコアを生かした処理をかんたんに書くのがいささか面倒だったりしますね。で、 parallel というライブラリを使うと fork を使って抽象化してくれるのですごく簡単にかける。https://github.com/grosser/parallelふつうに Parallel#each/map の中で並列処理させたいコードを書くだけ。戻り値が #map なら取得できる。 以下は zlib で gzip 圧縮させた結果。require 'rubygems'
require 'parallel'
require 'pathname'
require 'benchmark'
require 'zlib'

compress_f

Ruby で並列実行処理を簡単に書くRuby は 1.8 だとグリーンスレッドだし、1.9 でも Giant VM lock のためネイティブスレッドの実行は一つのため、マルチコアを生かした処理をかんたんに書くのがいささか面倒だったりしますね。で、 parallel というライブラリを使うと fork を使って抽象化してくれるのですごく簡単にかける。https://github.com/grosser/parallelふつうに Parallel#each/map の中で並列処理させたいコードを書くだけ。戻り値が #map なら取得できる。 以下は zlib で gzip 圧縮させた結果。require 'rubygems'
require 'parallel'
require 'pathname'
require 'benchmark'
require 'zlib'

compress_files = lambda {|file|
  Zlib::GzipWriter.open(file.realpath.to_s + '.gz') {|gz| gz.puts file.read }
}

puts "#{Parallel.processor_count} procesor(s)"

files = Pathname.glob('*.log')

Benchmark.bm do |x|
  x.report('normal') { 
    files.each &compress_files
  }
  x.report('thread') { 
    Parallel.each(files, :in_threads => Parallel.processor_count, &compress_files)
  }
  x.report('fork') { 
    Parallel.each(files, &compress_files)
  }
endCPU が i7 の環境(2コア・仮想4スレッド)では4 procesor(s)
      user     system      total        real
normal 16.740000   2.100000  18.840000 ( 19.154235)
thread 19.550000   2.350000  22.050000 ( 24.297111)
fork  0.010000   0.040000  27.890000 ( 12.871694)と、19秒強 -> 13秒弱と簡単に速度を上げることができた。みんな大好き parallel_test も内部では parallel を利用している。べんり。あと Thread での並列処理も抽象化も簡単に書けるので、select で IO 待ちするような処理も直感的に書いてスピードアップできる。require 'rubygems'
require 'parallel'
require 'open-uri'

urls = (1..10).map {|i| "http://example.com/?query=#{i}" }
results = Parallel.map(urls, :in_threads => 10) {|url|
  puts "download: #{url}"
  body = open(url).read
  puts "downloaded: #{url}"
  body
}Thread で 10並列でダウンロードで全部結果が帰ってきたら次、みたいな。download: http://example.com/?query=1
download: http://example.com/?query=2
download: http://example.com/?query=3
download: http://example.com/?query=4
download: http://example.com/?query=5
download: http://example.com/?query=6
download: http://example.com/?query=7
download: http://example.com/?query=8
download: http://example.com/?query=9
download: http://example.com/?query=10
downloaded: http://example.com/?query=2
downloaded: http://example.com/?query=5
downloaded: http://example.com/?query=4
downloaded: http://example.com/?query=1
downloaded: http://example.com/?query=9
downloaded: http://example.com/?query=7
downloaded: http://example.com/?query=3
downloaded: http://example.com/?query=8
downloaded: http://example.com/?query=10
downloaded: http://example.com/?query=6

Ruby で並列実行処理を簡単に書く

<p>最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですが<a href="#f1" title="Rails 2.3 -> 3 移行はクックパッド規模になるとかなり大変でしたが、いろいろな面白いアプローチを試せたので、これはこれで何処かでお話ししたいですね">*1</a>、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。</p>
<p>そこで Ruby インタプリタの変更<a href="#f2" title=" Ruby 1.9.2 化も考えましたが、テスト通すまでまただいぶ時間がかかる＆いっぺんにやると問題切り分けが難しいので一緒にアップグレードすることは見送りました ">*2</a>を行い検証をしたところ</p>
<ul>
<li>MRI 1.8.7
<ul>
<li>(Rails 2.3と比べ) 約200%遅い</li>
</ul>
</li>
<li>MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 無効)
<ul>
<li>約180%低速</li>
</ul>
</li>
<li>MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 有効)
<ul>
<li>約140%低速</li>
</ul>
</li>
</ul>
<p>のような感じで、無視できないほど速度が遅く、これではリリースが危ぶまれました。なお、どこで速度が遅いのかというと、GC の実行でだいぶ時間を使っていました。Rails3 でオブジェクトが増えたため、より GC の実行時間がかかる様になってしまったようです。</p>
<h4>Unicorn の導入</h4>
<p>次にアプリケーションサーバを Apache + Passenger の組み合わせから Nginx + Unicorn の組み合わせに変更しました。Unicorn について簡単に説明すると、Rack 環境をロードした master プロセスが fork して子の worker を作るため、以下の様な特性を持ちます。</p>
<ul>
<li>fork による worker 生成のため、子 worker の起動が高速
<ul>
<li>そのため再起動が高速になり、再起動時のサーバ負荷が少ない</li>
<li>ただユーザからの処理を捌かない master プロセスが必ず存在するため、メモリ使用量が1プロセス分増える</li>
</ul>
</li>
<li>epoll / libev 等のイベントでうまく複数接続を捌くモデルでなく、worker 1プロセス1接続のため安定性が向上する
<ul>
<li>そのため、大量のコネクションを要求する必要なウェブサービスには向かない</li>
</ul>
</li>
</ul>
<p>Unicorn の特徴について、より詳しくは以下のエントリーで述べられてます。</p>
<ul>
<li><a href="http://d.hatena.ne.jp/tkng/20100707/1278517873">UnicornでSinatraアプリをデプロイしてみた - 射撃しつつ前転</a></li>
</ul>
<p>実際に Apache + Passenger の組み合わせから Nginx + Unicorn の組み合わせにすると、わずかにスループットが上がるなあ、といった感じで大きなパフォーマンス改善は見られませんでした。これは Unicorn の特性が高速化よりも安定性や再起動時のメリット<a href="#f3" title=" graceful な再起動がほとんどエラーや負荷無く行える重要性は、ウェブサービスを運用してる方なら解ると思います ">*3</a>、シグナルを送るだけで操作できるシンプルさに重みが置かれてるからで、Rack というインターフェイスを通して操作される Ruby アプリケーションの直接的な速度にはあまり関わってこないことを考えても納得の結果でした。</p>
<h4>明示的な GC.start</h4>
<p>しかし Unicorn について調べている途中、<a href="http://unicorn.bogomips.org/TUNING.html">Tuning Unicorn</a> で <a href="http://unicorn.bogomips.org/Unicorn/OobGC.html">Unicorn::OobGC</a> という面白いアプローチを見つけました。<br>
これは指定のリクエスト回数アプリケーションが処理を終えたら、ユーザにコンテンツを返した後に明示的に GC.start するというアプローチです。何が良いのかというと、GC がユーザのリクエスト外で実行するため、リクエスト中の処理では GC が走りにくくなり、結果ユーザへのレスポンス返却速度が高速化されるというわけです。<br>
これを適用したところ、140%ぐらい遅かった速度が 130%ほどへとわずかに高速化されました。たぶん小規模なアプリケーションだと効果が結構見込めそうなのですが、メモリをだいぶ食ってる大規模なアプリケーションだとこれを使っても GC が頻繁に実行され、結果あまり速くならないようでした。</p>
<h4>GC を止める</h4>
<p>ここでいっそ GC.disable でユーザからのリクエスト処理中は GC を止めてしまい、リクエスト外で GC をしたらどうなるか、と思いついたので試してみました。<br>
Unicorn は worker が master から fork される特徴があり、fork した直後のプロセスに対して設定で処理を書けるので、unicorn.conf.rb の設定に</p>
<pre><code>after_fork do |server, worker|
  GC.disable if RAILS_ENV == 'production'
</code></pre>
<p>の、GC.disable で GC が走らない様にする処理を入れ、OobGC のコードを GC.disable 時にも GC.start を実行できる様に変更し、その後再度 GC.disable で止める処理を入れました。</p>
<ul>
<li><a href="https://github.com/defunkt/unicorn/commit/c7ba76a21c5d00fb5c173cd6aa847442bbc652cb">https://github.com/defunkt/unicorn/commit/c7ba76a21c5d00fb5c173cd6aa847442bbc652cb</a>
<ul>
<li>unicorn の master ブランチに入ってるので、次のリリース(バージョン 4.1.2 ?) には取り込まれると思います</li>
</ul>
</li>
</ul>
<p>この GC.disable のベンチマークを結果は以下です。<br>
<a href="http://f.hatena.ne.jp/secondlife/20111006173812"><img src="http://cdn-ak.f.st-hatena.com/images/fotolife/s/secondlife/20111006/20111006173812.png" alt="f:id:secondlife:20111006173812p:image" title="f:id:secondlife:20111006173812p:image"></a><br>
赤のグラフが GC.disable しなかったサーバで、青のグラフが GC.disable するサーバです。あからさまに GC をユーザからのリクエスト処理中は無効化した方が断然高速な結果に終わりました。Rails 2.3 のサーバと比べても65%遅い、もとい150%ほど高速な結果となりました！！</p>
<h4>GC を止める Production のアプリケーションサーバに適用</h4>
<p>というわけで、このユーザのリクエスト処理中は GC を無効化する方法でだいぶ高速化することが解ったので、一足先に Unicorn 化していた Rails 2.3 サーバ(Ruby のバージョンは MRI 1.8.7 で Ruby Enterprise ではない)に適用したところ、それだけで 130% ほど高速化 &#x26; CPU 消費量が減る <a href="#f4" title=" CPU 使用率はあまり変わらないと思ってたんですが大きく減ったのが不思議な感じです… ">*4</a> という素晴らしい結果になりました。</p>
<div class="photos photos-medium photos-hatena"><span itemscope="" itemtype="http://schema.org/Photograph"><a href="http://cdn-ak.f.st-hatena.com/images/fotolife/s/secondlife/20111003/20111003181721.png"><img src="http://cdn-ak.f.st-hatena.com/images/fotolife/s/secondlife/20111003/20111003181721.png" class="photo" itemprop="image"></a></span></div>
<p>なお Rails3 ほど顕著に高速化しなかったのは、Rails3 にくらべメモリ使用量が少ないからかと思います。その後 Rails3 に刷新後は当初の Unicorn 化する以前の Rails 2.3 アプリに比べ、最終的に 150% ほど高速化しました。</p>
<h4>まとめ</h4>
<p>Web アプリケーションの速度の高速化は、IO 処理の高速化を除いてしまうと、チューニングすればするほど大きく改善する方法はなくなっていくと思ってましたが、ユーザのレスポンス処理中は GC を止め、その外で実行するだけで大きくパフォーマンスが改善しました。Ruby 1.8 系統を使ってるサービスは試してみる価値があると思います。<br>
なお今後リリースされる予定の Ruby 1.9.3 では nari3 が実装された Lazy Sweep GC が載るので、OobGC 的な事を Ruby 自体が行ってくれ、GC の最大実行時間が減ると思うので、Ruby 1.9 なサービスは 1.9.3 に変えるだけでパフォーマンス改善がされそうですね。</p>
<ul>
<li><a href="http://www.infoq.com/jp/news/2011/08/ruby193-gc">Ruby 1.9.3 Preview 1がリリース。Lazy Sweep GCにより、GCの停止時間が改善。</a></li>
</ul>
<h4>おまけ・運用ノウハウなど</h4>
<h5>メモリリークの対応</h5>
<p>GC.disable している期間が長いと、GC.start したときに元のコードがメモリリークしてると、よりそのメモリーを解放できない様な感じで、どんどん Rails アプリケーションのプロセスサイズが肥大化して行ってしまいました。<br>
Unicorn は worker プロセスに SIGQUIT を送ると、ユーザのリクエスト処理が終わった直後にプロセスが死んで、master プロセスがそれを検知してすぐに fork する仕組みがあるので、以下のユーティリティを書いて Rack レイヤーで対応しました。</p>
<ul>
<li><a href="https://gist.github.com/1258681">https://gist.github.com/1258681</a></li>
</ul>
<pre><code>use UnicornKiller::Oom, 400 * 1024 # 使用メモリが400Mを超えると自分自身に SIGQUIT
use UnicornKiller::MaxRequests, 1000 # 1000 回リクエストを超えると自分自身に SIGQUIT
</code></pre>
<p>プロセスを終了しても即座に fork で新しい worker が作られるため、こんな感じのざっくりとした対応でも問題無く運用できてます。</p>
<h5>Unicorn + bundler でのデプロイ時の問題</h5>
<p>突然はまるのでちゅうい…。特に Unicorn は master プロセスへの SIGUSR2 (graceful な再起動)で再起動に失敗した場合、何事もなかったのように昔のプロセスは正常に生き続けるため、ぱっと見問題に気づきません…。</p>
<ul>
<li><a href="http://blog.twiwt.org/e/2e6270"></a></li>
<li><a href="https://willj.net/2011/08/02/fixing-the-gemfile-not-found-bundlergemfilenotfound-error/"></a></li>
</ul>
<h5>アプリケーションサーバのベンチマークとパラメータの調整</h5>
<p>ベンチマークには最初 ab (apache bench) でいくつかの URL でベンチ、次に JMeter で本番リクエストの上位80%のリクエストをエミュレートしてベンチをとりました。環境さえ作ればあとは叩くだけなので、ab / JMeter を使いつつ、アプリケーションサーバのメモリー数、CPU の利用状況を見て Unicorn のプロセス数の調整と Ruby Enterprise Edition の GC 周りの環境変数を調整しました。<br>
この辺はサービスごとに最適値が違うと思うので、ちまちま数字変えてやるのが良いと思います。</p>
<p><a href="#fn1">*1</a>:Rails 2.3 -> 3 移行はクックパッド規模になるとかなり大変でしたが、いろいろな面白いアプローチを試せたので、これはこれで何処かでお話ししたいですね</p>
<p><a href="#fn2">*2</a>: Ruby 1.9.2 化も考えましたが、テスト通すまでまただいぶ時間がかかる＆いっぺんにやると問題切り分けが難しいので一緒にアップグレードすることは見送りました</p>
<p><a href="#fn3">*3</a>: graceful な再起動がほとんどエラーや負荷無く行える重要性は、ウェブサービスを運用してる方なら解ると思います</p>
<p><a href="#fn4">*4</a>: CPU 使用率はあまり変わらないと思ってたんですが大きく減ったのが不思議な感じです…</p>

最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですがRails 2.3 -> 3 移行はクックパッド規模になるとかなり大変でしたが、いろいろな面白いアプローチを試せたので、これはこれで何処かでお話ししたいですね、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。そこで Ruby インタプリタの変更 Ruby 1.9.2 化も考えましたが、テスト通すまでまただいぶ時間がかかる＆いっぺんにやると問題切り分けが難しいので一緒にアップ

最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですがRails 2.3 -> 3 移行はクックパッド規模になるとかなり大変でしたが、いろいろな面白いアプローチを試せたので、これはこれで何処かでお話ししたいですね、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。そこで Ruby インタプリタの変更 Ruby 1.9.2 化も考えましたが、テスト通すまでまただいぶ時間がかかる＆いっぺんにやると問題切り分けが難しいので一緒にアップグレードすることは見送りました を行い検証をしたところMRI 1.8.7(Rails 2.3と比べ) 約200%遅いMRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 無効)約180%低速MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 有効)約140%低速のような感じで、無視できないほど速度が遅く、これではリリースが危ぶまれました。なお、どこで速度が遅いのかというと、GC の実行でだいぶ時間を使っていました。Rails3 でオブジェクトが増えたため、より GC の実行時間がかかる様になってしまったようです。Unicorn の導入次にアプリケーションサーバを Apache + Passenger の組み合わせから Nginx + Unicorn の組み合わせに変更しました。Unicorn について簡単に説明すると、Rack 環境をロードした master プロセスが fork して子の worker を作るため、以下の様な特性を持ちます。fork による worker 生成のため、子 worker の起動が高速そのため再起動が高速になり、再起動時のサーバ負荷が少ないただユーザからの処理を捌かない master プロセスが必ず存在するため、メモリ使用量が1プロセス分増えるepoll / libev 等のイベントでうまく複数接続を捌くモデルでなく、worker 1プロセス1接続のため安定性が向上するそのため、大量のコネクションを要求する必要なウェブサービスには向かないUnicorn の特徴について、より詳しくは以下のエントリーで述べられてます。UnicornでSinatraアプリをデプロイしてみた - 射撃しつつ前転実際に Apache + Passenger の組み合わせから Nginx + Unicorn の組み合わせにすると、わずかにスループットが上がるなあ、といった感じで大きなパフォーマンス改善は見られませんでした。これは Unicorn の特性が高速化よりも安定性や再起動時のメリット graceful な再起動がほとんどエラーや負荷無く行える重要性は、ウェブサービスを運用してる方なら解ると思います 、シグナルを送るだけで操作できるシンプルさに重みが置かれてるからで、Rack というインターフェイスを通して操作される Ruby アプリケーションの直接的な速度にはあまり関わってこないことを考えても納得の結果でした。明示的な GC.startしかし Unicorn について調べている途中、Tuning Unicorn で Unicorn::OobGC という面白いアプローチを見つけました。これは指定のリクエスト回数アプリケーションが処理を終えたら、ユーザにコンテンツを返した後に明示的に GC.start するというアプローチです。何が良いのかというと、GC がユーザのリクエスト外で実行するため、リクエスト中の処理では GC が走りにくくなり、結果ユーザへのレスポンス返却速度が高速化されるというわけです。これを適用したところ、140%ぐらい遅かった速度が 130%ほどへとわずかに高速化されました。たぶん小規模なアプリケーションだと効果が結構見込めそうなのですが、メモリをだいぶ食ってる大規模なアプリケーションだとこれを使っても GC が頻繁に実行され、結果あまり速くならないようでした。GC を止めるここでいっそ GC.disable でユーザからのリクエスト処理中は GC を止めてしまい、リクエスト外で GC をしたらどうなるか、と思いついたので試してみました。Unicorn は worker が master から fork される特徴があり、fork した直後のプロセスに対して設定で処理を書けるので、unicorn.conf.rb の設定にafter_fork do |server, worker|
  GC.disable if RAILS_ENV == 'production'の、GC.disable で GC が走らない様にする処理を入れ、OobGC のコードを GC.disable 時にも GC.start を実行できる様に変更し、その後再度 GC.disable で止める処理を入れました。https://github.com/defunkt/unicorn/commit/c7ba76a21c5d00fb5c173cd6aa847442bbc652cbunicorn の master ブランチに入ってるので、次のリリース(バージョン 4.1.2 ?) には取り込まれると思いますこの GC.disable のベンチマークを結果は以下です。f:id:secondlife:20111006173812p:image赤のグラフが GC.disable しなかったサーバで、青のグラフが GC.disable するサーバです。あからさまに GC をユーザからのリクエスト処理中は無効化した方が断然高速な結果に終わりました。Rails 2.3 のサーバと比べても65%遅い、もとい150%ほど高速な結果となりました！！GC を止める Production のアプリケーションサーバに適用というわけで、このユーザのリクエスト処理中は GC を無効化する方法でだいぶ高速化することが解ったので、一足先に Unicorn 化していた Rails 2.3 サーバ(Ruby のバージョンは MRI 1.8.7 で Ruby Enterprise ではない)に適用したところ、それだけで 130% ほど高速化 & CPU 消費量が減る  CPU 使用率はあまり変わらないと思ってたんですが大きく減ったのが不思議な感じです…  という素晴らしい結果になりました。なお Rails3 ほど顕著に高速化しなかったのは、Rails3 にくらべメモリ使用量が少ないからかと思います。その後 Rails3 に刷新後は当初の Unicorn 化する以前の Rails 2.3 アプリに比べ、最終的に 150% ほど高速化しました。まとめWeb アプリケーションの速度の高速化は、IO 処理の高速化を除いてしまうと、チューニングすればするほど大きく改善する方法はなくなっていくと思ってましたが、ユーザのレスポンス処理中は GC を止め、その外で実行するだけで大きくパフォーマンスが改善しました。Ruby 1.8 系統を使ってるサービスは試してみる価値があると思います。なお今後リリースされる予定の Ruby 1.9.3 では nari3 が実装された Lazy Sweep GC が載るので、OobGC 的な事を Ruby 自体が行ってくれ、GC の最大実行時間が減ると思うので、Ruby 1.9 なサービスは 1.9.3 に変えるだけでパフォーマンス改善がされそうですね。Ruby 1.9.3 Preview 1がリリース。Lazy Sweep GCにより、GCの停止時間が改善。おまけ・運用ノウハウなどメモリリークの対応GC.disable している期間が長いと、GC.start したときに元のコードがメモリリークしてると、よりそのメモリーを解放できない様な感じで、どんどん Rails アプリケーションのプロセスサイズが肥大化して行ってしまいました。Unicorn は worker プロセスに SIGQUIT を送ると、ユーザのリクエスト処理が終わった直後にプロセスが死んで、master プロセスがそれを検知してすぐに fork する仕組みがあるので、以下のユーティリティを書いて Rack レイヤーで対応しました。https://gist.github.com/1258681use UnicornKiller::Oom, 400 * 1024 # 使用メモリが400Mを超えると自分自身に SIGQUIT
use UnicornKiller::MaxRequests, 1000 # 1000 回リクエストを超えると自分自身に SIGQUITプロセスを終了しても即座に fork で新しい worker が作られるため、こんな感じのざっくりとした対応でも問題無く運用できてます。Unicorn + bundler でのデプロイ時の問題突然はまるのでちゅうい…。特に Unicorn は master プロセスへの SIGUSR2 (graceful な再起動)で再起動に失敗した場合、何事もなかったのように昔のプロセスは正常に生き続けるため、ぱっと見問題に気づきません…。アプリケーションサーバのベンチマークとパラメータの調整ベンチマークには最初 ab (apache bench) でいくつかの URL でベンチ、次に JMeter で本番リクエストの上位80%のリクエストをエミュレートしてベンチをとりました。環境さえ作ればあとは叩くだけなので、ab / JMeter を使いつつ、アプリケーションサーバのメモリー数、CPU の利用状況を見て Unicorn のプロセス数の調整と Ruby Enterprise Edition の GC 周りの環境変数を調整しました。この辺はサービスごとに最適値が違うと思うので、ちまちま数字変えてやるのが良いと思います。*1:Rails 2.3 -> 3 移行はクックパッド規模になるとかなり大変でしたが、いろいろな面白いアプローチを試せたので、これはこれで何処かでお話ししたいですね*2: Ruby 1.9.2 化も考えましたが、テスト通すまでまただいぶ時間がかかる＆いっぺんにやると問題切り分けが難しいので一緒にアップグレードすることは見送りました*3: graceful な再起動がほとんどエラーや負荷無く行える重要性は、ウェブサービスを運用してる方なら解ると思います*4: CPU 使用率はあまり変わらないと思ってたんですが大きく減ったのが不思議な感じです…

A Day in the Life

Perl 便利情報・足りないライブラリを自動でインストールする

Perl 便利情報・足りないライブラリを自動でインストールする

書いている人

おたよりを送る