Parameter Performa Jaringan Linux

 (github.com/leandromoreira)
4 poin oleh GN⁺ 2023-09-07 | 1 komentar | Bagikan ke WhatsApp
  • Tutorial singkat yang menunjukkan lokasi parameter sysctl/network yang sering digunakan dalam alur jaringan Linux
  • Nilai cargo cult yang memberikan throughput tinggi sekaligus latensi rendah di semua situasi tidak realistis; versi kernel modern sudah memiliki nilai default yang disetel dengan baik, dan mengubah default dapat merusak performa
  • Jalur penerimaan dirangkum sebagai alur dari pemeriksaan MAC/FCS oleh NIC, DMA, receive ring buffer, hard IRQ, NAPI, soft IRQ, ingress qdisc, netfilter, mesin status TCP, buffer penerimaan berbasis tcp_rmem, hingga pembacaan oleh aplikasi
  • Jalur pengiriman dirangkum sebagai alur dari sendmsg aplikasi, alokasi skb_buff, buffer tulis socket berbasis tcp_wmem, pemrosesan header TCP/IP, netfilter, output qdisc berbasis txqueuelen, transmit ring buffer, DMA, hingga IRQ penyelesaian transmisi NIC
  • Item penyetelan utama terkait dengan penanganan burst, penggunaan CPU, latensi, dan observasi drop
    • rx, tx ring buffer adalah antrean untuk menerima burst koneksi tanpa drop; jika diperbesar, latensi dapat meningkat
    • rx-usecs, tx-usecs, rx-frames, tx-frames adalah waktu tunggu dan jumlah frame sebelum hard IRQ dipicu; ini dapat menurunkan penggunaan CPU dan hard IRQ, serta meningkatkan throughput dengan biaya latensi
    • netdev_budget_usecs, netdev_budget, dev_weight, netdev_max_backlog terkait dengan NAPI polling cycle dan throughput pemrosesan ingress qdisc
    • txqueuelen dan default_qdisc terkait dengan antrean sisi OUTPUT dan queuing discipline default
  • Pemeriksaan, perubahan, dan pemantauan berpusat pada ethtool, sysctl, ip, tc, dan file /proc
    • Contoh: memeriksa ring buffer ethtool -g ethX, mengubahnya ethtool -G ethX rx value tx value
    • Contoh: memeriksa net.core.netdev_budget_usecs dengan sysctl net.core.netdev_budget_usecs, mengubahnya dengan sysctl -w net.core.netdev_budget_usecs value
    • Contoh: memeriksa default_qdisc dengan sysctl net.core.default_qdisc, memantau dengan tc -s qdisc ls dev ethX
  • Item buffer TCP mencakup tcp_rmem, tcp_wmem, dan tcp_moderate_rcvbuf; jika tcp_moderate_rcvbuf diaktifkan, TCP akan mencoba menyesuaikan ukuran buffer penerimaan secara otomatis
  • Item terkait status TCP dan congestion control meliputi net.core.somaxconn, tcp_fin_timeout, tcp_available_congestion_control, tcp_congestion_control, tcp_max_syn_backlog, tcp_syncookies, dan tcp_slow_start_after_idle
  • Pelacakan jaringan internal Linux dapat diperiksa dengan perf, dengan contoh perintah berbentuk perf trace --no-syscalls --event 'net:*' ping globo.com -c1 > /dev/null
  • Sebagai alat pengujian dan pemantauan, artikel ini menyarankan iperf3, vegeta, netdata, serta kombinasi prometheus + grafana + node exporter full dashboard

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-07
Opini Hacker News

  • Pada nilai bawaan Ubuntu Linux, net.ipv4.tcp_rmem sekitar 6 MB, sedangkan net.core.rmem_max sekitar 1 MB, sehingga muncul situasi yang aneh
    Soket TCP bawaan, jika diperlukan, dapat menaikkan TCP receive window hingga 6 MB, tetapi jika aplikasi di userspace memanggil setsockopt SO_RCVBUF, soket yang tadinya sudah bisa memakai 6 MB pun dibatasi maksimal 1 MB
    Bahkan ketika mencoba menurunkannya dari 6 MB ke 4 MB, hasilnya menjadi 1 MB, jadi terlihat sangat aneh; hal yang sama juga berlaku untuk SO_SNDBUF/wmem
    Sepertinya Linux mencampuradukkan prioritas opsi-opsi ini; saya penasaran mengapa core.rmem_max tidak dibuat lebih besar dan dijadikan nilai arahan yang otoritatif, atau apakah ada alasan historisnya

    • Jika tujuannya membatasi jumlah data yang di-buffer secara berlebihan, Anda bisa menurunkan TCP_NOTSENT_LOWAT, bukan SO_SNDBUF/wmem
      Nilai ini membatasi jumlah tambahan yang di-buffer melebihi jumlah yang diperlukan untuk bandwidth-delay product (BDP)
    • Nilai maksimum net.ipv4.tcp_rmem adalah batas autotuning yang dilakukan kernel
      Begitu SO_RCVBUF disetel, autotuning tidak lagi berlaku pada soket tersebut, dan net.core.rmem_max menjadi nilai maksimumnya
      Ini didokumentasikan cukup jelas di Documentation/networking/ip-sysctl.rst

  • Tulisan ini bagus, termasuk karena menunjukkan semua tahap sejak paket masuk ke NIC hingga sampai ke userspace
    Menambahkan satu hal terkait performa jaringan: jika sistem memiliki beberapa CPU, Anda perlu memeriksa alokasi NUMA, yang umum pada server besar
    Jika kartu jaringan berada di sisi satu CPU sementara aplikasi berjalan di CPU lain, performa juga bisa terpengaruh

  • Mengubah saja kontrol kongesti bawaan Linux, net.ipv4.tcp_congestion_control, ke bbr dapat menghasilkan perbedaan besar dalam sebagian situasi
    Mungkin terutama pada kasus dengan jarak jauh, kehilangan paket dan jitter yang sesekali, serta enkapsulasi
    Selama setahun terakhir saya men-debug masalah pada alur client host <-- HTTP --> reverse proxy host <-- HTTP over Wireguard --> service host; secara rata-rata sulit melewati 20% dari throughput maksimum teoretis, dan koneksi juga melambat seiring waktu hingga hampir seperti berhenti
    Setelah memakai solusi sementara berupa sering memaksa koneksi ditutup, saya mengubah kontrol kongesti ke bbr dan mendapat throughput yang mendekati maksimum teoretis serta koneksi yang stabil; perubahan ini diperlukan di kedua sisi Wireguard

    • BBR berbeda karena tidak memakai loss sebagai sinyal kongesti
      Kebanyakan stack TCP, begitu melihat loss pertama, akan memangkas send window menjadi separuh atau menurunkannya secara besar, sehingga jika ada VPN yang lossy, atau Anda mengirim burst besar pada 1 Gb/s ke uplink VPN 10 Mb/s, TCP melihat loss lalu mundur jauh
      BBR mencoba menemukan bandwidth bottleneck, mengukur round-trip time, lalu menaikkan laju kirim sampai RTT meningkat
      Jika RTT meningkat, BBR mengasumsikan ada antrean yang menumpuk di bagian tersempit jalur, lalu menurunkan laju kirim sampai antrean terkuras dan RTT kembali normal; setelah itu ia mengirim pada kecepatan tersebut untuk sementara sebelum mencoba menaikkannya sedikit lagi
      Beberapa tahun lalu, meski saya beralih dari uplink kabel 10 Mb/s ke koneksi fiber simetris 1 Gb/s, upload VPN kantor tetap sekitar 5 Mb/s dan itu menjengkelkan; setelah beralih ke RACK TCP atau BBR di FreeBSD, kecepatannya naik sekitar 8 kali lipat hingga mendekati batas VPN, sekitar 40 Mb/s
    • BBRv1 rusak, jadi jangan digunakan di internet publik
      Tuning performa ala cargo cult dengan copy-paste, seolah cukup menyetel satu nilai ajaib agar semuanya membaik, justru kebalikan dari pesan yang ingin disampaikan artikel aslinya
      Untungnya Google sedang meng-upstream BBRv3, jadi ini akan segera membaik
    • Kontrol kongesti bekerja dari sisi pengirim data ke arah penerima
      Jika hanya ingin meningkatkan performa satu arah, Anda tidak perlu mengubah kedua sisi Wireguard
      Untuk BBRv1 saya setuju dengan komentar-komentar lain, dan implementasi cubic di kernel Linux bekerja cukup baik untuk sebagian besar aplikasi

  • Penasaran apakah tuning performa juga bermakna untuk adapter Wi-Fi
    Di desktop, selain mematikan fitur, saya juga penasaran apakah ada cara untuk memperbaiki masalah Ethernet i210 dan i225
    Sepertinya dua ini adalah NIC yang paling umum saat ini, tetapi saya tidak begitu paham mengapa hardware jaringan dan driver yang umum bisa penuh cacat seperti ini
    Saya sangat tertarik pada RISC-V, dan terpikir bagaimana kalau memulai dari NIC yang sepenuhnya terbuka dan benar
    Kalau lebih murah daripada i210, pada akhirnya orang akan memasukkannya, tetapi mungkin saja itu hal yang mustahil

    • Jika bisa mengorbankan 10–20% throughput jaringan lokal maksimum, Anda bisa sangat meningkatkan fairness Wi-Fi, memperbaiki waktu ping, dan mengurangi bufferbloat
      Namun di Wi-Fi, lonjakan ping acak tetap masih terjadi
      Ada thread besar di https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/590... yang membahas pengaktifan dan tuning AQM, serta kompromi antara throughput dan latensi
    • i225 memang barang rusak, tetapi i210 memberikan performa yang sangat bagus
      Pada CPU sezamannya, 1Gb bukan tingkat yang terlalu sulit, dan i210 menyediakan 4 queue
      Penasaran apa yang tidak memuaskan dari i210
    • Saya memakai motherboard dengan i225 onboard, lalu membeli PCIe I350 dan masalahnya beres

  • Ikhtisar queue jaringan Linux yang dirangkum dalam gambar sangat bagus sampai rasanya ingin saya tempel di dinding
    Buku Systems Performance dari Brendan juga membahas performa jaringan Linux dan lain-lain dengan baik, dan sekarang sudah terbit sampai edisi ke-2
    Kedua edisinya sama-sama bagus, tetapi edisi ke-2 terutama berfokus pada Linux, sedangkan edisi pertama juga mencakup Solaris
    Yang lebih baru lagi, ada juga buku BPF Performance Tools dari penulis yang sama
    [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

  • Sekadar menelusuri tulisannya saja sudah menyenangkan, dan riset serta penyusunannya sangat bagus
    Namun saya penasaran siapa sebenarnya yang secara rutin melakukan tuning parameter jaringan Linux

  • Sepertinya dokumen ini perlu menyebut TCP secara eksplisit di suatu tempat
    Isinya sangat berfokus pada hal-hal terkait TCP, dan memang berguna karena orang terutama memakai TCP
    Namun nilai tuning default UDP sangat rendah, dan bagian itu terasa jelas tidak ada

    • Penasaran apakah ada materi yang bagus untuk tuning UDP

  • Saya ingin mendapat rekomendasi video atau seri yang membahas topik serupa
    Ada banyak materi networking umum, tetapi sulit menemukan materi yang membahas implementasi spesifik Linux

    • Dari sudut pandang mikrokontroler pun dibutuhkan materi yang sama
      Saya ingin mencoba membuat server echo TCP sederhana untuk mikrokontroler, tetapi kebanyakan contoh hanya memakai library TCP milik vendor dan hampir tidak menjelaskan proses menyiapkan serta membangun koneksi langsung ke router