Зігніть у величезному лог-файлі (> 14 ГБ) лише останній x ГБ?


34

Мені потрібно щось шукати у величезному лог-файлі (понад 14 ГБ). Я впевнений, що це в останні 4 Гб або близько того.

Чи є спосіб пропустити перший X ГБ, щоб прискорити роботу?


7
LC_ALL=C grepможе прискорити його.
— jfs

1
Ви зможете отримати велику швидкість, вибравши розумний grepвираз ... макіяжів невідомої довжини (як a.*thing) у деяких випадках буде потрібно набагато більше часу для оцінки. Можливо, ви оптимізуєте неправильну річ (хоча ніколи не зашкодить шукати лише частину файлу, очевидно - це просто не може бути найбільшим джерелом прискорення).
— Флоріс

Відповіді:


75

Я думаю, ви можете використовувати хвіст, щоб вивести лише останні 4 Гб або за допомогою -cперемикача

-c, --байт = [+] NUM
виводить останні NUM байт; або використовувати -c + NUM для виводу, починаючи з байта NUM кожного файлу

Ви, ймовірно, могли б зробити щось і з dd , встановивши bs=1і skipзмініть на зсув, який ви хочете почати, наприклад

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

83
Після цього слід налаштувати логротат.
— Джеральд Шнайдер

3
@Rogier Будь ласка, додайте відповідь із рішенням, а не додайте його у своєму запитанні. Це схоже на самовідповідь
— AL

5
@istheEnglishway: Ну ні, вони написали іншу команду.
— Легкі перегони з Монікою

11
Але ваша відповідь не дає фактичної команди, яка реалізує це рішення, що є додатковою вартістю. Ви можете відредагувати це у своїй відповіді, або ОП може опублікувати це як нову відповідь. Вони, безумовно, не повинні додавати це до питання, що саме сталося. І вам точно не слід кидати епітети на кшталт "засунути ніс".
— Легкі перегони з Монікою

7
@istheEnglishway, вірите чи не маючи приклад, це полегшує справи, ніж читати чоловічу сторінку (див. також:
— stackoverflow

32

Я просто публікую це, тому що деякі коментарі вимагали цього.

Що я в кінцевому підсумку використовував (15 ГБ файл). Це спрацювало дуже швидко і врятувало мені тону часу.

tail -f -c 14G file | grep something

Я також зробив дуже рудиментарний орієнтир у тому ж файлі. Я тестував:

файл grep xxx
// тривав назавжди (> 5 хвилин)

dd, якщо = файл bs = 1 пропуск = 14G | grep xxx
// дуже швидко <1 сек

хвіст -c 14г | grep xxx
// досить швидко <2 сек

tailтільки трохи коротше.

Примітка: суфікс, який використовується gта Gвідрізняється в команді (Ubuntu 15.10)


Чи очистили кеш диска між орієнтирами? Я підозрюю, що більшість часу в першому був I / O. Швидкість руху повинна бути порядку 15 ×, а не 300 ×.
— Рейд

2
@Reid я цього не зробив. Але я виконував кожну команду кілька разів. Я впевнений, що dd або хвіст значно підвищить швидкість, ніж просто grep (кеш чи ні).
— Роджер

19

Це не відповідає на заголовкове запитання, але воно зробить те, що ви хочете зробити. Використовуйте tac, щоб повернути файл, а потім натисніть grep, щоб знайти рядок. Якщо ваш рядок виникає лише один раз або відома кількість разів у файлі, тоді нехай він працює, поки не знайде відоме число подій. Таким чином, якщо ваше припущення про те, де він знаходиться у файлі, є невірним, воно все одно знайде його. Якщо ви хочете обмежити це, ви можете скористатися головою для цього. Команда head переходитиме між tac та grep.

Отже команда виглядає так:

tac < logfile | grep myString

1
Я прийшов сюди, щоб написати таку саму відповідь. Я здивований, що ніхто не звернувся до твого.
— Дмитро Григор’єв

2
Взяв мене хвилину, але потім я застогнав на каламбур ... tac - це протилежність коту.
— Саммі

1
Мені потрібно було копатись у журналі програми та / налагодження . Оскільки він обертає рядки, читати його не стає простіше ;-) Однак здається дуже швидким. Ніколи не бачив tac, тому дякую!
— Роджер
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.