寻觅生命中的那一片浅草......

VirtualBox虚拟机类型选择错误引起的血案

问题症状

  1. 系统是CentOS 7 64bit
  2. 跑了10+java进程,系统load很高,可以去到100+,系统为16核CPU
  3. top查看,CPU的us time是0.2%,sys time是31.8%
  4. 此时祭出perf top,看到消耗最高的是acpipmread

解决过程

调整VirtualBox的vm配置

Googleacpi_pm_read,得出以下文章

Virtualbox 4.3.4虚拟机上面linux guest的tsc时钟源不可用,降级使用acpipm的问题(导致clockgettime函数和gettimeofday性能变差,debian内核升级等)

经过一番折腾,处理是以下3条指令

VBoxManage.exe setextradata "192.168.2.12" "VBoxnternal/TM/MaybeUseOffsettedHostTSC" 1
VBoxManage setextradata "192.168.2.12" "VBoxInternal/TM/UseRealTSC" 1
VBoxManage setextradata "192.168.2.12" "VBoxInternal/TM/TSCVirtualized" 0

由于我埋头苦干,没有留意到上文已经是考古级别,我们用的virtualbox 6.0,有2个指令已经不起作用,导致vm无法开机,通过以下指令去除配置

VBoxManage setextradata "192.168.2.12" "VBoxInternal/TM/UseRealTSC"
VBoxManage setextradata "192.168.2.12" "VBoxInternal/TM/TSCVirtualized"

此时开机,系统load不高了,但某java进程还是100%,其他java进程则80%+,由于本机是内网开发机,不应该这么高

修改VM类型

同物理机上有另外一台vm,它是正常的,最后经过排查,发现192.168.2.12选择的是windows系统,而另外一台正常的则是Linux,然后我把vm类型修改为Linux,重新开机,稳定后,系统load只有0.x

从来没有想到vm类型影响这么大

2024年十二月
« 5月    
 1
2345678
9101112131415
16171819202122
23242526272829
3031