☰

/proc/[PID]/io에서 memmap IO가 무시되는 이유

tag-icon • tag-icon memory io proc
/proc/[PID]/io에서 memmap IO가 무시되는 이유

/proc/[PID]/io 및 memmap에 문제가 있습니다. Python 라이브러리를 사용하여 애플리케이션 IO를 분석해야 합니다.스카이비전.
내가 겪은 문제 중 하나는 /proc/[PID]/io.io에서 IO가 읽고 쓴 총 바이트 수가 올바르지 않다는 것입니다.

스크립트가 있습니다 copy.sh.

#!/bin/bash
cp huge.fits huge.2.fits
#python copyfits.py
#python copyfitsMemmapOFF.py
sleep 5 
cat /proc/$$/io

cp나는 해당 줄과 각 테스트에 대해 실행하고 싶은 줄을 주석 처리했습니다 .

copyfits.py포함하다:

from astropy.io import fits    
hdulist = fits.open('huge.fits', mode='readonly')
hdulist.writeto('huge.2.fits')
hdulist.close()

copyfitsMemmapOFF.py포함하다:

    from astropy.io import fits    
    hdulist = fits.open('huge.fits', mode='readonly', memmap=False)
    hdulist.writeto('huge.2.fits')
    hdulist.close()

각 솔루션에 대한 IO 결과는 다음과 같습니다.

cp huge.fits huge.2.fits

rchar: 9749929202
wchar: 9749551680

python copyfits.py

**rchar: 8399421**
wchar: 9749551685

python copyfitsMemmapOFF.py

rchar: 9757502959
wchar: 9749551685

내가 이해한 바에 따르면 memmap을 끄면 이 변수를 사용하여 응용 프로그램이 파일을 읽는 정도를 모니터링할 때 일관성 없는 IO 결과가 발생할 수 있습니다. memmap이 어떻게 표준 IO에 포함되지 않는 이유는 무엇이며 해당 IO를 어떻게 찾을 수 있습니까?
응용 프로그램 대신 커널에서 파일을 읽는 경우에도 파일에 계속 액세스할 수 있기 때문입니다.

답변1

/procio"명시적" I/O만 추적됩니다 .즉적은 수의 시스템 호출을 사용하여 I/O를 수행합니다. 읽기의 경우 read, readv, 및 입니다 . 다음을 사용하여 누적된 통계를 볼 수 있습니다 preadv.sendfilecopy_file_rangeadd_rchar존재하다fs/read_write.c.

메모리 매핑된 파일의 I/O는 많이 다릅니다. 읽을 때 페이지 오류 처리에 의존하며 성능을 향상시키기 위한 많은 최적화(미리 읽기 등)가 있습니다. /proc/${pid}/stat(필드 10 및 12)의 페이지 오류를 보면 이를 어느 정도 추적 할 수 있습니다 . 어려운 부분은 페이지 오류당 읽혀지는 데이터의 양을 계산하는 것입니다. 내 실험에서는 오류당 64KiB를 제안했지만 이를 뒷받침할 수 있는 신뢰할 수 있는 데이터를 찾지 못했습니다(상황에 따라 다를 수 있음).

나는 프로세스 관점에서 매핑된 I/O를 추적하는 기성 방법을 알지 못합니다(즉블록 I/O가 실제로 발생했는지 여부에 관계없이 프로세스로 읽은 바이트 수입니다.

메모리 매핑된 읽기의 결과를 정확하게 계산하는 것은 다소 까다로운 문제입니다. 주로 계산이 의도를 반영해야 하는 방식 때문입니다. io프로그램이 읽거나 쓰도록 명시적으로 요청한 바이트 수를 계산합니다. 그러나 프로세스가 파일을 메모리에 매핑할 때 읽기 세분성은 읽기 프로세스가 아닌 커널에 의해 결정됩니다. 4KiB당 1바이트만 읽을 수 있으며 커널은 전체 파일을 읽습니다. 계정에는 무엇을 반영해야 합니까? 프로세스가 실제로 메모리에서 읽은 바이트를 쉽게 반영하지 못하므로 성능에 큰 영향을 미칩니다(그리고 모든 아키텍처에서 구현하는 것은 불가능합니다).

관련 정보