ID nguyên nhân rt-policer · Phụ trách chính Hạ tầng mạng (Đội hạ tầng) · Phối hợp Hạ tầng server (Đội hạ tầng), Phát triển server (Đội phát triển game)
Gói cước của nhà mạng, giới hạn của instance cloud và thiết bị chống DDoS đôi khi bỏ ngay các gói vượt tốc độ quy định mà không đưa vào hàng đợi.
Vì sao Lượng dữ liệu gửi tức thời vượt tốc độ cho phép hoặc burst cho phép → Dẫn đến Gói vượt mức bị bỏ ngay, không qua hàng đợi (policing) → Trên màn hình Mỗi lúc burst lớn lại mất nhiều gói nên đứng hình rồi tua nhanh, trong khi tốc độ trung bình trông vẫn dưới giới hạn
Cả server, Một khu vực hoặc nhà mạng, Chỉ mình tôi
Khi nào
Khi đông người, Giờ cao điểm buổi tối
Phụ trách
Phụ trách chính Hạ tầng mạng (Đội hạ tầng) · Phối hợp Hạ tầng server (Đội hạ tầng), Phát triển server (Đội phát triển game)
Việc cần làm (Đội phát triển game)
Chia lượng dữ liệu dồn gửi mỗi tick ra rải trong tick để lượng gửi tức thời thấp hơn burst cho phép; nếu chạm giới hạn số gói mỗi giây thì gộp các message của một tick vào một gói.
Việc cần làm (Đội hạ tầng)
Mạng: kiểm tra counter vượt mức của policer trên thiết bị, dùng shaper thay cho policer, tăng burst cho phép. Thiết bị server·OS: kiểm tra chỉ số vượt giới hạn của cloud (trên AWS là bw_out_allowance_exceeded và pps_allowance_exceeded trong ethtool -S), nâng cấp instance, pacing phía server (hàng đợi fq của Linux).
Con số tham khảo
Shaper (đưa vào hàng đợi để làm chậm) làm tăng độ trễ, còn policer (bỏ ngay) làm tăng mất gói. Kết nối game TCP có thể đứng vài trăm ms chỉ vì một lần mất gói, nên nếu chỉ vượt giới hạn trong chốc lát thì policer thường gây ảnh hưởng lớn hơn.
Trên đồ thị
Chạm giới hạn rồi đi ngang · Lượng gửi theo chu kỳ ngắn, counter vượt mức của policer hoặc allowance
Chỗ cần xem
Counter vượt mức (exceed) và bỏ gói của thiết bị có đặt policer; nếu là cloud thì xem bw_out_allowance_exceeded và pps_allowance_exceeded trong ethtool -S. Với kết nối bị mất gói, xem RTT ngay trước lúc mất gói qua rtt của ss -ti hoặc bản bắt gói (packet capture)
Đúng nếu
counter vượt mức tăng, lượng gửi nhìn theo chu kỳ ngắn phẳng như bị cắt ngang ở một mức nào đó. RTT không tăng ngay trước khi mất gói, và chỉ lúc burst lớn mới mất nhiều gói cùng lúc
Loại trừ nếu
ngay trước khi mất gói, RTT đã tăng lên trước → tràn hàng đợi (“Tràn hàng đợi ở điểm nghẽn”, “Burst gửi làm tràn bộ đệm nhỏ”). Counter vượt mức không đổi → nguyên nhân khác
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
An Internet-Wide Analysis of Traffic PolicingGoogle Kết nối bị policing có tỷ lệ mất gói trung bình cao gấp 6 lần, và pacing hoặc shaping đạt được cùng mục đích đó. Cách phân biệt: policing bỏ phần vượt mức mà RTT không tăng, còn tràn hàng đợi thì RTT tăng trước khi mất gói (SIGCOMM 2016)