Skip to main content

Unicornでの設定

Unicornはシングルスレッドで、マルチプロセスで動作します。Unicornには、トラフィックに基づいて自動的にプロセス数を調整する機能がありません。これは、unicorf.conf.rbunicorn.conf.minimal.rbファイル、またはスクリプトを使用して設定する必要があります。

  • unicorn.conf.rbの例:

    # Define your root directory.
    root = "/home/deployer/apps/gifroll/current"
    
    # Define worker directory for Unicorn.
    working_directory "/path/to/app/current"
    
    # Define number of worker processes.
    # Each forked OS process consumes additional memory.
    worker_processes 4
    
    # Define timeout for hanging workers before they are restarted.
    timeout 30
    
    # Location of PID file.
    pid "/path/to/app/shared/pids/unicorn.pid"
    
    # Define log paths:
    
    # Allow redirecting $stderr to a given path. Unlike doing this from the shell,
    # this allows the Unicorn process to know the path being written to and rotates
    # the file if it is used for logging.
    stderr_path "#{root}/log/unicorn.log"
    
    # Same as stderr_path, except for $stdout. Not many Rack applications write
    # to $stdout, but any that do will have their output written here.
    stdout_path "#{root}/log/unicorn.log"
    
    # Loads Rails before forking workers for better worker spawn time.
    # Preloading your application reduces the startup time of individual
    # Unicorn worker_processes and allows you to manage the external connections
    # of each individual worker using the before_fork and after_fork calls.
    #
    # Please check if other external connections work properly with
    # Unicorn forking. Many popular gems (dalli memcache client, Redis) will have
    # compatibility confirmation with Unicorn and the process model.
    # Check the gem documentation for more information.
    preload_app true
    
    # When enabled, Unicorn will check the client connection by writing the
    # beginning of the HTTP headers before calling the application. This will
    # prevent calling the application for clients who have disconnected while
    # their connection was queued.
    check_client_connection false
    
    # Enable a local variable to guard against running a hook (before_fork, after_fork)
    # multiple times
    run_once = true
    
    # For example, use of before_fork and after_fork:
    #
    # POSIX Signals are a form of interprocess communication, and signal
    # events or state changes.
    # QUIT: Signals a process to exit, but creates a core dump.
    # TERM: Tells a process to terminate, but allows the process
    # to clean up after itself.
    #
    # Unicorn uses the QUIT signal to indicate a graceful shutdown.
    # The master process receives it and sends it to all workers, telling them to
    # shutdown after any in-flight request.
    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
      
      # You may want to execute code in the master process, before the forking
      # begins, to deal with operations that causes changes in state.
      # You need them to run once:
      if run_once
        # do_something_once_here ...
        run_once = false # prevent from firing again
      end
    end
    
    after_fork do |server, worker|
      Signal.trap 'TERM' do
        puts 'Unicorn worker intercepting TERM and doing nothing. Wait for master to send QUIT'
      end
      # ...
    end
    
    # For more information, check the Unicorn Configurator: https://msp-greg.github.io/unicorn/Unicorn/Configurator.html
  • unicorn.conf.minimal.rbの例:

    listen 2007 # by default Unicorn listens on port 8080
    worker_processes 2 # this should be >= nr_cpus
    pid "/path/to/app/shared/pids/unicorn.pid"
    stderr_path "/path/to/app/shared/log/unicorn.log"
    stdout_path "/path/to/app/shared/log/unicorn.log"

フォークの設定

Unicornには、利用可能なCPUコアをより有効に活用するためのマルチプロセスアーキテクチャがあります。起動時に、Unicornマスタプロセスはアプリケーションコードをロードし、マスタプロセスからアプリケーションコードを継承するワーカを生成します。リクエストはワーカによってのみ処理され、マスタプロセスでは処理されません。オペレーティングシステムのネットワークスタックは、受信したリクエストをキューに入れ、ワーカに配布されます。

Unicornはユーザのリクエストを切らずに、クラッシュしたワーカを再起動するように設計されています。ワーカがリクエストタイムアウトに達すると、マスタプロセスはワーカをkill -9で終了させ、新しいプロセスに置き換えます。ワーカプロセスの数やリクエストのタイムアウトは、設定できます。

設定

説明

worker_processes (nr)

worker_processes(ワーカプロセス)の数をnrに指定します。各ワーカプロセスは、一度に1つのクライアントだけを処理します。SIGTTINまたはSIGTTOUのシグナルをマスタプロセスに送信することで、設定ファイルをリロードすることなく、実行時にこの値を増減できます。

シグナルについての詳細は、icon-external-link.svgUnicornのサイトを参照ください。

Unicorn::Configurator#after_fork

after_fork(フォーク後)に特定のブロックに対してフックを指定します。

Unicorn::Configurator#before_fork

before_fork(フォーク前)に特定のブロックに対してフックを指定します。

Unicorn::Configurator#preload_app(bool) ⇒ ObjectEnabling

この設定は、ワーカプロセスをフォークする前にアプリケーションをプリロードします。これは、コピーオンライトに適したGCを使用する際にメモリを節約できますが、ソケットのようなリソースがマスタプロセスによってロード時に開かれて複数の子プロセスで共有される場合、問題が生じる可能性があります。

タイムアウトの設定

変数

説明

デフォルトの値

timeout 30

ワーカプロセスのタイムアウトを30秒に設定します。デフォルトは、60秒です。タイムアウトの設定により、この制限を超えたワーカを終了させることができます。このタイムアウトは、マスタプロセスによって強制実行され、ワーカプロセスによるスケジューリングの制限の影響を受けません。

60秒

delay integer

ソケットのバインドの試行を待機する時間を秒単位で指定します。

0.5秒

ヒント

Unicornは、NGINXと連携する場合に多くの設定があります。

APMツール の設定

次のAPMツールはUnicornをサポートしています。

関連項目