VPN rớt khi tải lên lớn: hãy đọc hàng đợi trước

Đường hầm ổn định cả ngày, rồi rớt mỗi khi một lần tải lên lớn bắt đầu. Các yêu cầu tương tác đứng trước, ứng dụng khách báo hết thời gian chờ, và kết nối trở lại khi quá trình truyền xong. Kiểu này chỉ vào hàng đợi và xử lý, không phải máy chủ từ xa sập, vì máy chủ chưa bao giờ có cơ hội trả lời kịp. Việc cần làm là tái hiện điều đó dưới tải có kiểm soát và đọc đúng các bộ đếm.

Mỗi lần chạy chỉ đổi một biến và giữ nguyên điểm cuối.

Dựng một so sánh tải có thể lặp lại

Ghi một đường cơ sở khi liên kết rảnh: thời gian khứ hồi, vài yêu cầu ứng dụng và nhật ký sự kiện của chính đường hầm. Sau đó bắt đầu một lần tải lên có kích thước đã biết và lặp lại đúng những phép đo đó trong khi nó chạy. Giữ nguyên điểm cuối, ứng dụng khách và đích kiểm tra, vì đổi hai thứ cùng lúc không cho bạn biết gì.

Để ý sự kiện nào xuất hiện trước. Thời gian khứ hồi tăng trước bất kỳ lỗi nào gợi ý hàng đợi; hết thời gian chờ dứt khoát với độ trễ ổn định gợi ý điều khác, như luân chuyển khóa hoặc một thao tác trên tài khoản. Hai kiểu dẫn đến các bước tiếp theo khác nhau. Viết lại quan sát trước khi đổi bất cứ thứ gì.

Lưu kết quả kèm dấu thời gian để có thể so sánh từng dòng giữa lần chạy có tải và lần rảnh.

Đọc hàng đợi, không đọc tốc độ

Đường truyền của người dùng đệm gói tin trong thiết bị của nhà cung cấp, và hàng đợi chiều lên đầy làm chậm mọi thứ, kể cả những gói điều khiển nhỏ giữ đường hầm sống. Một bài kiểm tra tốc độ báo con số cao nói rất ít về độ trễ đó, vì thế bài kiểm tra lúc rảnh đạt trong khi liên kết bão hòa thất bại.

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

So sánh các con số độ trễ khi có tải với khi rảnh. Nhảy từ hàng chục mili giây lên hàng trăm mà không mất gói là hàng đợi; mất gói với độ trễ ổn định chỉ vào một lỗi khác.

Kiểm tra thiết bị và đường điều khiển

Mã hóa và chuyển tiếp tốn thời gian xử lý, và một router nhỏ hay laptop bị giới hạn nhiệt có thể làm rơi gói khi bận. Hãy xem tải tổng thể chứ không phải phần trăm của một tiến trình, vì chuyển tiếp trong nhân và xử lý ngắt không xuất hiện ở nơi người ta thường nhìn.

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

Hết thời gian chờ phía ứng dụng khách cũng có thể trùng với một lần luân chuyển khóa theo lịch hoặc với một sự kiện chính sách phiên. Hãy đọc nhật ký của chính ứng dụng khách để biết thứ tự sự kiện, không chỉ thông báo lỗi của ứng dụng.

Đổi một thứ và lặp lại

Ở nơi nền tảng hỗ trợ, hãy giới hạn tốc độ tải lên hoặc xếp lưu lượng lớn dưới lưu lượng tương tác để hàng đợi không bao giờ đầy. Sau đó lặp lại đúng khối lượng công việc đó và so sánh đúng ba con số như trước. Một thay đổi cải thiện bài kiểm tra tốc độ nhưng để nguyên tình trạng hết thời gian chờ thì không sửa được gì.

Nâng thời gian chờ ở mọi nơi và làm yếu mã hóa là hai thay đổi khiến triệu chứng biến mất mà không xác định ranh giới nào đã hỏng. Không cái nào là sửa chữa. Cả hai đều đẩy lỗi về sau, nơi khó quy cho nguyên nhân hơn.

Kết thúc bằng việc kiểm tra một yêu cầu mới và hành vi kết nối lại mà người dùng thực sự dựa vào. Sự ổn định dưới mức tải đã gây ra phàn nàn là kết quả duy nhất đáng ghi lại.