핵심 기능

예제 구성

user www www;
worker_processes 2;

error_log /var/log/nginx-error.log info;

events {
    use kqueue;
    worker_connections 2048;
}

...

Directives

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

accept_mutex를 활성화하면 작업자 프로세스가 차례로 새로운 연결을 수락합니다. 그렇지 않을 경우, 모든 작업자 프로세스는 새 연결에 대해 알림을 받습니다. 새로운 연결 수가 적으면 일부 작업자 프로세스가 시스템 리소스를 낭비할 수 있습니다.

EPOLLEXCLUSIVE 플래그(1.11.3)를 지원하는 시스템에서나 reuseport를 사용할 때 accept_mutex를 활성화할 필요가 없습니다.

1.11.3버전 이전에 기본값은 on이었습니다.

Syntax:	 accept_mutex_delay time;
Default: accept_mutex_delay 500ms;
Context: events

accept_mutex를 활성화하는 경우, 다른 작업자 프로세스가 새로운 연결을 수락하는 중일 때 작업자 프로세스가 새 연결을 다시 수락하기 시작하는 최대 시간을 지정합니다.

Syntax:  daemon on | off;
Default: daemon on;
Context: main

nginx가 daemon이 되어야 할지 나타냅니다. 주로 개발 중에 사용합니다.

Syntax:	 debug_connection address | CIDR | unix:;
Default: —
Context: events

일부 클라이언트 연결에 디버깅 로그를 활성화합니다. 다른 연결은 error_log 명령에서 설정한 로깅 수준을 사용합니다. 디버깅된 연결은 IPv4 또는 IPv6(1.3.0, 1.2.1) 주소나 네트워크로 지정합니다. 연결은 호스트 이름을 사용하여 지정할 수도 있습니다. UNIX 도메인 소켓(1.3.0, 1.2.1)을 사용하여 연결하는 경우, 디버깅 로그는 “unix:” 매개변수로 활성화됩니다.

events {
    debug_connection 127.0.0.1;
    debug_connection localhost;
    debug_connection 192.0.2.0/24;
    debug_connection ::1;
    debug_connection 2001:0db8::/32;
    debug_connection unix:;
    ...
}

이 명령이 작동하려면 nginx를 –with-debug로 구축해야 합니다. “디버깅 로그“를 참조하세요.

Syntax:	 debug_points abort | stop;
Default: —
Context: main

이 명령은 디버깅에 사용합니다.

내부 오류를 탐지하는 경우(예: 작업자 프로세스를 다시 시작할 때 소켓 누수), debug_points를 활성화하면 코어 파일이 생성되거나(abort), 프로세스를 중단하고(stop) 시스템 디버거로 추가적인 분석을 합니다.

Syntax:	 env variable[=value];
Default: env TZ;
Context: main

기본적으로 nginx는 TZ 변수를 제외하고 상위 프로세스에서 상속한 모든 환경 변수를 제거합니다. 이 명령을 사용하면 상속된 변수의 일부를 보존하거나, 값을 변경하거나, 새 환경 변수를 생성할 수 있습니다. 그 후 이 변수는 다음과 같이 처리됩니다.

  • 실행 파일의 라이브 업그레이드 중 상속
  • ngx_http_perl_module 모듈에서 사용
  • 작업자 프로세스에서 사용 이렇게 시스템 라이브러리를 제어하지 못할 경우도 있습니다. 일반적으로 라이브러리는 이 명령을 사용하여 설정하기 훨씬 전인, 초기화 중에만 변수를 검사하기 때문입니다. 앞서 언급한 실행 파일의 라이브 업그레이드는 예외입니다.

TZ 변수는 항상 상속되고, 명시적으로 구성되지 않는 한 ngx_http_perl_module 모듈에 제공됩니다.

사용 예제:

env MALLOC_OPTIONS;
env PERL5LIB=/data/site/modules;
env OPENSSL_ALLOW_PROXY_CERTS=1;

NGINX 환경 변수는 nginx에서 내부적으로 사용하고 사용자가 직접 설정해서는 안됩니다.

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

로깅을 구성합니다. 동일한 구성 수전에서 여러 로그를 지정할 수 있습니다(1.5.2). main 구성 수준에서 파일에 로그를 작성하도록 명시적으로 정의하지 않을 경우, 기본 파일을 사용합니다.

첫 매개변수는 로그를 저장하는 file을 정의합니다. 특수 값 stderr는 표준 오류 파일을 선택합니다. syslog로의 로깅은 “syslog:” 접두사를 지정하면 구성할 수 있습니다. 순환 메모리 버퍼로의 로깅은 “memory:” 접두사와 버퍼 size를 지정하여 구성할 수 있고, 일반적으로 디버깅에 사용됩니다(1.7.11).

두 번째 매개변수는 로깅의 level을 결정하고 다음 중 하나가 될 수 있습니다. debug, info, notice, warn, error, crit, alert, or emerg. 위의 로그 수준은 심각도가 커지는 순으로 나와 있습니다. 특정 로그 수준을 설정하면 그 수준 이상의 모든 메시지가 로깅됩니다. 예를 들어, 기본 수준 error를 설정하면 error, crit, alert, 및 emerg 메시지가 로깅됩니다. 이 매개변수를 생략하면 error를 사용합니다.

debug 로깅이 작동하려면 nginx를 –with-debug로 구축해야 합니다. “디버깅 로그“를 참조하세요.

이 명령은 1.7.11버전부터 stream 수준에서 지정할 수 있고, 1.9.0버전부터는 mail 수준에서 지정할 수 있습니다.

Syntax:  events { ... }
Default: —
Context: main

연결 처리에 영향을 미치는 명령을 지정한 구성 파일 컨텍스트를 제공합니다.

Syntax:	 include file | mask;
Default: —
Context: any

다른 file이나 지정된 mask와 일치하는 파일을 구성에 포함합니다. 포함된 파일은 구문적으로 올바른 명령과 블록으로 구성해야 합니다.

사용 예제:

include mime.types;
include vhosts/*.conf;
Syntax:	 load_module file;
Default: —
Context: main
This directive appeared in version 1.9.11.

동적 모듈을 로드합니다.

예:

load_module modules/ngx_mail_module.so;
Syntax:	 lock_file file;
Default: lock_file logs/nginx.lock;
Context: main

nginx는 잠금 메커니즘을 사용하여 accept_mutex를 구현하고 공유된 메모리로의 액세스를 직렬화합니다. 대부분 시스템에서 잠금은 원자성 동작을 사용하여 구현되고, 이 명령은 무시됩니다. 어떤 시스템에서는 “잠금 파일” 메커니즘을 사용합니다. 이 명령은 잠금 파일의 이름에 대한 접두사를 지정합니다.

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

작업자 프로세스가 시작되었는지 확인합니다. 이 명령은 nginx 개발자가 사용합니다.

Syntax:	 multi_accept on | off;
Default: multi_accept off;
Context: events

multi_accept가 비활성화되면 작업자 프로세스가 한 번에 하나의 새로운 연결을 수락합니다. 그렇지 않은 경우, 작업자 프로세스는 한 번에 모든 새로운 연결을 수락합니다.

kqueue 연결 처리 방법을 사용하면 이 명령을 무시합니다. 수락을 기다리는 새 연결 수를 보고하기 때문입니다.

Syntax:	 pcre_jit on | off;
Default: pcre_jit off;
Context: main
This directive appeared in version 1.1.12.

구성 파싱 시점에 알려진 정규식에 대한 “JIT 컴파일”(PCRE JIT) 사용을 활성화하거나 비활성화합니다.

PCRE JIT는 정규식 처리 속도를 상당히 개선할 수 있습니다.

8.20버전에서부터 PCRE 라이브러리에 제공되는 JIT는 –enable-jit 구성 매개변수로 구축됩니다. PCRE 라이브러리를 nginx(–with-pcre=)로 구축하면 JIT는 –with-pcre-jit 구성 매개변수를 통해 지원됩니다.

Syntax:	 pid file;
Default: pid logs/nginx.pid;
Context: main

메인 프로세스의 프로세스 ID를 저장할 file을 정의합니다.

Syntax:  ssl_engine device;
Default: —
Context: main

하드웨어 SSL 가속기의 이름을 정의합니다.

Syntax:	 thread_pool name threads=number [max_queue=number];
Default: thread_pool default threads=32 max_queue=65536;
Context: main
This directive appeared in version 1.7.11.

작업자 프로세스를 차단하지 않고 파일을 다중 스레드 방식으로 읽고 전송하는 데 사용하는 스레드 풀의 name과 매개변수를 정의합니다.

threads 매개변수는 풀에서 스레드의 수를 정의합니다.

풀에 있는 모든 스레드가 사용 중일 경우, 새 작업은 대기열에서 대기합니다. max_queue 매개변수는 대기열에서 대기 가능한 작업 수를 제한합니다. 기본적으로 최대 65536개의 작업이 대기열에서 대기할 수 있습니다. 대기열 오버플로가 발생하면 작업이 오류와 함께 완료됩니다.

Syntax:  timer_resolution interval;
Default: —
Context: main

작업자 프로세스에서 타이머 해상도를 낮추어서, gettimeofday() 시스템 호출을 보내는 횟수를 줄이세요. 기본적으로 gettimeofday()는 커널 이벤트를 수신할 때마다 호출됩니다. 해상도를 낮추면 gettimeofday()는 지정된 interval마다 한 번씩만 호출됩니다.

예:

timer_resolution 100ms;

이 간격을 내부에 구현하는 방식은 사용하는 메서드에 따라 달라집니다.

  • the EVFILT_TIMER filter if kqueue is used;
  • timer_create() if eventport is used;
  • setitimer() otherwise.
Syntax:  use method;
Default: —
Context: events

사용할 연결 처리 method를 지정합니다. 일반적으로 이 메서드를 명시적으로 지정할 필요가 없는데, 그 이유는 nginx가 가장 효율적인 방법을 기본적으로 사용하기 때문입니다.

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

작업자 프로세스가 사용하는 usergroup 자격 증명을 정의합니다. group이 생략될 경우, user와 이름이 동일한 그룹을 사용합니다.

Syntax:  worker_aio_requests number;
Default: worker_aio_requests 32;
Context: events
This directive appeared in versions 1.1.4 and 1.0.7.

epoll 연결 처리 메서드와 함께 aio를 사용할 경우, 작업자 프로세스 1개에 대해 처리되지 않은 비동기식 I/O 작업의 최대 number를 설정합니다.

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

작업자 프로세스에서 연 동시 연결의 최대 개수를 설정합니다.

다만, 이 숫자에는 클라이언트와의 연결뿐만 아니라 다른 연결(예: 프록시된 서버와의 연결)이 모두 포함됩니다. 그밖에 고려할 사항이 있다면, 동시 연결의 실제 개수는 열린 파일의 현재 최대한도를 초과할 수 없습니다. 이 한도는 worker_rlimit_nofile로 변경할 수 있습니다.

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

작업자 프로세스를 CPU 세트에 바인딩합니다. 각 CPU 세트는 허용된 CPU의 비트마스크로 대표됩니다. 각 작업자 프로세스에 정의된 별도의 세트가 있어야 합니다. 기본적으로 작업자 프로세스는 특정 CPU에 바인딩되지 않습니다.

예를 들어,

worker_processes    4;
worker_cpu_affinity 0001 0010 0100 1000;

각 작업자 프로세스를 별도의 CPU에 바인딩하는 동안

worker_processes    2;
worker_cpu_affinity 0101 1010;

첫 작업자 프로세스는 CPU0/CPU2에 바인딩하고, 두 번째 작업자 프로세스는 CPU1/CPU3에 바인딩합니다. 두 번째 예시는 하이퍼 스레딩에 적절합니다.

특수 값 auto(1.9.10)를 사용하면 작업자 프로세스를 사용 가능한 CPU에 자동으로 바인딩합니다.

worker_processes auto;
worker_cpu_affinity auto;

선택적 마스크 매개변수를 사용하여 자동 바인딩에 사용할 CPU를 제한할 수 있습니다.

worker_cpu_affinity auto 01010101;

이 명령은 FreeBSD와 Linux에서만 사용할 수 있습니다.

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

nice 명령과 마찬가지로, 작업자 프로세스에 대한 예약 우선순위를 지정합니다. number가 음수이면 우선순위가 높다는 것을 나타냅니다. 일반적으로 허용되는 범위는 -20에서 20까지입니다.

예:

worker_priority -10;
Syntax:  worker_processes number | auto;
Default: worker_processes 1;
Context: main

작업자 프로세스의 개수를 정의합니다.

선택적 값은 CPU 코어 수, 데이터를 저장하는 하드 디스크 드라이브 수, 로드 패턴 등, 여러 가지 요소에 따라 달라집니다. 확실하지 않은 경우에는 우선 CPU 코어 개수로 설정하는 것이 좋습니다(“auto” 값이 자동 탐지 시도).

auto 매개변수는 1.3.8 및 1.2.5버전부터 지원됩니다.

Syntax:  worker_rlimit_core size;
Default: —
Context: main

작업자 프로세스에 대한 코어 파일의 최대 용량 한도(RLIMIT_CORE)를 변경합니다. 메인 프로세스를 다시 시작하지 않고 한도를 높이는 데 사용합니다.

Syntax:  worker_rlimit_nofile number;
Default: —
Context: main

작업자 프로세스에 대한 열린 파일의 최대 개수(RLIMIT_NOFILE)를 변경합니다. 메인 프로세스를 다시 시작하지 않고 한도를 높이는 데 사용합니다.

Syntax:  worker_shutdown_timeout time;
Default: —
Context: main
This directive appeared in version 1.11.11.

작업자 프로세스의 점진적 종료 시간제한을 구성합니다. time이 만료되면 nginx가 종료를 돕기 위해 현재 열려 있는 모든 연결을 닫으려고 시도합니다.

Syntax:  working_directory directory;
Default: —
Context: main

작업자 프로세스의 현재 작동 중인 디렉터리를 정의합니다. 이 디렉터리는 주로 코어-파일을 작성할 때 사용하며, 이 경우에 작업자 프로세스는 특정 디렉터리에 대한 쓰기 권한이 있어야 합니다.

Comments are closed.