☰

/proc/[PID]/io で memmap IO が無視される理由

tag-icon • tag-icon memory io proc
/proc/[PID]/io で memmap IO が無視される理由

/proc/[PID]/io と memmap に問題があります。 Pythonライブラリを使用してアプリケーションIOを分析する必要があります。スカイビジョン。
私が経験した問題の1つは、/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。

メモリマップされたファイルの入出力は大きく異なります。読み取り時にページエラー処理に依存し、パフォーマンスを向上させるための多くの最適化（先読みなど）があります。/proc/${pid}/stat（フィールド10と12）のページエラーを見ると、これをある程度追跡できます。難しい部分は、ページエラーごとに読み取られるデータ量を計算することです。私の実験ではエラーごとに64KiBを提案しましたが、それを裏付ける信頼できるデータが見つかりませんでした（状況によって異なる場合があります）。

私はプロセスの観点からマッピングされたI / Oを追跡する既成の方法を知りません（つまりブロックI / Oが実際に発生したかどうかにかかわらず、プロセスが読み取ったバイト数。

メモリマップされた読み取りの結果を正確に計算することは、やや難しい問題です。主に計算が意図を反映しなければならない方法によるものです。ioプログラムが読み書きすることを明示的に要求したバイト数を計算します。ただし、プロセスがファイルをメモリにマップすると、読み取り粒度は読み取りプロセスではなくカーネルによって決まります。 4KiBあたり1バイトしか読み取れず、カーネルはファイル全体を読み込みます。アカウントには何を反映すべきですか？プロセスは実際にメモリから読み取ったバイトを簡単に反映しないため、パフォーマンスに大きな影響を与えます（そしてすべてのアーキテクチャで実装することは不可能です）。

関連情報