私はまともな仕様（16GB RAM、Intel i7 4710HQ CPU、デュアルm-Sata SSD）を備えた比較的新しいノートブックでVagrant / virtualboxを使用してきました。
これまでに実行されたすべてのゲストで、SSHを介して行われたキーストロークが数秒後にエコーされるなど、非常に高い待ち時間を経験しました。 （リバースDNSルックアップとGSSAPI認証で一般的なSSH接続の問題を確認しましたが、問題は適用されず、初期接続にのみ影響しました。）
同時に（そして他のランダムな時間に）1つのコアが最大100％の利用率まで回転し、すべてVBoxHeadLessによって内部的に消費されますselect()。
$ ps -o time -p 5257; time sudo strace -c -p 5257 ; ps -o time -p 5257
TIME
00:23:51
Process 5257 attached
^CProcess 5257 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.95 3.214696 128588 25 select
0.03 0.000822 29 28 read
0.02 0.000521 23 23 futex
0.01 0.000413 21 20 sched_yield
------ ----------- ----------- --------- --------- ----------------
100.00 3.216452 96 total
real 0m3.81s
user 0m0.00s
sys 0m0.01s
TIME
00:23:55
$ ps -fp 5257
UID PID PPID C STIME TTY TIME CMD
henk 5257 25788 45 16:34 ? 00:18:20 /usr/lib/virtualbox/VBoxHeadless
ps -o time出力に注意してください。
00:23:51 (before)
00:23:55 (after)
time ...3.81sの結果と組み合わせると、プロセスが実際にイベントを待っている間にカーネルですべての時間を費やすことがわかります。
その間、ホストカーネルは問題を解決するためにロックを回転させるようですselect()。
私は同じUbuntu 14.04を使用するより控えめなi5ラップトップでvirtualbox / vagrantを使用しましたが、これらの動作を見たことがありません。
質問：
- ここで過剰なCPUの無駄の原因を見つけるために、どのように深く掘り下げることができますか？
- 応答が遅いvirtualboxクライアントについてよく知っている人はいますか？
修正する
再起動後は問題なくボックスを実行できません。考えられる説明：再起動せずにカーネルアップデートをインストールした可能性があります。
また、仮想化モジュールの競合による潜在的な問題も排除しました。昨日、カーネルからkvmモジュールを削除しましたが、改善されませんでした。今日のモジュールは再起動後に正常に戻りましたが、vboxのパフォーマンスには影響しませんでした。