Puncte:0

Ce problemă LAN este caracterizată de o viteză de încărcare foarte mică până când este începută o încărcare către o țintă diferită, în care ambele devin normale?

drapel in

Când încarc ceva de pe un server Windows (qemu kvm) pe un nou server Linux (bare metal) în aceeași rețea, viteza este foarte mică (aproximativ 1/100 din ceea ce ar trebui să fie posibil pentru uplink-ul de 1 GBit/s). Încărcările pe toate celelalte mașini (inclusiv alte servere Linux) din rețea funcționează la viteză maximă. Și de îndată ce pornesc o astfel de încărcare pe o altă mașină, în timp ce încărcarea pe serverul Linux problematic încă rulează, ambele încărcări devin rapid (deci încărcarea lentă înainte de a crește la aproximativ 50% din viteza uplink-ului în timp ce cealaltă pornește și rămâne și la asta). Odată ce „altă încărcare” se termină, fosta încărcare pe noul server problematic scade la viteza sa foarte mică.

Acesta pare să fie cazul pentru tot traficul (SSH, HTTP, SMB), în timp ce nicio altă mașină din rețea nu are problema. Deci, orice altă mașină din rețea se încarcă pe noul server fără probleme la viteză maximă.Se pare chiar că și gazda Linux bare metal nu are probleme.

Între ambele servere sunt două switch-uri Netgear 1/10GBit/s, dar nu VLAN-uri sau orice altă configurație specială. Am încercat câteva soluții tipice pentru gazdă/oaspete KVM (descărcare tx/rx, lso, adaptor virtual diferit, ...), dar fără nicio modificare. Privind tcpdumps pe sursă, țintă și gazdă, de asemenea, nu văd nimic care să pară neregulat. Deci, nicio pierdere de pachet sau alte probleme pe care le-am putut identifica (deși nu sunt un expert aici).

Așadar, înainte de orice altceva și din moment ce nu am văzut niciodată așa ceva, întrebarea mea principală este la ce fel de problemă mă uit aici?

Puncte:0
drapel cn

Prima mea presupunere ar fi că există ceva neplăcut cu negocierea automată ethernet între VM-ul Windows și cutia Linux baremetal care face ca „portul” VM-ului Windows să negocieze la un nivel mai scăzut, cum ar fi 10M în loc de 100M sau 1G. Când VM-ul Windows se încarcă pe un alt server, problema de negociere automată nu există (sau mai degrabă, este anulată atâta timp cât conexiunea la celălalt server este activă) și portul folosește 1G.

drapel in
Sună ca o concluzie logică. Cum l-aș depana, totuși? Tocmai am verificat `Get-NetAdapter | SELECT numele, LinkSpeed, fullduplex` pe VM Windows și `ethtool eth0` pe gazdă în timpul transferului lent rula și toate porturile de aici arată viteza așteptată.
drapel cn
Hmm. Primul lucru pe care l-aș face este să rulez `Get-NetAdapter` și `ethtool` atât în ​​timpul transferului lent în sine, cât și apoi în timpul transferului dublu, unde lucrurile se accelerează. De acolo, aș compara ieșirea pentru fiecare dintre „lent” și „dual” și aș căuta diferențe. De asemenea, VM-ul Windows pe care l-ați menționat este singura gazdă Windows? Adică, toate celelalte gazde din rețea sunt o aromă de GNU/Linux?

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.