Varnish hết cổng mở, rất nhiều kết nối SYN_SENT


8

Gần đây, chúng tôi đã gặp sự cố với thiết lập Varnish (3x) -> Apache (3x) của chúng tôi, dẫn đến SYN_SENTkết nối tăng đột biến .

Sự tăng đột biến là do lượng lưu lượng truy cập mới vào trang web (không phải là DDOS dưới bất kỳ hình thức nào) và có vẻ như các máy Varnish của chúng tôi đang gặp sự cố khi chuyển lưu lượng truy cập đến các máy chủ phụ trợ (giảm lưu lượng truy cập Apache có liên quan đến tăng đột biến trên vecni ), tắc nghẽn nhóm cổng có sẵn với SYN_SENT.

Keep-alives được kích hoạt trên Apache (15 giây).

Phía nào là lỗi trên? Lượng lưu lượng truy cập là đáng kể, nhưng không nên tạo ra một thiết lập như vậy (các máy frontend 3x Varnish, các máy chủ Apache phụ trợ 3x) bị đình trệ.

Xin vui lòng giúp đỡ.

Ảnh chụp màn hình Munin cho các kết nối thông qua tường lửa là ở đây .

Sơn dầu ~$ netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

      9 CLOSE_WAIT
     12 CLOSING
    718 ESTABLISHED
     39 FIN_WAIT1
   1714 FIN_WAIT2
     76 LAST_ACK
     12 LISTEN
    256 SYN_RECV
   6124 TIME_WAIT

/etc/sysctl.conf (Véc ni)

net.ipv4.netfilter.ip_conntrack_max = 262144
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.ip_local_port_range = 1024 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_fin_timeout = 30

Apache netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

     11 CLOSE_WAIT
    286 ESTABLISHED
     38 FIN_WAIT2
     14 LISTEN
   7220 TIME_WAIT

/etc/sysctl.conf (Apache)

vm.swappiness=10
net.core.wmem_max = 524288
net.core.wmem_default = 262144
net.core.rmem_default = 262144
net.core.rmem_max = 524288
net.ipv4.tcp_rmem = 4096 262144 524288
net.ipv4.tcp_wmem = 4096 262144 524288
net.ipv4.tcp_mem = 4096 262144 524288

net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_keepalive_time = 30

net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.core.somaxconn = 2048


net.ipv4.conf.lo.arp_ignore=8
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

vm.swappiness = 0

kernel.sysrq=1
kernel.panic = 30

1
Tường lửa nằm ở đâu? Hệ thống duy nhất có chỉ SYN_SENTsố cao là tường lửa; bạn đang nói rằng có vẻ như tường lửa là nút cổ chai?
Shane Madden

Tường lửa có SYN_SENT cao được đặt trên các máy Varnish.
dùng150997

thêm số liệu thống kê eth / conntrack tại đây: Grab.by/iA2M
user150997 27/12/12

1
/ Proc / sys / net / ipv4 / tcp_max_tw_buckets và tcp_max_syn_backlog của bạn được đặt thành gì? (của tôi là 180000, thời gian chờ là 180 nghìn và 1024 (tăng khi có thêm bộ nhớ)). Ngoài ra, tại sao bạn lại bật tw_recycle? Điều đó có gây ra lỗi không? (hoặc là tái chế?)
Grizly

1
Bạn có thể muốn xem xét việc đặt net.ipv4.tcp_tw_recycle về 0 - đặc biệt là nếu cân bằng tải. Tôi đã gặp vấn đề với HAproxy ở mức độ đồng thời cao với tính năng này được kích hoạt. Ngoài ra, tôi sẽ vô hiệu hóa iptables trong quá trình thử nghiệm. Tôi đã thấy một số kết quả kỳ lạ với theo dõi kết nối khi được sử dụng trong môi trường cân bằng tải.
jeffatrackaid

Câu trả lời:


3

Vấn đề của bạn có lẽ là với sysctl trên các máy chủ Apache.

Một số giả định: Thông thường Varnish xử lý từng kết nối nhanh hơn rất nhiều so với máy chủ web (trừ khi có lẽ máy chủ Varnish của bạn có ít CPU hơn và máy chủ Apache của bạn chỉ phục vụ các tệp tĩnh được lưu trong bộ nhớ.) Tôi sẽ giả sử các kết nối của bạn xử lý nhanh hơn trong Varnish hơn Apache.

Do đó, tài nguyên trên các máy chủ Apache của bạn có thể dồi dào, nhưng các yêu cầu sẽ phải xếp hàng ở đâu đó, nếu chỉ trong một thời gian ngắn. Ngay bây giờ họ không xếp hàng một cách lành mạnh, nơi cuối cùng họ được xử lý.

Có vẻ như các yêu cầu của bạn đang bị kẹt trong Varnish và không gửi đến các máy chủ Apache.

Có một số bằng chứng cho điều này:

Lưu ý trong biểu đồ munin của bạn, trước khi các SYN_SENT được sao lưu, các yêu cầu trong TIME_WAIT tăng lên, sau đó sau một thời điểm, chúng bắt đầu chồng chất thành các dạng SYN_SENT. Điều này cho thấy rằng các yêu cầu bắt đầu được trả lời chậm hơn, sau đó hàng đợi sao lưu và các yêu cầu không được trả lời.

Điều này cho tôi biết rằng máy chủ Apache của bạn không chấp nhận đủ các kết nối (nơi họ có thể ngồi và xếp hàng để Apache xử lý chúng.)

Tôi thấy một số giới hạn có thể có trong tệp cấu hình của bạn:

Khi bạn tăng đột biến, bạn có khoảng 30000 kết nối ở trạng thái SYN_SENT trên máy chủ Varnish của bạn.

Tuy nhiên, trên máy chủ Apache, max_syn_backlog của bạn chỉ là 16384. somaxconn của bạn chỉ là 2048.

Cũng lưu ý rằng kích thước bộ đệm bộ nhớ mạng của bạn trên các máy chủ Apache là rất thấp. Bạn đã điều chỉnh chúng trên máy chủ Varnish thành 16MB. Nhưng trên máy chủ Apache, net.ipv4.tcp_rmem của bạn chỉ có 524KB để phù hợp với net.core.rmem_max của bạn.

Tôi khuyên bạn nên tăng tất cả các tham số này trên máy chủ Apache.

Bạn sẽ cần tập trung nhiều hơn vào chẩn đoán trên máy chủ Apache để tìm hiểu chính xác những gì đang diễn ra, nhưng bạn có thể không cần nếu bạn nâng cao các giá trị này.

Bạn có thể không nên điều chỉnh net.ipv4.tcp_mem. Lưu ý đơn vị cho tham số này là trong các trang, không phải byte, do đó sao chép cùng một giá trị từ net.ipv4.tcp_rmem hoặc net.ipv4.tcp_wmem (cả hai bằng byte) sẽ không có ý nghĩa gì. Nó được tự động điều chỉnh bởi linux dựa trên dung lượng bộ nhớ của bạn nên hiếm khi cần điều chỉnh. Trong thực tế, đây có thể là vấn đề của bạn, tùy ý giới hạn bộ nhớ có sẵn cho hàng đợi kết nối tổng thể.

Xem: http://russ.garrett.co.uk/2009/01/01/linux-kernel-tuning/

Cũng lưu ý rằng "vm.swappiness = 0" của bạn được đặt hai lần, một lần là 10 và một lần nữa ở dưới cùng là 0, đó là giá trị hiệu quả.


0

Trên máy chủ Varnish, hãy thử thay đổi 2 tham số sau:

net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1

tw numuse sẽ cho phép nó sử dụng lại các kết nối trong TIME_WAIT.

tw_recycle có thể gây ra sự cố với bộ cân bằng tải, v.v.

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.