Как правильно рассчитать время команд grep?


9

Я хочу сравнить скорость этих двух команд:

grep pattern1 files* 
grep pattern2 files* 

К сожалению, первый grep считывает большую часть файлов * в буферы памяти, поэтому второй grep работает очень быстро, но по неправильной причине.

Как мне сказать Linux (Fedora 11): «пожалуйста, прекратите кэширование чтения с диска, потому что я что-то тестирую».


Вероятно, есть более разумный ответ ... но вы можете продублировать структуру каталогов, чтобы не иметь дело с одним и тем же файлом и у вас не будет проблем с кэшированием!
Нико

1
Кроме того, Fedora 11 вышла из строя в июне 2010 года. Пора обновить. Предстоящий релиз Fedora 15 выглядит действительно красиво. Или, если вам нужно что-то более стабильное в течение более продолжительного срока службы (и это звучит так, как если бы вы все еще были на 11), есть RHEL6 или CentOS 6 в любой другой день.
mattdm

У меня ушло навсегда, чтобы перейти с RH 7.3 на это! Обновления ломают вещи и пугают меня.
Баррикартер

2
Отключив кеширование, вы оцените не скорость сопоставления с образцом, а скорость вашего диска. Как советуют другие, просто дважды выполните первую команду: сначала запустите кэш, затем - тест.
Алекс

Я попробую, но моя главная проблема - скорость диска ... жесткий диск сходит с ума, когда я запускаю grep. Хммм, хорошо, это может означать, что оптимизация grep может совсем не помочь ... Мне нужно оптимизировать объем данных, которые я извлекаю.
Баррикартер

Ответы:


11

Я не думаю, что вы можете легко сказать "временно прекратить кеширование". Но то, что вы можете сделать, это сказать системе удалять кеш перед каждым запуском:

Как корень:

sync; echo 3 > /proc/sys/vm/drop_caches

(Это описано в документации к ядру по адресу Documentation / sysctl / vm.txt , что удобно, если, как и некоторые из нас, вы не всегда можете вспомнить, что делают значения 1, 2 или 3.)

Или, альтернативно, конечно, заправьте кеш и сравните производительность в кеше. (Я думаю, что оба полезные числа.)


1
echo 1удалит только кеш страницы, а не кеш диска.
Jsbillings

@ jsbillings - ну да. Исправлена.
Mattdm

Невероятно незначительные придирки: я должен был сделать «>>», а не «>»
barrycarter

@ barrycarter: правда? да!
Mattdm

3
@barrycarter: вы, вероятно, установили -o noclobber в своей оболочке, что позволяет не использовать> для перезаписи существующего файла.
Jsbillings

1

При синхронизации таких вещей я обычно запускаю его сначала, чтобы заполнить кеш. Затем выполните команду, используя время. При тестировании чего-то подобного вам следует больше беспокоиться о процессоре и истекшем времени, а не о времени ввода-вывода.

В любом случае трудно получить полностью точные сроки. Если входные файлы превышают размер памяти, доступной для буферов, то вы, скорее всего, в конечном итоге зациклите все файлы через буферный кеш. В противном случае вы можете просто получить доступ ко всем данным из буферного кеша. В реальной жизни часто существует смесь буферизованных данных и данных, считываемых с диска.


IRL, я запускаю эту команду только изредка, поэтому содержимое файлов * никогда не кэшируется. Я пытаюсь оптимизировать grep для быстрого запуска в этой ситуации. Когда содержимое файлов * уже находится в кэше, оно запускается менее чем за секунду (нет смысла оптимизировать это, поскольку выходные данные предназначены для конечного пользователя)
barrycarter

2
@barrycarter. Если файлы не кэшируются, и они выполняются менее чем за секунду, то я не думаю, что вы найдете много возможностей для оптимизации. Перемещение файлов в более быстрое хранилище было бы вероятной оптимизацией.
BillThor
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.