仮想マシンイメージを複製するたびに、システムの応答速度が非常に遅くなります。私はこれを使用しておりvirt-manager、IOがqemu-img convert複数のスレッドによって実行されていることがわかります。
情報を集めてみましたが、そうです。可能スワッピング（スワップパーティションのI / O）が多いです。 8GBのRAMと2GBのスワップスペースがあります。レプリケーション中およびレプリケーション後、free -hスワップスペースは100％使用されたとマークされます。しかし、これは当時システムがどれだけ交換されたかを知らせません。 VMを複製する前に、スワップ領域が何かで埋められている可能性があります。
私は機械式ハードディスクを使用しています。現在のオペレーティングシステムはFedora Linux 28です。
このような場合は、どのように準備し、関連情報を収集し、大規模な取引所があるかを確認するにはどうすればよいですか。
さまざまな情報を振り返り、整理できる一種の記録を望んでいました。つまり、単純なtopORiotopコマンドを実行すると前の出力を上書きするので、これは望ましくありません。
修正する
私は元の答えで提案したように、そのような情報を収集することはまだ役に立つと思います。しかし：
私のシステムがほとんど完全に反応しない最大の2つの理由を見つけました。どちらもバンピング（スワッピングまたはビスワッピング）とは関係ありません。
まず、バグがありますgnome-shell。メインスレッドでfsync（）を待ちます。 (Wayland) グラフィックサーバーのメインスレッドです。待機中はディスプレイは更新されません。このエラーは gnome-shell 3.30.2 で観察され、次のようになります。安定バージョン3.32から。
（この問題は、GNOME WaylandセッションとXorgセッションを比較することで診断できます。Xorgセッションでは、マウスカーソルがまだ移動できるはずです。）
2番目の問題はext4の既知の問題です。ファイルに書き込むと、fsync（）がオンになります。その他ファイルは「無限に待機する」ことがあります。したがって、これはgnome-shellエラーに影響します。
gnome-shellが修正されても、ext4の長い遅延はFirefoxに影響を与えるようです。上記のext4問題に対する修正がLinuxカーネルバージョン5.3にマージされました。[1][2]。
血まみれの詳細はここに記録されています。Linuxファイルシステムでの単純なファイルコピー（または書き込み）により10秒以上の待ち時間が発生する
答え1
vmstatメモリ、スワップ、およびIOを追跡するために使用される従来のLinuxコマンド。たとえばvmstat 5、5秒ごとに1行の統計を印刷します。
atopこれは新しいツールであり、非常に強力です。実行はatopに似ていますtopが、より多くの情報があります。ログが必要な場合は、atop -w <file>代わりにバイナリログに記録して使用できますatop -r <file>。atopパッケージには、デフォルトで10分間隔で自動的にログを記録するサービスも含まれています。
アップデート：atop2.4.0にはLinuxのサポートが追加されました。圧力失速情報。これがメモリ不足による遅延を検出するのに役立つことを願っています。メモリ不足統計（msまたはmfに表示atop）は、スワップおよび非スワップスラッシングを検出できます。技術的には、スワップされたジッタとスワップされていないジッタを区別するのに役立たないことを意味します。 :-).しかし、私はこの情報を知りたいです。ジャダーが私の問題であるという確信はあまりありません。アップデートからわかるように、ジャダーは実際には主な問題ではありません。
私が持っている主な問題については：これに関する情報を収集するのは難しいと思います。役に立つ一般的な追跡方法があります。offcputime --state 2。このツールをインストールするには少し努力が必要でした。
以前の回答
atopラップトップを一晩吊り下げて動作させるための回避策をインストールしました。。
atop慢性的なメモリ消費の問題がある場合、サービスのログは非常に有益かもしれません。デフォルトの10分ロギング間隔により、短い質問がない可能性があります。
- 私の問題は10〜20分間続くようです。
- スワップ使用量は、前の例の1.4Gから2G（100％）に増加します。
- RAMのスレッド
qemu-img自体のサイズは大きくありません。プロセスqemu-imgには2,500万人の住民だけがいます。 swout以前は175735。これは4096バイトのページで測定され、これは約0.7Gがスワップアウトされたことを意味します。
同時にcache0.8Gから2.3Gに増えた。 freeメモリが0.1Gで停止しました。
私はqemu-imgがキャッシュされたIOを実行しており、キャッシュが別のメモリを押し出していること、これがスワップの原因だと思います。スワップスペースがないと、まだいくつかの問題があると予想されます。つまり、ロードされたプログラムコードとは異なるキャッシュが削除されます。
drop_caches16Gファイルがあれば、かなりのcp量のスワッピングを実行できます。私は同じ問題が再現されていると思いますcp。私はそれが特定の詳細に限定されないと思いますqemu-img convert。