The Philosophy Behind unicorn
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 The Philosophy Behind unicorn Being a server that only runs on Unix-like platforms, unicorn is strongly tied to the Unix philosophy of doing one thing and (hopefully) doing
Debugging memory leaks in Ruby
Sam Saffron Programming, Technology and the Art of Hacking At some point in the life of every Rails developer you are bound to hit a memory leak. It may be tiny amount of constant memory growth, or a spurt of growth that hits you on the job queue when certain jobs run. Sadly, most Ruby devs out there simply employ monit , inspeqtor or unicorn worker killers. This allows you to move along and do mo
workerの枯渇状況が分かるrack-server_statusというgemを書いています - CubicLouve
unicornのwokerのbusy数とidle数の比率がわからなくて、うっかりworkerが枯渇して大変なことになったので、workerの状況を返すエンドポイントを追加するrackミドルウェアを書いています。 github.com ぶっちゃけkazeburoさんのPlack-Middleware-ServerStatus-Liteのruby版です。 github.com この中で使っているkazuhoさん製のParallel-Scoreboardも移植しました。(まだREADMEがない。。。) github.com 元は下記です。 github.com Kazuho@Cybozu Labs: Parallel::Scoreboard でワーカープロセスをモニタリングする方法 使い方 config.ruに下記の用に書く。 # In config.ru use Rack::ServerSta
Unicorn: Rack HTTP server for Unix and fast clients
../ 2024-06-27 23:40 - Unicorn/ 2023-10-03 17:15 - examples/ 2023-10-03 17:15 - files/ 2023-12-30 01:23 - public/ 2021-03-12 20:34 - Application_Timeouts 2023-10-03 17:15 3K Application_Timeouts.html 2023-10-03 17:15 6K CONTRIBUTORS 2023-10-03 17:15 1K CONTRIBUTORS.html 2023-10-03 17:15 5K COPYING 2023-10-03 17:15 34K ChangeLog 2020-04-22 02:00 42 ChangeLog.html 2020-04-22 02:00 230 DESIGN 2023-10
Configurator.html
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 Methods #after_fork #after_worker_exit #after_worker_ready #before_exec #before_fork #check_client_connection #client_body_buffer_size #default_middleware #early_hints #list
UnicornのWorkerプロセスをリサイクルする - Qiita
Web サーバやアプリケーションサーバは、リクエスト数やメモリ使用量がある閾値を超えたらプロセスの再起動を行う仕組みが用意されています。 Apache にも IIS にもそのための設定項目が用意されていて、この仕組みを一般にリサイクルと呼ぶようです。 UA からのリクエストをさばくワーカープロセスが疲弊せず、パフォーマンスを維持するための仕組みですね。 Ruby で人気のアプリケーションサーバである Unicorn ですが、残念ながらこのリサイクルの機能を持っていません。 どうにかできないかなーと思って調べていたら、この短所を補完する Gem がリリースされていました。 Unicorn Worker Killer | github そのまんまですね。 この Gem でできるのは、以下のようなリサイクルです。 ・一定のリクエスト数を超えたらランダムで再起動する（上限に達したら必ず再起動）。
rubyで動画などの大きなファイルをアップロードする場合のメモリの使い方について - Qiita
動画ファイルなどの、メモリ量に対して巨大なファイルをアップロードする場合、ファイルを全て読み込んで送信／受信を行うとメモリを圧迫してしまうため問題がある場合があります。 こういう場合はメモリの使用量は一定範囲に抑えるために、バッファに少しづつ読み込んでは送信し、送信できたら次を送信し、あるいは少し受け取ったらファイルシステムに書き出し、書き出したら次を読み込むといったことをやることになります。 rubyでこれを行う場合にどういう方法をとればいいのかについて確認したのでまとめてみました。 結論 送信（クライアント側） net/http を使う場合は Net::HTTPGenericRequest#body_stream= で読み出し可能な File や IO を渡す。 HTTPClient を使う場合はデータとして読み出し可能な File や IO を渡す。 RestClient は1.7.
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 の 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 を編
How To Optimize Unicorn Workers in a Ruby on Rails App | DigitalOcean
// Tutorial //How To Optimize Unicorn Workers in a Ruby on Rails App Introducing Unicorn If you are a Rails developer, you’ve probably heard of Unicorn, a HTTP server that can handle multiple requests concurrently. Unicorn uses forked processes to achieve concurrency. Since forked processes are essentially copies of each other, this means that the Rails application need not be thread safe. This is
Debugging, Unicorns, Rails and Timeouts
The goal of this post is to describe a debugging session, and different possible approaches for debugging in general. It also contains some tips and tricks to use with unicorn and Rails to debug request timeouts. I usually enjoy debugging because of the unknown thing to fix, like a pirate finding a hidden box of gold :). Seriously, I think one of the most important things in writing software is de
Mac + unicorn + nginx + Rails - Giworld
環境 Mac OSX 10.8.3 Rails 3.2.13 Ruby 2.0.0-p0 Homebew は導入済みとする Unicorn Install gem install unicorn 設定 /config/unicorn.rb を作成 # ワーカーの数 worker_processes 2 # ソケット経由で通信する listen File.expand_path('tmp/sockets/unicorn.sock', ENV['RAILS_ROOT']) # ログ stderr_path File.expand_path('log/unicorn.log', ENV['RAILS_ROOT']) stdout_path File.expand_path('log/unicorn.log', ENV['RAILS_ROOT']) # ダウンタイムなくす preload_app
Ruby 2.0 Garbage Collection
There’s been a lot of talk about the improvements in Ruby 2.0’s Garbage Collection performance. That’s a great thing, because GC in older versions of Ruby wasn’t very performant. Most of the conversation about generational GC (or other strategies) revolves around making Ruby GC more efficient. This has a great impact on your users, because less GC time means that their pages return faster. But wha
Tuning unicorn
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 Tuning unicorn unicorn performance is generally as good as a (mostly) Ruby web server can provide. Most often the performance bottleneck is in the web application running on
Heroku+Railsの高速化 - 思ったこと
こんばんわ。 Herokuに乗っけてる自分のサービスを3Gで見たとき、 読み込み遅すぎて発狂しました。 対策、何個かやってみたメモ。 Unicorn導入 Gemfileにunicornを追加 group :production gem 'unicorn' end config/unicorn.rbを作成 worker_processes Integer(ENV["WEB_CONCURRENCY"] || 3) timeout 15 preload_app true before_fork do |server, worker| Signal.trap 'TERM' do puts 'Unicorn master intercepting TERM and sending myself QUIT instead' Process.kill 'QUIT', Process.pid end de
logentriesでnginxのエラーを監視する - komagataのブログ
小さいrailsサービスあるある railsで何かサービスを作ったとする。ExceptionNotificationも入れた。NewRelicで5分毎に死活監視もしてる。なのに「落ちてるみたいです」とTwitterで言われる。 nginx + unicornの組み合わせでアクセスが増えた時、大抵真っ先に起こるのがunicornのtime out。 2013/02/08 18:36:10 [error] 20932#0: *3506622 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 〜ってやつ。 重いDBのクエリとかでアクセスをさばくスピードより接続数が増えてきて起こる。railsアプリまで処理が行かないのでExceptionは起こらない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kzk/unicorn-worker-killer: Automatically restart Unicorn workers based on 1) max number of requests and 2) max memory
Server::Starter で Unicorn を起動する場合の Slow Restart : sonots:blog
「Server::Starterに対応するとはどういうことか」の補足 : sonots:blog
Ruby Threads, Unicorn, and You