凤凰时尚网移动版

Syntax: timer_resolution interval;
 
Default: —  
Context: main
 

Reduces timer resolution in worker processes, thus reducing the number of gettimeofday() system calls made. By default, gettimeofday() is called each time a kernel event is received. With reduced resolution, gettimeofday() is only called once per specified interval.

Example:

Internal implementation of the interval depends on the method used:

the EVFILT_TIMER filter if kqueue is used;

timer_create() if eventport is used;

setitimer() otherwise.

Syntax: use method;
 
Default: —  
Context: events
 

Specifies the connection processing method to use. There is normally no need to specify it explicitly, because nginx will by default use the most efficient method.

Syntax: user user [group];
 
Default: user nobody nobody;  
Context: main
 

Defines user and group credentials used by worker processes. If group is omitted, a group whose name equals that of user is used.

Syntax: worker_aio_requests number;
 
Default: worker_aio_requests 32;  
Context: events
 

This directive appeared in versions 1.1.4 and 1.0.7.

When using with the connection processing method, sets the maximum number of outstanding asynchronous I/O operations for a single worker process.

Syntax: worker_connections number;
 
Default: worker_connections 512;  
Context: events
 

Sets the maximum number of simultaneous connections that can be opened by a worker process.

It should be kept in mind that this number includes all connections (e.g. connections with proxied servers, among others), not only connections with clients. Another consideration is that the actual number of simultaneous connections cannot exceed the current limit on the maximum number of open files, which can be changed by .

Syntax: worker_cpu_affinity cpumask ...;
worker_cpu_affinity auto [cpumask];
 
Default: —  
Context: main
 

Binds worker processes to the sets of CPUs. Each CPU set is represented by a bitmask of allowed CPUs. There should be a separate set defined for each of the worker processes. By default, worker processes are not bound to any specific CPUs.

For example,

binds each worker process to a separate CPU, while

binds the first worker process to CPU0/CPU2, and the second worker process to CPU1/CPU3. The second example is suitable for hyper-threading.

The special value auto (1.9.10) allows binding worker processes automatically to available CPUs:

The optional mask parameter can be used to limit the CPUs available for automatic binding:

Syntax: worker_priority number;
 
Default: worker_priority 0;  
Context: main
 

Defines the scheduling priority for worker processes like it is done by the nice command: a negative number means higher priority. Allowed range normally varies from -20 to 20.

Example:

Syntax: worker_processes number | auto;
 
Default: worker_processes 1;  
Context: main
 

Defines the number of worker processes.

The optimal value depends on many factors including (but not limited to) the number of CPU cores, the number of hard disk drives that store data, and load pattern. When one is in doubt, setting it to the number of available CPU cores would be a good start (the value “auto” will try to autodetect it).

Syntax: worker_rlimit_core size;
 
Default: —  
Context: main
 

Changes the limit on the largest size of a core file (RLIMIT_CORE) for worker processes. Used to increase the limit without restarting the main process.