☰

파이프 뷰어 - 진행률 모니터링 성능 결과

tag-icon • tag-icon text-processing performance cpu pv
파이프 뷰어 - 진행률 모니터링 성능 결과

많은 양의 데이터를 정렬하기 위해 배치 스크립트를 작성 중입니다. 모든 데이터는 텍스트이지만 스크립트를 실행하는 데 시간이 오래 걸립니다. 스크립트가 실행 중이라는 시각적 표시를 제공하고 싶습니다. 진행률 표시줄과 기타 멋진 진행률 표시기를 pv만들 수 있는 이 프로그램을 찾았습니다 .CLI

내 질문은 이와 같은 것이 성능에 어떤 영향을 미칠지, 그리고 바퀴를 재발명할 필요가 없는 다른 대안이 있는지입니다.

나는 그것을 검색했지만 성능이 중요한 장기 작업의 진행 상황만 표시할 것이라고 생각했기 때문에 놀라운 것을 찾지 못했습니다. 하지만 저는 클록 주기를 사용하고 있다고 생각합니다. 진행률을 표시하는 데 사용되는 주기 수와 상관없이 디스크 I/O 또는 네트워크 데이터 전송을 측정하는 데에도 사용할 수 있습니다.

어떤 아이디어가 있나요?

추신: 나는 또한 이 echo -ne트릭을 사용하여 나만의 것을 만드는 것에 대해 생각해 보았지만 실현 가능하게 하려면 %모든 루프에서 연산자를 사용하고 100번째 정도의 루프에서만 작업을 수행해야 하지만 이는 많은 작업이 될 것입니다. 폐기물 계산......

답변1

일반적으로 (부족)제로 카피파일을 직접 읽는 "작업자" 프로세스가 아닌 한 프로세스에서 다른 프로세스로 데이터를 복사하는 것은 추가 IPC로 인해 측정 가능한 오버헤드입니다. 파이프라인은 성능(또는 기능) 손실을 초래할 수도 있습니다.다른 이유들: 파이프 입력의 경우 프로세스는 seek()해당 입력을 사용할 수도 없고 사용할 수도 없습니다 mmap().

일반적으로 주요 성능 병목 현상은 아마도 디스크 I/O 및 CPU 계산 시간(귀하의 경우 집중적일 수 있음)일 것입니다. 이는 IPC보다 훨씬 비쌀 수 있지만많은여기에 있는 변수(CPU 유형, 디스크 유형그리고파일 시스템 유형, 사용 가능한 물리적 RAM, 운영 체제 및 버전, 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에서는 다음을 읽을 수 있습니다.각 프로세스에 대한 I/O 통계 /proc(3.3 참조)CONFIG_TASKSTATS( 커널에서 이 기능을 활성화 해야 합니다 ). 이는 간단하거나 유연하지는 않지만 pv오버헤드가 낮습니다. pidstat이를 사용하면 PID에 실시간 처리량(속도)을 표시하는 데 사용할 수 있지만 완료 표시기로서는 유용성이 떨어집니다.

비슷한 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

(경고: 작은 파일의 경우 정확하지 않습니다. libc stdio 버퍼링으로 인해 결과가 왜곡될 수 있습니다.)

지금 염두에 두고 있는 다른 옵션은 다음과 같습니다.

  • lsof사용된프로세스의 fd 오프셋을 모니터링합니다. 정확히 가볍지는 않지만 다중 플랫폼이며 사후에 장기 실행 프로세스에서 시작할 수 있지만 그렇게 할 수는 없습니다 ( 한 번에 크기와 편견을 제공하는 것을 거부하기 pv때문에 예쁘지도 않습니다 ). lsof양)

  • 데이터 읽기/쓰기를 추적하기 위한 일부 해킹 항목 LD_PRELOAD과 일부 스텁, 이것도 멀티 플랫폼이지만 직접 작성해야 할 것 같습니다(정확히 이 작업을 수행하는 항목은 없지만 여기에 하나가 있습니다).내 관련 답변)

  • 고쳐 쓰다:누군가 범용 전송 모니터링 도구를 작성하는 데 어려움을 겪었습니다.이력서그리고 사용핵심 도구Linux의 명령. 이는 /proc fdinfo이 방법과 유사한 논리를 사용합니다(위의 쉘 해킹에 표시됨). 또한 /proc를 검색하고 전송이 발견되면 진행 중인 전송을 보고하는 백그라운드 모드도 있습니다. 관련 질문 보기CP 속도와 복사 비율을 볼 수 있습니까?

답변2

이 명령을 사용한 상황에서는(주로 zfs 전송 및 수신 작업과 함께) pvCPU에 많은 오버헤드가 발생하지 않습니다. 아직 처리 중인지 알고 싶다면 pv이를 통해 전송된 데이터 수를 계산할 수 있습니다. 완료 시간을 추정하려면 처리할 데이터의 합계를 계산하는 사전 명령을 추가할 수 있습니다 pv -s <SIZE>. 이 사전 계산으로 인해 약간의 오버헤드가 발생할 수 있습니다.

관련 정보