Linux Ubuntu 20.04.1 x86_64のQEMUにメモリリークがありますか?

Linux Ubuntu 20.04.1 x86_64のQEMUにメモリリークがありますか?

同じインスタンスを複数回実行する(5.15.0-72-generic - 20.04.1-Ubuntu - x86_64)OSvプロジェクト用のテストベッドがあります。単一の実行スクリプトを実行するのは非常に簡単で、次のようになります。

while [ $x -le $t ]
   do
   ./scripts/capstan_run.sh "$delay"
   now="$(date +'%d%m%Y-%H%M%S')"
   ./scripts/stats.sh > stats/"$x"_"$delay"_stats_"$now".txt & PID=$!
   sleep "$delay" #sleep delay mills for the execution
   kill $PID ; wait $PID 2>/dev/null
   echo "Delay $delay before fetches"
   sleep "$delay" #sleep delay mills before fetch files
   ./scripts/fetch_files.sh "$delay"
   ./scripts/shutdown_vm.sh

   ((x++))
   done

capstun_run.shQEMU 仮想化層で実行されるコンテナー開始エミュレーションを使用します。その後、スリープモードに入り、インスタンスからファイルを検索します。このshutdown.shスクリプトはQEMUを終了します。

killall qemu-system-x86_64

実行間のメモリ使用量の増加が観察された。それは一定であり、決して減少しません。サーバーには126G RAMと24個のCPUがあります。

たとえば、使用されているメモリは8%から始まり、0.1%ずつ12%まで増加することを観察できます。

Date                Memory      Disk        CPU
...
07/04/2023-163242       12.03%      27%     15.00%      
07/04/2023-163247       12.03%      27%     16.00%      
07/04/2023-163252       12.03%      27%     16.00%      
07/04/2023-163257       12.03%      27%     16.00%      
07/04/2023-163303       12.03%      27%     16.00%      
07/04/2023-163308       12.04%      27%     16.00%      
07/04/2023-163313       12.03%      27%     16.00%      
07/04/2023-163318       12.04%      27%     15.00%      
07/04/2023-163323       12.04%      27%     16.00%      
07/04/2023-163328       12.04%      27%     16.00%      
07/04/2023-163334       12.04%      27%     16.00%      
07/04/2023-163339       12.04%      27%     16.00%      
07/04/2023-163344       12.06%      27%     16.00%      
07/04/2023-163349       12.08%      27%     16.00%      
07/04/2023-163354       12.09%      27%     16.00%      
07/04/2023-163359       12.09%      27%     15.00%      
07/04/2023-163405       12.09%      27%     15.00%      
07/04/2023-163410       12.09%      27%     15.00%      
07/04/2023-163415       12.09%      27%     15.00%      

QEMUにメモリリークがありますか?

===更新===

stats.shは、次のように使用された%memを計算します。

free -m | awk 'NR==2{printf "%.2f%%\t\t", $3*100/$2 }

だから「used/total*100」にキャッシュが含まれていないのでバグがあると思います。

私の評価は正しいですか?

ベストアンサー1

QEMUプロセスが終了すると、カーネルは使用中のすべてのメモリーを解放しました。セルフアドレス空間内のメモリリークは、プロセス自体が終了した後も保持されません。キャッシュにメモリが使用されているのを見る可能性が高くなります。このメモリはパフォーマンスを向上させるために使用され、必要に応じていつでも回収できます。キャッシュに使用されるメモリは、通常、メモリ不足を増加させません。

可能性は低いですが、QEMUがtmpfsなどの仮想アドレス空間の外側にメモリを割り当てる可能性があります(キャッシュメモリと見なされますが、削除することはできません)。プロセスが自動的に解放されないリソースを使用できる方法はいくつかあります。その他プロセスからリソースが漏洩します。ファイル記述子を閉じることができません。。 QEMUがどのように使用されているかを詳しく知らないと、これが本当であるかどうかはわかりませんが、そうではありません。


free「使用可能」フィールドではなく「使用可能」フィールドを使用する必要があります。後者はキャッシュを減らしますが、キャッシュされたメモリと見なされるメモリの一部は回収できません。かつていた畑、2014年に追加は実際に使用可能なメモリをより正確に表現したものです。

多くのロードバランシングおよびワークロードデプロイメントプログラムは/proc/meminfoをチェックして、使用可能なメモリ量を推定します。通常、「無料」と「キャッシュ」を追加してこれを行いますが、これは10年前は大丈夫でしたが、今日はほとんど間違いありません。

Cachedには、共有メモリセグメント、tmpfs、ramfsなどのページキャッシュで解放できないメモリが含まれており、ほとんどのアイドルシステムでほとんどのメモリを占有できる回収可能なスラブメモリが含まれていないため、これは間違っています。システムメモリのファイル。

awk行を次に変更する必要があります。

awk '$1 == "MemTotal:" {total=$2} $1 == "MemAvailable:" {avail=$2} END {printf "%.2f%%\t\t", (avail/total)*100}' < /proc/meminfo

計算に使用可能なメモリを使用することに加えて、安定した(予測可能な)形式を持ち、機械で読み取ることができるものを代わりに使用し/proc/meminfoますfree

おすすめ記事