înregistrare Logare
Puncte:1
Orion Red avatar Server

Ce îmi spun rezultatele de la Linux time wrapper că sa întâmplat cu această comandă cp?

drapel in
Orion Red

Părerea mea despre această problemă este din partea dezvoltatorului. Scriu codul care este plasat pe o mașină virtuală RHEL care rulează ca unul dintre multele dintr-un sistem de întreprindere. Sistemul de fișiere utilizat este un dispozitiv de stocare la distanță, atașat la rețea.

Am avut o variabilitate mare asupra comenzilor simple în timpul lotului. Așa că am stabilit un test pentru a obține mai multe informații, dar acum nu știu ce am găsit.

Am rulat următoarea comandă la fiecare 30 de minute și am înregistrat rezultatul. Este o copie a unui fișier de 6 GB. Ceea ce văd este un salt al timpului scurs de la 11 secunde la 190 de secunde când sistemul este ocupat cu o mulțime de joburi și această comandă de testare are un timp CPU scăzut.

Ceea ce pot vedea este că coloana „I” (intrari ale sistemului de fișiere) este populată atunci când CPU este scăzut, dar nu atunci când este ridicat. Coloana „w” (schimbări involuntare) este, de asemenea, mult mai mare.

Întrebarea mea este, ce se întâmplă cu această sarcină/comandă care o obligă să ruleze ATÂT DE MULT MAI MULT când timpul CPU scade? Schimbarea in/out stochează toate acele date pe un alt dispozitiv care este mult mai lent? În general, ce se întâmplă în timpul unui schimb de intrare/ieșire?

Comandă în curs de rulare:

/usr/bin/time -a -o filename.txt cp file.txt fileCopy.txt
Data Timp e S U P c w eu O
3/14/2022 5:19:02 64.9 16.23 1.03 26% 3005 29210 12000016 12000000
3/14/2022 5:49:02 12.7 11.63 0.79 97% 2069 76 0 12000000
3/14/2022 6:19:02 100.39 14.74 0.78 15% 1034 29925 12000136 12000000
3/14/2022 6:49:24 191.32 18.86 0.94 10% 3374 36164 12001024 12000000
3/14/2022 7:19:02 71.61 15.61 0.88 23% 1610 30316 12000296 12000000
3/14/2022 7:49:02 70.73 17.5 0.91 26% 1408 29540 12000072 12000000
3/14/2022 8:19:02 10.95 9.89 0.7 96% 1709 75 0 12000000
3/14/2022 8:49:02 11.01 10.22 0.73 99% 239 85 0 12000000

Descrierile coloanelor din pagina de manual pentru /usr/bin/time

e Timp real scurs (în secunde).
S Numărul total de secunde CPU pe care procesul le-a petrecut în modul kernel.
U Numărul total de secunde CPU petrecute în modul utilizator.
P Procentul CPU pe care l-a primit acest job, calculat ca (%U + %S) / %E.
c Numărul de ori în care procesul a fost schimbat de context involuntar (deoarece intervalul de timp a expirat).
w Numărul de așteptări: de ori când programul a fost comutat de context în mod voluntar, de exemplu în timp ce se aștepta finalizarea unei operațiuni I/O.
I Numărul de intrări ale sistemului de fișiere de către proces.
O Numărul de ieșiri ale sistemului de fișiere ale procesului.
17
0 + 0
Puncte:1
John Mahowald avatar Server
drapel cn
John Mahowald

P în acest context înseamnă raportul dintre timpul CPU pe care acest job a obținut în raport cu timpul total scurs. Aproape 100% înseamnă că aproape tot timpul a fost pe CPU, la fel și CPU-ul a fost constrâns pentru acele rulări. Spre deosebire de celelalte curse în care altceva a fost factorul limitativ. Mai mult timp de sistem (aka kernel) decât timpul de sistem, așa cum este tipic pentru sarcinile grele I/O.

Având în vedere că volumul de lucru a fost copierea unui fișier de 6 GB, putem deduce că rulările de 11 secunde au în medie mai mult de 0,5 GB scrieri pe secundă. Coloana O confirmă același număr de scrieri de fiecare dată, în concordanță cu un proces simplu de copiere a unui fișier.

Coloana de intrare are totuși variații majore. Execuțiile lente au citiri aproximativ egale cu scrierile. Dar alergările rapide nu fac nicio citire! Presupun că fișierul este încă stocat în cache în RAM de când a fost citit ultima dată. DRAM este mult mai rapid decât chiar și stocarea în stare solidă. Ceea ce este o creștere grozavă a vitezei, până când, sub presiunea memoriei, sistemul de operare renunță la datele din cache și trebuie să citească din nou din stocarea lentă.

Deci aceasta este o sarcină de 200 de secunde, care ocazional poate dura 12 secunde. Probabil din cauza memoriei cache a paginii Linux.

Găsirea cauzei principale a unei probleme de performanță necesită adesea o înțelegere mai profundă a întregului sistem, dincolo de orice anumit set de metrici.

Sistemul de fișiere utilizat este un dispozitiv de stocare la distanță, atașat la rețea.

Rețineți că lucrul cu copierea dvs. este prin stocare în rețea, deci ar putea fi, de asemenea, orice pe sistemul de la distanță sau pe rețea între ele. Performanță de stocare la distanță. Vitezele și utilizarea rețelei (probabil IP). Sau ar putea fi local pentru această VM, în care oaspetele concurează pentru resurse cu orice altceva rulând pe infrastructura dumneavoastră.

Întotdeauna este posibil să aprofundăm cum funcționează lucrurile.Contează deloc stocarea în rețea (NFS?) sau vedeți acest lucru și pentru discul local? 0,7 secunde de timp CPU utilizator este destul de mult de lucru, de fapt, cât de mult este contabilitatea pentru a gestiona multe apeluri de sistem? Ce înseamnă de fapt CPU ocupat când majoritatea așteaptă memorie lentă și stocare foarte lentă? Nu este ușor să răspunzi la întrebări, dar poate că nu este nevoie să sapi prea adânc odată ce lucrul funcționează corespunzător.

0 + 0
Orion Red avatar
drapel in
Orion Red
„Presupun că fișierul este încă stocat în cache în RAM de când a fost citit ultima dată.” - Acest lucru are sens total atunci când stau cu adevărat și privesc situația în ansamblu.De asemenea, mă poate conduce la o modalitate de a remedia această problemă specială în timpul de procesare. Este un porc într-o situație python în care obținem un fișier masiv de 16 GB, îl criptăm/comprimam pentru a fi utilizat mai târziu, apoi îl decriptăm/extindem atunci când este necesar. APOI sortând-o. Celelalte fișiere relevante au mai puțin de 800 MB, așa că s-ar putea să pot pune acești pași spate în spate și să elimin nevoia de atâtea operațiuni.
0
Răspunde
Orion Red avatar
drapel in
Orion Red
Cum ți-ar plăcea să fii creditat când iau asta în lanț?
0
Răspunde
John Mahowald avatar
drapel cn
John Mahowald
Poate că decriptarea și procesarea se pot întâmpla într-o conductă, dacă accesul la flux este posibil, dar posibil nu. Sau doar aruncați memoria și stocarea rapidă la problemă. În ceea ce privește atribuirea, numele meu și un link către acesta, ca tipic pentru licența CC BY-SA pentru toate lucrurile Stack Exchange https://stackoverflow.com/help/licensing Poate că nu ați avea ocazia să vă adaptați și să partajați, dar dacă spunem că ați scris vreodată o postare de blog de inginerie despre interpretarea comenzii umile de timp, licența necesită atribuire.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

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.