VirtualBox

Opened 14 years ago

Closed 14 years ago

#6005 closed defect (fixed)

VBoxSVC consuming large amount of mem

Reported by: Bernhard Owned by:
Component: other Version: VirtualBox 3.1.2
Keywords: VboxSVC memory Cc:
Guest type: Linux Host type: Linux

Description

Hi Forum,

I'm using 2 VMs on a 2GB RAM host. The two VMs are started as "VBoxHeadless -s myfavorites" After a couple of days running, the memory usage increased dramatically as I can see with top:

top - 08:26:51 up 10 days, 23:20,  1 user,  load average: 0.10, 0.07, 0.07
Tasks:  75 total,   3 running,  72 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.2%us,  1.2%sy,  0.0%ni, 98.3%id,  0.0%wa,  0.2%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  1.7%sy,  0.2%ni, 95.8%id,  2.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   1928900k total,  1914380k used,    14520k free,    16588k buffers
Swap:  4209008k total,  3030792k used,  1178216k free,   327504k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
12592 root      20   0 3620m 549m  908 S    0 29.2  21:57.32 VBoxSVC
12569 root      25   5  803m 546m  31m S    2 29.0 630:39.53 VBoxHeadless
12935 root      39  19  545m 288m  28m S    0 15.3 156:04.64 VBoxHeadless

The VboxSVC is using a bunch more than the two VMs !!!! After a restart of the two VMs and killing the VBoxSVC everything looks nice:

top - 09:24:14 up 11 days, 17 min,  2 users,  load average: 0.05, 0.11, 0.23
Tasks:  77 total,   3 running,  74 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.3%us,  2.7%sy,  0.2%ni, 95.7%id,  0.9%wa,  0.1%hi,  0.1%si,  0.0%st
Cpu1  :  0.3%us,  4.0%sy,  0.5%ni, 91.4%id,  3.6%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   1928900k total,  1721096k used,   207804k free,    63076k buffers
Swap:  4209008k total,     4684k used,  4204324k free,   873760k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
14441 root      20   0  632m 388m  37m S    1 20.6   2:42.80 VBoxHeadless
14512 root      20   0  481m 300m  34m S    4 15.9   1:01.23 VBoxHeadless
14465 root      20   0  144m 6756 5084 S    1  0.4   0:03.53 VBoxSVC

But the VBoxSVC process starts eating up the RAM bit by bit right from the start with a "feeled speed" of approx 100MB per second CPU time the process is running

Attachments (2)

VBox_VM2.log (32.4 KB ) - added by Bernhard 14 years ago.
Log of second VM
VBox_VM1.log (34.9 KB ) - added by Bernhard 14 years ago.
Log of first VM

Download all attachments as: .zip

Change History (9)

comment:1 by Bernhard, 14 years ago

Almost any idea is welcome to get a workaround. I also don't have any idea to adresss this issue to a specific function.

best Bernhard

comment:2 by Frank Mehnert, 14 years ago

The VBox.log of the two VMs could be interesting because the configuration of the VMs influences VBoxSVC. Furthermore, does VBoxSVC consume that much memory if your start only one of these VMs?

by Bernhard, 14 years ago

Attachment: VBox_VM2.log added

Log of second VM

by Bernhard, 14 years ago

Attachment: VBox_VM1.log added

Log of first VM

comment:3 by Bernhard, 14 years ago

I Attached two log files. Meanwhile I rebooted the host. Right now I can't see this effect. But two other thoughts:

  • now two VBoxSVC processes are running (earlier I could only see one)
  • is it possible, that the cmdline parameters have an influence (-v on <--> -v off)
  • could it be, that the mem eating VBoxSVC was a "dying rest" of an earlier VBoHeadless process, that didn't finish correctly --> maybe a VRDP session with an "unclean" disconnect ?

(Actually I have no idea what this VBxSVC is used for)

best reagards Bernhard

comment:4 by Jon, 14 years ago

I'm having a similar issue wih 3.1.2 on a RHEL 5 (AMD 64) box after running 5 VMs for several weeks. The machine has 16GB of ram, and eventually VBoxSVC will eat up the remainder as well as all my swap. This usually happens between 2-6 weeks after startup for me and requires stopping all the VMs and restarting vbox to free it. Load jumps too due to all the IO with the swap.

top - 12:55:01 up 94 days, 11:11,  1 user,  load average: 2.13, 1.89, 1.99
Tasks: 191 total,   1 running, 190 sleeping,   0 stopped,   0 zombie
Cpu(s):  7.9%us,  2.7%sy,  0.0%ni, 89.4%id,  0.1%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  16365948k total, 15972588k used,   393360k free,   570536k buffers
Swap: 18874352k total, 18874352k used,        0k free,   877756k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                               
26980 vbox      15   0 20.1g 6.6g 1396 S  0.0 42.3 251:36.22 VBoxSVC                                                                                                               
26248 vbox      15   0 1928m 1.5g 2340 S 10.0  9.6   5823:19 VBoxHeadless                                                                                                          
  812 vbox      15   0 1903m 1.5g 2184 S  3.3  9.5   3970:21 VBoxHeadless                                                                                                          
27019 vbox      15   0 1634m 1.2g 2344 S  0.7  7.8 917:00.04 VBoxHeadless                                                                                                          
12215 vbox      15   0 1370m 1.0g 2016 S  1.0  6.5 186:46.98 VBoxHeadless                                                                                                          
26959 vbox      15   0 1411m 1.0g 2304 S  6.3  6.4   6201:40 VBoxHeadless                                                                                                          
 9723 vbox      15   0 66196 1508 1068 S  0.0  0.0   0:00.03 bash                                                                                                                  
26973 vbox      15   0 88584 1044  944 S  0.0  0.0  93:03.53 VBoxXPCOMIPCD                                                                                                         
27003 vbox      15   0 87796 1020  940 S  0.0  0.0   0:00.33 VBoxNetDHCP    

The VMs themselves are all still running fine. I can also attach logs but most of the Vbox.log files for the individual VMs haven't been written to for several days prior to vboxsvc growing like this. The growth is sudden as it will go from 0 swap usage to full in the time it takes for a single Nagios check.

comment:5 by Klaus Espenlaub, 14 years ago

Clearly seems to be a memory leak. VBox.log won't help much in this case. Is it still happening with VirtualBox 3.1.6?

comment:6 by Bernhard, 14 years ago

As far as I can see, no. in 3.1.6 it looks fine. From my pov you may close this ticket .

comment:7 by Sander van Leeuwen, 14 years ago

Resolution: fixed
Status: newclosed

Thanks for the feedback.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use