Các tham số hiệu năng mạng Linux

 (github.com/leandromoreira)
4 điểm bởi GN⁺ 2023-09-07 | 1 bình luận | Chia sẻ qua WhatsApp
  • Một tutorial ngắn cho thấy các tham số sysctl/network thường dùng nằm ở đâu trong luồng mạng của Linux
  • Không thực tế khi kỳ vọng các giá trị cargo cult luôn mang lại cả thông lượng cao lẫn độ trễ thấp trong mọi tình huống; các phiên bản kernel mới đã có giá trị mặc định được tinh chỉnh tốt, và việc thay đổi mặc định có thể làm giảm hiệu năng
  • Đường nhận được tóm tắt theo luồng: NIC kiểm tra MAC/FCS, DMA, receive ring buffer, hard IRQ, NAPI, soft IRQ, ingress qdisc, netfilter, máy trạng thái TCP, bộ đệm nhận dựa trên tcp_rmem, cho đến khi ứng dụng đọc dữ liệu
  • Đường gửi được tóm tắt theo luồng: ứng dụng gọi sendmsg, cấp phát skb_buff, bộ đệm ghi socket dựa trên tcp_wmem, xử lý header TCP/IP, netfilter, output qdisc dựa trên txqueuelen, transmit ring buffer, DMA, đến IRQ hoàn tất truyền của NIC
  • Các hạng mục tinh chỉnh cốt lõi liên quan đến xử lý burst, mức dùng CPU, độ trễ và quan sát drop
    • rx, tx ring buffer là hàng đợi để nhận các burst kết nối mà không bị drop; khi tăng lên, độ trễ có thể tăng
    • rx-usecs, tx-usecs, rx-frames, tx-frames là thời gian chờ và số frame trước khi phát sinh hard IRQ; có thể giảm mức dùng CPU và hard IRQ, đồng thời tăng thông lượng với cái giá là độ trễ
    • netdev_budget_usecs, netdev_budget, dev_weight, netdev_max_backlog liên quan đến NAPI polling cycle và thông lượng xử lý của ingress qdisc
    • txqueuelen và default_qdisc liên quan đến hàng đợi phía OUTPUT và queuing discipline mặc định
  • Việc kiểm tra, thay đổi và giám sát chủ yếu được thực hiện bằng ethtool, sysctl, ip, tc và các tệp trong /proc
    • Ví dụ: kiểm tra ring buffer bằng ethtool -g ethX, thay đổi bằng ethtool -G ethX rx value tx value
    • Ví dụ: kiểm tra net.core.netdev_budget_usecs bằng sysctl net.core.netdev_budget_usecs, thay đổi bằng sysctl -w net.core.netdev_budget_usecs value
    • Ví dụ: kiểm tra default_qdisc bằng sysctl net.core.default_qdisc, giám sát bằng tc -s qdisc ls dev ethX
  • Các mục bộ đệm TCP gồm tcp_rmem, tcp_wmem, tcp_moderate_rcvbuf; khi tcp_moderate_rcvbuf được bật, TCP sẽ cố gắng tự động điều chỉnh kích thước bộ đệm nhận
  • Các mục liên quan đến trạng thái TCP và điều khiển tắc nghẽn được tổng hợp cùng nhau gồm net.core.somaxconn, tcp_fin_timeout, tcp_available_congestion_control, tcp_congestion_control, tcp_max_syn_backlog, tcp_syncookies, tcp_slow_start_after_idle
  • Có thể kiểm tra tracing mạng nội bộ của Linux bằng perf; lệnh ví dụ có dạng perf trace --no-syscalls --event 'net:*' ping globo.com -c1 > /dev/null
  • Các công cụ kiểm thử và giám sát được đề xuất gồm iperf3, vegeta, netdata, và bộ kết hợp prometheus + grafana + node exporter full dashboard

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-09-07
Ý kiến trên Hacker News

  • Trên cấu hình mặc định của Ubuntu Linux, net.ipv4.tcp_rmem khoảng 6MB, còn net.core.rmem_max khoảng 1MB, tạo ra một tình huống kỳ lạ
    Socket TCP mặc định có thể tăng cửa sổ nhận TCP lên đến 6MB khi cần, nhưng nếu ứng dụng ở user space gọi setsockopt SO_RCVBUF thì ngay cả socket vốn đã có thể dùng 6MB cũng bị giới hạn tối đa 1MB
    Ngay cả khi muốn giảm từ 6MB xuống 4MB thì kết quả lại thành 1MB, trông rất kỳ quặc; điều tương tự cũng áp dụng cho SO_SNDBUF/wmem
    Có vẻ Linux đang lẫn lộn thứ tự ưu tiên của các tùy chọn này, nên tôi thắc mắc vì sao không đặt core.rmem_max lớn hơn và coi nó là chỉ thị có thẩm quyền, hay có lý do lịch sử nào không

    • Nếu mục tiêu là hạn chế lượng dữ liệu bị buffer quá mức, có thể hạ TCP_NOTSENT_LOWAT thay vì SO_SNDBUF/wmem
      Giá trị này giới hạn lượng dữ liệu được buffer thêm ngoài mức cần thiết cho tích băng thông-độ trễ (BDP)
    • Giá trị tối đa của net.ipv4.tcp_rmem là giới hạn cho cơ chế tự động tinh chỉnh do kernel thực hiện
      Ngay khi đặt SO_RCVBUF, cơ chế tự động tinh chỉnh sẽ bị tắt cho socket đó, và net.core.rmem_max trở thành giá trị tối đa
      Điều này được ghi khá rõ trong Documentation/networking/ip-sysctl.rst

  • Bài này rất hay, kể cả ở chỗ cho thấy mọi bước từ khi gói tin đi vào NIC cho đến khi tới user space
    Nói thêm một điều về hiệu năng mạng: nếu hệ thống có nhiều CPU, nên kiểm tra phân bổ NUMA, vốn rất phổ biến trên các máy chủ lớn
    Nếu card mạng nằm ở phía một CPU còn ứng dụng chạy trên CPU khác, hiệu năng cũng có thể bị ảnh hưởng

  • Chỉ cần đổi cơ chế kiểm soát nghẽn mặc định của Linux, net.ipv4.tcp_congestion_control, sang bbr cũng có thể tạo ra khác biệt rất lớn trong một số tình huống
    Có lẽ đặc biệt đúng khi có khoảng cách xa, mất gói không liên tục, jitter và đóng gói/encapsulation
    Trong năm qua tôi đã debug sự cố với luồng client host <-- HTTP --> reverse proxy host <-- HTTP over Wireguard --> service host; trung bình rất khó vượt quá 20% thông lượng tối đa theo lý thuyết, và kết nối cũng chậm dần theo thời gian đến mức gần như dừng hẳn
    Sau khi dùng giải pháp tạm là thường xuyên buộc đóng kết nối, tôi đổi kiểm soát nghẽn sang bbr thì đạt thông lượng gần mức tối đa lý thuyết và kết nối ổn định; thay đổi này cần áp dụng ở cả hai phía Wireguard

    • BBR khác ở chỗ nó không dùng mất gói làm tín hiệu nghẽn
      Phần lớn TCP stack khi thấy mất gói lần đầu sẽ giảm một nửa cửa sổ gửi hoặc hạ xuống rất nhiều; vì vậy nếu là VPN có mất gói, hoặc gửi burst lớn ở 1Gb/s vào uplink VPN 10Mb/s, TCP sẽ thấy mất gói và lùi lại mạnh
      BBR cố tìm băng thông nút cổ chai, đo thời gian khứ hồi và tăng tốc độ gửi cho đến khi RTT tăng
      Khi RTT tăng, nó giả định hàng đợi đang tích tụ ở đoạn hẹp nhất trên đường đi, rồi giảm tốc độ gửi cho đến khi hàng đợi thoát bớt và RTT trở lại bình thường; sau đó gửi ở tốc độ đó một thời gian rồi lại thử tăng nhẹ
      Vài năm trước, dù tôi đã chuyển từ uplink cáp 10Mb/s sang đường quang đối xứng 1Gb/s, tốc độ upload qua VPN công ty vẫn chỉ quanh 5Mb/s, rất bực; khi đổi sang RACK TCP hoặc BBR trên FreeBSD, tốc độ tăng khoảng 8 lần lên đến giới hạn của VPN, khoảng 40Mb/s
    • BBRv1 bị lỗi, nên không dùng trên Internet công cộng
      Kiểu tinh chỉnh hiệu năng “sùng bái hàng hóa” bằng cách copy-paste một giá trị ma thuật rồi nghĩ mọi thứ sẽ tốt hơn là điều hoàn toàn trái ngược với ý mà bài gốc muốn nói
      May là Google đang upstream BBRv3, nên tình hình sẽ sớm tốt hơn
    • Kiểm soát nghẽn hoạt động theo hướng từ phía gửi dữ liệu sang phía nhận
      Nếu chỉ muốn cải thiện hiệu năng theo một chiều thì không cần đổi cả hai phía Wireguard
      Về BBRv1 thì tôi đồng ý với các ý kiến khác, còn triển khai cubic trong kernel Linux hoạt động khá tốt với hầu hết ứng dụng

  • Tò mò liệu việc tinh chỉnh hiệu năng cũng có ý nghĩa với adapter Wi‑Fi hay không
    Trên desktop, ngoài việc tắt tính năng ra thì cũng tò mò liệu có cách nào khắc phục các vấn đề Ethernet của i210 và i225 không
    Có vẻ đây là hai NIC phổ biến nhất hiện nay, nhưng không hiểu vì sao phần cứng mạng và driver phổ biến lại nhiều lỗi đến vậy
    Mình rất quan tâm đến RISC‑V, và tự hỏi liệu có nên bắt đầu từ một NIC hoàn toàn mở và đúng đắn không
    Nếu rẻ hơn i210 thì cuối cùng người ta sẽ đưa vào, nhưng có lẽ đó cũng có thể là điều bất khả thi

    • Nếu có thể hy sinh 10–20% thông lượng mạng cục bộ tối đa, có thể tăng đáng kể tính công bằng của Wi‑Fi, cải thiện thời gian ping và giảm bufferbloat
      Tuy nhiên trên Wi‑Fi vẫn xảy ra các đợt tăng vọt ping ngẫu nhiên
      Có một thread lớn tại https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/590... bàn về việc bật và tinh chỉnh AQM, cũng như sự đánh đổi giữa thông lượng và độ trễ
    • i225 thì đúng là đồ hỏng, nhưng i210 cho hiệu năng rất tốt
      1Gb trên CPU cùng thời cũng không phải mức gì quá khó, và i210 cung cấp 4 queue
      Tò mò không biết bạn không hài lòng điểm gì ở i210
    • Mình từng dùng một bo mạch chủ có i225 onboard, rồi mua PCIe I350 để giải quyết vấn đề

  • Phần tổng quan hàng đợi mạng Linux được trình bày bằng hình quá xuất sắc, đến mức muốn in ra dán lên tường ở đâu đó
    Cuốn Systems Performance của Brendan cũng trình bày tốt về hiệu năng mạng Linux, và đã có đến bản thứ 2
    Cả hai bản đều rất hay, nhưng bản 2 chủ yếu tập trung vào Linux, còn bản 1 có cả Solaris
    Gần đây hơn còn có cuốn BPF Performance Tools của cùng tác giả
    [1] Systems Performance: Enterprise and the Cloud, 2nd Edition (2020)
    https://www.brendangregg.com/systems-performance-2nd-edition...
    [2] BPF Performance Tools:
    https://www.brendangregg.com/bpf-performance-tools-book.html

  • Chỉ lướt qua bài viết thôi cũng đã thấy thú vị; phần nghiên cứu và cấu trúc rất tốt
    Tuy vậy, tò mò không biết trong thực tế ai là người thường xuyên tinh chỉnh các tham số mạng Linux

  • Tài liệu này có lẽ nên ghi rõ ở đâu đó là TCP
    Nội dung tập trung rất nhiều vào các mối quan tâm liên quan đến TCP, và vì mọi người chủ yếu dùng TCP nên đúng là hữu ích
    Nhưng các giá trị tinh chỉnh mặc định của UDP thì tệ đến mức thấp, mà phần đó lại bị bỏ sót khá rõ

    • Tò mò có tài liệu nào tốt về tinh chỉnh UDP không

  • Muốn được gợi ý video hoặc series nói về nội dung tương tự
    Tài liệu mạng nói chung thì nhiều, nhưng rất khó tìm tài liệu đi vào triển khai cụ thể của Linux

    • Cũng cần những tài liệu như vậy từ góc nhìn vi điều khiển
      Muốn thử làm một TCP echo server đơn giản cho vi điều khiển, nhưng hầu hết ví dụ chỉ dùng thư viện TCP riêng của vendor và gần như không giải thích quá trình trực tiếp thiết lập cũng như xác lập kết nối với router