非常に遅いdnf
非常に遅いdnfで奇妙な問題が発生し、パッケージのインストール中にコンピューターが数秒間フリーズします。 Fedora 29を実行していますが、これは何年もの間起こっています。それ以外の場合、コンピュータは正常に動作し、クラッシュすることはありません。明らかに、dnfだけが弱点にぶつかります。 「dnfアップグレード」は100パッケージで1時間かかるだけでなく、毎年Fedoraをアップグレードするときはクリスマス休暇を待つので、3000以上のパッケージアップデートが金曜日の夜に始まり、日曜日に終了するため、週末はコンピュータなしで生活できます。
ルートディレクトリは古いSSDディスクにマウントされ、/ homeは新しいクラシックディスク（WD Caviar Black）にマウントされます。バックアップ用に別のディスクがあります（複数のディスクがインストールされていることを伝えるため）。古いSSDの誤動作が疑われ、ルートパーティションをクラシックディスクの1つに移動しましたが、状況は改善されませんでした（さらに遅くなりました）。
Journalctl、dmesg、または/ var/log/messagesには、特別なものは何も表示されません。 Sysbenchによると、インストールされているすべてのディスクのディスクパフォーマンスは、Fedora 29を実行し、dnfが良好な別の（古い）コンピューターと同じように良好です（数分でアップグレード、ランチ時に年間リリースアップグレード）。
誰かが何が起こっているのかをどこで探すべきか考えていますか？
追伸top、iotop、iostat、dmesg、journalctlなど、基本的なことはたくさんチェックされました。 iotopは、ディスク上でpythonによる99.99％のアクティビティを表示します...（dnf）アップグレードを実行するときですが、それは正常だと思います。 （上記のように）sysbenchでも、ディスクが簡単にdnfを実行する別のコンピューターよりも少し速いことが示されています。
メーカー：i7-920プロセッサ、24 G RAM、スワップなし
Robert：どのシステムコールが最も長くかかっているかを知ることは興味深いでしょう。
Perfトレースを使用して単純な（ランダム）パッケージをインストールし、ソートして最長の呼び出しを見つけることはできますか？
例：＃perf trace -s -o /tmp/trace.out dnf install -y xorg-x11-apps-7.7-20.fc28.x86_64
次に、/ tmp/trace.outファイルの内容を投稿します。これは要約ファイルなので、大きすぎてはいけませんが、どのシステムコールが最も長くかかっているか、およびそれらが通常の範囲外にあるかどうかを示すのに役立ちます。