You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
自分が現在関わっているプロジェクトでは、nginx + unicornの構成で運用しているのですが、この構成でサーバのメモリが足りなくなるという現象に悩まされていました。 unicornのワーカプロセスは、通常では起動したままユーザからのリクエストを処理し、再起動されることはありません。 その関係で、長時間運用していると、そのワーカプロセスがメモリをあるだけ食いつぶすような挙動になります。 こんな時に便利なのが「unicorn-worker-killer」です。 unicorn-worker-killerを使うことで、ワーカプロセスが以下の条件の場合に、自動的に再起動してくれます。 ワーカプロセスが指定回数のリクエストを処理した場合 ワーカプロセスが指定量のメモリを使用している場合 いずれの場合でもワーカプロセスの再起動は、現在のリクエストを処理した後に再起動（いわゆるgraceful r
インストール rails server で起動するデフォルトのサーバは WEBrick で実用レベルではありません。代わりに Unicorn を利用します。 # gem パッケージに含まれていなければ追加します % vi Gemfile ... gem 'unicorn' % bundle update 設定 config/unicorn.rb として設定ファイルを作成します。 worker_processes 2 stderr_path File.expand_path('../../log/unicorn/stderr.log', __FILE__) stdout_path File.expand_path('../../log/unicorn/stdout.log', __FILE__) pid File.expand_path('../../log/unicorn/unicorn.
# Railsのルートパスを求める。(RAILS_ROOT/config/unicorn.rbに配置している場合。) rails_root = File.expand_path('../../', __FILE__) # RAILS_ENVを求める。（RAILS_ENV毎に挙動を変更したい場合に使用。今回は使用しません。) # rails_env = ENV['RAILS_ENV'] || "development" # 追記に記載してます。入れた方がいいです。 ENV['BUNDLE_GEMFILE'] = rails_root + "/Gemfile" # Unicornは複数のワーカーで起動するのでワーカー数を定義 # サーバーのメモリなどによって変更すること。 worker_processes 2 # 指定しなくても良い。 # Unicornの起動コマンドを実行するディレクトリを指
表参道.rb #1で用いた資料です。 ページ内で募集している会社はこちらになります。 Port株式会社 https://www.theport.jp/ もちろん、デザイナーも募集中です。 興味があれば、とりあえず、一度、お話しましょう！！！ あと、発表試料中にマズい内容があれば、すぐに該当箇所を消しますのでご連絡ください。 いずれにせよ、連絡は@@tabunmuri255まで！！！Read less
Unicornのワーカー数を増やすべきか考えるために、今いくつのワーカーがリクエストを捌いているのかさくっと調べたいことがあると思います。 Passengerだとpassenger-statusコマンドが標準で付いていて便利なのですが、Unicornではそうもいきません。 今知りたい場合 たとえば以下のような1行コマンドで調べられます。 ps l --ppid=`cat /path/to/rails/tmp/pids/unicorn.pid` | \ awk "{ print \$10}" | grep R | wc -l これは、masterプロセスの子プロセスを一覧してステータスがTASK_RUNNINGのものを数えているだけです。 多少雑ですが、watchで数秒おきに見ておけば、負荷状況がざっくりとわかります。 muninで監視する場合 これだけだと短いので、muninで監視する設定
最近は仕事でSinatraアプリを書いたりしているので、Sinatraアプリを動かすためにはどのHTTPサーバを使うのがベストなのかが気になっている。（先に結論を書いておくけれど、どれがベスト、という唯一の選択肢は今のところありません。適材適所です。） SinatraはRackの上に構築されているので、Rackに対応したHTTPサーバーを使って動かす事になるのだが、この数がやたらと多く、どれを使えばいいのか迷う。代表的なものを挙げただけでも、WebRick, Mongrel, Thin, Unicorn, Passenger(Apacheとかに組み込んで使うやつ), FastCGI, (普通の)CGI、これぐらいは選択肢がある（いくつかHTTPサーバじゃない物も混ざっているが、Rackが対応してるという点は共通している）。 WebRickはそもそもパフォーマンスに重点を置いていないし、Mo
随分長いことブログ放置してしまったのだけどネタ見付けたので久々の記事。 UnicornはPassengerより遅かった？ なんかTwitterで「アクセス少ないときはPassengerよりUnicornのが速いのに、アクセス多くなってきたらその逆になった」って話をみかけたので、それ単にUnicornのworkerが足りないんじゃないの、と返したのだけど、どういうことかという話を少しまとめる。 まず、Unicornのworkerは1プロセスにつき1度に1リクエストしか処理しない。だから例えば、凄い大雑把な計算だけど、平均50msくらいでレスポンスを返すアプリだとすれば、1workerは20req/secくらいは返せるかなと見積もって、ピーク時に100req/secくらいアクセスがありそうだったらworkerを5個くらい立てとくかな、足んなかったらもうちょっとかな、みたいに考える。実際どんくら
本記事は英語版ブログで2010年5月18日に公開された記事の翻訳版です。 Engine Yard のお客様や開発者の友人の多くが Unicorn を愛用し、推奨しているので、これについて兼ねてから勉強したいと思ってました。そんな矢先に、幸いにもその学習機会が自然と訪れました。最初は無料のリソースをいろいろと見ながら疑問を解決しようとしましたが、思ったより難しく、結局は大元のソースに当たることにしました。 まず、十分な時間をかけて Unicorn の README ファイルを熟読しました。このファイルには総合情報が網羅されていますが、読み終えた後でも疑問が解決しなかったので、すべてまとめて Unicorn の開発チームに E メールで送ってみました。有難いことに、返信には私の全質問に対する答えが詳しく書かれていました。そのおかげで内情に通じることができたので、この素晴らしいリソースを皆さんと
はじめに Gogengo! はさくらVPS 上で Thin のインスタンス 1つで動いていました。これだと重い処理のリクエストがきたら他のリクエストが待ちになってしまったり、大量の負荷がきたときに耐えられない恐れがあるので Nginx + Unicorn で動かしたくなりました。 Passenger ではなく Unicorn にした理由は 2つです。 Passenger は動かしたことがあったけど Unicorn はなかった Unicorn はダウンタイムがないのがカッコいいと思った さくらVPS で環境をつくったときの手順はこちらにまとめてあります。 対応する前に Unicorn の仕組みについて知るため『次世代RailsサーバーUnicornを使ってみた | TechRacho』を読みました。とても詳しくてわかりやすい文献です。 今回の対応の大半はミニ開発合宿でやりました。@satoc
俺のミームを受けてみろ @T_Hash アクセスが少なければ速度は Unicorn > Passenger, アクセスが集中すると Unicorn < Passengerになる。どうしようかな 2012-03-02 14:09:44
RailsサーバーのUnicornはmasterプロセスにUSR2シグナルを送ると、新しい設定・アプリのリロードを無停止で行うgraceful restartな動きをしてくれます。 この仕組を理解してなかったのでそれのメモ。 ドキュメントも何も見てない時の認識 現行のmasterが新しい設定・アプリをロードした新masterプロセスをforkする 新masterとそこから生えるworkerがreadyになって、新旧のUnicornが処理を行う 頃合いを見て旧masterは勝手に落ちる と思ってたんだけど、実際試してみても3のタイミングになっても旧masterがなかなか落ちてくれない。 旧masterのCPU利用率はだんだん下がってきているので、それがなくなったら落ちるのかと勝手に思ってたけどそうでもない。ウーンとなっててドキュメント見たら普通に書いてありました。 USR2を送った時の動き
Unicornの再起動はシグナル（USR2等）を発行することで非同期的に行われるので、成功したのか失敗したのかがわかりづらい。 例えばCapistrano等でアプリケーションをデプロイしたあと、Unicornの再起動を行い、その再起動が成功か失敗かを判断したいことがある。 というわけで、 Unicorn を 同期的に restart するスクリプトを書いた。 使い方と仕組み 上記スクリプトを unicorn_restart.rb みたいな名前で保存し、以下のように Unicorn の PID ファイルを与えて実行します。 $ unicorn_restart.rb /tmp/unicorn.pidこれは以下のように動作します。 unicorn の master プロセスに USR2 シグナルを送る unicorn.pid.oldbin を監視し、再起動が終わるのを待つ 再起動が終わったら、
unicorn $ gem install unicorn $ rvmsudo unicorn_rails -p 80すると起動します。WEBrick とはここでお別れ。 ところで Rails3 は Rack アプリケーションなので、unicorn_rails を使う必要はありません。Rails.root で $ unicornするだけでちゃんと立ち上がります。でも RAILS_RELATIVE_URL_ROOT を渡せる daemon として起動したとき、tmp/pids/unicorn.pid に pid を吐いてくれる tmp/cache/, tmp/pids/, tmp/sessions/, tmp/sockets/ を自動生成 と幾つか便利なところがあるので unicorn_rails を使えばいいと思います。 unicorn の config ですけど、実際にアプリを公開すると
2010.07.09 次世代Ruby on RailsサーバーUnicorn（汎用のRackアプリケーションサーバ）を使ってみた 2010.07.20追記: prefixを指定した運用も可能でした。ご指摘頂きありがとうございます。 2010.07.28追記: 関連記事「RailsサーバUnicornを飼いならす! 運用時の便利技」へのリンクを張りました。 Railsサーバはたくさんあってややこしいですね！ 最近さらにUnicornというものが頭角を表してきたようで、Twitterやgithubも使っているようなので使ってみましたので、特徴や使い方などレポートしてみたいと思います。 このブログの他にもEngine Yardのブログ記事「Everything You Need to Know About Unicorn」やgithubの記事「Unicorn!」が非常に参考になると思いますので、
Rainbows! is a HTTP server for sleepy Rack applications. It is based on Unicorn, but designed to handle applications that expect long request/response times and/or slow clients. For Rack applications not heavily bound by slow external network dependencies, consider Unicorn instead as it simpler and easier to debug. Rainbows! is about Diversity We aim to support as many concurrency models as we can
Application_Timeouts CONTRIBUTORS DESIGN FAQ HACKING ISSUES KNOWN_ISSUES LICENSE Links NEWS PHILOSOPHY README SIGNALS Sandbox TUNING unicorn_1 Unicorn Configurator HttpServer OobGC PrereadInput StreamInput TeeInput Util Worker Signal handling In general, signals need only be sent to the master process. However, the signals Unicorn uses internally to communicate with the worker processes are docume
デプロイしたけど何かおかしい？ 先日、Unicornを採用しているウェブアプリで問題が発生しました。デプロイした最新のコードが実行されているように見えますが、時々古いコードの挙動を見せるのです。 今回はそのトラブルシューティングの一部始終を紹介しながら、Unicornのホットデプロイ（ダウンタイムなしでアプリケーションを更新すること）の仕組みをおさらいします。担当は私、去年KRAYに入社しました@irohirokiです。よろしくお願いします。 問題 まずはデプロイ先のサーバにSSHして、Unicornのプロセスを調べてみました。 $ ps ax -H PID TTY STAT TIME COMMAND 3159 ? Sl 0:00 unicorn master (old) -c unicorn.conf -D 3162 ? Sl 0:00 unicorn worker[0] -c unic
追記(2012/02/21 09:39): nginx 設定ファイルの例に、X-Frame-Options, X-Content-Type-Options に関する設定を加筆しました。 追記(2011/10/17 19:18): Rails 3.1 用に、nginx 設定ファイルの例を加筆・修正しました。 追記(2010/09/25 12:07): 現在はさくらの VPS を使用しています。 追記(2010/08/16 11:18): nginx 設定ファイルの例に root 文を書き忘れていたので追加しました。 話題の Unicorn を試してみました。 Unicorn については、以下の記事が詳しいです。 次世代Ruby on RailsサーバーUnicorn（汎用のRackアプリケーションサーバ）を使ってみた | TechRacho 現在 PONPON は nginx + Unico
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
