Grep w ogromnym pliku dziennika (> 14 GB) tylko ostatnie x GB?

Muszę przeszukać coś w ogromnym pliku dziennika (ponad 14 GB). Jestem prawie pewien, że to ostatnie 4 GB.

Czy istnieje sposób na pominięcie pierwszego X GB, aby przyspieszyć?

linux log-files grep

— zrozumiałem
źródło

LC_ALL=C grepmoże to przyspieszyć.

— jfs

Będziesz mógł uzyskać dużą prędkość, wybierając rozsądne grepwyrażenie ... symbole wieloznaczne o nieznanej długości (np. a.*thing) W niektórych przypadkach będą trwać znacznie dłużej. Może się zdarzyć, że optymalizujesz pod kątem niewłaściwej rzeczy (chociaż wyszukiwanie części tylko pliku nigdy nie boli, oczywiście - może to nie być największe źródło przyspieszenia).

— Floris,

Odpowiedzi:

Wydaje mi się, że można użyć ogona tylko do wyjścia o pojemności około 4 GB za pomocą -cprzełącznika

-c, --bytes = [+] NUM wypisuje
ostatnie NUM bajtów; lub użyj -c + NUM, aby wypisać zaczynając od bajtu NUM każdego pliku

Prawdopodobnie możesz coś zrobić również z dd , ustawiając bs=1i skipustawiając przesunięcie, które chcesz zacząć np

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

— user9517 obsługuje GoFundMonica
źródło

Następnie powinieneś skonfigurować logrotate.

— Gerald Schneider,

@Rogier Dodaj odpowiedź z rozwiązaniem zamiast dodawać ją w swoim pytaniu. Jest to podobne do odpowiedzi własnej: serverfault.com/help/self-answer

— AL

@istheEnglishway: Cóż, nie, opublikowali inne polecenie.

— Lekkość ściga się z Moniką

Ale twoja odpowiedź nie zawiera rzeczywistego polecenia implementującego to rozwiązanie, które stanowi wartość dodaną. Możesz edytować to w swojej odpowiedzi lub OP może opublikować jako nową odpowiedź. Zdecydowanie nie powinni dodawać tego do pytania, co się stało. I zdecydowanie nie powinieneś rzucać się po epitetach takich jak „szturchanie nosem”.

— Lekkość ściga się z Moniką

@istheEnglishway, wierzcie lub nie mając przykładu, czynią rzeczy łatwiejszymi niż czytanie strony

— podręcznika

Po prostu to publikuję, ponieważ niektóre komentarze o to poprosiły.

To, czego ostatecznie użyłem, to (plik 15 GB). Działało bardzo szybko i oszczędzało mi mnóstwo czasu.

tail -f -c 14G file | grep something

Zrobiłem również bardzo podstawowy test porównawczy dla tego samego pliku. Testowałem:

plik grep xxx
// trwał wiecznie (> 5 minut)

dd if = plik bs = 1 pomiń = 14G | grep xxx
// bardzo szybko <1 sek

ogon-c 14g | grep xxx
// dość szybko <2 sek

tailjest tylko nieco krótszy.

Uwaga: sufiks stosowane gi Gróżnić w zależności od polecenia (Ubuntu 15.10)

— zrozumiałem
źródło

Czy wyczyściłeś pamięć podręczną dysku między testami porównawczymi? Podejrzewam, że większość czasu w pierwszym była we / wy. Przyspieszenie powinno być rzędu 15 ×, a nie 300 ×.

— Reid

@Reid nie zrobiłem. Ale uruchomiłem każde polecenie wiele razy. Jestem całkiem pewien, że dd lub tail znacznie przyspieszą prędkość po prostu grep (pamięć podręczna lub nie).

— Roger,

To nie odpowiada na pytanie tytułowe, ale zrobi to, co chcesz. Użyj tac, aby odwrócić plik, a następnie użyj grep, aby znaleźć swój ciąg. Jeśli ciąg znaków występuje w pliku tylko raz lub znaną liczbę razy, pozwól mu działać, dopóki nie znajdzie znanej liczby wystąpień. W ten sposób, jeśli twoje założenie dotyczące tego, gdzie jest w pliku, jest nieprawidłowe, nadal je znajdzie. Jeśli chcesz to ograniczyć, możesz użyć do tego głowy. Komenda główna będzie przechodzić między tac a grep.

Polecenie wygląda więc tak:

tac < logfile | grep myString

— Itsme2003
źródło

Przyszedłem tutaj, aby napisać dokładnie tę samą odpowiedź. Dziwię się, że nikt nie ocenił twojego.

— Dmitrij Grigoriew

Zajęło mi to chwilę, ale potem jęknąłem na kalambur ... tac jest przeciwieństwem kota.

— Sammi

Musiałem przekopać się w dzienniku aplikacji / debugowania . Ponieważ odwraca wiersze, jego czytanie nie jest łatwiejsze ;-) Wydaje się jednak bardzo szybkie. Nigdy nie widziałem tac, więc dzięki!

— Roger,