Grep in un enorme file di registro (> 14 GB) solo l'ultimo x GB?


34

Devo cercare qualcosa in un enorme file di registro (oltre 14 GB). Sono abbastanza sicuro che sia negli ultimi 4 GB circa.

C'è un modo per saltare il primo X GB per accelerare le cose?


7
LC_ALL=C greppotrebbe accelerarlo.
jfs

1
Sarai in grado di ottenere molta velocità scegliendo grepun'espressione sensata ... i caratteri jolly di lunghezza sconosciuta (come a.*thing) in alcuni casi impiegheranno molto più tempo a valutare. È possibile che tu stia ottimizzando per la cosa sbagliata (anche se non fa mai male cercare solo una parte del file, ovviamente - potrebbe non essere la migliore fonte di speedup).
Floris,

Risposte:


75

Immagino che potresti usare tail per emettere solo gli ultimi 4 GB circa usando l' -cinterruttore

-c, --bytes = [+] NUM
emesso gli ultimi NUM byte; oppure usa -c + NUM per l'output a partire dal byte NUM di ciascun file

Probabilmente potresti fare qualcosa anche con dd impostando bs=1e skipinserendo l'offset che vuoi iniziare ad es

dd if=file bs=1024k skip=12g | grep something

83
Successivamente, è necessario configurare logrotate.
Gerald Schneider,

3
@Rogier Aggiungi una risposta con la soluzione anziché aggiungerla alla tua domanda. Questo è simile all'auto-risposta: serverfault.com/help/self-answer
AL

5
@istheEnglishway: Beh, no, hanno inviato un comando diverso.
Lightness Races con Monica

11
Ma la tua risposta non fornisce il comando effettivo che implementa quella soluzione, che è un valore aggiunto. È possibile modificarlo nella risposta oppure l'OP potrebbe pubblicarlo come nuova risposta. Non dovrebbero assolutamente aggiungerlo alla domanda, che è quello che è successo. E sicuramente non dovresti gettare in giro epiteti come "infilarti il ​​naso".
Lightness Races con Monica

7
@istheEnglishway, che ci crediate o meno che un esempio renda le cose più facili che dover leggere una pagina man (vedi anche: documentazione di StackOverflow)
Pierre.Sassoulas

32

Sto solo postando questo perché alcuni dei commenti lo hanno chiesto.

Quello che ho usato è stato (file da 15 GB). Ha funzionato molto velocemente e mi ha fatto risparmiare un sacco di tempo.

tail -f -c 14G file | grep something

Ho anche fatto un benchmark molto rudimentale sullo stesso file. Ho testato:

file grep xxx
// ha impiegato per sempre (> 5 minuti)

dd if = file bs = 1 skip = 14G | grep xxx
// molto veloce <1 sec

coda -c 14g | grep xxx
// abbastanza veloce <2 sec

il tailè solo un po 'più breve.

NB: il suffisso utilizzato ge Gdifferisce per comando (Ubuntu 15.10)


Hai cancellato la cache del disco tra i benchmark? Sospetto che la maggior parte delle volte nel primo caso fosse I / O. L'accelerazione dovrebbe essere dell'ordine di 15 ×, non di 300 ×.
Reid

2
@Reid non l'ho fatto. Ma ho eseguito ogni comando più volte. Sono abbastanza sicuro che dd o tail aumenteranno la velocità in modo significativo su grep (cache o no).
Roger,

19

Questo non risponde alla domanda sul titolo, ma farà quello che vuoi fare. Utilizzare tac per invertire il file, quindi utilizzare grep per trovare la stringa. Se la stringa si verifica solo una volta o un numero noto di volte nel file, lasciarla funzionare fino a quando non trova il numero noto di occorrenze. In questo modo, se la tua ipotesi su dove si trova nel file non è corretta, lo troverà comunque. Se vuoi limitarlo, puoi usare head per farlo. Il comando principale andrebbe tra il tac e il grep.

Quindi il comando appare come:

tac < logfile | grep myString

1
Sono venuto qui per scrivere la stessa identica risposta. Sono sorpreso che nessuno abbia votato per tuo.
Dmitry Grigoryev,

2
Mi ci è voluto un minuto, ma poi ho gemito al gioco ... tac è l'opposto del gatto.
Sammi,

1
Avevo bisogno di scavare in un registro di applicazione / debug . Perché inverte le righe, non sta diventando più facile da leggere ;-) Tuttavia, sembra molto veloce. Mai visto tac, quindi grazie!
Roger,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.