máy chủ web apache không phản hồi với trạng thái máy chủ hiển thị tất cả các tiến trình con đang chờ kết nối [đã đóng]


10

Thiết lập của tôi: Tôi có 3 máy chủ web gần như giống hệt nhau phục vụ cùng một trang web động được tải cao với cân bằng tải đơn giản trên dns. Dịch vụ này đã hoạt động được hơn hai năm với cùng một cấu hình apache: apache2, php5, ub Ubuntu 8.04 linux 2.6.24-29-server.

Vấn đề của tôi: Từ khoảng hai tuần trước, tôi gặp vấn đề với cấu hình này. Gần như mỗi ngày tôi có một khoảnh khắc nhỏ trong khoảng 5 phút, trong đó trang web không thể truy cập được. Tôi vẫn có thể đăng nhập vào máy chủ qua ssh. Nếu tôi chạy htop, tôi thấy máy chỉ đơn giản là không làm gì cả. Tôi có khoảng 1000 tiến trình apache đang chạy, nhưng không có hoạt động cpu.

Tôi đã sử dụng mod_status apache để gỡ lỗi tình huống này. Bảng điểm quá trình trông như thế này:

_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

Vì vậy, hầu hết các quá trình chỉ chờ kết nối. sau khoảng 5 phút, tình hình sẽ trở lại bình thường: tôi có rất ít quy trình trên mọi máy, hầu hết các công nhân đều có trạng thái "." - (có nghĩa là họ đang mở để xử lý yêu cầu) và tất nhiên trang web có thể truy cập được!

Vì vậy, tôi đang cố gắng tìm một cái gì đó trong nhật ký, nhưng đơn giản là không có gì ... nhật ký truy cập apache im lặng trong khoảng 4 phút, tương tự đối với nhật ký lỗi. tôi cũng không thể tìm ra bất cứ điều gì sai trong nhật ký hệ thống khác.

tình hình là như nhau trên cả 3 máy chủ web (tất cả chúng đều có điều kiện tải cực đại và không phản hồi này cùng một lúc), vì vậy tôi không cho rằng đây là liên quan đến phần cứng. nhưng tôi nghĩ rằng, điều này có thể liên quan đến một số vấn đề mạng (tcp).

có ý kiến ​​gì không

EDIT: một số thông tin khác, mà tôi vừa khám phá:

Nó vừa xảy ra một lần nữa và tôi đã có thể xác minh rằng tôi cũng không thể kết nối cục bộ khi sự cố này xảy ra.

Tôi đã thực hiện một số thống kê kết nối với lệnh sau đây sau khi nó xảy ra: netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

  • 109 CLOSE_WAIT
  • 2652 THÀNH LẬP
  • 2 FIN_WAIT1
  • 11 LẦN_ACK
  • 12 NGHE
  • 91 SYN_RECV
  • 1 ĐỒNG HỒ
  • 16 TIME_WAIT

Nếu tôi thực hiện cùng một lệnh một thời gian sau, tôi có một cái gì đó như thế này:

  • 4 ĐÓNG
  • 108 THÀNH LẬP
  • 18 FIN_WAIT1
  • 182 FIN_WAIT2
  • 37 LẦN_ACK
  • 12 NGHE
  • 50 SYN_RECV
  • 11276 TIME_WAIT

Vì vậy, trong tình huống bình thường, tôi chỉ có 100-200 kết nối mở bởi các khách hàng bị xử lý bởi apache trong thời điểm này. Khi tôi gặp "sự cố" này, tôi có nhiều kết nối hơn. Cách tốt nhất để phân tích này là gì?

EDIT2: các dòng quan trọng trong apache2.conf là:

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

Nó là một prefork2 apache2 với php_mod.

Máy chủ có ram 8GB và phân vùng trao đổi 4gb.


Trang web có hiển thị các triệu chứng tương tự khi bạn chạy wget hoặc curl từ máy chủ cục bộ hoặc giữa các máy chủ (nếu chúng nằm trên cùng một mạng) không?
Alex Forbes

Có thể kết xuất lưu lượng truy cập ( tcpdump) sẽ giúp bạn tìm hiểu gốc rễ của vấn đề ... btw chính sách sử dụng bộ nhớ và tường lửa của bạn là gì?
drcelus

@ al4 lần cuối cùng này, tôi đã có thể kết nối với trang trạng thái máy chủ từ máy chủ cục bộ, trong khi tôi không thể kết nối với trang web từ bên ngoài. Tôi không chắc lắm, vì nó cũng có thể là một điều ngẫu nhiên, trong khi một số công nhân đã sẵn sàng. tôi sẽ kiểm tra điều này nhiều hơn vào lần tới khi sự cố xảy ra. gợi ý của bạn là gì, nếu tôi có thể xác nhận bất kỳ sự khác biệt nào giữa các kết nối bên ngoài và cục bộ?
Jeff

Nếu bạn có thể xác nhận rằng nó hoạt động cục bộ nhưng không phải từ bên ngoài, nó sẽ củng cố trường hợp mạng là vấn đề - có nghĩa là bạn nên kiểm tra với tcpdumps và wireshark ở cả hai đầu để xem những gì đang vượt qua, thay vì tiến hành các quá trình apache. Tôi cũng sẽ kiểm tra từ một máy chủ lưu trữ trên cùng một mạng LAN nếu có thể. Và kiểm tra dmesg để xem liệu có bất kỳ tin nhắn nào có thể liên quan nhưng có vẻ như bạn đã thực hiện điều đó.
Alex Forbes

nó vừa xảy ra lần nữa và tôi đã có thể xác minh rằng tôi cũng không thể kết nối cục bộ khi sự cố này xảy ra. tôi cũng đã thực hiện một số thống kê kết nối với netstat: xem văn bản câu hỏi
Jeff

Câu trả lời:


2

Bạn nên kích hoạt trạng thái mở rộng của mod_status ( http://httpd.apache.org/docs/2.2/mod/mod_status.html#extendsstatus ) để theo dõi các máy chủ và yêu cầu hiện tại đang được xử lý. Tôi nghĩ rằng có một tập lệnh / trang (s) mất quá nhiều thời gian để giải phóng kết nối và nó làm cho các kết nối bị xếp chồng.


1

Đầu tiên: Kiểm tra Max open filesgiới hạn của bạn trong quá trình. Một kết nối ổ cắm hoạt động được tính là một tệp mở. cat /proc/###/limitslà một cách tốt để kiểm tra giá trị hiệu quả cho một quy trình khác. Bạn có thể nhận danh sách các tệp đang mở với lsof -p ###### là id tiến trình của máy chủ web của bạn. Bạn có thể so sánh lsof -p ### | wc -lđể xem bạn đang tiến gần đến giới hạn như thế nào. Bạn cũng sẽ thấy các thông báo trong error_log của apache nếu bạn đang đạt đến giới hạn.

Bạn cần một tệp xử lý cho mỗi kết nối ổ cắm, và cho mỗi tập lệnh cgi hoặc tham chiếu tệp dữ liệu. Đối với 920 MaxCl Client, bạn nên định cấu hình ít nhất 4.000 tệp cho quy trình httpd. Bạn có thể tăng số lượng tệp bằng cách thêm tệp vào /etc/security/limits.d/ với các nội dung sau. Đảm bảo tên người dùng khớp với những gì bạn đang sử dụng cho máy chủ web của bạn.

apache soft nofile 10000
apache hard nofile 10000

Thứ hai: Nếu cạn kiệt cổng là vấn đề của bạn, bạn có thể điều chỉnh một số cài đặt ip trong /etc/sysctl.conf. (Bắt đầu với net.ipv4.tcp_fin_timeout). Đây thường là một vấn đề chỉ với rất nhiều kết nối rất nhỏ. Nhiều ổ cắm TIME_WAIT là một chỉ báo về điều này, nhưng điều này cho thấy sự cạn kiệt cổng chỉ khi có lỗi trong syslog về possible SYN floodingSending cookies. Bạn cũng nên đảm bảo rằng máy chủ của bạn đứng sau một tường lửa có thể ngăn chặn các cuộc tấn công SYN độc hại.


0

Ngoài ra, hãy nhớ rằng trong MPM prefork, mỗi tiến trình sẽ có PHP trong không gian bộ nhớ của nó (cài đặt giới hạn bộ nhớ của nó là gì?). Bạn có thể muốn thử thay đổi thành MPM worker, có thể yêu cầu một mô-đun PHP hơi khác.

Cũng đáng giá bông tai từ xa để cắt cấu hình Apache của các mô-đun bên ngoài

Theo kinh nghiệm của tôi, những thứ như vậy được kích hoạt bởi những thứ như trình thu thập công cụ tìm kiếm hoặc những thứ như xung đột ARP. Hoặc mức lưu lượng trong một số phần liên quan của mạng.

Bạn cũng có thể thấy 'sar' hữu ích ... không thân thiện nhất, nhưng chắc chắn hữu ích.

Cũng có thể liên quan đến io. Sar có thể cho bạn biết (nếu bạn định cấu hình nó để ghi lại hoạt động của đĩa), thời gian chờ io trung bình là bao nhiêu. Bạn cũng có thể xem thời gian Chờ IO ở trên cùng (là phần trăm, đọc phần trên thực tế nghĩa là gì). Điều này có thể có ý nghĩa nếu bạn đang sử dụng SAN hoặc môi trường ảo.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.