우리 회사에는 3개의 전용 서버가 있습니다. 하나는 Nginx를 실행하고 웹 서버(php) 역할을 하고, 다른 하나는 MySQL과 Memcached를 처리하고, 다른 하나는 정적 파일(css, js 및 이미지)을 제공하는 데 사용됩니다.
모든 서버는 New Relic, 특히 정적 파일 서버에서 뛰어난 성능을 보이는 것으로 나타났습니다.
- CPU가 지속적으로 10% 미만
- 수신된 네트워크 IO는 매우 낮고 전송 속도는 최고 약 10Mb/s이지만 MySQL 서버의 사양은 동일하며 일반적으로 최고 속도는 20mb/s이므로 이것이 문제가 될지는 의심스럽습니다.
- 0.5 미만의 평균 부하
문제는 피크 시간에 일부 사용자의 경우 사진(크기가 100kb - 200kb)을 로드하는 데 오랜 시간이 걸린다는 것입니다(보통 몇 초밖에 걸리지 않지만 때로는 몇 초, 때로는 최대 1분까지 소요됨). 최악의 경우 초).
우리가 무엇을 할 수 있을지 아세요? 이상적으로는 CPU, RAM 또는 대역폭이 어떤 종류의 제한에도 도달하지 않은 경우 이런 일이 발생해서는 안 됩니다.
우리가 살펴보고 변경해야 할 주요 Nginx 구성 매개변수가 있습니까?
답변1
제가 생각할 수 있는 가능성은 두 가지입니다.
- 디스크가 I/O 한도에 도달했습니다.
- nginx의 작업 스레드 제한에 도달했습니다. 를보세요노동자_*핵심 모듈의 구성 매개변수 및작업자 연결이벤트 모듈에서 이를 향상시키는 방법을 알아보세요. 기본값은 단일 스레드인 단일 작업자 프로세스이므로 다중 CPU 플랫폼에서 실행하는 경우 반드시 이 프로세스를 강화해야 합니다. 단일 CPU 상자를 사용하는 경우에도 다른 것보다 훨씬 먼저 디스크 I/O 바인딩을 수행하고 다른 스레드가 더 많은 요청을 수신하고 처리할 수 있으므로 정적 리소스를 제공하는 시스템에서 이 숫자를 늘리는 것이 좋습니다. 첫 번째는 디스크에서 데이터가 공급되기를 기다리고 있습니다.
답변2
여기 앉아서 하루 종일 병목 현상이 발생하는 위치를 추측할 수도 있지만 좀 더 일반적인 조언을 통해 스스로 병목 현상을 훨씬 더 빨리 찾는 데 도움이 될 것입니다.
jeffatrackaid 님이 쓴 글어제 이 답변이는 보다 간결한 버전입니다.내가 꽤 오래전에 썼던 것. 성능 디버깅이 수행되는 방법을 이해하는 데 도움이 되도록 먼저 해당 내용을 읽어 보는 것이 좋습니다.
귀하의 경우에는 먼저 Firebug를 사용하여 피크 시간 동안 요청의 어느 비트가 느려지는지 확인합니다. 대역폭이 실제 문제가 아닌 경우 대역폭을 배제해야 합니다. Firebug의 "Net" 섹션을 보고 요청의 어느 부분이 빠른 시간과 느린 시간 사이에 변경되는지 살펴보세요.
그런 다음 느린 시간 동안 nginx 작업자 중 하나에 대해 -t및 옵션을 모두 사용하여 strace를 실행했습니다 . -T그 출력을 분석하면 nginx가 느려지는 위치를 정확히 알 수 있습니다. strace 출력을 파일에 기록한 다음 파일에서 less또는 를 사용하여 grep시간이 오래 걸리는 시스템 호출을 식별하는 것이 유용합니다.
-c추적 옵션을 일부 활용할 수도 있습니다 .
느린 시스템 호출을 식별한 후에도 어떤 nginx 매개변수를 변경해야 하는지 파악하는 것은 여전히 약간의 작업이 될 수 있지만 잘 진행되고 있을 것입니다. 해당 부분에 대해 도움이 필요하면 다시 방문하여 더 구체적인 질문을 하시기 바랍니다.
파일 기반 시스템 호출로 판명되면 기다리고 있던 파일을 찾을 때까지 추적을 거꾸로 살펴보십시오. 그것은 큰 힌트가 될 것입니다.