Shulou(Shulou.com)06/03 Report--

Detailed explanation of Common configuration of Nginx (1)

This article introduces all kinds of commonly used configurations of nginx according to the documents of nginx official site, without proofreading, if there are any errors, please look at Haihan.

General syntax for Nginx configuration

The basic configuration syntax of Nginx

Configuration item name configuration item value 1 [configuration item value 2.]; the configuration item name is at the beginning of the line, the configuration item value and the configuration item name are separated by a space, and multiple configuration item values are also separated by a space, and each line must end with a semicolon. # configuration item name configuration item value 1 [configuration item value 2]; # you can comment out this line

The Nginx configuration is divided into individual configuration blocks. The main configuration block is responsible for the global configuration, and each sub-block inherits the global configuration. Each subblock also has different configuration items.

Main block: master configuration (global configuration) event {...} event-driven related configuration blocks http {} http/https protocol related configuration blocks mail {...} mail server related configuration blocks stream {.} streaming server related configuration blocks master configuration block configuration

The main configuration is divided into four categories by function:

Configuration necessary for normal operation

Optimize performance-related configuration

Related configurations for debugging and locating problems

Event-driven related configuration

1. Configuration necessary for normal operation: userSyntax: 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.

Defines the credentials of the user or group used by the worker process. Omitting the group name means that the group name is the same as the user name.

PidSyntax: pid file;Default: pid nginx.pid;Context: main

Defines a file that will store the process ID of the main process.

Specifies the file path where the nginx matser process ID is stored.

IncludeSyntax: include file | mask;Default:-Context: any

Includes another file, or files matching the specified mask, into configuration. Included files should consist of syntactically correct directives and blocks.

Configuration files can be embedded in other configuration files, and include indicates that the embedded file location can be an explicit file name or a file name with wildcards. (include can be an absolute path or a relative path, and the relative path is the path of the relative Nginx configuration file, that is, the directory where the Nginx.conf is located)

Load_moduleSyntax: load_module file;Default:-Context: mainThis directive appeared in version 1.9.11.

Loads a dynamic module.

Load the dynamic module. This directive will only take effect after ngnix version 1.9.11

2. Configuration related to performance optimization worker_processesSyntax: worker_processes number | auto;Default: worker_processes 1 domestic 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).

Defines the number of worker processes. This setting directly affects performance, and the best value depends on a variety of factors including, but not limited to, the CPU core, the number of hard drives on which book data is stored, and the loading mode. A better choice is to set the value equal to the number of CPU available (auto automatically detects the number of CPU cores and uses this as the setting value for this item).

Worker_cpu_affinitySyntax: 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.

The set CPU core is bound to the worker process, and each CPU setting is bound to each worker process with a bit mask. By default, the worker process is not bound to any CPU. (each CPUmask represents a CPU core)

For example:

The host has four cores, and four worker processes are set up and bound to each CPU

Worker_processes4; worker_cpu_affinity 0001 0010 0100 1000

The host has four cores. Two worker processes are established. The first process is bound to CPU0/CPU2 and the second process is bound to CPU1/CPU3.

Worker_processes2; worker_cpu_affinity 0101 1010

Use automatic automatic binding

Worker_processes auto; worker_cpu_affinity auto

Automatically bind and restrict CPU usage

Worker_cpu_affinity auto 01010101 leading workerships prioritySyntax: worker_priority number;Default: worker_priority 0politic 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.

Define the priority of the worker process, which is equivalent to the nice instruction: negative numbers have a higher priority, with values ranging from-20 to 20.

Worker_rlimit_nofileSyntax: worker_rlimit_nofile number;Default:-Context: main

Changes the limit on the maximum number of open files (RLIMIT_NOFILE) for worker processes. Used to increase the limit without restarting the main process.

Modify the maximum value that the worker process can open the file, and you can increase the limit without restarting the main process.

3. Debugging and locating problems daemonSyntax: daemon on | off;Default: daemon on;Context: main

Determines whether nginx should become a daemon. Mainly used during development.

Determines whether nginx becomes a daemon, mainly during development.

Master_processSyntax: master_process on | off;Default: master_process on;Context: main

Determines whether worker processes are started. This directive is intended for nginx developers.

Determines whether to enable the worker process. This directive is intended for use by nginx developers.

Error_logSyntax: error_log file [level]; Default: error_log logs/error.log error;Context: main, http, mail, stream, server, location

Configures logging. Several logs can be specified on the same level (1.5.2). If on the main configuration level writing a log to a file is not explicitly defined, the default file will be used.

The first parameter defines a file that will store the log. The special value stderr selects the standard error file. Logging to syslog can be configured by specifying the "syslog:" prefix. Logging to a cyclic memory buffer can be configured by specifying the "memory:" prefix and buffer size, and is generally used for debugging (1.7.11).

The second parameter determines the level of logging, and can be one of the following: debug, info, notice, warn, error, crit, alert, or emerg. Log levels above are listed in the order of increasing severity. Setting a certain log level will cause all messages of the specified and more severe log levels to be logged. For example, the default level error will cause error, crit, alert, and emerg messages to be logged. If this parameter is omitted then error is used.

Configure logs, and several logs can be specified at the same level. If the profile path is not explicitly specified at the master profile level, the default configuration is used.

The first field defines the location of the log storage file. Special value stderr selects the standard error file. Files for syslog can be indicated before with syslog:. For cyclic memory buffer, you can specify it with memory:, and to specify the buffer size, this instruction is usually used for debugging.

The second field determines the log level. Choose one of debug, info, notice, warn, error, crit, alert, emerg. These log levels range from mild to severe from left to right. When the log level is determined, all logs for that level and above are logged. For example: setting the error level records the four basics of error, crit, alert and emerg. If the entry is omitted, the default level is error.

IV. Event-driven configuration

Event-driven related configuration configuration and events configuration block

Events {...} worker_connectionsSyntax: worker_connections number;Default: worker_connections 512 X 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 worker_rlimit_nofile.

Sets the maximum synchronous connection for the worker process.

This setting should be noted that this number includes all connections (for example, proxy connections to servers, etc.), not just client connections.

Another noteworthy issue is that the actual synchronous connection value is smaller than the open file value previously set in worker_rlimit_nofile.

UseSyntax: 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.

Indicates the connection process method used. There is usually no need to specify explicitly, because NGINX defaults to using the most efficient method.

Accept_mutexSyntax: accept_mutex on | off;Default: accept_mutex off;Context: events

If accept_mutex is enabled, worker processes will accept new connections by turn. Otherwise, all worker processes will be notified about new connections, and if volume of new connections is low, some of the worker processes may just waste system resources.

If accept_mutex is enabled, the worker process takes turns accepting new connections. If this is not set, the new connection will not be notified to each worker process. In the case of few new connections, some worker process resources will be wasted.

Accept_mutex_delaySyntax: accept_mutex_delay time;Default: accept_mutex_delay 500mstertext: events

If accept_mutex is enabled, specifies the maximum time during which a worker process will try to restart accepting new connections if another worker process is currently accepting new connections.

When accept_mutex is enabled, indicates the timeout for the worker process to re-accept a new connection when another worker process is accepting a new connection.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.