Cosa fa grep quando non esegue la CPU?

Quando cerco partite con grep, noto spesso che la ricerca successiva richiede molto meno tempo della prima, ad esempio 25 secondi contro 2 secondi. Ovviamente, non è riutilizzando le strutture di dati dalla sua ultima esecuzione: quelle avrebbero dovuto essere deallocate. Eseguendo un timecomando grep, ho notato un fenomeno interessante:

real    24m36.561s
user    1m20.080s
sys     0m7.230s

Dove va il resto del tempo? C'è qualcosa che posso fare per farlo correre veloce ogni volta? (ad es. fare in modo che un altro processo legga i file, prima di grepcercarli.)

grep performance

— alex
fonte

Risposte:

È abbastanza spesso correlato alla cache della pagina .

La prima volta, i dati devono essere letti (fisicamente) dal disco.

La seconda volta (per file non troppo grandi) è probabile che si trovi nella cache della pagina.

Quindi potresti dare prima un comando come cat (1) per portare il file (non troppo grande) nella cache della pagina (cioè nella RAM), quindi un secondo grep (1) (o qualsiasi programma che legge il file) sarebbe generalmente più veloce .

^{(tuttavia, i dati devono ancora essere letti dal disco qualche volta)}

Vedi anche (a volte utile nei tuoi programmi applicativi, ma praticamente raramente) readahead (2) e posix_fadvise (2) e forse madvise (2) & sync (2) & fsync (2) ecc ....

Leggi anche LinuxAteMyRAM .

A proposito, questo è il motivo per cui si consiglia, durante il benchmarking di un programma, di eseguirlo più volte. Inoltre, questo è il motivo per cui potrebbe essere utile acquistare più RAM (anche se non si eseguono programmi che utilizzano tutto per i loro dati).

Se vuoi saperne di più, leggi alcuni libri come ad esempio Sistemi operativi: Tre pezzi facili

— Basile Starynkevitch
fonte

Quindi, la TL;DRrisposta è "[blocco in attesa di] I / O".

— Margarciaisaia,

@PaulDraper Non proprio :) cat+ ci grepvorrà ancora più tempo che grepda solo.

— Chepner,

@chepner A meno che tu non possa multithread e utilizzarlo catcome pre-fetch economico mentre stai facendo qualcos'altro, in preparazione per l' grepinteresse.

— hBy2Py

@MarkKCowan: gatti adorabili! :-) ⁠

— G-Man dice "Ripristina Monica" il

@ G-Man: puoi anche sostituire due delle cats con taclo stesso effetto e un maggiore utilizzo della RAM: D O tutti i gatti con tac

— Mark K Cowan,

-1

In un ambiente di archiviazione di rete, possono verificarsi anche ritardi relativamente significativi quando si accede per la prima volta a un file che risiede su un "filer" separato dal server. Una volta che il file è stato effettuato l'accesso sul server, verrà memorizzato nella cache locale e l'accesso successivo ai dati sarà molto più veloce.

Ecco un esperimento semplicemente calcolando un checksum dei dati del file, non grep. La prima invocazione è lenta e quelle successive sono veloci.

> du -Dh file_348m
348M    file_348m

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.60user 0.15system 0:03.02elapsed 25%CPU (0avgtext+0avgdata 1524maxresident)k
708144inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.67user 0.06system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.65user 0.07system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.66user 0.06system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

— Winston Smith
fonte

Gradirei commenti per i voti negativi, poiché non so come interpretarli. Credo che la descrizione della mia risposta sia corretta. Forse l'esempio di comando non è chiaro? O non ti piace che non abbia confrontato il comando grep? (Ho usato intenzionalmente un comando più semplice, md5sum, per cercare di illustrare il mio punto.)

— Winston Smith,

Penso che il motivo sia che il tuo post non ha aggiunto nuove informazioni pertinenti a ciò che stavo chiedendo. Sapevo già che c'era un ritardo, e la prima risposta forniva già una spiegazione del perché stesse accadendo. Ma sì, ottengo anche voti bassi senza spiegazioni. Anche su domande con buone risposte.

— Alex,

Grazie @Alex per aver suggerito un motivo. Stavo cercando di distinguere tra il tempo di overhead per spostare i dati dalla memoria locale alla memoria, descritta dalla prima risposta, e il tempo di overhead per spostare i dati dalla memoria di rete al server locale. Penserò se potrei descriverlo più chiaramente o fornire esempi di comando migliori.

— Winston Smith,

Credo che dopo aver letto il tuo post, il mio pensiero è, è ancora il sovraccarico di spostare i dati da qualsiasi luogo siano archiviati, in memoria. Che si tratti di archiviazione di rete o di archiviazione locale, non importa: Unix lo vede ancora passare da una directory alla memoria. ps-- sembra che la mia spiegazione sia corretta-- il mio commento con la ragione ha ottenuto un voto.

— Alex,

Vedo, stavo aggiungendo una distinzione che non è importante per quello che stavi cercando. OK. A proposito, ho votato a fondo il tuo commento, quindi non risolve la questione del motivo del downvoting. :-)

— Winston Smith il