Linux ağ performansı parametreleri

 (github.com/leandromoreira)
4 puan yazan GN⁺ 2023-09-07 | 1 yorum | WhatsApp'ta paylaş
  • Linux ağ akışı içinde sık kullanılan sysctl/ağ parametrelerinin nerede konumlandığını gösteren kısa bir eğitim
  • Her durumda aynı anda yüksek throughput ve düşük gecikme sağlayan cargo cult değerleri gerçekçi değildir; modern çekirdek sürümlerinde varsayılanlar zaten iyi ayarlanmıştır ve varsayılanları değiştirmenin performansa zarar verme ihtimali vardır
  • Alım yolu; NIC'in MAC/FCS doğrulaması, DMA, receive ring buffer, hard IRQ, NAPI, soft IRQ, ingress qdisc, netfilter, TCP durum makinesi, tcp_rmem tabanlı alım tamponu ve uygulamanın okumasına kadar uzanan akış olarak özetlenir
  • Gönderim yolu; uygulamanın sendmsg çağrısı, skb_buff ayrılması, tcp_wmem tabanlı soket yazma tamponu, TCP/IP başlık işlemleri, netfilter, txqueuelen tabanlı output qdisc, transmit ring buffer, DMA ve NIC gönderim tamamlama IRQ'suna kadar olan akış olarak özetlenir
  • Temel ayar kalemleri burst işleme, CPU kullanımı, gecikme ve drop gözlemiyle ilişkilidir
    • rx, tx ring buffer'ları, bağlantı burst'lerini drop olmadan karşılamak için kullanılan kuyruklardır; artırılmaları durumunda gecikme artabilir
    • rx-usecs, tx-usecs, rx-frames, tx-frames, hard IRQ oluşmadan önceki bekleme süresi ve frame sayısını belirler; CPU kullanımı ve hard IRQ sayısı azaltılarak gecikme maliyeti karşılığında throughput artırılabilir
    • netdev_budget_usecs, netdev_budget, dev_weight, netdev_max_backlog, NAPI polling cycle ve ingress qdisc throughput'u ile ilgilidir
    • txqueuelen ve default_qdisc, OUTPUT tarafındaki kuyruk ve varsayılan queuing discipline ile ilgilidir
  • İnceleme, değiştirme ve izleme; ağırlıklı olarak ethtool, sysctl, ip, tc ve /proc dosyaları etrafında şekillenir
    • Örnek: ring buffer görüntüleme ethtool -g ethX, değiştirme ethtool -G ethX rx value tx value
    • Örnek: net.core.netdev_budget_usecs görüntüleme sysctl net.core.netdev_budget_usecs, değiştirme sysctl -w net.core.netdev_budget_usecs value
    • Örnek: default_qdisc görüntüleme sysctl net.core.default_qdisc, izleme tc -s qdisc ls dev ethX
  • TCP tamponu kalemleri olarak tcp_rmem, tcp_wmem, tcp_moderate_rcvbuf ele alınır; tcp_moderate_rcvbuf ayarlıysa TCP, alım tamponu boyutunu otomatik olarak ayarlamaya çalışır
  • TCP durumu ve tıkanıklık kontrolüyle ilgili kalemler arasında net.core.somaxconn, tcp_fin_timeout, tcp_available_congestion_control, tcp_congestion_control, tcp_max_syn_backlog, tcp_syncookies, tcp_slow_start_after_idle birlikte özetlenir
  • Linux iç ağ izleme, perf ile incelenebilir; örnek komut biçimi perf trace --no-syscalls --event 'net:*' ping globo.com -c1 > /dev/null şeklindedir
  • Test ve izleme araçları olarak iperf3, vegeta, netdata, prometheus + grafana + node exporter full dashboard kombinasyonu önerilir

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-07
Hacker News yorumları

  • Ubuntu Linux varsayılanlarında net.ipv4.tcp_rmem yaklaşık 6 MB, net.core.rmem_max ise yaklaşık 1 MB olduğundan tuhaf bir durum ortaya çıkıyor.
    Varsayılan TCP soketi gerekirse TCP alma penceresini 6 MB’a kadar çıkarabiliyor; ancak kullanıcı alanındaki bir uygulama setsockopt SO_RCVBUF çağırdığında, zaten 6 MB yapabilen soket bile en fazla 1 MB ile sınırlanıyor.
    6 MB’tan 4 MB’a düşürmeye çalışsanız bile sonucun 1 MB olması gibi çok garip görünüyor; aynı şey SO_SNDBUF/wmem için de geçerli.
    Linux bu seçeneklerin önceliklerini karıştırıyor gibi görünüyor; neden core.rmem_max daha büyük tutulup yetkili yönerge değeri olarak alınmıyor, bunun tarihsel bir nedeni var mı merak ediyorum.

    • Amaç aşırı tamponlanan veri miktarını sınırlamaksa SO_SNDBUF/wmem yerine TCP_NOTSENT_LOWAT düşürülebilir.
      Bu değer, bant genişliği-gecikme çarpımı (BDP) için gereken miktarın ötesinde ek olarak tamponlanacak miktarı sınırlar.
    • net.ipv4.tcp_rmem için maksimum değer, çekirdeğin yaptığı otomatik ayarlamanın sınırıdır.
      SO_RCVBUF ayarlandığı anda o sokette otomatik ayarlama devreden çıkar ve net.core.rmem_max maksimum değer olur.
      Bu, Documentation/networking/ip-sysctl.rst içinde oldukça açık şekilde belgelenmiş.

  • Paketin NIC’e girdikten sonra kullanıcı alanına ulaşmasına kadar olan tüm adımları göstermesi dahil, harika.
    Ağ performansıyla ilgili bir şey daha eklemek gerekirse, birden fazla CPU bulunan sistemlerde büyük sunucularda yaygın olan NUMA tahsisini kontrol etmek gerekir.
    Ağ kartı bir CPU tarafındaysa ve uygulama başka bir CPU’da çalışıyorsa bu performansı da etkileyebilir.

  • Linux’un varsayılan tıkanıklık denetimi olan net.ipv4.tcp_congestion_control değerini yalnızca bbr olarak değiştirmek bile bazı durumlarda muazzam fark yaratıyor.
    Muhtemelen özellikle mesafe, aralıklı paket kaybı ve jitter ile kapsülleme olduğunda böyle.
    Geçen 1 yıl boyunca client host <-- HTTP --> reverse proxy host <-- HTTP over Wireguard --> service host akışındaki bir sorunu hata ayıkladım; ortalamada teorik maksimum verimin %20’sini aşmak zordu ve bağlantı da zaman geçtikçe neredeyse duracak kadar yavaşlıyordu.
    Bağlantıyı sık sık zorla kapatma gibi geçici çözümler kullanıyorduk; tıkanıklık denetimini bbr olarak değiştirince teorik maksimuma yakın verim ve kararlı bağlantı elde ettik. Bu değişiklik Wireguard’ın iki tarafında da gerekliydi.

    • BBR’ın farkı, kaybı tıkanıklık sinyali olarak kullanmamasıdır.
      Çoğu TCP yığını ilk kaybı gördüğünde gönderim penceresini yarıya indirir veya ciddi ölçüde düşürür; bu yüzden kayıplı bir VPN’de ya da 10 Mb/s VPN uplink’ine 1 Gb/s ile büyük burst gönderdiğinizde TCP kaybı görüp büyük ölçüde geri çekilir.
      BBR, darboğaz bant genişliğini bulmaya çalışır; gidiş-dönüş süresini ölçer ve RTT artana kadar aktarım hızını yükseltir.
      RTT artınca yolun en dar bölümünde kuyruk oluştuğunu varsayar; kuyruk boşalıp RTT normale dönene kadar aktarım hızını düşürür, sonra bir süre o hızda gönderip tekrar biraz yükseltmeyi dener.
      Birkaç yıl önce 10 Mb/s kablo uplink’inden 1 Gb/s simetrik fiber hatta geçmeme rağmen şirket VPN yüklemelerinin yaklaşık 5 Mb/s’de kalması sinir bozucuydu; FreeBSD’de RACK TCP veya BBR’a geçince VPN sınırı olan yaklaşık 40 Mb/s’ye, yani yaklaşık 8 katına çıktı.
    • BBRv1 bozuk, bu yüzden açık internette kullanılmamalı.
      Tek bir sihirli değeri ayarlayınca her şey iyileşir tarzındaki kopyala-yapıştır kargo kültü performans ayarı, özgün metnin anlatmak istediğinin tam tersidir.
      Neyse ki Google BBRv3’ü upstream ediyor; yakında durum daha iyi olacak.
    • Tıkanıklık denetimi, veriyi gönderen taraftan alan taraf yönünde çalışır.
      Yalnızca tek yöndeki performansı iyileştirmek istiyorsanız Wireguard’ın iki tarafını da değiştirmeniz gerekmez.
      BBRv1 konusunda diğer yorumlara katılıyorum; Linux çekirdeğindeki cubic uygulaması çoğu uygulama için oldukça iyi çalışır.

  • Wi‑Fi adaptörlerinde de performans ayarlamasının anlamlı olup olmadığını merak ediyorum
    Masaüstünde işlevleri kapatmak dışında i210 ve i225 Ethernet sorunlarını düzeltmenin bir yolu olup olmadığını da merak ediyorum
    Günümüzde en yaygın NIC’lerin bu ikisi gibi görünüyor; yaygın ağ donanımı ve sürücülerinin neden bu kadar kusurlu olduğunu pek anlayamıyorum
    RISC-V’ye çok ilgim var; tamamen açık ve doğru çalışan bir NIC ile başlamaya ne dersiniz diye düşünüyorum
    i210’dan ucuz olursa eninde sonunda sisteme koyarlar, ama belki de bu imkânsız bir iştir

    • Maksimum yerel ağ aktarım hızının %10–20’sinden feragat edebilirseniz Wi‑Fi adilliğini ciddi ölçüde artırabilir, ping sürelerini iyileştirebilir ve bufferbloat’u azaltabilirsiniz
      Ancak Wi‑Fi’de rastgele ping sıçramaları yine de meydana gelir
      https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/590... adresinde AQM’yi etkinleştirme ve ayarlama ile aktarım hızı ve gecikme arasındaki ödünleşimi ele alan büyük bir başlık var
    • i225 düpedüz bozuk bir ürün, ama i210’dan harika performans alınabiliyor
      Aynı dönemin CPU’ları için 1Gb zaten pek zorlayıcı bir seviye değil ve i210 4 kuyruk sunuyor
      i210’dan ne konuda memnun olmadığını merak ediyorum
    • i225 onboard bulunan bir anakart kullanıyordum; PCIe I350 alarak sorunu çözdüm

  • Görselleştirilmiş Linux ağ kuyrukları özeti o kadar iyi ki bir yere, duvara asmak istiyorum
    Brendan’ın Systems Performance kitabı da Linux ağ performansı vb. konuları iyi ele alıyor ve şimdiden 2. baskısına ulaştı
    İki baskı da harika; ancak 2. baskı ağırlıklı olarak Linux’a odaklanıyor, 1. baskı ise Solaris’i de içeriyor
    Daha yakın zamanda aynı yazarın BPF Performance Tools kitabı da çıktı
    [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

  • Yazıya sadece göz atmak bile keyifliydi; araştırma ve yapılandırma çok iyiydi
    Ancak Linux ağ parametrelerini düzenli olarak ayarlayanların gerçekte kimler olduğunu merak ediyorum

  • Bu belgede bir yerde açıkça TCP yazması gerekiyor gibi
    İçerik TCP ile ilgili kaygılara oldukça yoğunlaşmış ve insanlar çoğunlukla TCP kullandığı için faydalı da
    Ama varsayılan UDP ayar değerleri feci derecede düşük; bu kısmın belirgin biçimde eksik olduğu görülüyor

    • UDP ayarlaması için iyi bir kaynak olup olmadığını merak ediyorum

  • Benzer konuları ele alan video veya seri önerileri almak isterim
    Genel ağ konulu kaynak çok, ancak Linux’un somut implementasyonunu ele alan kaynak bulmak zordu

    • Mikrodenetleyici bakış açısından da aynı tür kaynağa ihtiyaç var
      Mikrodenetleyiciler için basit bir TCP echo sunucusu yapmayı denemek istiyorum, ama örneklerin çoğu yalnızca üreticinin kendi TCP kütüphanesini kullanıyor ve yönlendiriciye doğrudan bağlantı ayarlayıp kurma sürecini neredeyse hiç açıklamıyor