Що робить grep, коли не працює процесор?

Шукаючи матчі із grep, я часто помічаю, що наступний пошук займає значно менше часу, ніж перший - наприклад, 25s проти 2s. Очевидно, це не через повторне використання структур даних з останнього запуску - ті повинні були бути розміщені. Запускаючи timeкоманду grep, я помітив цікаве явище:

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

Куди йде інший час? Чи я можу щось зробити, щоб він кожного разу швидко працював? (наприклад, інший процес прочитав файли, перш ніж grepїх шукати.)

grep performance

— Олексій
джерело

Відповіді:

Він досить часто пов'язаний з кешем сторінок .

Перший раз дані потрібно читати (фізично) з диска.

Вдруге (для не надто великих файлів), ймовірно, він буде сидіти в кеш-пам'яті сторінки.

Таким чином, ви можете видати спочатку таку команду, як cat (1), щоб внести (не занадто великий) файл у кеш сторінки (тобто в оперативній пам'яті), тоді другий греп (1) (або будь-яка програма, що читає файл), як правило, працює швидше .

^{(однак, дані все-таки потрібно прочитати з диска на деякий час)}

Дивіться також (іноді корисне у ваших прикладних програмах, але практично рідко) читати (2) та posix_fadvise (2) та, можливо, madvise (2) та синхронізувати (2) та fsync (2) тощо.

Читайте також LinuxAteMyRAM .

BTW, тому рекомендується при порівняльному оцінюванні програми запускати її кілька разів. Крім того, саме тому може бути корисним придбати більше оперативної пам’яті (навіть якщо ви не запускаєте програми, використовуючи все це для своїх даних).

Якщо ви хочете зрозуміти більше, прочитайте книгу, наприклад, Операційні системи: Три простих п’єси

— Базиль Старинкевич
джерело

Отже, TL;DRвідповідь - "[блок очікування] I / O".

— mgarciaisaia

@PaulDraper Насправді :) cat+ grepще триватиме більше часу, ніж grepодин.

— чепнер

@chepner Якщо ви не можете перечитати багато сторінок і використовувати catяк дешевий попередній збір, роблячи щось інше, підготувавшись для grepінтересу.

— hBy2Py

@MarkKCowan: Прекрасні коти! :-) ⁠

— G-Man каже: "Відновіть Моніку"

@ G-Man: Ви також можете замінити два cats tacна той самий ефект та більшу кількість оперативної пам’яті: D Або всіх котів з tac

— Mark K Cowan

-1

У мережевому середовищі зберігання даних також можуть бути відносно значні затримки, коли ви вперше отримаєте доступ до файлу, який знаходиться на "файлі", окремо від сервера. Після того, як цей файл буде доступний на сервері, він буде кешований локально і подальший доступ до даних буде набагато швидшим.

Ось експеримент просто обчислення контрольної суми даних файлу - не grep. Перша виклик повільна, а наступні - швидкі.

> 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

— Вінстон Сміт
джерело

Буду вдячний за коментарі для downvote (s), тому що я не знаю, як їх інтерпретувати. Я вважаю, що моя відповідь є правильною. Можливо, приклад команди не зрозумілий? Або вам не подобається, що я не оцінював команду grep? (Я навмисно використовував більш просту команду, md5sum, щоб спробувати проілюструвати свою думку.)

— Вінстон Сміт

Я думаю, що причина полягає в тому, що ваш пост не додав нової інформації, що стосується того, про що я питав. Я вже знав, що відбувається затримка, і перша відповідь вже дала пояснення, чому це відбувається. Але так, я також отримую посилання без пояснень. Навіть на запитання з гарними відповідями.

— Алекс

Дякуємо @Alex, що запропонував причину. Я намагався розрізнити між накладним часом переміщення даних з локального сховища в пам'ять, який описала перша відповідь, і накладним часом переміщення даних з мережевого сховища на локальний сервер. Я подумаю, чи зміг би я описати це більш чітко або навести кращі приклади команд.

— Вінстон Сміт

Думаю, після прочитання вашої публікації, на мій погляд, це все-таки накладні витрати на переміщення даних, звідки вони зберігаються, до пам'яті. Будь то з мережевого або локального сховища, не має значення - Unix все ще сприймає це як переміщення з каталогу в пам'ять. ps-- схоже, що моє пояснення правильне-- мій коментар із причиною отримав позитивну позицію.

— Алекс

Я бачу, я додав відмінність, не важлива для того, що ви шукали. ДОБРЕ. До речі, я підтримав ваш коментар, тож це не вирішує питання про прихильність. :-)

— Вінстон Сміт