読者です 読者をやめる 読者になる 読者になる

おもしろwebサービス開発日記

Ruby や Rails を中心に、web技術について書いています

passegner のドキュメントを読む

気になったところだけのメモです。nginx用。

Phusion Passenger users guide, Nginx version

サブURIにデプロイする

例えば http://example.com/rails をアプリのトップディレクトリにしたい場合で、

root /websites/phusion;

な時。

ln -s /webapps/mycook/public /websites/phusion/rails

のようにシンボリックリンクを張って、 passenger_base_uri /rails; を server ディレクティブ内に設定するとおk。

passenger_log_level

nginxのエラーログファイルにどこまでの情報を書くかを決める設定。

0
error と warning のみ
1
最重要なデバッグ用情報を表示。アドミニストレータ用。
2
デバッグ情報を表示。開発者用。
3
2よりもっと詳しくデバッグ情報を表示。

デフォルトは 0。

passenger_use_global_queue

global queueを使うかどうかの設定。デフォルトはoff。

HTTPリクエストはたくさん来たときにキューに入れられる。

  • global queuing が off な時は、バックエンドのプロセスは独自のキューを持っていて、passengerはリクエストの数が公平になるようにキューを振り分ける。
  • global queuing が on の時は、バックエンドのプロセス達はglobalなqueueを共有して使う。バックエンドのプロセスが空いたらそこにリクエストを投げる。

global queuing が on の時は off の時に比べてパフォーマンスがちょっと落ちる(5%くらいらしい)。一般的に処理に時間のかかるリクエストが多い場合はonにしたほうがよさげだけど、最終的にonにするかoffにするかはパフォーマンスを調べないと何とも言えなさげ。

passenger_max_pool_size

同時に起動できるrailsインスタンスの最大数。数値を大きくするとたくさんのリクエストを裁けるけどメモリをたくさん使う。デフォルトは6。いろいろ数値を変えて試さないといけない設定。最低でもCPUのコアの数にするべき。2GBのメモリだったら30がおすすめ。VPSでメモリが256MBでMySQLも一緒に動かしてるとかなら2がおすすめ。

passenger_max_instance_per_app

一つのアプリで同時に起動できるインスタンスの最大値。passenger_max_pool_sizeより小さい値にしないとダメ。0に設定するとpassenger_max_pool_sizeの設定値まで同時起動可能になる。デフォルト0。

passenger_pool_idle_time

インスタンスがアイドル状態でいられる最大の秒数。ここで設定された秒数以上、インスタンスがなんのトラフィックも受け取らなければメモリ節約のためシャットダウンする。この値を減らすとアプリがspawnされる回数が増える。spawnは比較的遅いけどメモリ節約とトレードオフな感じ。

最適な値はビジターが使う平均時間の倍。

0に設定すると、インスタンスは本当に必要にならない限りシャットダウンしなくなる。例えば、passenger の worker process が多くて、アクティブじゃないアプリケーションのインスタンスを他のアプリケーションのインスタンスに移す必要があるときとか。hostを共有しておらず、少ないアプリを実行しているのであれば0を設定するのを推奨する。デフォルトは300。

メモリの使用量を調べる

なんかpsやtopだと正確なメモリ使用量を測定できない(psやtopで表示されているメモリ使用量より実際はもっと少ない)らしい。passenger-memory-statsコマンドを使うと passenger と nginx が実際に使ってるメモリの容量を調べることが出来る。

Private や private dirty RSS フィールドにプロセスの実際のメモリ使用量を表示する。

passengerの内部状態を調べる

passenger-status コマンドで内部状態を表示できる。

General Information
max
passengerがspawn出来るインスタンスの最大数。passenger_max_pool_sizeと同じ。
count
現在生きているインスタンスの数。maxと同じか小さい数になる。
active
現在リクエストを処理しているインスタンスの数。countと同じか小さい数になる。
inactive
リクエストを処理していないインスタンスの数。count - active。
Domains
Sessions
インスタンスのキューに入っているクライアントの数
Processed
インスタンスがいくつのリクエストをさばいているかの数。最大はpassenger_max_requestsで設定した数値。
Uptime
インスタンスの実行時間。

passenger はデフォルトで fair load balancing なので、Uptimeはどのインスタンスもだいたい同じくらいになる。

spike

"spike"と表示されているインスタンスには何か問題がある。例えば他と比べてたくさんのsessionを受け付けてるとか。spikeになる原因として考えられるのは下記の二つ。

  1. 処理に時間のかかるリクエストを処理している。この場合は global queuing を on にしたがいいかも。
  2. アプリがfrozen。

frozenなアプリをデバッグする

インスタンスがfrozenになった(反応しなくなった)ら、SIGABRT で kill する。そうするとアプリはバックトレース付きの例外をraiseする。インスタンスをkillしてもpassengerは自動でkillされたインスタンスを再起動するので特に悪影響とかないみたい。バックトレース付きの例外は通常nginxのerror log に書き込まれる。Rails であれば production.log に書き込まれるかもしれない。

bundler support

前にメモってたpassengerのBundler support - maeshimaの日記

リクエスト毎にアプリを再起動する方法

コードの自動リロードをサポートしていないフレームワークでアプリを開発しているときなど、リクエスト毎にアプリを再起動したいときがある。 tmp/always_restart.txt を作るとリクエスト毎に自動で再起動するようになる。

sub-uriにデプロイしたときに画像,css,javascriptURIが使えなくなる問題の回避方法

<%= image_tag("foo.jpg") %>

みたいにrailsのヘルパ使えばうまいことしてくれるみたい。

spawning methods

passenger 3になったらちゃんと勉強するつもりなので省略。