Hi!
2012年 3月 の投稿一覧
unicornを使ってみた(2) – REMPにおけるメモリ利用量の変化
では、実際に現在のREMPの場合において、どの程度メモリ使用量が変化したのかを確認してみました。
Apacheをフロントのリバースプロキシとして、背後にRack用のWebサーバ(Thin or unicorn)を動かすという挙動はかわらないので、Thinとunicornの両方のサーバを立てて、リバースプロキシ(mod_proxy)で均等に複数のプロセスで起動させているthinサーバとunicornにアクセスする様にして3分毎に実メモリ使用量を監視してグラフにしてみました。
mod_proxyの設定は以下の様な形にしています。以下の様に設定することでthinの1プロセスとunicornへ均等にアクセスがされる様にしています。
<IfModule mod_proxy.c> (中略) <Proxy balancer://***> BalancerMember http://127.0.0.1:4040 loadfactor=10 #thinのプロセス(1/2) BalancerMember http://127.0.0.1:4041 loadfactor=10 #thinのプロセス(2/2) BalancerMember http://127.0.0.1:4044 loadfactor=20 #unicornのプロセス </Proxy> </IfModule>
で、この様な設定にした状態でREMPの本番環境にしてみたところ、得られた各プロセスが消費しているメモリ使用量の変化は以下の様な具合です。
(赤色の線がThinの1プロセス vs 緑色の線がunicornのマスタープロセス+水色の線がunicornのワーカープロセス で比較すればよいのかな。と。)
少なくてもREMPのAPIサーバ側のSinatraで実装したアプリをThinの上で稼働させた場合とunicornで稼働させた場合を比較するケースでは、単純に見ると半分程度にメモリ使用量を押さえることができる様です。
もう少し更に検証したいと思います。
unicornを使ってみた(1) – 導入
REMPで今までApacheのリバースプロキシを通してthinサーバでAPIを稼働させていたのですが、稼働時間が長くなるとメモリの利用割合が増える状況が続いていたため、どうしようかと悩んでいたところ会社でmizzyさん(@gosukenator)からunicornだとメモリ利用量が押さえられるという話を伺ったので早速切り替えてみました。
unicornは、Rack 環境をロードした master プロセスが fork して子の worker を作る仕組みになっているため、安定性とメモリ利用量を小さくすることができることが期待されます。
unicornのインストールはgemを使うことで簡単に行えます。
$ sudo gem install unicorn
現在、REMPのAPIサーバはthinで動いているのでアプリケーションのルートにunicornの設定ファイルを書き足すことでunicorn上でアプリをすぐに動かすことができます。
ここでは、
- Apacheのリバースプロキシから内部の4044番ポートにフォワード
- unicornのワーカーは4本作る
- preload_appを有効にして、workerをforkする前のアプリケーションの先読みを有効にする
設定例を書いています。
# unicorn.conf listen "/tmp/unicorn.sock", :backlog => 64 preload_app true port = 4044 listen port worker_processes 4 pid "tmp/pids/unicorn.pid" stderr_path "log/unicorn_error.log" stdout_path "log/unicorn_out.log"
この設定ファイルを書き足せば以下のコマンドですぐに動かすことができます。
(-Dでデーモン化)
$ unicorn -c unicorn.conf -D
設定ファイル内のログに正常にログが吐かれていれば、稼働していることを確認することができます。
$ cat log/unicorn_error.log 125.***.***.*** - - [18/Mar/2012 18:56:11] "GET /status/info HTTP/1.1" 200 2 0.0045 125.***.***.*** - - [18/Mar/2012 18:56:11] "GET /status/info HTTP/1.1" 200 2 0.0531
thinサーバをプロセス別に再起動させる方法
自分用メモ。
サーバ上で起動させているThinサーバを再起動させたい場合、
$ thin -C thin.yaml restart
と行うと、yamlでthinのプロセスが常駐する様に設定していた場合、一度全部のプロセスを閉じた後、設定数分のプロセスの起動が行われるため、接続が不可能な状態が一瞬生じます。
せっかく複数プロセスが稼働しているのであれば、一つずつのプロセスで再起動がかけられればよいので、方法を調べたところ --onebyone というオプションを付与することで実現できました。
$ thin -C thin.yaml --onebyone restart
といった具合。
こうすると、以下の様に個々のプロセスの停止と起動が繰り返されます。
$ thin -C thin.yaml --onebyone restart Stopping server on 0.0.0.0:4040 ... Sending QUIT signal to process 12835 ... >> Waiting for 1 connection(s) to finish, can take up to 30 sec, CTRL+C to stop now >> Exiting! Starting server on 0.0.0.0:4040 ... Waiting for server to start ... Stopping server on 0.0.0.0:4041 ... Sending QUIT signal to process 12846 ... Starting server on 0.0.0.0:4041 ... Waiting for server to start ... (以下略)
最近のコメント