Wat betekenen ‘real’, ‘user’ en ‘sys’ in de output van tijd(1)?

Wat betekenen ‘real’, ‘user’ en ‘sys’ in de output van tijd?

Welke is zinvol bij het benchmarken van mijn app?

Antwoord 1, autoriteit 100%

Reële, gebruikers- en Sys-procestijdstatistieken

Het ene is het andere niet. Real verwijst naar de werkelijke verstreken tijd; Gebruiker en Sys verwijzen naar de CPU-tijd die alleen door het proces wordt gebruikt.

• Reëelis de tijd van de wandklok – de tijd van het begin tot het einde van het gesprek. Dit is allemaal verstreken tijd, inclusief tijdsegmenten die door andere processen worden gebruikt en tijd die het proces geblokkeerd doorbrengt (bijvoorbeeld als het wacht tot I/O is voltooid).

• Gebruikeris de hoeveelheid CPU-tijd die is besteed aan gebruikersmoduscode (buiten de kernel) binnenhet proces. Dit is alleen de werkelijke CPU-tijd die wordt gebruikt bij het uitvoeren van het proces. Andere processen en de geblokkeerde tijd die het proces doorbrengt, tellen niet mee voor dit cijfer.

• Sysis de hoeveelheid CPU-tijd die tijdens het proces in de kernel wordt doorgebracht. Dit betekent het uitvoeren van de CPU-tijd die wordt besteed aan systeemaanroepen binnen de kernel,in tegenstelling tot bibliotheekcode, die nog steeds in de gebruikersruimte draait. Net als ‘gebruiker’ is dit alleen de CPU-tijd die door het proces wordt gebruikt. Zie hieronder voor een korte beschrijving van de kernelmodus (ook bekend als ‘supervisor’-modus) en het systeemaanroepmechanisme.

User+Syszal u vertellen hoeveel daadwerkelijke CPU tijd uw proces wordt gebruikt. Merk op dat dit in alle CPU’s is, dus als het proces meerdere draden heeft (en dit proces wordt uitgevoerd op een computer met meer dan één processor), kan het mogelijk de wandkloktijd overschrijden die is gemeld door real(dat gebeurt meestal). Merk op dat in de uitgang deze cijfers de useren sysTijd van alle kinderprocessen (en hun afstammelingen) ook wanneer ze konden zijn verzameld, b.v. Met wait(2)of waitpid(2), hoewel de onderliggende systeemoproepen de statistieken voor het proces en de kinderen afzonderlijk retourneren.

Oorsprong van de statistieken gerapporteerd door time (1)

De statistieken gerapporteerd door timezijn verzameld uit verschillende systeemgesprekken. ‘Gebruiker’ en ‘SYS’ komen van wait(2)(posix ) of times (2)(posix ), afhankelijk van het specifieke systeem. ‘Real’ wordt berekend op basis van een start- en eindtijd die is verzameld uit de gettimeofday (2)bel. Afhankelijk van de versie van het systeem kunnen verschillende andere statistieken, zoals het aantal contextschakelaars ook worden verzameld door time.

Op een machine met meerdere processors kan een multi-threaded proces of een proces dat kinderen vertakt een verstreken tijd hebben die kleiner is dan de totale CPU-tijd, omdat verschillende threads of processen parallel kunnen lopen. Ook zijn de gerapporteerde tijdstatistieken van verschillende oorsprong, dus tijden die zijn geregistreerd voor zeer kortlopende taken kunnen onderhevig zijn aan afrondingsfouten, zoals het voorbeeld van de originele poster laat zien.

Een korte inleiding over Kernel vs. Gebruikersmodus

Op Unix of een ander besturingssysteem met beschermd geheugen, ‘Kernel’ of ‘Supervisor’modus verwijst naar een geprivilegieerde moduswaarin de CPU kan werken. bevoorrechte acties die de veiligheid of stabiliteit kunnen beïnvloeden, kunnen alleen worden uitgevoerd als de CPU in deze modus werkt; deze acties zijn niet beschikbaar voor applicatiecode. Een voorbeeld van een dergelijke actie kan het manipuleren van de MMUzijn om toegang te krijgen tot de adresruimte van een ander Verwerken. Normaal gesproken kan gebruikersmoduscode dit niet doen (met goede reden), hoewel het gedeeld geheugenvan de kernel, dat kongelezen of geschreven worden door meer dan één Verwerken. In dit geval wordt het gedeelde geheugen expliciet aangevraagd bij de kernel via een beveiligd mechanisme en moeten beide processen er expliciet aan gekoppeld worden om het te kunnen gebruiken.

De bevoorrechte modus wordt meestal de ‘kernel’-modus genoemd omdat de kernel wordt uitgevoerd door de CPU die in deze modus draait. Om over te schakelen naar de kernelmodus moet je een specifieke instructie geven (vaak een trap genoemd ) die de CPU overschakelt naar draaien in de kernelmodus en code uitvoert vanaf een specifieke locatie in een springtabel.Om veiligheidsredenen kunt u niet overschakelen naar de kernelmodus en uitvoeren willekeurige code – de traps worden beheerd via een tabel met adressen waarnaar niet kan worden geschreven tenzij de CPU in de supervisormodus werkt. Je trap met een expliciet trapnummer en het adres wordt opgezocht in de sprongtabel; de kernel heeft een eindig aantal gecontroleerde ingangspunten.

De ‘systeem’-aanroepen in de C-bibliotheek (met name die beschreven in Sectie 2 van de man-pagina’s) hebben een gebruikersmoduscomponent, wat u feitelijk vanuit uw C-programma aanroept. Achter de schermen kunnen ze een of meer systeemaanroepen naar de kernel doen om specifieke services zoals I/O uit te voeren, maar ze hebben nog steeds code die in gebruikersmodus draait. Het is ook heel goed mogelijk om desgewenst rechtstreeks een trap naar de kernelmodus te sturen vanuit elke gebruikersruimtecode, hoewel je misschien een stukje assembler moet schrijven om de registers correct in te stellen voor de aanroep.

Meer over ‘sys’

Er zijn dingen die je code niet kan doen vanuit de gebruikersmodus – dingen zoals geheugen toewijzen of toegang krijgen tot hardware (HDD, netwerk, enz.). Deze staan onder toezicht van de kernel en alleen deze kan ze doen. Sommige bewerkingen zoals mallocoffread/fwritezullen deze kernelfuncties aanroepen en dat zal dan tellen als ‘sys’-tijd. Helaas is het niet zo eenvoudig als “elke oproep naar malloc wordt geteld in ‘sys’-tijd”. De aanroep naar malloczal zelf enige verwerking doen (nog steeds geteld in ‘gebruiker’-tijd) en dan ergens onderweg kan het de functie in kernel aanroepen (geteld in ‘sys’-tijd). Na terugkomst van de kernelaanroep, zal er wat meer tijd zijn in ‘user’ en dan zal mallocterugkeren naar je code. Wat betreft wanneer de omschakeling plaatsvindt en hoeveel ervan in de kernelmodus wordt uitgegeven… je kunt niet zeggen. Het hangt af van de implementatie van de bibliotheek. Ook kunnen andere schijnbaar onschuldige functies mallocen dergelijke op de achtergrond gebruiken, die dan weer enige tijd in ‘sys’ zullen hebben.

Antwoord 2, autoriteit 14%

Om het geaccepteerde antwoorduit te breiden, wilde ik nog een reden geven waarom real≠ user+ sys.

Houd er rekening mee dat realde werkelijke verstreken tijd aangeeft, terwijl de waarden useren sysde CPU-uitvoeringstijd vertegenwoordigen. Als gevolg hiervan kan op een multicore-systeem de tijd van useren/of sys(evenals hun som) de realtime overschrijden. Op een Java-app die ik voor de klas gebruik, krijg ik bijvoorbeeld deze reeks waarden:

real    1m47.363s
user    2m41.318s
sys     0m4.013s

Antwoord 3, autoriteit 2%

• echt: de werkelijke tijd die is besteed aan het uitvoeren van het proces van begin tot eind, alsof het werd gemeten door een mens met een stopwatch

• gebruiker: de cumulatieve tijd besteed door alle CPU’s tijdens de berekening

• sys: de cumulatieve tijd die door alle CPU’s is besteed aan systeemgerelateerde taken zoals geheugentoewijzing.

Merk op dat gebruiker + sys soms groter kan zijn dan echt, zoals
meerdere processors kunnen parallel werken.

Antwoord 4

Real toont de totale doorlooptijd van een proces;
terwijl Gebruiker de uitvoeringstijd toont voor door de gebruiker gedefinieerde instructies
en Sys is voor tijd voor het uitvoeren van systeemaanroepen!

Reële tijd omvat ook de wachttijd (de wachttijd voor I/O enz.)

Antwoord 5

Ik wil een ander scenario noemen waarin de realtime veel groter is dan gebruiker + sys. Ik heb een eenvoudige server gemaakt die na een lange tijd reageert

real 4.784
user 0.01s
sys  0.01s

het probleem is dat in dit scenario het proces wacht op het antwoord dat niet op de gebruikerssite of in het systeem staat.

Iets soortgelijks gebeurt wanneer u de opdracht finduitvoert. In dat geval wordt de tijd vooral besteed aan het aanvragen en krijgen van een reactie van SSD.

Antwoord 6

In heel eenvoudige bewoordingen denk ik er graag zo over na:

• realis de werkelijke hoeveelheid tijd die nodig was om het commando uit te voeren (alsof je het had getimed met een stopwatch)

• useren sysgeven aan hoeveel ‘werk’ de CPUmoest doen om het commando uit te voeren. Dit ‘werk’ wordt uitgedrukt in tijdseenheden.

Over het algemeen:

• useris hoeveel werk de CPUheeft gedaan om de code van de opdracht uit te voeren
• sysis hoeveel werk de CPUmoest doen om taken van het type ‘systeemoverhead’ (zoals het toewijzen van geheugen, bestands-I/O, enz.) in om het lopende commando te ondersteunen

Aangezien deze laatste twee keren het ‘werk’ tellen dat is gedaan, is er geen tijd die een thread heeft besteed aan wachten (zoals wachten op een ander proces of totdat schijf-I/O is voltooid).

realis echter een maatstaf voor de werkelijke looptijd en niet voor ‘werk’, dus bevatde tijd die wordt besteed aan wachten.