dnfが遅すぎる

dnfが遅すぎる

パッケージのインストール中にコンピュータが数秒間停止するのに十分なdnfが遅い奇妙な問題に遭遇しました。 Fedora 29を実行していますが、これは何年も起こりました。そうしないと、コンピュータが正常に動作し、競合が発生しません。明らかにdnfにはいくつかの弱点があります。 「dnfアップグレード」は100個のパッケージを完了するのに1時間かかりますが、毎年Fedoraをアップグレードすると、Begins Friday nightで3000個以上のパッケージが更新されるため、週末にコンピュータなしで購入できるようにクリスマス休暇を待ちます。日曜日に終わります。

ルートは既存のSSDディスクにマウントされ、/homeは新しいクラシックディスク(WD Caviar Black)にマウントされ、バックアップ用に別のディスクがあります(複数のディスクがマウントされていることを示します)。既存のSSDが正しく機能していないと思われ、ルートパーティションをクラシックディスクの1つに移動しましたが、状況は改善されませんでした(遅くなりました)。

Journalctl、dmesg、または/var/log/messagesには特別な内容は表示されません。 Sysbenchによると、インストールされているすべてのディスクのディスクパフォ​​ーマンスは、良いdnfを含むFedora 29を実行している他の(古い)コンピュータと同様に良いです(数分でアップグレード、年間アップグレードはランチタイムにリリースされます)。

何が起こっているのかを調べるためにどこを見なければならないのかを知っている人はいますか?

PSトップ、iotop、iostat、dmesg、journalctl、これらの基本的なものをたくさん確認しました。 iotopはアップグレードを実行すると、ディスク上の99.99%のアクティビティとしてPython ...(dnf)を表示しますが、これは通常のようです。上記のsysbenchでも、dnfを簡単に実行する他のコンピュータよりもディスクが少し速いことがわかりました。

ブランド:i7-920プロセッサ、24G RAM、スワップなし

答え1

ロバート:どのシステムコールが最も長いかを知ることは興味深いでしょう。

perfトレースを使用して単純な(ランダム)パッケージをインストールし、ソートして最も長い呼び出しを見つけることはできますか?

例: # perf Trace -s -o /tmp/trace.out dnf install -y xorg-x11-apps-7.7-20.fc28.x86_64

次に、/tmp/trace.out ファイルの内容を公開します。要約ファイルなので、それほど大きくはありませんが、どのシステムコールが最も長いか、通常の範囲を超えているかを指摘するのに役立ちます。

答え2

この質問がずっと前からあったことは分かりますが、この問題の原因は書き込み速度がとんでもなく遅いSMR(Single Magnetic Resonance)ドライブを使用しているからであると思います。以下はいくつかの参考資料です。

そしていくつかのベンダーの参考資料:

関連情報