← 返回命令列表

Linux command

gunicorn 命令

文本

复制后可按需替换文件名、目录或参数。

常用示例

Run a WSGI application

gunicorn [myapp:app]

Run on a specific host and port

gunicorn --bind [0.0.0.0:8000] [myapp:app]

Run with multiple workers

gunicorn --workers [4] [myapp:app]

Run with automatic worker restart

gunicorn --reload [myapp:app]

Run with access logging

gunicorn --access-logfile [access.log] [myapp:app]

Run as a daemon

gunicorn --daemon --pid [gunicorn.pid] [myapp:app]

Run with Unix socket

gunicorn --bind unix:[/tmp/gunicorn.sock] [myapp:app]

Use async workers

gunicorn --worker-class [gevent] --workers [4] [myapp:app]

说明

Gunicorn (Green Unicorn) is a Python WSGI HTTP server for Unix systems, designed to serve web applications in production using a pre-fork worker model. A master process manages a pool of worker processes, each of which independently handles incoming requests. The application is specified as module:variable (e.g., `myapp:app` for Flask or `myproject.wsgi:application` for Django), and the recommended worker count is (2 x CPU cores) + 1 to balance concurrency against memory usage. The default synchronous worker handles one request at a time per process, which is suitable for CPU-bound applications. For I/O-bound workloads with many concurrent connections, async worker classes such as `gevent` or `eventlet` use cooperative multithreading to multiplex thousands of connections within fewer processes, while the `gthread` worker uses OS threads. Workers that exceed the configurable timeout are automatically killed and restarted by the master process, providing resilience against hung requests. In production, Gunicorn typically runs behind a reverse proxy like Nginx, which handles SSL termination, static file serving, and request buffering. Communication between the proxy and Gunicorn occurs over HTTP or a Unix domain socket.

参数

-b, --bind _ADDRESS_
Socket to bind (HOST:PORT, unix:PATH, or fd://FD).
-w, --workers _INT_
Number of worker processes (default: 1).
-k, --worker-class _STRING_
Worker type: sync, gevent, eventlet, tornado, gthread.
--threads _INT_
Threads per worker (for gthread worker).
-t, --timeout _INT_
Worker timeout in seconds (default: 30).
--graceful-timeout _INT_
Timeout for graceful worker restart.
--reload
Restart workers when code changes (development only).
-D, --daemon
Daemonize the process.
-p, --pid _FILE_
PID file path.
--access-logfile _FILE_
Access log file (- for stdout).
--error-logfile _FILE_
Error log file (- for stderr).
--log-level _LEVEL_
Logging level: debug, info, warning, error, critical.
-c, --config _FILE_
Configuration file path.
--preload
Load application code before forking workers.
--max-requests _INT_
Restart workers after this many requests (0 = disabled). Helps prevent memory leaks.
--max-requests-jitter _INT_
Random jitter added to max-requests to stagger restarts.
--keep-alive _INT_
Seconds to wait for requests on a Keep-Alive connection (default: 2).
-n, --name _STRING_
Process name for ps output.
-u, --user _USER_
Switch worker processes to run as this user.
-g, --group _GROUP_
Switch worker process to run as this group.

FAQ

What is the gunicorn command used for?

Gunicorn (Green Unicorn) is a Python WSGI HTTP server for Unix systems, designed to serve web applications in production using a pre-fork worker model. A master process manages a pool of worker processes, each of which independently handles incoming requests. The application is specified as module:variable (e.g., `myapp:app` for Flask or `myproject.wsgi:application` for Django), and the recommended worker count is (2 x CPU cores) + 1 to balance concurrency against memory usage. The default synchronous worker handles one request at a time per process, which is suitable for CPU-bound applications. For I/O-bound workloads with many concurrent connections, async worker classes such as `gevent` or `eventlet` use cooperative multithreading to multiplex thousands of connections within fewer processes, while the `gthread` worker uses OS threads. Workers that exceed the configurable timeout are automatically killed and restarted by the master process, providing resilience against hung requests. In production, Gunicorn typically runs behind a reverse proxy like Nginx, which handles SSL termination, static file serving, and request buffering. Communication between the proxy and Gunicorn occurs over HTTP or a Unix domain socket.

How do I run a basic gunicorn example?

Run `gunicorn [myapp:app]` in a terminal, then adjust file names, paths, flags, or remote targets for your system.

What does -b, --bind _ADDRESS_ do in gunicorn?

Socket to bind (HOST:PORT, unix:PATH, or fd://FD).