ja ja ja en ja en ja en ja ja en ja en ja en ja en ja en ja sv ja fr ja ja en ja ja ja ja ja en ja ja en ja en ja en ja ja ja ja ja ja ja ja en fr ja en ja en ja en ja fr en ja en ja en ja ja en ja ja ja ja ja en ja ja ja ja en ja en ja en nl ja nb ja ja nb ja ja en ja ja en ja ja en en en ja ja ja ja ja ja ja ja ja ja ja ja ja cv es es ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja
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
passengerがspawn出来るインスタンスの最大数。passenger_max_pool_sizeと同じ。
現在生きているインスタンスの数。maxと同じか小さい数になる。
現在リクエストを処理しているインスタンスの数。countと同じか小さい数になる。
リクエストを処理していないインスタンスの数。count - active。
インスタンスのキューに入っているクライアントの数
インスタンスがいくつのリクエストをさばいているかの数。最大はpassenger_max_requestsで設定した数値。
インスタンスの実行時間。
passenger はデフォルトで fair load balancing なので、Uptimeはどのインスタンスもだいたい同じくらいになる。
"spike"と表示されているインスタンスには何か問題がある。例えば他と比べてたくさんのsessionを受け付けてるとか。spikeになる原因として考えられるのは下記の二つ。
処理に時間のかかるリクエストを処理している。この場合は global queuing を on にしたがいいかも。
アプリが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,javascriptのURIが使えなくなる問題の回避方法
みたいにrailsのヘルパ使えばうまいことしてくれるみたい。
spawning methods
passenger 3になったらちゃんと勉強するつもりなので省略。
willnet 2010-07-05 16:18
最近の Rack サーバ事情について
先月、heroku の推しサーバが unicorn から puma に変わったと…
nginx で solr のアクセスを制限する
solr(tomcat) のアクセス制限のメモです。 前提 nginx, solr(to…
nginx + passenger で 502 Bad Gateway になるときの対処法
passengerからnginxをインストール launchctlで起動時に自動でn…
Rails 3 + passenger で environment を定義する方法
Rails 2 まで、passenger上でenvironmentを指定するディレクテ…
passenger2.2.9 released
Phusion Passenger 2.2.9 released « Phusion Corporate Blogの…
« Rubykaigi2010に参加した アジャイルな見積もりと計画作り 第二章 -… »
id:willnet はてなブログPro
べんりで楽しいwebサービスをたくさん作りたい
読者です 読者をやめる 読者になる 読者になる
@netwillnetをフォロー
失敗したテストのログだけを出力するぞ
iCARE Dev Meetup #34で登壇しました
`Thread.current[:hoge]`はスレッドローカル変数を参照していると思いきや実際はファイバーローカル変数だった