私は、Ubuntu リポジトリのデフォルトで提供されている 64 ビット カーネル 5.4.0-74-generic を搭載した最新の Ubuntu 20.04 を実行している PC/ラップトップをいくつか持っています。そのうちの 1 台は、Intel i3 CPU を搭載したごく普通の PC ですが、18.04 から 20.04 にアップグレードしてから休止状態にするのに 2 分強かかります。
休止状態のデバッグについて私が見つけたさまざまなリソースは、主にウェイクアップまたはサスペンドの完全な失敗をカバーしていますが、非常に長い時間がかかるディスクへのサスペンドについてはカバーしていません。ウェイクアップは正常に動作し、数秒しかかかりません。休止状態に長い時間がかかる原因をどうやって調べればよいでしょうか?systemd-analyze blame休止状態用のものはありますか?
これまでのところ、initcall_debug no_console_suspendに追加しGRUB_CMDLINE_LINUX_DEFAULTて/etc/default/grubコンソールを表示しましたが、長時間かかる理由を示すものは何も表示されません。ネットワーク インターフェイスに対して「ハードウェア ユニットのハングが検出されました」と表示されます。ただし、これは休止状態の開始直後に表示されるため、予想される動作だと思います。
私はsystemctl hibernateこれを起動するために使用します。他のログインユーザーやユーザープロセスがない状態でコンソールで root として実行した場合でも、電源がオフになるまで 2 分かかります。
答え1
私のアドバイス：
決める質問する @ askubuntu.com真剣に取り組んでください。
;)データを収集し、最小限の設定で問題を再現し、具体的に取り組んでください。十分なスワップ領域があることを確認してください。このコマンドは、
freeRAM (「Mem」) とスワップの量を示します。スワップの合計は RAM の合計よりも大きくする必要があります。ある時点で RAM を追加したことに気付きましたが、スワップ パーティションのサイズは増やしていませんでした。編集(2021-06-07):サイズの差は約 1 GB でした。サイズを増やすと、休止状態が繰り返し高速化されましたが、これはスワップ パーティションを保持する SSD の書き込み速度の変化によって生じたアーティファクトであると私はまだ考えています。(次の点も参照してください。)休止状態はどのくらいの速さであるべきでしょうか?基本的に、ディスクへのサスペンド中は、すべての RAM がディスクに書き込まれます。RAM の量とディスクの書き込み速度によって、必要な時間が決まります。私はスワップ パーティションを探し、を使用してゼロにするのにかかる時間を調べました
dd if=/dev/zero。dd速度は 108 MB/秒でした。7 GB の書き込みには約 65 秒かかりました。私の PC には 8 GB あります。したがって、休止状態には少なくとも 1 分はかかると予想する必要があります。試してみる部品を取り外してデバッグするシステムの: 必要のないハードウェアを取り外します。最初にログインするかどうかに関係なく、新規起動後すぐに休止状態になります。
追加
initcall_debug no_console_suspend質問に記載されているように、カーネルコマンドラインに追加します。
今のところ、休止状態が遅い原因は、RAM を追加した (そのため休止状態に時間がかかる)、追加した RAM に合わせてスワップ領域を増やすのを忘れた (スワップは 7G でしたが RAM は 8G)、SSD の書き込み速度が時間の経過とともに低下した (少なくとも 2 倍) ことだと思います。
さらに詳しい、推奨される読み物: