USBに保存されている1GB ISOファイルの内容を内部ストレージにコピーしようとしています。テストの一環として、USBからハードドライブへの繰り返しコピー操作を続けると、時にはCPUの停止が発生し、システムがいくつかの重要なネットワークパケットを見逃したり、他の重要なタスクを妨げることがわかりました。
私が従ったステップ：
- ISO（ISO-9660）をHDDのフォルダの1つにマウントします。
- その後、MountedフォルダからHDDの他のフォルダにコピーを開始します。
- コピーが完了したら。コピーしたフォルダを削除してください。
- 10秒待ってからプロセスを再開してください。
copy、、、rsyncコマンドを使ってみましたdd。そしてcopy何のrsync結果も得られませんでした。ただし、ddコマンドを直接使用すると、パフォーマンスがさらに向上する可能性があります。ただし、残念ながら読み取り専用ファイルシステムなので、マウントされたディレクトリから直接使用することはできません。
私はisoを読み書き可能なファイルシステムにするためにいくつかの方法を探しましたが、ISO-9660ファイル形式は読み取り専用ファイルシステムとして設計されているようです。
directオプションはキャッシュを避け、I / Oに直接アクセスするためです。 /proc/sys/vm/dirty_backgroud_bytes および /proc/sys/vm/dirty_bytes をそれぞれ 500000 および 550000 に設定して、同じ動作を模倣しようとしました。しかし、数時間後に失敗しました。
その後、hdparamツールを使用してハードドライブのキャッシュを無効にしてからコピーしようとしました。しかし、これは失敗につながりました。
使用されたコマンド：
Rsync: rsync --recursive --bwlimit=1024 <src dir> <target dir>
Copy : cp -a <src dir> <target dir>
find the folders the in the directory and copy it one by one
dd: dd if=<src file> of=<target file> conv=notruc iflag=direct oflag=direct
CPU停止をどのように測定しますか？
ターゲットマシンに向かうネットワークをキャプチャし、特定の時間にこれらのネットワークパケットを予測し、Softirqを生成するアプリケーション（最も高い優先順位でユーザースペースで実行）を持っています。したがって、ネットワークパケットが自分のシステムに到着していてアプリケーションが割り込みを生成しない場合は、カーネルトレースを確認すると、待ち行列のカーネル呼び出しによって受信されたネットワークパケットがまだアプリケーションに到達していないことがわかります。
kmem_cache_alloc
Kmem_K_alloc
rcu_utilization
kmem_kfree
kmem_cache_free
ext4_ind_map_blocks_exit
ext4_da_予約スペース
kmem_mm_page_free_direct
kmem_mm_page_alloc --> 14回連続呼び出し
kmem_mm_page_alloc_zone_locked --> 12回連続呼び出し
kmem_mm_page_alloc再び - >連続8回呼び出し
ext3_get_blocks_enter
ext3_get_blocks_exit
ext4_da_write_begin --> 頻繁に発生するが連続的ではない ext4_da_write_end --> 頻繁に発生するが連続的ではない ext4_ind_map_blocks_enter --> 頻繁に発生するが連続的ではない ext4_mark_inode_dirty --> 頻繁に発生するが連続的ではない
この質問と次の質問に関する洞察を共有できますか？
それでは、このような停止（キャッシュ）が発生する原因は何ですか？それを避ける方法はありますか？
それでは、directフラグを使用してマウントされたフォルダ（読み取り専用）からターゲットフォルダにコピーする方法はありますか？
コピーするディレクトリには読み取りおよび書き込み権限がありますが、何らかの理由でoflag = directも機能しません。
読み取りおよび書き込み権限を持つisoを準備する方法はありますか？
答え1
ネットワークプロセスのI / Oレイテンシを減らすためにいくつかの方法があります。ユースケースに応じて、唯一のオプションはリアルタイムカーネルに切り替えることです。Linux用PREEMPT_RTパッチ。理由については、下記をご覧ください。しかし、これは非常に極端な方法なので、まず他の方法を試してみてください。
- ネットワークプロセスとレプリケーションプロセスのI / O優先順位を調整するには、次のコマンドを使用します。イオアニス
mount -o syncキャッシュを無効にするには、ファイルシステムをマウントします。directまたはI / Oを使用している場合は、syncこのコマンドを使用してブロックサイズを変更してみてくださいdd。おそらく、非常に大きいか非常に小さいチャンクが良い選択かもしれません、例えばページサイズと一致するチャンクサイズであるかもしれませんが、これは推測だけです。
リアルタイムカーネル
要件によっては、これが唯一の実行可能なオプションである可能性があります。説明します。あなたは書く:
ターゲットマシンに行くネットワークをキャプチャし、特定の時間にこれらのネットワークパケットを予測するアプリケーション（優先順位の高いユーザースペースで実行）があります。
問題を診断するにはいくつかのことが必要です。例：パッケージが「失われた」と見なされる期間はどのくらいですか？どのくらいのパケット損失が許されますか？これは、期限が500μsか500msか、そしてパケットの5％または0.05％が遅延するか「失われる」ことを許可されるかによって、大きな違いを生み出します。
ただし、タイムウィンドウに関係なくリアルタイム（RT）カーネルを実行しない限り、この要件を100％満たすことはできません。 「リアルタイム」という用語は、特定のイベント（たとえば、着信ネットワークパケット）に反応するのにかかる時間を具体的に保証することを意味します。
一般（非リアルタイム）Linuxカーネルは次のことを行います。そのような保証はありません。したがって、キャッシュや目的のタスクなど、現在重要と見なされるタスクを実行している間、ユーザー空間全体を数秒間ブロックすることもできます。ユーザー空間の優先順位に関係なく。したがって、何をしても、コンピュータがネットワークパケットを待つ以外の作業を行う場合、RTコアに切り替えないと、常にランダムで無期限の遅延が発生するリスクがあります。これが実行される唯一のプロセスであっても、一部のドライバは、数分/時間/日ごとにいくつかのバッファをクリーンアップするために数ミリ秒を費やす必要があるとランダムに決定できます。今。
だからあなたの暗黙の質問に対する答え「I / Oが原因で他のプロセスがネットワークパケットに遅く応答するのはなぜですか？」例:「カーネルがこれを行うことを許可されているからです。」。
したがって、ISOファイルシステムを読み書き可能にすること（可能ではないと思う）、directI / Oを使用するかRTカーネルを使用する以外の方法では問題は解決されません。ただこのようなことが起こる可能性が低くなるだけです。