Man Linux: Main Page and Category List

NAME

       gunicorn - Event-based HTTP/WSGI server

SYNOPSIS

       gunicorn [OPTIONS] APP_MODULE

OPTIONS

       -c CONFIG, --config=CONFIG
         Config file. [none]

       -b BIND, --bind=BIND
         Address to listen on. Ex. 127.0.0.1:8000 or unix:/tmp/gunicorn.sock

       -w WORKERS, --workers=WORKERS
         Number of workers to spawn. [1]

       -a ARBITER, --arbiter=ARBITER
         gunicorn arbiter entry point or module [egg:gunicorn#main]

       -p PIDFILE, --pid=PIDFILE
         Set the background PID FILE

       -D, --daemon
         Run daemonized in the background.

       -m UMASK, --umask=UMASK
         Define umask of daemon process

       -u USER, --user=USER
         Change worker user

       -g GROUP, --group=GROUP
         Change worker group

       -n PROC_NAME, --name=PROC_NAME
         Process name

       --log-level=LOGLEVEL
         Log level below which to silence messages. [info]

       --log-file=LOGFILE
         Log to a file. - equals stdout. [-]

       d, --debug
         Debug mode. only 1 worker.

       --version
         Show program's version number and exit

       -h, --help
         show this help message and exit

DESCRIPTION

       Green Unicorn (gunicorn) is an HTTP/WSGI server designed to serve fast
       clients or sleepy applications. That is to say; behind a buffering
       front-end server such as nginx or lighttpd.

        * Optional support for Eventlet and Gevent to provide asynchronous
          long-polling ("Comet") connections.
        * Process management: Gunicorn reaps and restarts workers that die.
        * Easy integration with Django and Paster compatible applications (Pylons,
          TurboGears 2, etc.
        * Load balancing via pre-fork and a shared socket
        * Graceful worker process restarts
        * Upgrading without losing connections
        * Decode chunked transfers on-the-fly, allowing upload progress notifications
          or stream-based protocols over HTTP

TUNING

   KERNEL PARAMETERS
       There are various kernel parameters that you might want to tune in
       order to deal with a large number of simultaneous connections.
       Generally these should only affect sites with a large number of
       concurrent requests and apply to any sort of network server you may be
       running. They're listed here for ease of reference.

       The commands listed are tested under Mac OS X 10.6. Your flavor of Unix
       may use slightly different flags. Always reference the appropriate man
       pages if uncertain.

   INCREASING THE FILE DESCRIPTOR LIMIT
       One of the first settings that usually needs to be bumped is the
       maximum number of open file descriptors for a given process. For the
       confused out there, remember that Unices treat sockets as files.

        $ sudo ulimit -n 1024

   INCREASING THE LISTEN QUEUE SIZE
       Listening sockets have an associated queue of incoming connections that
       are waiting to be accepted. If you happen to have a stampede of clients
       that fill up this queue new connections will eventually start getting
       dropped.

        $ sudo sysctl -w kern.ipc.somaxconn="1024"

   WIDENING THE EPHEMERAL PORT RANGE
       After a socket is closed it eventually enters the TIME_WAIT state. This
       can become an issue after a prolonged burst of client activity.
       Eventually the ephemeral port range is used up which can cause new
       connections to stall while they wait for a valid port.

       This setting is generally only required on machines that are being used
       to test a network server.

SEE ALSO

       gunicorn_django(1)