Zlepšení výkonu TCP v gigabitové síti se spoustou připojení a vysokým provozem malých paketů

Řešení 1:

Problém může být v tom, že na vaší síťové kartě dochází k příliš velkému počtu přerušení. Pokud problém není v šířce pásma, je problémem frekvence:

• Zvyšte vyrovnávací paměti pro odesílání/příjem na síťové kartě

  ethtool -g eth0
  

Zobrazí aktuální nastavení (256 nebo 512 záznamů). Pravděpodobně je můžete zvýšit na 1024, 2048 nebo 3172. Více pravděpodobně nedává smysl. Toto je pouze kruhová vyrovnávací paměť, která se zaplní pouze v případě, že server není schopen zpracovat příchozí pakety dostatečně rychle.

Pokud se vyrovnávací paměť začne plnit, řízení toku je dalším prostředkem, jak sdělit routeru nebo přepínači, aby zpomalil:

• Zapněte řízení toku příchozích/odchozích na serveru a portech přepínače/směrovače, ke kterým je připojen.

  ethtool -a eth0
  

Pravděpodobně se zobrazí:

Pause parameters for eth0:
Autonegotiate:  on
RX:             on
TX:             on

Zkontrolujte /var/log/messages pro aktuální nastavení eth0. Zkontrolujte něco jako:

eth0:Link je až 1000 Mb/s, plně duplexní, TX a Rx řízení toku

Pokud nevidíte tx a rx, musí správci vaší sítě upravit hodnoty na přepínači/routeru. Na Cisco, které má zapnuté řízení toku příjmu/vysílání.

Pozor: Změna těchto hodnot způsobí, že váš odkaz bude spuštěn a spuštěn na velmi krátkou dobu (méně než 1 s).

• Pokud toto vše nepomůže - můžete také snížit rychlost síťové karty na 100 MBit (udělejte totéž na portech přepínače/routeru)

  ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100
  

Ale ve vašem případě bych řekl - zvedněte přijímací vyrovnávací paměti v prstencové vyrovnávací paměti NIC.

Řešení 2:

Následující nemusí být definitivní odpovědí, ale určitě přinese nějaké nápady

Zkuste je přidat do sysctl.conf

##  tcp selective acknowledgements. 
net.ipv4.tcp_sack = 1
##enable window scaling
net.ipv4.tcp_window_scaling = 1
##
net.ipv4.tcp_no_metrics_save = 1

Zatímco selektivní tcp ack je dobré pro optimální výkon v případě sítě s velkou šířkou pásma. Ale pozor na další nevýhody. Výhody změny velikosti okna jsou popsány zde. Pokud jde o třetí možnost sysctl:Ve výchozím nastavení TCP ukládá různé metriky připojení do mezipaměti trasy, když se připojení uzavře, takže připojení navázaná v blízké budoucnosti je mohou použít k nastavení počátečních podmínek. Obvykle se tím zvýší celkový výkon, ale někdy může dojít ke snížení výkonu. Pokud je nastaveno, TCP nebude ukládat do mezipaměti metriky při uzavírání připojení.

Zkontrolujte pomocí

ethtool -k ethX

abyste zjistili, zda je vykládání povoleno nebo ne. Snížení zátěže kontrolního součtu TCP a snížení zátěže velkých segmentů podporuje většina dnešních ethernetových síťových karet a zjevně je podporuje i Broadcom.

Zkuste použít nástroj

powertop

když je síť nečinná a když je dosaženo saturace sítě. To určitě ukáže, zda jsou na vině přerušení NIC. Odpovědí na takovou situaci je dotazování zařízení. FreeBsd podporuje přepínač dotazování přímo v ifconfig, ale linux takovou možnost nemá. Chcete-li povolit dotazování, přečtěte si toto. Říká se, že BroadCom také podporuje hlasování, což je pro vás dobrá zpráva.

Jumbo packet tweak vám to nemusí ubrat, protože jste zmínili, že váš provoz se skládá převážně z malých paketů. Ale i tak to zkuste!

Řešení 3:

Všiml jsem si v seznamu vylepšení, že časová razítka jsou vypnutá, prosím nedělejte to. To je starý návrat do dávných dob, kdy byla šířka pásma opravdu drahá a lidé chtěli ušetřit pár bajtů/paket. V současné době jej používá například zásobník TCP, aby zjistil, zda paket přicházející pro soket v „CLOSE_WAIT“ je starý paket pro připojení nebo zda je to nový paket pro nové připojení a pomáhá při výpočtech RTT. A úspora několika bajtů pro časové razítko není NIC ve srovnání s tím, co přidají adresy IPv6. Vypnutí časových razítek přináší více škody než užitku.

Toto doporučení pro vypnutí časových razítek je jen návratem, který se neustále předává z jedné generace systémových administrátorů na další. Něco jako "městská legenda".

Řešení 4:

musíte rozložit zátěž na všechna jádra CPU. Spusťte 'irqbalance'.

Řešení 5:

V mém případě pouze jediné ladění:

net.ipv4.tcp_timestamps = 0

provedli velmi velkou a užitečnou změnu, doba načítání stránek se zkrátila o 50 %.