사이트 업데이트 후 일주일에 한 번 방문자 수가 급증하는 트래픽이 비교적 적은 사이트를 운영하고 있습니다. 이 급증하는 동안 나머지 주에 비해 사이트 성능이 매우 떨어집니다. 실제로 서버의 부하는 매우 낮고 안정적으로 10 % 미만의 CPU 및 30 % 미만의 RAM (하드웨어가 실제로 수행중인 작업에 대한 완전한 오버 킬이어야 함)을 유지하지만 어떤 이유로 Apache가 수량을 처리 할 수없는 것으로 보입니다 요청. RHEL 5.7, 커널 2.6.18-274.7.1.el5, x86_64에서 Apache 2.2.3을 실행하고 있습니다.
ab를 사용하여 근무 외 시간에이 동작을 재현하려고하면 약 256 명의 사용자를 초과하면 성능이 크게 저하됩니다. 내가 할 수있는 가장 작은 유스 케이스로 테스트를 실행하면 (정적 텍스트 파일, 총 223 바이트) 성능은 245 개의 동시 요청에서 일관되게 정상입니다.
Connection Times (ms)
min mean[+/-sd] median max
Connect: 15 25 5.8 24 37
Processing: 15 65 22.9 76 96
Waiting: 15 64 23.0 76 96
Total: 30 90 27.4 100 125
Percentage of the requests served within a certain time (ms)
50% 100
66% 108
75% 111
80% 113
90% 118
95% 120
98% 122
99% 123
100% 125 (longest request)
그러나 최대 265 개의 동시 요청을 래칫하자마자 그들 중 일부는 불완전한 시간이 걸리기 시작합니다.
Connection Times (ms)
min mean[+/-sd] median max
Connect: 13 195 692.6 26 3028
Processing: 15 65 21.3 72 100
Waiting: 15 65 21.3 71 99
Total: 32 260 681.7 101 3058
Percentage of the requests served within a certain time (ms)
50% 101
66% 108
75% 112
80% 116
90% 121
95% 3028
98% 3040
99% 3044
100% 3058 (longest request)
이러한 결과는 여러 번의 실행에서 매우 일관됩니다. 해당 상자로 이동하는 다른 트래픽이 있기 때문에 하드 컷오프가있을 경우 정확히 어디에 있는지 확실하지 않지만 256에 가까운 것으로 보입니다.
당연히, 이것이 프리 포크의 스레드 제한으로 인한 것이라고 가정했기 때문에 사용 가능한 스레드 수를 두 배로 늘리고 스레드 풀이 불필요하게 커지거나 줄어들지 않도록 구성을 조정했습니다.
<IfModule prefork.c>
StartServers 512
MinSpareServers 512
MaxSpareServers 512
ServerLimit 512
MaxClients 512
MaxRequestsPerChild 5000
</IfModule>
mod_status는 현재 512 개의 사용 가능한 스레드로 실행되고 있음을 확인합니다.
8 requests currently being processed, 504 idle workers
그러나 265 개의 동시 요청을 시도해도 여전히 이전과 거의 동일한 결과가 나타납니다.
Connection Times (ms)
min mean[+/-sd] median max
Connect: 25 211 714.7 31 3034
Processing: 17 94 28.6 103 138
Waiting: 17 93 28.5 103 138
Total: 57 306 700.8 138 3071
Percentage of the requests served within a certain time (ms)
50% 138
66% 145
75% 150
80% 161
90% 167
95% 3066
98% 3068
99% 3068
100% 3071 (longest request)
설명서 (및 Stack Exchange)를 검색 한 후이 병목 현상을 해결하기위한 추가 구성 설정이 손실되었습니다. 내가 놓친 것이 있습니까? 아파치 이외의 답변을 찾기 시작해야합니까? 다른 사람이이 행동을 본 적이 있습니까? 도움을 주시면 감사하겠습니다.
편집하다:
Ladadadada의 조언에 따라, 나는 아파치에 대하여 strace를 달렸다. 나는 -tt와 -T로 몇 번 시도했지만 평범한 것을 찾을 수 없었습니다. 그런 다음 현재 실행중인 모든 아파치 프로세스에 대해 strace -c를 실행하려고 시도했으며 다음을 얻었습니다.
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
22.09 0.317836 5 62128 4833 open
19.91 0.286388 4 65374 1896 lstat
13.06 0.187854 0 407433 pread
10.70 0.153862 6 27076 semop
7.88 0.113343 3 38598 poll
6.86 0.098694 1 100954 14380 read
(... abdridged)
이 권리를 읽고 있다면 (그리고 자주 strace를 사용하지 않기 때문에 나와 함께 견딜 경우) 시스템 요청 중 어느 것도 이러한 요청에 걸리는 시간을 설명 할 수 없습니다. 요청이 작업자 스레드에 도달하기 전에 병목 현상이 발생하는 것처럼 보입니다.
편집 2 :
여러 사람들이 제안했듯이 웹 서버 자체에서 테스트를 다시 실행했습니다 (이전 테스트는 중립 인터넷 위치에서 실행되었습니다). 결과는 놀랍습니다.
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 11 6.6 12 21
Processing: 5 247 971.0 10 4204
Waiting: 3 245 971.3 7 4204
Total: 16 259 973.3 21 4225
Percentage of the requests served within a certain time (ms)
50% 21
66% 23
75% 24
80% 24
90% 26
95% 4225
98% 4225
99% 4225
100% 4225 (longest request)
결론은 인터넷 기반 테스트와 비슷하지만 로컬에서 실행하면 일관되게 조금 더 나빠 보입니다 . 더 흥미롭게도 프로필이 크게 바뀌 었습니다. 장기 실행 요청의 대부분이 "연결"에 소비되기 전에 병목 현상이 처리 중이거나 대기중인 것으로 나타납니다. 나는 이것이 실제로 네트워크 제한에 의해 가려져 있던 별도의 문제일지도 모른다고 생각합니다.
Apache 호스트와 동일한 로컬 네트워크의 다른 컴퓨터에서 테스트를 다시 실행하면 훨씬 더 합리적인 결과가 나타납니다.
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.8 2 4
Processing: 13 118 99.8 205 222
Waiting: 13 118 99.7 204 222
Total: 15 121 99.7 207 225
Percentage of the requests served within a certain time (ms)
50% 207
66% 219
75% 220
80% 221
90% 222
95% 224
98% 224
99% 225
100% 225 (longest request)
이 두 가지 테스트는 함께 여러 가지 질문을 제기하지만, 그와는 별도로 특정 양의로드에서 발생하는 심각한 네트워크 병목 현상에 대한 강력한 사례가 있습니다. 다음 단계에서는 네트워크 계층을 별도로 조사 할 것이라고 생각합니다.