気になったところだけのメモです。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 ディレクティブ内に設定するとおｋ。
passenger_log_level
nginxのエラーログファイルにどこまでの情報を書くかを決める設定。
デフォルトは 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_user_switching, passenger_default_user
前にメモってた
passengerのUser switchingについて - おもしろWEBサービス開発日記のrailsメモ - はてな？Railsグループ
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
Domains
- Sessions
- インスタンスのキューに入っているクライアントの数
- Processed
- インスタンスがいくつのリクエストをさばいているかの数。最大はpassenger_max_requestsで設定した数値。
- Uptime
- インスタンスの実行時間。
passenger はデフォルトで fair load balancing なので、Uptimeはどのインスタンスもだいたい同じくらいになる。
spike
"spike"と表示されているインスタンスには何か問題がある。例えば他と比べてたくさんのsessionを受け付けてるとか。spikeになる原因として考えられるのは下記の二つ。
- 処理に時間のかかるリクエストを処理している。この場合は global queuing を on にしたがいいかも。
- アプリがfrozen。
frozenなアプリをデバッグする
インスタンスがfrozenになった(反応しなくなった)ら、SIGABRT で kill する。そうするとアプリはバックトレース付きの例外をraiseする。インスタンスをkillしてもpassengerは自動でkillされたインスタンスを再起動するので特に悪影響とかないみたい。バックトレース付きの例外は通常nginxのerror log に書き込まれる。Rails であれば production.log に書き込まれるかもしれない。
bundler support
リクエスト毎にアプリを再起動する方法
コードの自動リロードをサポートしていないフレームワークでアプリを開発しているときなど、リクエスト毎にアプリを再起動したいときがある。 tmp/always_restart.txt を作るとリクエスト毎に自動で再起動するようになる。
sub-uriにデプロイしたときに画像,css,javascriptのURIが使えなくなる問題の回避方法
<%= image_tag("foo.jpg") %>みたいにrailsのヘルパ使えばうまいことしてくれるみたい。
spawning methods
passenger 3になったらちゃんと勉強するつもりなので省略。
