저는 괜찮은 사양(16GB RAM, Intel i7 4710HQ CPU, 듀얼 m-Sata SSD)을 갖춘 비교적 새로운 노트북에서 Vagrant/virtualbox를 사용해 왔습니다.
지금까지 실행한 모든 게스트에서 SSH를 통해 이루어진 키 입력이 몇 초 후에 에코되는 등 매우 높은 대기 시간을 경험했습니다. (역방향 DNS 조회 및 GSSAPI 인증을 통해 일반적인 SSH 연결 문제를 확인했는데 해당 문제가 적용되지 않고 초기 연결에만 영향을 미쳤습니다.)
동시에(그리고 다른 임의의 시간에) 하나의 코어가 최대 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().
나는 동일한 우분투 14.04를 사용하는 좀 더 겸손한 i5 랩톱에서 virtualbox/vagrant를 사용했지만 이러한 동작을 본 적이 없습니다.
질문:
- 여기서 과도한 CPU 낭비의 원인을 찾기 위해 어떻게 더 깊이 파고들 수 있습니까?
- 응답 속도가 느린 virtualbox 클라이언트에 대해 잘 아는 사람이 있습니까?
고쳐 쓰다
재부팅한 후에는 문제 없이 상자를 실행할 수 없습니다. 가능한 설명: 재부팅하지 않고 커널 업데이트를 설치했을 수 있습니다.
또한 가상화 모듈 충돌로 인한 잠재적인 문제도 제거했습니다. 어제 커널에서 kvm 모듈을 제거했지만 개선되지 않았습니다. 오늘 모듈은 재부팅 후 정상으로 돌아왔지만 vbox 성능에는 영향을 미치지 않았습니다.