Ubuntu 18.04 - 発熱の問題 - Systemd-udevdのCPU使用率が100%に近づいています。

Ubuntu 18.04 - 発熱の問題 - Systemd-udevdのCPU使用率が100%に近づいています。

私はすべてのLinuxディストリビューションを初めて使用するユーザーです。数日前、Dell Inspiron N5010にUbuntu 18.04をインストールしました。私のラップトップは最初の起動から発熱の問題に直面していました。インターネット検索で犯人を見つけるのに役立ちました。

私のシステムには、98.xと3x.xのCPU使用率を持つ2つの実行インスタンスを持つ「systemd-udevd」プロセスがあります。

私は言及しましたこのリンクはaskubuntuにあります。私が直面したのと同じ問題について説明します。そこで私は2つの一時的な解決策を学びました。 Bluetoothに関連しています。

  1. BIOSでBluetoothを無効にします。Ubuntu 18.04でこれを行う方法は?
  2. 次のコマンドを実行します。

sudo systemctl stop systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

sudo systemctl start systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

このコマンドはターゲットプロセスを終了してシステムを冷却しますが、コンピュータを起動するたびにこのコマンドを繰り返す必要があるため、面倒です。

この問題を解決するのを手伝ってください。

答え1

問題を解決する

BIOSでBluetoothを無効にしましたが、再起動時にsystemd-udevdプロセスが実行されなくなりました。

このプロセスを完了するために従う必要がある手順をリストします(Dell Inspiron N5010の場合)。

  1. システムが起動してDellロゴが表示されたら、F2キーを繰り返し押してBIOSセットアッププログラムを開きます。
  2. キーボード(BIOSモードではマウスが機能しない)を使用してワイヤレスに移動します。
  3. ワイヤレスでBluetoothを無効にします。
  4. システムを再起動します。

答え2

まあ、BIOSの側面については助けることができません。私の能力を少し超えていますが、ラップトップを起動するたびにこれらのコマンドを実行したくない場合は、Canを使用してcrontabにコマンドを追加するだけですcrontab -e

@reboot systemctl restart systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

~からhttps://askubuntu.com/questions/228304/how-do-i-run-a-script-at-start-up

答え3

問題を完全に解決できなかったので残念です。問題を軽減するためのいくつかの手がかりと方法は次のとおりです。

  • まず、私は確信しています。クリス・フィッシャー~から木星放送(コミュニティ副社長Linux アカデミー)は彼のX1 Extremeまたは同様の問題と同じ問題を抱えています。彼は"Linuxが分離されました(おそらく8-10ヶ月前だったでしょう。)ドッキングステーションや外部モニターがあるという点で、USB-Cを介したThunderboltに関連していることを覚えているようです。が修正を見つけたかどうか覚えていると確信しています。

    BIOS 設定で Thunderbolt の「補助モード」が有効になっていると、一部のノートブックに問題が発生することがわかりますので、設定を操作するときは注意してください。まず調査し、常にバックアップしてください。

  • 第二に、あなたのユースケースはわかりませんが、ラップトップでLTSカーネルを実行するのは一般的に良い考えではありません。より安定していると思うかもしれませんが、実際には、状況は急速に変化する傾向があるため、いくつかのハードウェアの問題が発生する可能性がある偶然の状況に近いです。私は治療を受け、X1 Yoga 3rdでのみ最新のカーネルを実行します。 (19.04で十分です。使ってみましたか?)

    LTS/カーネルバージョンが本当に必要な場合は、ヘッドレスVMまたはコンテナを使用してSSH経由で接続することを検討してください。 KVM + virtioドライバを使用すると、違いを感じることはありません。

この問題を調査するためのいくつかの提案は次のとおりです。

  • 使用ターボチャージャー実際のハードウェアを読みたい場合は、他のすべて(/procなどから読み取ったもの)は、「システムが設定しようとしているもの」(CPUコア周波数など)です。実際にこれが起こっています。ターボチャージャーもっと) 十分低い。

  • これら2つのコマンドを引き続き実行する必要がある場合は、cronジョブを使用することをお勧めしますか?@reboot何人かの人と協力して、すべてのことsleep n ; commandがスムーズに進むようにしましょう。またはsystemd timer必要に応じて単位。 (食べ物~のためアイデア.) この問題は、少なくとも自動的に修正する必要があります。

あなたがこれを理解できることを願っています。ただし、これはカーネルのバージョン/モードとハードウェアの特定の組み合わせに関連している可能性があります。私は個人的にもっと学ぶ前に他のディストリビューション/カーネルを試してみます。もちろん、カスタムカーネルのコンパイルが好きでない限り。

進行状況を報告します!

関連情報