[꿀팁] 고성능 Nginx를위한 튜닝 - (2) 프로세스 처리량 늘리기

#Nginx설치 #웹서버-설치 #Nginx웹서버설치 #웹서버튜닝 #high performancen nginx #system performance tunning #웹서버 튜닝 #성능개선 #시스템튜닝 #파일시스템 튜닝

고성능웹서버를 위한 리눅스 튜닝을 하는 방법들을 정리하여 보았습니다. 막상 관련 글을 쓰려니 내용이 길어져서 연재 형식으로 진행을 해보고자 합니다.

1. 디스크의 I/O 병목 줄이기
2. 프로세스 처리량 늘리기 (Process)
3. TCP 관련 처리량 늘리기
4. 메모리 및 CPU 튜닝하기 (Processor)
5. 마이크로캐싱
6. 로그 부하 줄이기
7. Dos, DDos 방어 설정

 

[꿀팁] 고성능 Nginx를위한 튜닝 - (2) 프로세스 처리량 늘리기

대용량의 트레픽을 처리하는 것은 대량의 네트웍 요청을 수용하고 대량의 파일을 읽고 쓰는 량을 늘려 주는 것입니다.
우선 어플리케이션의 성능 향상은 대량의 파일을 동시에 읽고 쓰는 량을 늘리고, 두번째 시스템의 물리적인 처리속도와 처리량을 초과하여 유입되는 요청을 별도의 큐(Queue)에 쌓아서 적절한 처리 속도를 유지하는 것입니다.
아무리 시스템이 좋아도 절대시간 처리량보다 많은 량이 동시에 유입된다고 이것을 한꺼번에 처리하게 되면 시스템의 프로세스 관리 부하로 인해서 오히려 처리량이 저하되는 현상을 격게 됩니다.
이런 경우를 이론 적으로 "암달의 법칙 (Amdahl's law)"으로 이해를 할수 있을 것 같습니다.

병렬 처리의 한계 암달의 법칙의 이해

암달의 법칙(Amdahl's law)은 미국의 컴퓨터 공학자이자 기업가였던 진 암달(Gene Amdahl)이 만든 법칙으로 암달의 저주(Amdahl's curse), 암달의 인수(Amdahl's argument)라고 합니다.

암달의 법칙의 개요

암달의 법칙은 1965년 옮긴 어드밴스드 컴퓨팅 시스템랩에서 만든 것으로 컴퓨터 성능 최적화의 한계점을 측정하기 위해 만든 법칙입니다. "프로그램의 병렬처리로 처리량을 늘리는데는 성능 향상에 한계가 있다"는 법칙이다. 프로그램은 병렬처리가 가능한 부분과 불가능한 순차적인 부분으로 구성되어 있어 프로세스를 아무리 병렬화 시켜도 더 이상 성능이 향상되지 않는 한계가 존재 한다는 것입니다.

- 암달의 법칙:Amdahl's law -

 

암달의 법칙의 내용

• 성능 한계는 캐쉬, 메모리, 버스와 같이 제한된 물리 자원을 프로세스가 서로 점유하려고 경쟁하는 오버헤드가 발생되기 때문입니다.

 

[꿀팁] 프로세스(Process) 처리량을 늘리기 위한 기술

 

• 리눅스 커널 파라미터를 튜닝하여 동시 처리량 늘리기
• - fs.file-max 와 /etc/security/limits.conf
• Nginx 워크프로세스와 백로그를 이용한 대량 트레픽 처리
• Nginx Thread Pool 기술을 통한 안정적인 처리 속도 관리 (New)

 

1. 리눅스 커널 파라미터를 튜닝하여 동시 처리량 늘리기

• fs.file-max 모든 프로세스에 대해 열린 파일의 최대 수를 지정합니다.
• 파일을 open 하는 경우 뿐만 아니라 대량의 네트웍 호출시 TCP커넥션의 소켓(Socket)수도 파일 핸들로 취급됩니다. 하나의 프로세스가 대량의 파일을 읽거나 네트웍 통신을 하기 위해서는 파일 핸들 부족을 고려하여 늘려 줍니다.

[fs.file-max 수정]
# echo 65536 > /proc/sys/fs/file-max
# sysctl -w fs.file-max=65536

[재부팅시에도 계속 값이 적용 하는 방법] : /etc/sysctl.con에 수정 / 추가를 합니다
# echo "fs.file-max=65536" >> /etc/sysctl.conf
# sysctl -a

 

• /etc/security/limits.conf 계정 환경에 대한 보안 제한 설정 변경

PAM 인증으로 로그인하여 시스템의 데몬을 구동하는 경우에는 시스템 자원의 사용량에 대하여 보안에서 제한하고 있습니다. (This file sets the resource limits for the users logged in via PAM.)
아래와 같은 두가지 항목에 대하여 "nginx"라는 사용자를 통해서 nginx를 사용하는 계정으로 추가하면 됩니다.
만약 계정의 이름을 잘 모르면 "*" 으로 설정합니다.

[/etc/security/limits.conf 수정]

- nofile - max number of open file descriptors
- nproc - max number of processes
- "soft" for enforcing the soft limits
- "hard" for enforcing hard limits

[ nginx 계정에 대한 제한 설정]
nginx hard nproc 10240
nginx soft nproc 10240
nginx hard nofile 204800
nginx soft nofile 204800

 

2. Nginx 워크프로세스와 백로그를 이용한 대량 트레픽 처리

nginx 어플리케이션의 성능을 환경에 맞게 적용하기 위해서는 아래와 같이 기본 설정을 변경 합니다.

• user nginx [nobody]; # user [ group] 으로 default nobody [nobody] 입니다

[Nginx config의 공통영역]

• worker_processes 6; # [auto | cpu core 수]
• worker_rlimit_nofile 204800;

worker_processess 는 물리적인 cpu core 수에 따라 설정하며 10~20% 정도의 core는 운영체제를 위해 남겨 둡니다. 예를 들어 24core CPU라면 Nginx에서 사용할 코어수를 1~20정도 할당하고 2~4개는 OS용으로 남겨둡니다.

[Nginx config의 events 처리 영역]

• worker_connections 8192; # 동시에 8192개의 요청을 받을수 있습니다.]
• multi_accept on; # 순차적으로 요청을 받지 않고 동시에 요청을 접수합니다.
• use epoll; # Linux 2.6+ 이상에서 사용하는 효율적인 이벤트 처리 방식

[Nginx의 연결 처리 방식 종류]
* select , pool : 표준 방식 , 다른 방식을 지정하지 않으면 사용되는 기본 방식입니다.
* kqueue : FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 및 macOS에서 순차적인 처리를 위한 방식
* epoll : Linux 2.6+ 이상에서 사용하는 효율적인 이벤트 처리 방식
* /dev/poll : Solaris711/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 및 Tru64 UNIX 5.1A + 에서 사용

[Nginx config의 http 영역]
# 커널 내에서 하나의 FD와 다른 FD간에 데이터를 복사합니다. # read () + write ()
sendfile on ;
# 응답 헤더를 TCP packet 한 조각으로 보냅니다.
tcp_nopush on ;
# 전송된 데이터를 버퍼링하지 않음, 실시간으로 느린 네트워크에서 작은 패킷 문제를 해결(Nagle의 알고리즘) 합니다.
tcp_nodelay on ;
# 서버가 응답하지 않는 클라이언트에서 연결을 닫을 수 있도록 허용 합니다.
reset_timedout_connection on ;
# 요청 시간 초과-기본값 60 입니다.
client_body_timeout 10 ;
# 클라이언트가 응답을 중지하여 메모리를 확보합니다. 기본값 60
send_timeout 2 ;
#이 시간이 지나면 서버가 연결을 종료합니다. 기본값 75
keepalive_timeout 30 ;
# 테스트 환경의 경우 - 클라이언트가 연결 유지를 통해 수행 할 수있는 요청 수입니다.
keepalive_requests 100000 ;
# 닫힌 소켓이 FIN_WAIT1 상태로 오랫동안 유지되는 것을 방지 할 수 있습니다.
reset_timedout_connection on;
# 클라이언트 요청 본문을 읽기 제한 시간이며, 408(Request Time-out) 오류를 냅니다.
client_body_timeout 10; [default 60초]
#클라이언트에 응답을 전송하기위한 시간 제한시간이며, 응답없거나 느린 클라이언트를 제한합니다.
send_timeout 2; [default 60초]

[Nginx config의 server 영역]
listen one.example.com backlog=8192; 과 같이 별도의 백로그 설정이 가능합니다.

user nginx; # default nobody

worker_processes 6; # [auto | cpu core 수]
worker_rlimit_nofile 204800;

pid /var/run/nginx.pid;
error_log /var/log/nginx.error_log debug;
# [ debug | info | notice | warn | error | crit ]
#

events {
      worker_connections 8192; [4096 ~ 8192 정도]
      multi_accept on;
      use epoll;
      # use [ kqueue | epoll | /dev/poll | select | poll ];
}

http {
      include conf/mime.types;
      default_type application/octet-stream;
      sendfile on;
      tcp_nopush on;
      tcp_nodelay on;
      keepalive_timeout 15;
      keepalive_requests 100000;

      reset_timedout_connection on;
      client_body_timeout 10;
      send_timeout 2;


      ..... 생략 ....
      server {
            listen one.example.com backlog=8192;
           server_name one.example.com www.one.example.com;
           .... 생략 ....

            # serve static files
            location ~ ^/(images|javascript|js|css|flash|media|static)/ {
                    root /data/example/static;
                    expires 30d;
             }

           location / {
              .... 생략 ....
            }
            location /app {
             .... 생략 ....
            }
      }
}

 

3. Thread Pool 기술을 통한 일정한 처리 속도 향상 (New)

Nginx 스레드 풀 구성은 Nginx의 새로운 개념입니다. 풀링을 이용하여 대량의 처리를 보다 안정적으로 처리하기 위해서 사용하는 방식입니다. 그리고 None Block 입출력으로 async I/O 인 aio (Nginx Plus) 방식 또한 쓰레드와 함께 활용시 프로세스간 경합을 줄이고 성능을 극대화 할 수 있습니다.
유입되는 서비스 종류별 부하를 분산 하는 경우와 백엔드의 특성에 따라 처리 속도나 장애를 격리 하는데 유용합니다

스레드 풀을 사용 하려면 NGINX 버전 1.7.11 이상에서 지원되며 --with-threads인수로 컴파일 합니다.

thread pool "NAME" queue overflow: N tasks waiting

default 라는 스레드 풀은 32 개의 작업 스레드와 작업 대기열에 대한 최대 길이는 65536입니다.
각 설정은 아래와 같이 설정 영역에 맞도록 작성하면 됩니다.

# in the 'main' context
thread_pool default threads=32 max_queue=65536;

# in the 'http', 'server', or 'location' context
aio threads=default;

쓰레드 풀을 2가지로 만들어 특정 URI 별로 별도의 풀이 작동되도록 구성할수 있습니다.

# in the 'main' context
thread_pool pool_one threads=128 max_queue=0;
thread_pool pool_two threads=32 max_queue=65536;
http {
      server {
           location /one {
                 aio threads=pool_one;
            }
            location /two {
                 aio threads=pool_two;
            }
      }
#...
}

couplewith.tistory.com/entry/꿀팁-고성능-Nginx를위한-튜닝-1-디스크의-IO-병목-줄이기

[꿀팁] 고성능 Nginx를위한 튜닝 - (1) 디스크의 I/O 병목 줄이기

couplewith.tistory.com/entry/꿀팁-고성능-Nginx를위한-튜닝-3-TCP-관련-처리량-늘리기

[꿀팁] 고성능 Nginx를위한 튜닝 - (3) TCP 관련 처리량 늘리기-리눅스커널튜닝

github.com/denji/nginx-tuning

denji/nginx-tuning

www.nginx.com/blog/thread-pools-boost-performance-9x/

Boosting NGINX Performance 9x with Thread Pools

nginx.org/en/docs/http/ngx_http_core_module.html

Module ngx_http_core_module

 

1. 디스크의 I/O 병목 줄이기
2. 프로세스 처리량 늘리기 (Process)
3. TCP 관련 처리량 늘리기
4. 메모리 및 CPU 튜닝하기 (Processor)
5. 마이크로캐싱
6. 로그 부하 줄이기
7. Dos, DDos 방어 설정