[Rails] memcache-clientやdalliでfork後のresetは大切｜TechRacho by BPS株式会社
Railsのsession_storeやcache_storeとして、memcachedを使うことはよくあると思います。 今回は、memcachedのRuby用クライアントgem, memcache-clientやdalliにて、Passengerやunicornのfork後の初期化をきちんと書かないと、悲惨なことになるというお話です。 ※他のgemやmemcached以外でも当てはまります。 必要な初期化処理 以下の処理を、config/environments/production.rbや、config/initializers/session_store.rbなど、どこでも良いので初期化コードに書いておく必要があります。 dalliを利用している場合 https://github.com/mdesjardins/dalli/tree/ # passengerの場合 if define
![[Rails] memcache-clientやdalliでfork後のresetは大切｜TechRacho by BPS株式会社](https://cdn-ak-scissors.b.st-hatena.com/image/square/6825dc350622c493ec8eadba4adb6cd2ccf3cfe1/height=288;version=1;width=512/https%3A%2F%2Ftechracho.bpsinc.jp%2Fwp-content%2Fuploads%2F2012%2F08%2F1345358135_messagebox_warning.png)
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のコードに手を入れるの
unicornでダウンタイムなしに再起動する - rochefort's blog
ダウンタイム無しってすごい。 でも、そんな実行環境は今のところ必要ないので monitの監視程度まで試したら、passengerに移行するやもしれません。 USR2時に旧プロセスを停止する 設定 ruby/1.9.1/gems/unicorn-4.1.1/examples/unicorn.conf.rb や unicorn.conf.rb にサンプルがありますが before_forkというcallbackが使えて、下記のように旧プロセスに対してシグナルを発行することが可能です。 old_pid = "#{server.config[:pid]}.oldbin" if old_pid != server.pid begin sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU Process.kill(sig, F
KOSHIGOE学習帳 - [Ruby] Unicorn 概要
{{toc_here}} はじめに Unicornは、Unix系システムで動作するRackアプリケーション用サーバ。接続時間が短いことを前提とした設計となっている。 - http://unicorn.bogomips.org/ preforkモデル Unicornはpreforkモデルを採用している。 Reverse Proxy └TCP Socket[0.0.0.0:8080] > Unicorn(Master) ├(fork)─Worker[0] < TCP Socket[0.0.0.0:8080] ├(fork)─Worker[1] < TCP Socket[0.0.0.0:8080] ┆ └(fork)─Worker[N-1] < TCP Socket[0.0.0.0:8080] マスタプロセスからforkした複数のワーカープロセスがあり、クライアントからのリクエストを
[再起動など] Unicorn | Rails3
インストール 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.
Unicornのgraceful restartで少しハマった件 - hack in 3 minutes
RailsサーバーのUnicornはmasterプロセスにUSR2シグナルを送ると、新しい設定・アプリのリロードを無停止で行うgraceful restartな動きをしてくれます。 この仕組を理解してなかったのでそれのメモ。 ドキュメントも何も見てない時の認識 現行のmasterが新しい設定・アプリをロードした新masterプロセスをforkする 新masterとそこから生えるworkerがreadyになって、新旧のUnicornが処理を行う 頃合いを見て旧masterは勝手に落ちる と思ってたんだけど、実際試してみても3のタイミングになっても旧masterがなかなか落ちてくれない。 旧masterのCPU利用率はだんだん下がってきているので、それがなくなったら落ちるのかと勝手に思ってたけどそうでもない。ウーンとなっててドキュメント見たら普通に書いてありました。 USR2を送った時の動き
Unicornのダウンタイムなし再起動は考え無しに使うと危険 - ひげろぐ
UnicornのプロセスにUSR2シグナルを送ると古いプロセスを残しつつ新しいプロセスが起ち上がるので、ダウンタイムが発生しない。 というのはUnicornの利点の一つとして数えられているが、実は罠なんじゃないだろうかと思い始めた。 USR2を送った直後の状態でプロセスのリストを見ると以下のようになる。（行が長いのでプロセス名の部分だけ抜粋） akahige:# ps aux |grep unico unicorn_rails master -E production -D --path /hoge-app -l0.0.0.0:8080 unicorn_rails worker[0] -E production -D --path /hoge-app -l0.0.0.0:8080 unicorn_rails master (old) -E production -D --path /hog
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Optimal number of per CPU unicorn processes