Puncte:1

De ce pot merge mai departe

drapel us

Am 4 cutii CentOS 7 cu NIC SuperMico 10000BaseT conectate la un switch Netgear ProSafe XS712T cu cabluri Cat8. Switch este toate setările implicite, dar arată NIC-urile la 10G Full. NIC-urile sunt configurate:

[root@VH11 ~]# ethtool ens1f0
Setări pentru ens1f0:
        Porturi acceptate: [ TP ]
        Moduri de legătură acceptate: 100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
        Utilizare acceptată a cadrului de pauză: simetric
        Suportă auto-negociere: Da
        Moduri FEC acceptate: Nu sunt raportate
        Moduri de link anunțate: 10000baseT/Full
        Utilizarea cadrului de pauză anunțată: simetrică
        Auto-negociere anunțată: Da
        Moduri FEC anunțate: Nu sunt raportate
        Viteza: 10000 Mb/s
        Duplex: complet
        Port: pereche răsucită
        PHYAD: 0
        Transceiver: intern
        Auto-negociere: activată
        MDI-X: Necunoscut
        Suporta Wake-on: d
        Trezire: d
        Nivelul curent al mesajului: 0x00000007 (7)
                               link sonda drv
        Link detectat: da

Există NUMAI NIC-uri 10G conectate la comutator.

Pot obține viteze de transfer mai mici de 1G la transferurile de fișiere, așa cum sunt raportate de rsync, scp și iftop atunci când transfer 1 fișier 20G. Când testez de pe server > switch > server cu iperf, îmi spune că primește 9,38 Gbits/sec, dar primesc doar 10% din asta la transferurile de fișiere cu rsync sau scp.

Ce greșesc aici?

Mulțumesc anticipat pentru timpul acordat.

Informații adăugate: Pentru segmentul de rețea de 1 GB:

[root@VH14 ~]# time scp bigfile [email protected]:/home
Parola lui [email protected]:
fișier mare 100% 4494 MB 110,1 MB/s 00:40

0m46.657s reale
utilizator 0m18.975s
sys 0m4.646s

Pentru segmentul de rețea de 10 GB:

[root@VH14 ~]# time scp bigfile [email protected]:/home/bf3
Parola lui [email protected]:
fișier mare 100% 4494 MB 112,3 MB/s 00:40

0m45.693s reale
utilizator 0m34.643s
sys 0m8.440s

172. și 10. sunt pe comutatoare diferite. Switch-ul 10G nu are uplink și comunică doar cu serverele. Deci, deși iperf spune că primesc aproximativ 10G, rezultatele transferului sunt în esență aceleași pe ambele subrețele.

Nu cred că i/o disc este problema mea:

[root@VH14 ~]# hdparm -t /dev/md126

/dev/md126:
 Citește discul cu tampon de sincronizare: 4150 MB în 3,00 secunde = 1382,80 MB/sec
[root@VH14 ~]# hdparm -T /dev/md126

/dev/md126:
 Citituri de sincronizare stocate în cache: 19798 MB în 1,99 secunde = 9945,27 MB/sec

Informații suplimentare: MTU pe NIC-urile 10G este 9124. Procesoarele sunt Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz

Michael Hampton avatar
drapel cz
Cutiile tale vechi sunt capabile să țină pasul cu supraîncărcarea de criptare?
jerryrig avatar
drapel us
Serverele au 56 de nuclee și 256G RAM. Încărcare medie Htop de .66 cu 4 transferuri în curs. Am conectat NIC la NIC, eliminând comutatorul și am obținut aceleași rezultate la transferurile de fișiere.
Michael Hampton avatar
drapel cz
Deci nu cutii vechi, doar sistemul de operare vechi. Este la zi? Ați încercat un transfer HTTP? Sunteți conștient de pornirea lentă a TCP? Cum variază viteza de transfer pe parcursul descărcării?
jerryrig avatar
drapel us
Serverele sunt complet actualizate. Totuși, nu aveți http instalat. Viteza de transfer este constantă și primele 10 secunde sau cam asa ceva. Am actualizat postarea cu mai multe informații. BTW: CentOS7 este încă în viață. Ne voi muta la Oracle Linux 8 (RHEL8) în curând.
Nikita Kipriyanov avatar
drapel za
Ați activat cadrele Jumbo? Ce este sarcina de întrerupere în sistem (cel puțin, ce este în câmpul „si” din partea de sus când rulați teste)? De asemenea, observați că 56 de nuclee nu spun nimic despre performanța fiecărui nucleu; acest CPU ar putea fi o colecție imensă de lucrători lenți, fiecare dintre ei nu poate rula suficient de repede, dar împreună pot învinge un gigant. ssh, rsync sunt single threaded afaik, nu beneficiază de multicore. De exemplu. încercați nu 4, ci 56 de transferuri simultane, pentru a menține CPU-ul foarte ocupat.
Nikita Kipriyanov avatar
drapel za
@vidarlo a menționat că iperf spune 10G
vidarlo avatar
drapel ar
@NikitaKipriyanov Într-adevăr! Mi-a lipsit. Îmi pare rău!
jerryrig avatar
drapel us
MTU pe NIC-urile 10G este 9124. Procesoarele sunt CPU Intel(R) Xeon(R) E5-2690 v4 @ 2,60 GHz
jerryrig avatar
drapel us
Interesant, după crearea unei monturi NFS între 2 servere cu NICS 10G conectat direct, iftop arată 7,6 Gb cu fișierul cp la comanda NFS în timp ce cu rsync arată 3,44 Gb. Deci, cel puțin, ajung undeva cu NFS. Cred că trebuie să existe câteva setări reglabile în ierarhia sysctl care vor rezolva acest lucru. Nu le-am găsit încă, totuși.
Nikita Kipriyanov avatar
drapel za
Și din nou, ce spun /proc/întreruperile în timpul transferului?

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.