私は最近、Windows 7と並んでUbuntu 12.04をSamsungラップトップにインストールしました。Ubuntuを使用するたびに(アイドル状態であっても)、kworkerは8コアのうちの90%を使用します。それは実際には私の使用には影響しませんが、それは私を悩ませ、私はそれが私のプロセッサに害を与えるかもしれないことを恐れています。別のLinuxディストリビューション(Linux Mint)をインストールしようとしても、kworkerが同じ問題を引き起こしました。だから私は何をすべきかわかりません。本当に助かります。
代わりに、このCPU使用率は正常ではなく、よく知られているkworkerバグに関連していると思います: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/88779
私や他の多くの人にとっての解決策は、まず第一に、次のようなもので悪いことを引き起こしている「gpe」を見つけることでした。
grep . -r /sys/firmware/acpi/interrupts/
高い値を確認します(私の場合はgpe13でした-200Kのような値です-異なる場合は、それに応じて変更する必要があります)。その後:
~ cp /sys/firmware/acpi/interrupts/gpe13 /pathtobackup
~ crontab -e
この行を追加して、起動/再起動ごとに実行されるようにします。
@reboot echo "disable" > /sys/firmware/acpi/interrupts/gpe13
保存/終了。次に、サスペンドから復帰した後も動作させるには:
~ touch /etc/pm/sleep.d/30_disable_gpe13
~ chmod +x /etc/pm/sleep.d/30_disable_gpe13
~ vim /etc/pm/sleep.d/30_disable_gpe13
このものを追加します。
#!/bin/bash
case "$1" in
thaw|resume)
echo disable > /sys/firmware/acpi/interrupts/gpe13 2>/dev/null
;;
*)
;;
esac
exit $?
保存/終了、完了。
テスト済みおよび作業中:
Ubuntu 12.10 on Samsung Chronos 7 series - Model no. NP700Z7C --
Ubuntu 16.04.2 on Clevo - Model no. P650RS --
CPU使用率は正常であるように思われ、使用率の高いCPU(CPU1)は1つのみです。全部で3つのプロセスが実行状態にあり、そのうち2つがkworkerとgnome-system-moです(トップコマンド画面の最初の2つのプロセスは追加した短い)。
「kworker」は、カーネルワーカースレッドのプレースホルダープロセスです。カーネルスレッドは、特に割り込み、タイマー、I/Oなどがある場合にカーネルの実際の処理の大部分を実行します。システム」実行中のプロセス時間。何らかの方法でシステムから安全に削除できるものではなく、nepomukやKDEとはまったく関係ありません(これらのプログラムはシステムコールを行う場合があり、カーネルが何かを行う必要がある場合があります)
Kworkerの詳細については、次のリンクを参照してください。- KWorkerとその重要性
昨日Linux Mint 17をインストールし、今晩、kworkerが4 cpusの1つを100%消費していることに気付きました。上記のチェックを実行しましたが、割り込みに対して0以外は見つかりませんでした。
私が通常実行しているサービスを調べているときに、nfsサーバーをシャットダウンすると、kworkerスレッドがzilchに戻ったことがわかりました。 nfsサーバーを再起動しても問題は解決しませんでした。
このバグレポート( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1322407 )を見つけました。これは、カーネル3.13で同様のnfsサーバーの問題が修正されたことを示しています。 0-32.57。 Mint 17の最新の更新プログラムはカーネル3.13.0-24-genericを実行しているように見えるため、実行中のカーネルには修正がありません。これが他の誰かに役立つかどうかはわかりませんが、私は体系的に各nfsクライアントマシンに行き、「umount -a -t nfs」を行い、効果があるかどうかを待ちました。マウントを解除した後、kworkerが何も落ちなかったため、問題を引き起こしていると思われるクライアントを見つけました。クライアント 'mount -a -t nfs'でnfs共有を再マウントしましたが、問題は戻りませんでした。