unicornのタイムアウト時にもRailsのログをちゃんと出力させる - 昼メシ物語
unicornはconfで timeout 20 とかやっとくと、20秒以上かかったらそのworkerが殺される。それはいい。問題はその殺され方にあって、タイムアウトしたunicorn workerはmasterにKILLシグナルで強制的に殺される。KILLで殺されてしまうと、worker側でtrapして安全に終了処理をすることができない。 一番困るのは、Railsのloggerは（production環境のデフォルトだと）リクエストが終了するまでバッファリングしているので、リクエストの途中でKILLされてしまうとloggerがflushされない。つまり、unicornのタイムアウト時には、リクエストのログは一切production.logには出力されない。異常時のログが出ないとか、まじで困ると思うんだけど、みんなどうしてんだろ。 これに対処するためにはunicornのコードに手を入れるの
Capstarano3でデプロイ時にUnicornが再起動しているようで失敗している時の対処法 - Qiita
Capstarano3 + Unicornでデプロイしている時、capコマンドで実行するとUnicornの再起動ログがSuccessになっているのにもかかわらず、サーバのUnicornプロセスを確認すると、どうも再起動されていない…。という現象にぶち当たり、色々調べると成功しているように見せかけて、実は失敗していたっていうお話。 Unicornが再起動されたかの確認 paコマンドでいつ起動されたかの確認 $ ps -eo lstart,pid,args | grep uni Mon Nov 10 13:48:14 2014 17039 unicorn master -c /var/www/app/current/config/unicorn/staging.rb -E staging -D Mon Nov 10 13:48:18 2014 17083 unicorn worker[0] -
unicornにどんなシグナル送るとどうなるのかまとめました - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
File: SIGNALS [Unicorn: Rack HTTP server for fast clients and Unix] の一部を超訳しただけ
Zero Downtime Deployment With Unicorn And Capistrano - benjaminknofe.com
Everytime we're fixing a bug or adding a new feature, we want it to go live very fast to have happy users at gigmit. Thats why we really love to deploy several times a day. While running a pretty standard Rails stack with Unicorn and handling deployments with Capistrano, we always had a few seconds when the Unicorn workers were restarted. We did this only at night, because it wasn't always sure[1]
Unicornの自動起動設定｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
先日、OS起動時にUnicornが自動起動するよう設定する機会があり、その際にUnicornの停止や再起動についておさらいした覚え書きである。 前提 Unicornの停止方法 公式ドキュメントに記載されているが、要約する。 Unicornには停止用コマンドなどは用意されていない。Unicornはひとつのmasterプロセスと複数のworkerプロセスからなるが、masterプロセスにシグナルを送信することで停止できる。 送信シグナルによって以下の違いがある。 QUIT：gracefulな終了（workerの処理待ちをする。） INT/TERM：強制終了（強制的にworkerプロセスをkillする。） ※一般的に、killコマンドでシグナル指定しなければTERMが送信され、Ctrl+Cでプロセスを止めればINTが送信されるが、INT/TERMのいずれでも停止処理は同じである。 http://
unicorn-worker-killerが便利だった件 · zephiransasのチラシの裏
自分が現在関わっているプロジェクトでは、nginx + unicornの構成で運用しているのですが、この構成でサーバのメモリが足りなくなるという現象に悩まされていました。 unicornのワーカプロセスは、通常では起動したままユーザからのリクエストを処理し、再起動されることはありません。 その関係で、長時間運用していると、そのワーカプロセスがメモリをあるだけ食いつぶすような挙動になります。 こんな時に便利なのが「unicorn-worker-killer」です。 unicorn-worker-killerを使うことで、ワーカプロセスが以下の条件の場合に、自動的に再起動してくれます。 ワーカプロセスが指定回数のリクエストを処理した場合 ワーカプロセスが指定量のメモリを使用している場合 いずれの場合でもワーカプロセスの再起動は、現在のリクエストを処理した後に再起動（いわゆるgraceful r
最近の Rack サーバ事情について - おもしろwebサービス開発日記
先月、heroku の推しサーバが unicorn から puma に変わったという発表がありました。unicorn だとスロークライアントの影響を受けやすいというのが理由なようです。 もう少し詳しく調べてみましょう。 そもそもスロークライアントってなに その名の通り遅い回線のクライアントです。3G環境のモバイル端末などが該当します。 「unicorn だとスロークライアントの影響を受けやすい」とは unicorn はプロセスモデルのサーバであり、blocking I/O モデルを採用しています。つまり、クライアントとの通信中プロセスが専有されるということです。 例えば unicorn がワーカプロセスを3つ立ち上げていて、そこへ通信完了に10分かかるようなスロークライアントが3つ接続されたら…、続くクライアントはスロークライアントの通信が完了するまで実行を待たなければならなくなります。プ
UnicornのWorkerプロセスをリサイクルする - Qiita
Web サーバやアプリケーションサーバは、リクエスト数やメモリ使用量がある閾値を超えたらプロセスの再起動を行う仕組みが用意されています。 Apache にも IIS にもそのための設定項目が用意されていて、この仕組みを一般にリサイクルと呼ぶようです。 UA からのリクエストをさばくワーカープロセスが疲弊せず、パフォーマンスを維持するための仕組みですね。 Ruby で人気のアプリケーションサーバである Unicorn ですが、残念ながらこのリサイクルの機能を持っていません。 どうにかできないかなーと思って調べていたら、この短所を補完する Gem がリリースされていました。 Unicorn Worker Killer | github そのまんまですね。 この Gem でできるのは、以下のようなリサイクルです。 ・一定のリクエスト数を超えたらランダムで再起動する（上限に達したら必ず再起動）。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
init script for unicorn on RHEL, Cent OS, Scientific Linux way
https://qiita.com/kimulab/items/bb5758ab7c3502ca4246
PumaとUnicornで最近自分が理解したこと