Ahoj,
tak nepovedlo, použil jsem mimo jiné info zde i odkazy z příspěvku, který je od @kamilj v tomto vlákně označené jako řešení.
Bohužel jsem stále na stropu cca 3,8 Gbps kdy se server chová tak, že si zhruba drží tuto propustnost a jediné co se mění je, že klesá propustnost uživatelských tříd, dejme tomu že mám nastavenou max rychlost pro download na 150 Mbps a upload tady řešit nebudu s ním je vše ok. Zhruba do traffiku 3 Gbps vše funguje jak má (jak s HTB tak i s HFSC), pak se začne postupně snižovat propustnost uživatelských tříd.
Při níže uvedených tocích a paketech za sekundu dosahuje zákaznická třída těchto propustností:
(kdy stále kvuli fq_codel jede v krásných latencích, takže zákazník pokud by mu stačilo 25 Mbps a neměřil si rychlost, nic nepozná):
(test zákaznické třídy meřeno na speedtest.net, Gbps a PPS čteny ze serveru shaperu)
při 3 Gbps na download interface propustnost zákaznické třídy 130 Mbps a během měření klesá na 116 Mbps
-- download interface PPS tx 240 455 pkts/s - rx 146 030 pkts/s
při 3,5 Gbps na download interface propustnost zákaznické třídy 100 Mbps a během měření klesá na 85 Mbps
-- download interface PPS tx 251 117 pkts/s - rx 148 104 pkts/s
při 3,7 Gbps na download interface propustnost zákaznické třídy 53 Mbps
-- download interface PPS tx 251 160 pkts/s - rx 161 590 pkts/s
při 3,8 Gbps na download interface propustnost zákaznické třídy 42 Mbps
-- download interface PPS tx 265 494 pkts/s - rx 168 819 pkts/s
při 3,8 Gbps na download interface propustnost zákaznické třídy 30 Mbps při malém nárůstu PPS viz níže
-- download interface PPS tx 269 910 pkts/s - rx 169 545 pkts/s
při 3,8 Gbps na download interface propustnost zákaznické třídy 25 Mbps při dalším malém nárůstu PPS viz níže
-- download interface PPS tx 274 884 pkts/s - rx 186 888 pkts/s
Pak jsem vypnul shaper na upload interfacu směrem do netu a myslel jsem že "odlečím už tak nicotné zátěži" serveru a projeví se to byť jen trochu, ale na download interface a shaper jednoho směru to nemělo vliv.
Zde bych chtěl dodat že toto je už se shaperem HFSC protože s HTB si ty propustnosti vydělte 2, to je ještě větší tragedie.
Zde je výpis třech tříd při zátěži (defaultní, hlavní, a zákaznická napojená na hlavní, která se pak opakuje per zákazník a je jich jenom asi 2000) HFSC při zátěži, podotýkám, že dropped v default třídě 1:ffff se nehýbe:
`class hfsc 1:ffff parent 1: rt m1 0bit d 0us m2 2Gbit
Sent 7149103684 bytes 6786478 pkt (dropped 2214, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class hfsc 1:1 parent 1: ls m1 0bit d 0us m2 14Gbit ul m1 0bit d 0us m2 14Gbit
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class hfsc 1:1c5e parent 1:1 leaf 845f: ls m1 0bit d 0us m2 1Mbit ul m1 0bit d 0us m2 165Mbit
Sent 344186220 bytes 537282 pkt (dropped 0, overlimits 0 requeues 0)
backlog 25738b 10p requeues `
Dále bych se mohl dát i výpisy qdisců fq_codel, ale myslím že je to zbytečné, bez nich ta zákaznická třída má stejně blbou propustnost i bez koncového "chytrého" qdiscu který jsem pokusně odebral.
Takže stav je takový, že nikde nic nedropuje, a přesto to jede naprd při nějakém hrdlu na 3,7 Gbps nebo PPS cca 274 884 pkts/s - rx 186 888 pkts/s což považuji za nicotné PPS.
Pokud zcela vypnu HFSC tak trafik okamžitě vystřelí z těch 3,8 Gbps na 4,7 Gbps a pak do toho na testovacím stroji klidně změřím další 1 Gbps a nikde to není znát.
Níže info o optimalizaci serveru a pár výpisů:
Server nyní má vyplý hyperthreading, má fixované fronty síťových karet na procesory:
20 CPU rozděleno tak aby 4 CPU byly pro běžné úkoly serveru a 16 CPU je rozdělen po 8 na každou dvouportovou 10G síťovou kartu.
server nevykazuje žádnou zátěž ve špičce jak s vypnutým shaperem, tak se zapnutým shaperem není v tom vidět rozdíl
se zapnutým shaperem a v problematické špičce je výpis utility top:
top - 17:00:34 up 1 day, 1:48, 1 user, load average: 0,85, 1,09, 1,22
Tasks: 268 total, 1 running, 267 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,0 us, 0,4 sy, 0,0 ni, **99,5 id**, 0,0 wa, 0,0 hi, **0,0 si**, 0,0 st
MiB Mem : 32010,1 total, 26225,6 free, 1444,5 used, 4620,4 buff/cache
MiB Swap: 976,0 total, 976,0 free, 0,0 used. 30565,5 avail Mem
procesory jedou na maximální frekvenci což jsem z toho dostal 1,9 GHz (1,8 by měl být max) a jedou v C0 stavu a nikdy z něj nevylezou - zde vidím potenciální problém, protože jsem se dočetl, že se doporučuje 3GHz a výše, je to opravdu ta příčina mého stropu nebo to někdo podobně provozujete také na "úsporných" XEONECH?
v utilitě htop nevidím žádné vytížení žádného procesoru nad 1%
v utilitě perf top je toto "nic" jenom velký idle pool:
Samples: 309K of event 'cycles', **4000 Hz**, Event count (approx.): 142577726448 lost: 0/0 drop: 0/0
Overhead Shared Object Symbol
78,47% [kernel] [k] cpu_idle_poll.isra.0
1,98% [kernel] [k] native_queued_spin_lock_slowpath
0,82% [kernel] [k] clflush_cache_range
0,81% [kernel] [k] nft_do_chain
0,77% [kernel] [k] xas_find
0,59% [kernel] [k] i40e_napi_poll
Zkoušel jsem mnoho různých změn nastavení zákaznických tříd jak v HTB tak HFSC i tunit parametry koncového fq_codel qdiscu, ale nikdy to nemělo obsolutně žádný dopad (pominu ty negativní při ujetých konfiguracích)
Máte prosím někdo nějaký nápad jakým směrem se vydat?
Mohl byste mi někdo prosím napsat jestli provozujete server v podobné zátěži a jaké jsou zkušenosti?
Nemůže být kámen úrazu plochý návrh kdy do jedné hlavní třídy je napojeno cca 2000 zákaznických tříd, místo varianty s více větvenou hierarchií HTB/HFSC stromu třeba hlavní třída per lokalita a do ní teprve zákaznické třídy?
Díky!
H.
