VPS上のUbuntuが応答しなくなります：BUG：ソフトロックアップ-CPU＃0が22秒間スタックします
Xen上でUbuntuを実行するVPSがあります。問題は、これが1日に1回、約20〜50分間、ランダムな時間にサーバーが完全に外部に応答しなくなることです。この期間が経過すると、何も起こらなかったかのように、応答が再開され、アップタイムが失われることも、再起動されることもありません。一時停止中のアニメーションのように、再び応答を開始します。
これらの停止は、例外ではないメモリとCPUの条件下で発生します。たとえば、メモリが70％、CPUが5％です。重要でないサービスはすべて停止したので、使用量は非常に均一です。これらの停止は、メモリ/ CPUの増加時（毎日のタスク中）には特に発生しません。CPU使用率が非常に低い（2％未満）ときに発生することもありますが、以前はスワッピング中に発生しました。
これらのブラックアウトは、Ubuntu 12.04 LTSとUbuntu 14.04 LTSの両方で発生しています。まったく変更はありません（この問題を解決するためにUbuntuをアップグレードしました）。
私たちのウェブホストサイトにログインし、管理コンソールを使用して、この間のエラーメッセージを確認することができます。おそらく、これらのメッセージはXen仮想化からのものであり、メインメッセージは次のようになります。
BUG: soft lockp - CPU#0 stuck for 22s! [ksoftireqd/0:3] (repeats many times)
SysRq : Emergency Sync (Sometimes this is the only message in the console)
異なる負荷状況下で以前に見られた他のものは次のとおりです。
BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
（何度も繰り返す）または：
INFO: rcu_sched detected stall on CPU 0 (t=15000 jiffies)
（tが大きくなると何度も繰り返されます）
グーグルから、nohz = offやacpi = offなどのさまざまなカーネルパラメータを試してみましたが、役に立ちませんでした。テクニカルサポートによると、他のUbuntuインストールでも同じ問題は発生していません。
誰かがこの問題について何かアイデアや経験を得ましたか？
これが将来この問題を見ている人を助けることを願っています。
同様の環境でこの問題が発生しています。
- Ubuntu 14.04 3.13.0カーネル
- QEMU KVM環境
Splunkクラスターマスターは、平均して5分ごとにこれらの警告を発行していました。 CPU負荷は定期的に最大35％になり、警告はsplunkdまたはpythonがプロセスをロックさせた可能性が最も高いものとしてリストします。
多くの髪を引っ張って歯を噛んだ後、絶望的にVirt-Managerのディスクバス設定を「virtio」から「SATA」に変更しました。
問題はなくなりました。
現時点ではまだシステムを監視していますが、変更後（これまでの30分）から警告は出されておらず、CPU負荷は約2％で安定しています。
シャンパンと花火が始まるのは少し早いことは知っていますが、期待しています。
さて、私が何を試しても、この問題の解決策は見つかりませんでした。結局、UbuntuをDebian 7.0に置き換えたところ、問題はなくなりました。異常なCPU使用率が上には表示されませんが、VPS監視パネルには表示されました（このCPU使用率は、2- 3日で最大10％、その後0％に戻り、CPU使用率グラフに「ノコギリ」パターンが表示されます）。私はしましたnot Ubuntuの再インストールを試みました（ただし、14.04にアップグレードしようとしましたが）。それにもかかわらず、Debianはその評判から期待するほど堅固であり、残念ながら、Ubuntuがその評判を満たすことについても同じことが言えます。私はUbuntuが大好きで、Unityも絶対に好きですが、Ubuntuは幅広いハードウェアで安定していないようです。
私は自分の質問に回答しました。1）解決策を見つけた、2）他の解決策が見つからなかった（CentOSの場合を除いて、CentOS 6からCentOS 5にダウングレードした）ため、これはおそらく歓迎されない場合に役立つかもしれませんこの問題を持つ他の人に。私は解決策に満足できないことを知っています：UbuntuをDebianで置き換えてください！しかし、結局、それは私が問題を修正するためにしたことです。ちなみに、Debianについてはこの問題の報告が見つからなかったため、Debianを採用しましたが、UbuntuおよびCentOSについてはこの問題の報告を見つけました。