cmpコマンドを完了するのにかかる時間はなぜこのように変化しますか?

cmpコマンドを完了するのにかかる時間はなぜこのように変化しますか?

このcmpコマンドを使用して、SDカードに保存されている1GBファイルとメインメモリに保存されている参照1GBファイルを比較します。個々のcmpコマンドの完了時間は17秒から3.5分まで非常に多様でした。

ファイルは同じであると予想され、これまですべての場合で同じでした。 SDカードにある100個の1GBファイルをメインメモリに保存されている参照1GBファイルと比較する機能(下記参照)を実行します。通常、cmpループ内のすべての100は、スクリプト期間中に高速(20秒未満)の遅い傾向があります。

出力によるtopと、時間がかかるほど持続時間が長くなるプロセスは観察されません。

コマンド完了時間がcmp変わる原因は何ですか?

また、コマンドが合理的な時間(25秒未満)で完了するようにするにはどうすればよいですか?

これは、組み込みアプリケーションのYocto展開で発生します。

function check_files() {
    for filename in /mnt/Android/data/File_*;
    do
        echo "Checking $filename"
        result=$(cmp -l /data/1GB_File.bin $filename)
        resultlength=${#result}
        if [ $resultlength -gt 0 ]; then
            date >> /data/errors.txt
            echo $filename >> /data/errors.txt
            echo $result >> /data/errors.txt
            echo "==========" >> /data/errors.txt
        fi
    done
}

ベストアンサー1

アプローチを再設計することをお勧めします。あなたの方法は/data/1GB_File.bin引き続き読まれます/mnt/Android/data/File_*

「ディスクキャッシュ」は通常、ディスクI / Oを高速化するのに役立ちますが、ファイルサイズは1 GBで、ループの2〜N回目にキャッシュされたデータ(/data/1GB_File.bin)と新しいデータ(キャッシュされた)データ要求がインターリーブされます。ただし、データ(ディスクブロックサイズのメモリチャンク)は、「最も最近使用された」(「古いものから」)アルゴリズムを介してキャッシュから削除されるため、キャッシュされたデータを強制する新しいデータと以前にキャッシュされたデータの読み取り(変更変更)の間の競争です。 LRUリストの場所)。また、一般的なシステムアクティビティではディスクキャッシュを使用します。

ディスクキャッシュが「一般システム使用量」に2 x 1 GBを足した値より大きくない場合は、常に競合とそれに応じたタイミングの変化に直面します。

各ファイルのチェックサムと標準を計算します。各ファイルは一度だけ読む必要があります。チェックサムと比較してみてください。

読むman md5sum、次のことをする未テスト:

check_files() {
    md5sum /mnt/Android/data/File_* >data.tmp
    md5dum /data/1GB_File.bin >standard.tmp
    #
    # extract the "correct" checksum 
    golden="$(cut -d" "   f1 standard.tmp)"
    #
    # do any of the suspect files not 
    # have the golden checksum?
    grep -v "$golden" data.tmp >bad.tmp
    if [[ $? -eq 0 ]]; then
        (date;cat bad.tmp;echo "==========" )>> /data/errors.txt
    fi
    #uncomment the `rm` line when you're sure it works
    # can test with adding any other filename
    # to the first `md5sum` line.
    #rm -f standard.tmp data.tmp bad.tmp 2>/dev/null
    # why not return a status from this function?
}
  
 

おすすめ記事