Что делает grep, когда не работает процессор?

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

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

Куда уходит все остальное время? Есть ли что-нибудь, что я могу сделать, чтобы он работал быстро каждый раз? (например, другой процесс читает файлы, прежде чем grepискать их.)

grep performance

— Alex
источник

Ответы:

Это довольно часто связано с кешем страниц .

В первый раз данные должны быть прочитаны (физически) с диска.

Второй раз (для не слишком больших файлов) он, скорее всего, будет сидеть в кеше страниц.

Таким образом, вы можете сначала выполнить команду вроде cat (1), чтобы вывести (не слишком большой) файл в кеш страницы (то есть в ОЗУ), затем вторая grep (1) (или любая программа, читающая файл) будет обычно работать быстрее ,

^{(однако данные все еще должны быть прочитаны с диска в какое-то время)}

Смотрите также (иногда полезно в ваших прикладных программах, но практически редко) readahead (2) & posix_fadvise (2) и, возможно, madvise (2) & sync (2) & fsync (2) и т. Д ....

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

Кстати, именно поэтому при тестировании программы рекомендуется запускать ее несколько раз. Кроме того, именно поэтому может быть полезно купить больше оперативной памяти (даже если вы не запускаете программы, использующие все это для своих данных).

Если вы хотите понять больше, прочитайте какую-нибудь книгу, например, « Операционные системы: три простых пьесы»

— Василий Старынкевич
источник

Итак, TL;DRответ: «[блок ожидает] ввода / вывода».

— mgarciaisaia

@PaulDraper Не совсем :) cat+ grepэто все равно займет больше времени, чем в grepодиночку.

— chepner

@chepner Если вы не можете многопоточность и использовать catв качестве дешевой предварительной выборки, пока вы делаете что-то еще, в рамках подготовки к grepинтересам.

— hBy2Py

@MarkKCowan: милые кошки! :-) ⁠

— G-Man говорит: «Восстанови Монику»

@ G-Man: Вы также можете заменить два из них catс tacтем же эффектом и более высоким использованием оперативной памяти: D Или все кошки с TAC

— Марк К Коуэн

-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-- похоже, мое объяснение верное-- мой комментарий с причиной получил возражение.

— Алекс

Я вижу, я добавил различие, которое не важно для того, что вы искали. OK. Кстати, я проголосовал за ваш комментарий, поэтому он не решает вопрос о причине голосования. :-)

— Уинстон Смит