연결을 기다리는 모든 하위 프로세스를 표시하는 서버 상태에 응답하지 않는 Apache 웹 서버

내 설정 : dns에 대한 간단한로드 밸런싱을 통해 동일한 고로드 동적 웹 사이트를 제공하는 거의 동일한 웹 서버 시스템이 3 대 있습니다. 이 서비스는 apache2, php5, ubuntu 8.04 linux 2.6.24-29-server와 같은 동일한 아파치 구성으로 2 년 이상 작동 해 왔습니다.

내 문제 : 약 2 주 전부터이 구성에 문제가 있습니다. 거의 매일 웹 사이트에 접근 할 수없는 약 5 분 동안 작은 순간이 있습니다. 여전히 ssh를 통해 서버에 로그인 할 수 있습니다. 내가 실행 htop하면 컴퓨터가 아무것도하지 않는 것을 볼 수 있습니다. 약 1000 개의 아파치 프로세스가 실행 중이지만 CPU 활동이 없습니다.

이 상황을 디버깅하기 위해 아파치 mod_status를 사용했습니다. 프로세스 스코어 보드는 다음과 같습니다.

_C.___K_______________________R._______.__K_K____K___C_______.__
_______C__________.___________________________________.________C
_.____K__________K___K_WK_____._K_____________________________._
W______K__________K________.____________________._______C_______
_C_.__K__K____.._.._____________________________________C_______
_R___________K___.______C________.C_________.______._____C______
____________KKC____K_____K__WC_________________C_____.__.____.__
_____________________C_________K______.____C______._____________
_.___C____.___.___________________________.K______.____K________
W__.___________________C.__.____K________K_______R_._.__._______
__C__C_.__________C__C_______._____W______________C_.___C_______
____.______C_____________C________.____C____________.________._K
__.__________.K_____________K_________._____C____.K__________KW_
__K.W________R_________._______.___W___________.____.__K_____W__
W___.___..________W____K

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process

따라서 대부분의 프로세스는 연결을 기다리고 있습니다. 약 5 분 후 상황이 정상으로 돌아옵니다. 모든 시스템에서 프로세스가 가장 적고 대부분의 작업자는 "."상태 (요청을 처리하기 위해 열려 있음을 의미 함)를 가지고 있으며 물론 웹 사이트에 연결할 수 있습니다!

그래서 로그에서 무언가를 찾으려고하지만 단순히 아무것도 없습니다 ... 아파치 액세스 로그는 약 4 분 동안 침묵합니다. 오류 로그와 동일합니다. 또한 다른 시스템 로그에서 잘못된 것을 파악할 수 없습니다.

상황은 모든 3 개의 웹 서버에서 동일합니다 (모두이로드 피크와 응답하지 않는 조건을 동시에 가짐). 하드웨어와 관련이있는 것은 아닙니다. 하지만 이것은 일부 네트워크 (tcp) 문제와 관련이 있다고 생각합니다.

어떤 아이디어?

편집 : 내가 방금 발견 한 더 많은 정보 :

방금 다시 발생하여이 문제가 발생했을 때 로컬로 연결할 수 없는지 확인할 수있었습니다.

발생한 후 다음 명령으로 연결 통계를 만들었습니다. netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

• 109 CLOSE_WAIT
• 2652 설립
• 2 FIN_WAIT1
• 11 LAST_ACK
• 12 듣기
• 91 SYN_RECV
• 1 SYN_SENT
• 16 TIME_WAIT

얼마 후에 같은 명령을 실행하면 다음과 같은 결과가 나타납니다.

• 4 폐쇄
• 108 개설
• 18 FIN_WAIT1
• 182 FIN_WAIT2
• 37 LAST_ACK
• 12 듣기
• 50 SYN_RECV
• 11276 TIME_WAIT

따라서 정상적인 상황에서는 현재 아파치가 클라이언트가 처리하는 100-200 개의 열린 연결 만 있습니다. 이 "충돌"이 발생하면 더 많은 연결이 있습니다. 이것을 분석하는 가장 좋은 방법은 무엇입니까?

EDIT2 : apache2.conf의 중요한 라인은 다음과 같습니다

KeepAlive On
MaxKeepAliveRequests 20
KeepAliveTimeout 1
<IfModule mpm_prefork_module>
ServerLimit           920
StartServers          30
MinSpareServers       80
MaxSpareServers      120
MaxClients          920
MaxRequestsPerChild   700
</IfModule>

php_mod가있는 apache2 프리 포크입니다.

서버에는 8GB 램과 4GB 스왑 파티션이 있습니다.

처리중인 현재 호스트 및 요청을 모니터링하려면 mod_status ( http://httpd.apache.org/docs/2.2/mod/mod_status.html#extendedstatus ) 의 확장 상태를 활성화해야 합니다. 연결을 해제하는 데 너무 많은 시간이 걸리고 연결이 쌓이는 스크립트 / 페이지가 있다고 생각합니다.

첫째 : Max open files프로세스 의 한계를 확인하십시오 . 활성 소켓 연결은 열린 파일로 계산됩니다. cat /proc/###/limits다른 프로세스의 유효 값을 확인하는 좋은 방법입니다. lsof -p ###여기서 ###은 웹 서버의 프로세스 ID 인 열린 파일 목록을 얻을 수 있습니다 . lsof -p ### | wc -l한계에 얼마나 근접했는지 비교할 수 있습니다 . 한계에 도달하면 아파치의 error_log에 메시지가 표시됩니다.

각 소켓 연결 및 각 cgi 스크립트 또는 데이터 파일 참조에 대한 파일 핸들이 필요합니다. 920 MaxClient의 경우 httpd 프로세스에 대해 최소 4,000 개의 파일을 구성해야합니다. 다음 내용으로 /etc/security/limits.d/에 파일을 추가하여 파일 수를 늘릴 수 있습니다. 사용자 이름이 웹 서버에 사용중인 이름과 일치하는지 확인하십시오.

apache soft nofile 10000
apache hard nofile 10000

둘째 : 포트 고갈이 문제인 경우 /etc/sysctl.conf에서 일부 IP 설정을 조정할 수 있습니다. (로 시작 net.ipv4.tcp_fin_timeout). 이것은 일반적으로 매우 작은 연결이 많은 경우에만 문제가됩니다. 많은 TIME_WAIT 소켓이 중 하나 개 지표이지만,이 정도 시스템 로그에 오류가 동반에만 포트 고갈 표시 possible SYN flooding와 Sending cookies. 또한 서버가 악의적 인 SYN 공격을 막을 수있는 방화벽 뒤에 있는지 확인해야합니다.

또한 prefork MPM에서 각 프로세스는 메모리 공간에 PHP를 갖습니다 (메모리 제한 설정은 무엇입니까?). 약간 다른 PHP 모듈이 필요할 수있는 작업자 MPM으로 변경하려고 할 수 있습니다.

외부 모듈의 Apache 구성을 정리할 수있는 원격 귀걸이

내 경험상 이러한 것들은 검색 엔진 크롤러 또는 ARP 충돌과 같은 것들에 의해 유발됩니다. 또는 네트워크의 일부 관련 부분의 트래픽 수준.

'sar'가 유용 할 것입니다. 가장 친숙하지는 않지만 확실히 유용합니다.

아마 io 관련. Sar는 디스크 활동을 기록하도록 구성한 경우 평균 IO 대기 시간을 알려줍니다. IO 대기 시간을 맨 위에서 볼 수도 있습니다 (실제 백분율을 의미하며 실제로 의미하는 내용을 읽습니다). SAN 또는 가상 환경을 사용하는 경우 중요 할 수 있습니다.