Nginx 매개 변수 최적화

Nginx 와 Apache 의 초기 차이
Nginx 는 Apahce 서버 와 달리 대량의 최적화 설정 을 한 후에 마술 처럼 뚜렷 한 성능 을 향상 시 키 는 효과 가 있 습 니 다. Nginx 는 설치 가 완 료 된 후에 대부분의 매개 변 수 는 최적화 되 었 습 니 다. 우리 가 관리 해 야 할 것 이 많 지 않 습 니 다.
Nginx 매개 변수 최적화 설정 및 원인
\ # 차단 과 비 차단 네트워크 모델 의 개념
동기 화 블록 모델, 프로 세 스 를 요청 합 니 다. 자세히 말 하면 요청 이 도착 한 후에 열 작업 을 해 야 합 니 다. 모든 작업 을 진행 할 때 우 리 는 이 프로 세 스 를 멈 추고 기다 리 게 합 니 다. 결 과 를 기다 린 후에 다음 작업 을 진행 합 니 다. 프로 세 스 가 어느 정도 증가 한 후에 더 많은 CPU 시간 을 이 프로 세 스 에 낭비 합 니 다.성능 이 급 격 히 떨 어 지기 때문에 부하 효율 이 높 지 않다.
비 차단 모델 은 위 와 는 전혀 다 릅 니 다. 요청 이 도착 하면 요청 한 일이 진행 되 고 있 지만 오래 걸 립 니 다. 이 때 프로 세 스 는 여기 서 멈 춰 서 기다 리 는 것 이 아니 라 현재 하고 있 는 일 을 한 대열 에 던 진 다음 프로 세 스 가 다른 일 을 합 니 다.다음 요청 이나 다음 이벤트 에 응답 합 니 다. 기다 리 는 이벤트 가 완료 되면 다음 동작 을 수행 합 니 다. 그룹 프로 세 스 가 다음 진행 할 이벤트 로 돌아 간 후에 인수 합 니 다.
하나의 프로 세 스 는 극단 적 인 시간 내 에 대량의 요청 에 응답 할 수 있 지만, 이 수 치 는 많 을 수록 좋 은 것 은 아니다.
권장 값 < = cpu 핵심 수량, 일반적으로 cpu 수량 보다 높 으 면 좋 은 점 을 가 져 오지 않 습 니 다. 프로 세 스 전환 비용 의 부정적인 영향 도 있 을 수 있 습 니 다. 이 값 은 모든 cpu 가 충분히 작 동 할 수 있 고 이 값 보다 적 으 면 시스템 이나 다른 응용 프로그램 에서 해 야 할 일 을 할 수 있 습 니 다.
\ # 작업 프로 세 스 수
worker_process 4; 위 참조 설정
\ # 작업 프로 세 스 를 CPU 로 연결 합 니 다.
worker_cpu_affinity 0001 0010 0100 1000;
작업 프로 세 스 workerprocess 는 특정한 cpu 에 연결 되 어 있 으 며, 프로 세 스 가 cpu 사이 에서 전환 하 는 비용 을 피 합 니 다. 여러 그룹 으로 구성 되 어 있 습 니 다.(cpu 는 몇 개의 커 널 에 몇 개의 커 널 이 있 습 니 다. 각 그룹 에 몇 개의 숫자 가 있 습 니 다. 몇 개의 작업 프로 세 스 가 있 으 면 몇 개의 숫자 를 설정 합 니 다. 다음 과 같 습 니 다. 4 핵 4 프로 세 스 의 cpu 가 있 기 때문에 다음 그룹 마다 4 개의 숫자 가 있 습 니 다. 그리고 각 그룹의 숫자 는 cpu 의 어느 위치 에 연결 되 어 있 는 지 대표 합 니 다.)
\ # 8 핵 4 프로 세 스 의 설정 방법 worker cpu affinity 00000001 00000000 10000000;
\ # 최대 파일 은 설명 자 를 열 수 있 습 니 다.
worker_rlimit_nofile 65535;
모든 프로 세 스 가 파일 설명자 수 를 열 수 있 습 니 다. (Liux 에서 네트워크 포트 를 엽 니 다. 장치, 디스크 파일 은 파일 설명자 로 되 돌아 갑 니 다)파일 설명자 가 모든 프로 세 스에 서 열 수 있 는 최대 수량 은 제한 되 어 있 습 니 다. 이 제한 을 초과 하면 오류 가 발생 하고 요청 이 거 부 됩 니 다. nginx 에서 요청 을 보 내 면 시스템 현재 프로 세 스에 서 파일 설명자 가 상한 에 도달 하면 502 오 류 를 되 돌려 줍 니 다. 따라서 nginx 가 시스템 을 최대 화 할 수 있 도록 해 야 합 니 다.파일 수 를 열 수 있 습 니 다. 이 값 은 클 수록 좋 습 니 다. 이론 값 = 시스템 에서 사용 할 수 있 는 최대 수 / 프로 세 스 수 입 니 다. 그러나 각 프로 세 스 간 작업량 이 평균 적 으로 분 배 된 것 이 아니 기 때문에 이 값 은 좀 더 크게 설정 할 수 있 습 니 다. 이렇게 하면 모든 프로 세 스 가 파일 설명자 의 제한 으로 링크 를 거부 하지 않도록 충분히 보장 합 니 다. 물론 시스템 의 파일 설명자 제한 도 조절 할 수 있 습 니 다.ulimit - a, open file 항목 에 표시 되 며, ulimit - a + 수 치 를 통 해 수정 합 니 다 (구체 적 인 매개 변 수 는 Liux 최적화 에 따라 설정 합 니 다).
이벤트 모듈
\ # 모든 프로 세 스 의 최대 연결 수
(동시 응답 능력 의 핵심 설정 값) worker connections 2000;
모든 작업 프로 세 스 가 얼마나 많은 사용자 의 연결 을 동시에 진행 할 수 있 는 지 지정 합 니 다. 이 값 은 Nginx 서버 의 최대 부 하 량 에 직접적인 영향 을 줍 니 다. 충분 한 연결 을 받 아야 충분 한 부 하 를 견 딜 수 있 습 니 다. 모든 프로 세 스 가 허용 하 는 최대 시간 연결 수 (응답 가능 한 사용자 수 와 같 지 않 음). worker connections * worker processes = maxconnection; 다음은 Nginx 최대 연결 수의 계산 입 니 다. 1. 정적 서버 일 때 일반 max Client = work connections * worker processes / 2; (2 를 제외 한 이 유 는 일반 브 라 우 저 에서 두 개의 연결 이 열 리 기 때문에 한 사용자 가 두 개의 연결 을 차지 합 니 다)2. 역방향 프 록 시 서버 로 서 max Client = worker connections * worker processes / 4; (위 에서 2 로 나 누 는 이 유 는 다른 두 연결 은 당연히 Nginx 에서 백 엔 드 서버 로 의 프 록 시 입 니 다.)상기 두 설정 은 설정 파일 에 나타 나 지 않 습 니 다. 다만 압력 테스트 를 할 때 최대 연결 수 를 예측 하 는 데 편리 합 니 다. 예 를 들 어 압력 테스트 를 할 때 최대 연결 수 는 5000 으로 예상 합 니 다. 실측 이 부족 할 때 이 매개 변 수 를 통 해 어떻게 조정 해 야 하 는 지 알 수 있 습 니 다.
\ # 이벤트 처리 네트워크 모델 지정
epoll 을 사용 하 는 지 kquene (* BSD) use epoll 을 사용 하 는 지 가리 키 기;
구체 적 인 네트워크 모델 은 이 글 의 첫 번 째 부분 에서 Nginx 는 비 차단 모델 을 사용 합 니 다. 비 차단 모델 은 서로 다른 운영 체제 에서 구체 적 으로 실현 하 는 데 차이 가 있 습 니 다. 보통 Liux 에서 epoll 이 고 일부 BSD 시스템 에 서 는 kquene 모델 을 사용 합 니 다. 실제 대부분 은 우리 가 설정 할 필요 가 없습니다. 설치 할 때 Nginx 는 시스템 이 어떤 모델 을 지원 하 는 지 자동 으로 식별 하여 진행 합 니 다.합 리 적 인 값 의 선택 입 니 다. 추가 적 으로 설명 하 는 것 은 Windows 에서 Nginx 는 windows 에 대해 비 차단 색 네트워크 모델 을 최적화 하 는 프로 그래 밍 을 하지 않 았 기 때문에 Windows 에서 비 차단 네트워크 모델 을 사용 할 수 없습니다. 이것 은 Nginx 가 Windows 에서 Liux 보다 성능 이 낮은 이 유 를 결정 합 니 다. 그래서 생산 환경 에서 높 은 부하 상황 에서 Windows 시스템 을 사용 하 는 것 을 권장 하지 않 습 니 다.
PS: 초고 부하 에서 가장 좋 은 네트워크 응답 능력 을 달성 하려 면 네트워크 와 관련 된 Liux 커 널 파 라미 터 를 최적화 할 필요 가 있 습 니 다.
HTTP 모듈

include        mime.type;
default_type    application/octet-stream;

\ # 접근 로그
access_log off;
모든 사용자 의 매번 요청 은 기록 해 야 하지만 높 은 부하 상황 에서 대량의 요청 이 들 어 온 후에 대량의 로그 기록 을 하면 많은 비용 이 들 수 있 습 니 다. 이 방문 로 그 를 닫 으 면 많은 IO 비용 을 줄 일 수 있 습 니 다. 이것 은 성능 이 우수 하 다 는 측면 에서 볼 수 있 습 니 다. 그러나 실제 운영 측면 에서 볼 때 사용자 행동, 예 를 들 어 방문 빈도 와 자주 사용 하 는 것 을 잃 을 수 있 습 니 다.방문 한 페이지.
\ # 오류 로그
error_log logs/error.log crit;
같은 방문 로그, 오류 로그 가 많 으 면 적지 않 은 스트레스 를 받 을 수 있 습 니 다. off 로 설정 할 수 있 습 니 다. 그러나 오류 가 발생 했 을 때 높 은 단계 로 설정 할 수 있 습 니 다. 심각 한 오류 만 기록 할 수 있 습 니 다. 이렇게 하면 IO 의 압력 을 적 절 히 줄 일 수 있 습 니 다.
\ # 커 널 복사 모드 사용 하기
커 널 복사 모드 를 사용 하 는 옵션 은 가장 빠 른 IO 효율 을 유지 해 야 합 니 다. (기본 오픈) sendfile on;
커 널 복사 에 관 해 서 는 쉽게 말 하면 하나의 디스크 파일 이 nginx 를 통 해 네트워크 에서 보 내 집 니 다. 이 과정 에서 일반적인 모드 를 사용 하면 디스크 에서 메모리 로 읽 히 고 메모리 에 시스템 급 메모리, 사용자 급 메모리, 그리고 네트워크 의 내장 이 있 습 니 다. 메모리 에 일련의 복 제 를 거 쳐 야 보 내 면 일련의 메모리 비용 이 발생 합 니 다. 켜 지면이 항목 은 커 널 복사 모드 입 니 다. 디스크 급 IO 단계 에서 네트워크 IO 단계 로 직접 복사 하고 사용자 차원 을 거치 지 않 으 며 복사 과정 이 속 도 를 빠르게 하기 때문에 정상 적 인 상황 에서 열 린 상 태 를 유지 하면 됩 니 다.
\ # 링크 시간 초과 설정
keepalive_timeout 30s;
이 긴 설정 은 자신의 사용 장면 에 따라 하나의 링크 가 한 페이지 의 다른 자원 을 다 불 러 오 면 됩 니 다. 만약 에 페이지 에 대량의 그림 이 있 으 면 큰 설정 을 할 수 있 습 니 다. 만약 에 세련 되 고 작은 설정 을 할 수 있다 면 이 수치 가 너무 큰 상황 에 대해 이렇게 이해 할 수 있 습 니 다. 만약 에 이것 이 한 서버 에서 100 개의 링크 만 받 을 수 있다 고 가정 하면현재 100 개의 요청 이 도 착 했 습 니 다. 우리 가 요청 을 처리 한 후에 우 리 는 이 100 개의 링크 를 살아 남 게 합 니 다. 그러면 이 100 개의 링크 는 매우 적 거나 근본적으로 괜 찮 습 니 다. 그러면 현재 새로운 사용자 가 요청 하고 싶 어 합 니 다. 그 는 이미 들 어 오지 못 했 습 니 다. 그러나 이미 들 어 온 링크 는 아무것도 하지 않 고 연결 수 를 차지 하면 단위 시간 내 에 해당 하 는 최대 사용자 수 를 사용 할 수 있 습 니 다.낮 추 는 것 은 부정적인 영향 을 미 치 는 것 이기 때문에 이 값 을 최대한 낮 게 설정 해 야 한 다 는 것 이 이 값 의 의미 입 니 다.
\ # 내용 압축 사용 하기
콘 텐 츠 압축 을 사용 하면 네트워크 트 래 픽 gzip on 을 효과적으로 낮 출 수 있 습 니 다. 압축 파일 의 크기 를 제한 합 니 다. 즉, 너무 작은 파일 에 대해 파일 크기 가 이 값 에 이 르 지 않 아야 압축 을 할 수 있 습 니 다. 콘 텐 츠 의 과도 한 압축 효과 가 좋 지 않 을 뿐만 아니 라 시스템 자원 에 낭 비 를 초래 할 수 있 습 니 다. gzip min length 1000; 선택 한 압축 단 계 는 선택 할 수 있 는 값 이 1 - 9 이 고 압축 단계 가 높 을 수록 압축 률 이 높 습 니 다.높 고 시스템 성능 에 대한 요구 가 높 으 므 로 서버 의 성능 에 따라 설정 해 야 합 니 다. gzip comp level 4; 압축 분류의 설정 gzip type text / plain text / css application / json application / x - javascript text / xml application / x - httpd - PHP image / jpeg image / gif image / png;
압축 할 파일 을 지정 하고 압축 되 지 않 는 파일 을 지정 합 니 다. 예 를 들 어 사용자 가 그림 을 다운로드 하고 파일 을 다운로드 하 는 바 이 너 리 는 압축 액 에서 얼마 압축 되 지 않 지만 일부 텍스트, html 페이지, js 등 은 좋 은 효 과 를 얻 을 수 있 습 니 다. 압축 효과 가 좋 은 유형 을 지정 하여 압축 하고 압축 효과 가 좋 지 않 은 것 을 제거 하면 시스템 자원 을 절약 할 수 있 습 니 다.
\ # 정적 파일 캐 시
(기본적으로 열 리 지 않 음) 최대 캐 시 수량, 파일 은 생존 기간 을 사용 하지 않 습 니 다. open file cache max = 655350 inactive = 20 s; 캐 시 유효 시간 간격 open file cache valid 30s 를 검증 합 니 다. 유효 시간 내 파일 최소 사용 횟수 open file cache min use 2;
정적 파일 캐 시 역할 을 합 니 다. 만약 에 저희 가 웹 페이지 파일 을 자주 방문 하면 매번 디스크 에서 이 파일 을 읽 어야 합 니 다. 그러면 대량의 IO 가 소모 되 고 성능 이 높 지 않 습 니 다. 자주 방문 하 는 이런 것들 을 메모리 에 불 러 오 면 사용자 가 요청 할 때 메모리 에서 직접 꺼 내 면 서버 의 해당 능력 을 크게 향상 시 키 고 서비스 도 향상 시 킬 수 있 습 니 다.장치 의 부 하 량 입 니 다. open file - cache 를 통 해 캐 시 를 열 수 있 습 니 다. max 값 은 캐 시 에 최대 몇 개의 파일 을 저장 할 수 있 는 지, inactive 값 은 파일 의 생존 기간 입 니 다. 캐 시 수량 이 제한 되 어 있 기 때문에 이 제한 을 초과 할 때 일정한 알고리즘 에 따라 자주 사용 하지 않 는 파일 을 제거 하고 자주 사용 하 는 것 을 넣 어 캐 시 명중률 을 높 여야 합 니 다. 여기 서 우 리 는 파일 을 통 해 저장 합 니 다.당 좌 시간 과 유효 시간 내 에 파일 사용 횟수 를 결정 합 니 다. 이 두 가 지 를 결합 한 의 미 는 파일 이 캐 시 에 불 러 온 후에 단위 시간 내 에 방문 횟수 에 도달 해 야 명중률 이 효과 적 인 파일 이 고 명중률 이 낮은 파일 에 도달 하지 못 하면 방출 된다 는 것 입 니 다. 구체 적 인 예 를 들 어 30s 검증 시간 내 에 한 파일 이 20s 내 에 두 번 이상 사용 하면 석 방 됩 니 다.놓 아 줘..