Средство просмотра канала - последствие производительности монитора Прогресса

Обычно (при отсутствии хитрости нулевой копии ) можно измерить накладные расходы за счет дополнительного IPC: копирования данных из одного процесса в другой, а не непосредственного чтения файлов "рабочей лошадки". Конвейер может также привести к потере производительности (или функциональности) по другим причинам : с помощью конвейерного ввода процесс не может искать() на своем входе, и не может mmap() на своем входе.

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

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

# time ( pv -pt somethinglarge.iso | sha256sum )
[...]
real    0m8.066s
user    0m5.146s 
sys     0m1.075s

# time ( sha256sum somethinglarge.iso )
[...]
real    0m7.913s
user    0m5.064s
sys     0m0.309s

Обратите внимание на сходные реальное и пользовательское время, а также заметное увеличение времени системы для случая с конвейером за счет дополнительного копирования.

На некоторых ОС, в частности Linux, вы можете прочитать статистику входов/выходов для каждого процесса из /proc (см. 3.3) (для этого вам понадобится CONFIG_TASKSTATS, включенный в ядре). Это не так просто и не так гладко, как pv, но это низко над головой. pidstat использует это, его можно использовать для отображения пропускной способности (скорости) ПИД-регулятора в реальном времени, но он менее полезен в качестве индикатора завершения.

Аналогичный вариант linux (для этого не нужен CONFIG_TASKSTATS), при наличии дескриптора процесса и файла, можно отследить смещение дескриптора файла в поле /proc/PID/fdinfo/FD (поле pos:). Вот игрушечный скрипт, который показывает следующее:

FILE=/tmp/some-large-input
SZ=$(stat -c "%s" "$FILE")

# start slow process in background
( some-slow-command $FILE ) &
PID=$!
FD=/proc/$PID/fdinfo/3       # some experimentation required
# or iterate over /proc/$PID/fd/* with readlink 

# start %-ometer in background, exits when FD disappears
(
while nawk '/^pos:/{printf("%i\n",$2*100/'$SZ')}' $FD 2>/dev/null ; do
    sleep 5  # adjust
done | dialog --gauge "$PID: processing $FILE ($SZ bytes)" 10 60
) &

wait $PID
if [ $? -eq 0 ]; then
    echo 100 | dialog --gauge "$PID: completed $FILE ($SZ bytes)" 10 60
else 
    echo ...
fi

(Caveat: неточно для маленьких файлов, буферизация libc будет искажать результаты)

Другие опции, которые приходят мне в голову прямо сейчас:

• используйте lsof для мониторинга смещений fd процессов. не совсем легкая, но мультиплатформенная, и вы можете запускать ее на любом длительном процессе после того, что вы не можете сделать с pv (это тоже некрасиво, так как lsof отказывается дать и размер, и смещение за один раз)

• что-то хакерское с LD_PRELOAD и некоторыми заглушками, которые отслеживают чтение/запись данных, это тоже мультиплатформенность, но я думаю, что вы должны написать свое (я не знаю ни одной, которая делает именно это, но вот соответствующий ответ моего)

• Обновление: кто-то столкнулся с проблемой написания утилиты для мониторинга переноса общего назначения cv для использования с командами coreutils под Linux. Он использует логику, аналогичную подходу /proc fdinfo (как показано в примере взлома оболочки выше). Он также имеет фоновый режим, в котором сканирует /proc и сообщает о выполняющихся передачах по мере их нахождения. См. соответствующий вопрос Можно ли увидеть скорость cp и процент копирования?