Насколько я понимаю, размеры клавиш ограничены 2 гигабайтами. Это означает, что максимальный объем данных, которые вы можете сохранить при заданном ключе, составляет 2 гигабайта. Все значения String ограничены 512 MiB.
http://redis.io/topics/data-types
http: // groups.google.com/group/redis-db/browse_thread/thread/1c7e33fbc98734b3?fwc=2
Включите режим буферизации строк grep
при использовании BSD grep (FreeBSD, Mac OS X и т. д.)
tail -f file | grep --line-buffered my_pattern
Вам не нужно делать это для GNU grep (используется на почти любой Linux), поскольку он по умолчанию будет скрываться (YMMV для других Unix-подобных, таких как SmartOS, AIX или QNX).
Используйте awk (еще одна большая утилита bash) вместо grep, где у вас нет опции для буферизации строк! Он будет непрерывно передавать ваши данные из хвоста.
так вы используете grep
tail -f <file> | grep pattern
Вот как вы будете использовать awk
tail -f <file> | awk '/pattern/{print $0}'
{print $0}
является избыточным, так как печать является действием по умолчанию при выполнении условия.)
– tripleee
9 February 2015 в 15:00
Да, на самом деле все будет хорошо. Grep
, и большинство команд Unix работают по потокам по одной строке за раз. Каждая строка, которая выходит из хвоста, будет анализироваться и передаваться, если она соответствует.
grep
является последней командой в цепочке труб, она будет действовать, как вы объясните. Однако, если он посередине, он будет буферизовать примерно 8 кбайт одновременно.
– Mahmoud Al-Qudsi
18 February 2016 в 01:52
sed будет правильной командой ( stream editor)
tail -n0 -f <file> | sed -n '/search string/p'
, а затем, если вы хотите, чтобы команда tail вышла, как только вы нашли определенная строка:
tail --pid=$(($BASHPID+1)) -n0 -f <file> | sed -n '/search string/{p; q}'
Очевидно, что багизм: $ BASHPID будет идентификатором процесса команды tail. Команда sed следующая после хвоста в трубе, поэтому идентификатор процесса sed будет $ BASHPID + 1.
$BASHPID+1
), будет во многих ситуациях ложным, и это не помогает решить проблему буферизации, которая, вероятно, пытается спросить OP. В частности, рекомендация sed
по сравнению с grep
здесь кажется просто вопросом (сомнительным). (Вы можете получить p;q
поведение с grep -m 1
, если это то, что вы пытаетесь выполнить.)
– tripleee
16 August 2017 в 09:17
В большинстве случаев вы можете tail -f /var/log/some.log |grep foo
, и он будет работать нормально.
Если вам нужно использовать несколько grep в работающем файле журнала, и вы обнаружите, что вы не получаете выход, вам может понадобиться вставьте переключатель --line-buffered
в средние grep (s), например:
tail -f /var/log/some.log | grep --line-buffered foo | grep bar
Не видел, чтобы кто-то предлагал мои обычные варианты:
less +F <file>
ctrl + c
/<search term>
<enter>
shift + f
Я предпочитаю это, потому что вы можете использовать ctrl + c
, чтобы останавливать и перемещаться по файлу всякий раз, а затем просто нажмите shift + f
, чтобы вернуться к текущему потоковому поиску.
Я все время использую tail -f <file> | grep <pattern>
.
Он будет ждать до тех пор, пока grep не начнет снижаться, пока он не закончится (я использую Ubuntu).
Если вы хотите найти совпадения в файле whole (а не только в хвосте), и вы хотите, чтобы он сидел и ждал новых совпадений, это прекрасно работает:
tail -c +0 -f <file> | grep --line-buffered <pattern>
Флаг -c +0
указывает, что выход должен начинаться с 0
байт (-c
) с начала (+
) файла.
вы можете рассмотреть этот ответ как улучшение .. Обычно я использую
tail -F <fileName> | grep --line-buffered <pattern> -A 3 -B 5
-F лучше в случае поворота файла (-f не будет работать должным образом, если файл повернут)
-A и -B полезно для получения строк непосредственно перед и после появления шаблона. Эти блоки появятся между разделителями пунктирных линий
grep -C 3 <pattern>
, заменяет -A & lt; N & gt; и -B & lt; N & gt; если N равно.
– Arun Sangal
2 March 2017 в 01:45
Я думаю, что ваша проблема в том, что grep использует некоторую буферизацию вывода. Попробуйте
tail -f file | stdbuf -o0 grep my_pattern
, он установит режим буферизации вывода grep в небуферизованный.
grep
.
– Peter V. Mørch
5 July 2012 в 12:08
unbuffer
(в пакете expect-dev
на debian) king i >. Поэтому я бы использовал unbuffer поверх stdbuf.
– Peter V. Mørch
7 July 2012 в 20:41
top
с stdbuf и unbuffer). И на самом деле нет «волшебного» решения: иногда небуффер не работает, например, awk использует другую реализацию буфера (stdbuf тоже не сработает).
– XzKto
9 July 2012 в 08:48
stdbuf
, `unbuffer и stdio буферизации в pixelbeat.org/programming/stdio_buffering
– Tor Klingberg
27 April 2015 в 14:45
strace
. Без--line-buffered
это не сработает. – sjas 11 September 2016 в 22:22tail -f | grep
, а--line-buffered
решает ее для меня (на Ubuntu 14.04, GNU grep версии 2.16). Где «использовать буферизацию строки», если stdout является tty ». логика реализована? В git.savannah.gnu.org/cgit/grep.git/tree/src/grep.c ,line_buffered
задается только парсером аргументов. – Aasmund Eldhuset 9 January 2017 в 23:21--line-buffered
Я не получаю никакого вывода. Однако, после тестирования, похоже, что GNU grep делает то, что вы описываете. Так что, как и большинство Unix, это зависит от реализации вашей платформы. Поскольку в вопросе не указана платформа, ваша информация оказывается ложной - после просмотра кода для BSD grep и сравнения его с GNU grep поведение определенно контролируется опцией -line-buffered. Просто по умолчанию только GNU grep сбрасывается. – Richard Waite 28 October 2017 в 22:37