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のコードに手を入れるの
Rails: Puma/Unicorn/Passengerの効率を最大化する設定（翻訳）｜TechRacho by BPS株式会社
まとめ: アプリのサーバー設定はRuby Webアプリのスループットやコストあたりのパフォーマンスに大きな影響を与えます。設定の中でも最も重要なものについて解説します（2846 word、13分） RubyのWebアプリサーバーは、ある意味で自動車のガソリンに似ています。よいものを使ってもそれ以上速くなりませんが、粗悪なものを使えば止まってしまいます。実際にはアプリサーバーでアプリを著しく高速化することはできません。どのサーバーもだいたい同じようなものであり、取っ替え引っ替えしたところでスループットやレスポンスタイムが向上するわけではありません。しかしダメな設定を使ったりサーバーで設定ミスしたりすれば、たちまち自分の足を撃ち抜く結果になります。クライアントのアプリでよく見かける問題のひとつがこれです。 本記事では、3つの主要なRuby アプリサーバーであるPuma、Unicorn、Pass
Dotenvはproductionで使わないほうがよいのではという話 - なんかかきたい
またRubyとかRailsの話になってる。本当はこんな話なんてしたくなくて、スクフェスの話でもしたい。凛ちゃんマジえんじぇー。 Webアプリケーションを書いていると、データベースのユーザ名やパスワード、接続先サーバのIPなどなど、アプリケーションコードとは関係がないけれどもリポジトリ内には含めたくない、動かす環境に合わせて変更する必要のある設定を扱う機会がしばしばある。 こういう設定は環境変数に設定すると便利だよっていう考えがあって、The Twelve Factorsで紹介されていたりする。 The Twelve-Factor App これを実現するには、例えば /etc/environment や ~/.bash_profile みたいなファイルに書けばいいんだけど、開発環境では1台のPC上で複数のアプリケーションを書く機会も少なくないはず。 そういう場合に、/etc/environm
Unicorn の graceful restart と環境変数 - eagletmt's blog
Unicorn の graceful restart は無停止でのデプロイを可能にして非常に便利だが、fork を用いて実装されている都合で古いプロセスから新しいプロセスに環境変数が引き継がれるため、そのことに起因するトラブルがいくつかある。 dotenv の設定が書き変わらない 設定情報を dotenv で管理している人も多いと思うけど、環境変数を使っているので罠がある。 例えば最初に .env に MEMCACHE_SERVERS=memcache-server-001:11211 と書いてあったとする。 このとき Unicorn を起動すると、dotenv によって MEMCACHE_SERVERS=memcache-server-001:11211 が環境変数に追加される。 その後、接続先として memcache-server-002:11211 を追加したくなって .env を編
最近の Rack サーバ事情について - おもしろwebサービス開発日記
先月、heroku の推しサーバが unicorn から puma に変わったという発表がありました。unicorn だとスロークライアントの影響を受けやすいというのが理由なようです。 もう少し詳しく調べてみましょう。 そもそもスロークライアントってなに その名の通り遅い回線のクライアントです。3G環境のモバイル端末などが該当します。 「unicorn だとスロークライアントの影響を受けやすい」とは unicorn はプロセスモデルのサーバであり、blocking I/O モデルを採用しています。つまり、クライアントとの通信中プロセスが専有されるということです。 例えば unicorn がワーカプロセスを3つ立ち上げていて、そこへ通信完了に10分かかるようなスロークライアントが3つ接続されたら…、続くクライアントはスロークライアントの通信が完了するまで実行を待たなければならなくなります。プ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
