Frage Grep in einer riesigen Logdatei (> 14 GB) nur die letzte x GB?


Ich muss etwas in einer riesigen Protokolldatei suchen (über 14 GB). Ich bin mir ziemlich sicher, dass es in den letzten 4 GB oder so ist.

Gibt es eine Möglichkeit, das erste X GB zu überspringen, um die Dinge zu beschleunigen?


34
2018-01-31 08:31


Ursprung


LC_ALL=C grep kann es beschleunigen. - jfs
Sie werden eine Menge Geschwindigkeit bekommen, indem Sie ein vernünftiges auswählen grep Ausdruck ... Wildcards unbekannter Länge (wie a.*thing) wird in manchen Fällen sehr viel länger dauern. Es kann sein, dass Sie für die falsche Sache optimieren (obwohl es nie weh tut, nur einen Teil der Datei zu suchen, offensichtlich - es kann einfach nicht die größte Quelle der Beschleunigung sein). - Floris


Antworten:


Ich schätze, du könntest es benutzen Schwanz um nur die letzten 4GB oder so auszugeben, indem Sie die -c Schalter

-c, --bytes = [+] NUM
  Ausgabe der letzten NUM Bytes; oder verwenden Sie -c + NUM, um beginnend mit dem Byte NUM jeder Datei auszugeben

Du könntest wahrscheinlich etwas damit anfangen dd auch durch Einstellung bs=1 und skipB. zu dem Offset, den Sie starten möchten, z.

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

75
2018-01-31 08:41



Danach sollten Sie logrotate konfigurieren. - Gerald Schneider
@ Rogier Bitte fügen Sie eine Antwort mit der Lösung hinzu, anstatt sie in Ihre Frage einzufügen. Dies ist vergleichbar mit der Selbstantwort: serverfault.com/help/self-answer - A.L
@istheEnglishway: Nun, nein, sie haben einen anderen Befehl gepostet. - Lightness Races in Orbit
Aber Ihre Antwort enthält nicht den eigentlichen Befehl, der diese Lösung implementiert, was einen Mehrwert darstellt. Sie könnten das in Ihre Antwort ändern, oder das OP könnte es als neue Antwort veröffentlichen. Sie sollten es definitiv nicht zur Frage hinzufügen, was passiert ist. Und Sie sollten auf keinen Fall umhauen wie "Nase reinstecken". - Lightness Races in Orbit
@istheEnglishway, glaube es oder nicht, ein Beispiel zu haben, mache die Dinge einfacher als eine Manpage lesen zu müssen (siehe auch: stackoverflow-Dokumentation) - Pierre.Sassoulas


Ich poste das nur, weil einige der Kommentare danach gefragt haben. 

Was ich am Ende benutzt habe, war (15 GB Datei). Es hat sehr schnell funktioniert und mir eine Menge Zeit gespart.

tail -f -c 14G file | grep something

Ich habe auch einen sehr rudimentären Benchmark für die gleiche Datei erstellt. Ich habe getestet:

grep xxx-Datei
  // nahm für immer (> 5 Minuten)

dd if = Datei bs = 1 überspringen = 14G | Grep xxx
  // sehr schnell <1 sek

Schwanz -c 14g | Grep xxx
  // ziemlich schnell <2 sek

das tail ist nur ein bisschen kürzer.

NB: das verwendete Suffix g und G unterscheiden sich per Befehl (Ubuntu 15.10)


32
2018-02-01 10:08



Haben Sie den Festplatten-Cache zwischen den Benchmarks gelöscht? Ich vermute die meiste Zeit in der ersten war I / O. Die Beschleunigung sollte in der Größenordnung von 15 × und nicht 300 × liegen. - Reid
@Reid habe ich nicht. Aber ich bin gelaufen jeder Befehl mehrmals. Ich bin mir ziemlich sicher, dass dd oder Schwanz wird die Geschwindigkeit deutlich steigern Grep (Cache oder nicht). - Roger


Dies beantwortet nicht die Titelfrage, aber es wird tun, was Sie tun möchten. Verwenden Sie tac, um die Datei umzukehren, und verwenden Sie dann grep, um Ihre Zeichenfolge zu finden. Wenn Ihre Zeichenfolge nur einmal oder in der Datei bekannt ist, lassen Sie sie laufen, bis sie die bekannte Anzahl von Vorkommen findet. Auf diese Weise, wenn Ihre Annahme, wo es in der Datei ist falsch ist, wird es immer noch finden. Wenn Sie es begrenzen möchten, können Sie head verwenden, um das zu tun. Der Kopfbefehl würde zwischen dem Tac und dem Grep gehen.

Der Befehl sieht also so aus:

tac < logfile | grep myString

20
2018-02-01 05:02



Ich kam hierher, um genau dieselbe Antwort zu schreiben. Ich bin überrascht, dass niemand deine diktiert hat. - Dmitry Grigoryev
Nahm mich eine Minute, aber dann stöhnte ich auf das Wortspiel ... Tac ist das Gegenteil von Katze. - Sammi
Ich musste in einem Anwendung / Debug-Protokoll. Weil es die Linien umkehrt, wird es nicht einfacher zu lesen ;-) Scheint jedoch sehr schnell. Niemals gesehen tac, so danke! - Roger