VirtualBox

Opened 12 years ago

Closed 12 years ago

#9940 closed defect (worksforme)

Memory leak on VM network IO — at Version 20

Reported by: jeffh Owned by:
Component: network Version: VirtualBox 4.0.4
Keywords: memory leak ubuntu windows Cc:
Guest type: other Host type: other

Description (last modified by Frank Mehnert)

Hello,

I have several VM servers running Ubuntu 11.04 64 bit, and the Virtualbox-OSE 4.04 release that comes with it. I was going to do some testing of the current release, but after perusing the changelogs and bug trackers, I did not see anything indicating that this had been identified or fixed. I can arrange to test current or pre-releases if needed.

What seems to be happening is that certain types of network IO are causing the host to leak memory into the guest's process. Here are some instances that I noticed it in:

Setup:

Ubuntu Server 11.04 64bit guest running iSCSI target Windows Server 2003 guest mounting the iSCSI volume.

Initiating a large robocopy job causes a memory leak in the Ubuntu guest, but not the Windows guest.

From a 3rd Windows PC: I browse to a SMB share of the Windows guest's iSCSI volume and select all files, then right-click>properties, to enumerate all of the ~200GB of 300,000 files and get their size and count. This causes a huge memory leak in the Windows guest, but not the Ubuntu guest.

I also have a memory leak in a Ubuntu/Squid/Dansguardian Proxy server, but it's only pronounced if I allow a significant amount of mem_caching of web content.

Rebooting either VM does not correct the leak, I have to shut it down completely, then start it again from Virtualbox or vboxmanage.

Change History (21)

comment:1 by vasily Levchenko, 12 years ago

Could you please attach the log and please describe how do you detect the leak? and is it the same for 4.1.6 or 4.0.14?

in reply to:  1 comment:2 by jeffh, 12 years ago

Replying to Hachiman:

Could you please attach the log and please describe how do you detect the leak? and is it the same for 4.1.6 or 4.0.14?

I'm detecting the leak with Ubuntu's System Monitor application by viewing the process list. VM's that I've alotted 2GB of RAM to might be using 4GB or 6GB or RAM, without even touching their swap partition or paging file. If I view Task Manager in Windows, or use pmap in Linux, I can't find any processes within the VM that are using all of the RAM.

I'll try to test 4.1.6 and 4.0.14 tomorrow, and I'll attach the logs.

comment:3 by jeffh, 12 years ago

*Sorry, I should also say about detecting the memory leaks with System Monitor: The RAM can creep up forever, the Windows file enumeration bug grows very quickly, but the iSCSI target VMs can sustain weeks of growing before I have to shut them down. I shut one of them down today, and it went from about 4GB of RAM before I shut it down, and then down to only about 300MB when I started it again, and then crept up to about 400MB by the end of the day.

comment:4 by jeffh, 12 years ago

I tested 4.1.6, same thing. I created a Ubuntu test VM running a Samba file server, and a Windows XP VM to run the robocopy job. During the Windows install, the VM hit 1.1GB or RAM (I assigned 1GB), and that usage persisted for several reboots until I shut it down completely. After starting it again, it held steady at 250MB or RAM used.

Before the robocopy job began, RAM usage was around:

  • Ubuntu Samba server: 350MB
  • Windows XP: 250MB

After 20 minutes of Robocopying:

  • Ubuntu Samba server: 2.1GB
  • Windows XP: 250MB

After stopping the robocopy job, and waiting 15 minutes:

  • Ubuntu Samba server: 2.1GB
  • Windows XP: 250MB

From my experience with the bug, I can tell you that the memory will not be reclaimed after any amount of time except if the VM is completely shut down, and then started again.

The robocopy was of a large shared folder, with about 100GB of data in it, and tens of thousands of folders/files.

by jeffh, 12 years ago

Attachment: VBox.log added

Log from Ubuntu/Samba server running 4.1.6

comment:5 by Frank Mehnert, 12 years ago

Could you also check if you replace the Virt-I/O networking by E1000?

in reply to:  5 comment:6 by jeffh, 12 years ago

Replying to frank:

Could you also check if you replace the Virt-I/O networking by E1000?

Changing Virt-IO to the Intel PRO-1000MT/Server NIC had the exact same result.

I'm wondering if the leak might actually be happening when the VM writes to disk, rather than during network activity? I noticed that there is a disproportionate growth of the process' RAM whenever it's copying a large file that is several GB, as opposed to what seems to be smaller growth when copying several GB of smaller files. I can try to perform more conclusive testing of that theory if you think it will help.

FWIW, I'm using dynamically expanding disks for all of these VMs, I'll try a separate test with fixed-size disks later, to see if that makes a difference.

comment:7 by jeffh, 12 years ago

Here's some more insight:

Using fixed-sized disks: Makes no difference.

I did observe that in the Ubuntu/Samba test case, the memory usage skyrockets until it hits the amount of memory allocated to the guest (2GB in this case), after which, the rate of leaking is much slower. I'm not concerned about the guest not returning any of the 2GB back to the host, but what concerns me is that when it slowly starts to exceed 2GB, that none of that memory will ever be returned to the host either, which means that I can't have a VM running indefinitely, it will always eventually need to be shutdown completely and then restarted.

However, the Windows file-enumeration leak I talked about is much more severe. There isn't nearly as much raw transferring of data going on(should just be Windows API calls to recursively enumerate files/folders, and read properties), but in about 15 minutes time, it caused the Windows VM that was alotted 2GB of RAM to exceed 4GB of total RAM usage.

Let me know if you'd like exact instructions on how to reproduce my testing setup.

comment:8 by Frank Mehnert, 12 years ago

Yes, I would appreciate that!

comment:9 by jeffh, 12 years ago

Sure, here's part 1:

Creating the Ubuntu VM server:

  1. Find a spare PC with a reasonable amount of RAM
  2. Download the latest Ubuntu Desktop 64-bit CD from www.ubuntu.com
  3. Install using default settings
  4. Install updates, either from Update Manager, or by running "sudo apt-get update ; sudo apt-get upgrade" from the terminal
  5. Install virtualbox either from the virtualbox.org .deb packages, or by running "sudo apt-get install virtualbox-ose" from the terminal.

Part 2: Creating the Ubuntu/Samba/iSCSItarget VM:

  1. Download the latest Ubuntu Server 64-bit CD from www.ubuntu.com
  2. Create a new VM with a reasonably high amount of hard drive space, mount the Ubuntu Server ISO to the CD drive. In settings, you'll most likely want to change the NIC to bridged mode, and then start the VM
  3. Install using the default options, don't worry about installing roles or selecting packages just yet
  4. When the VM reboots, log in and run "sudo apt-get update" and then "sudo apt-get upgrade".
  5. Install the required packages with this command: "sudo apt-get install samba iscsitarget"
  6. Run the command "sudo mkdir /testshare ; sudo chmod -R 777 /testshare" and then "sudo nano /etc/samba/smb.conf", hit "Page Down" on your keyboard until you hit the bottom of the file, and add an entry like this:
    [testshare]
      path = /testshare
      guest ok = Yes
      read only = No
      browseable = Yes
    
    You can hit CTRL+X and then 'y' to save and exit.

Now, in windows explorer, browse to \[ip address of the VM]\testshare, and you should see an empty folder.

Setting up iSCSI Target:

  1. Type the following command: "sudo nano /etc/default/iscsitarget", and change "ISCSITARGET_ENABLE=false" to "ISCSITARGET_ENABLE=true".
  2. Type "sudo nano /etc/default/iet/ietd.conf", hit "Page Down" to get to the bottom of the file, and add an entry like this:
    Target iqn.1999-9.com.vboxtesting:ubuntu.sdb
    Lun 0 Path=/dev/sdb,Type=blockio
    
  3. Shutdown the VM with this command: "sudo shutdown now -h"
  4. In the VM settings, add a 2nd hard drive (this will become sdb, which the iSCSI volume will write to).
  5. Start the VM

Part 3: Creating the Windows VM and mounting the shares/iSCSI volumes, to be continued...

comment:10 by jeffh, 12 years ago

Part 3: Windows

  1. Create a Windows VM(again, you'll probably want the NIC in bridged mode) and install Windows(I used Windows XP and Windows Server 2003)
  2. Install rktools.exe to get robocopy, and Microsoft's iSCSI initiator from here:
    www.microsoft.com/download/en/details.aspx?id=17657
    www.microsoft.com/download/en/details.aspx?id=18986
  3. Launch the Microsoft iSCSI initiator, under "Discovery", click "add", and specify the IP address of the Ubuntu VM. On the "Targets" tab, click "Refresh", and you should see the target you created earlier. Update to previous instructions: I had a problem with iSCSI target in Ubuntu 11.10 just now related to not finding a module. I don't know if it was just a fluke, or if it's a problem with 11.10. My working iSCSI target VMs are running Ubuntu Server 11.04, 11.10 may be broken
  4. Click Start, Run, and type "compmgmt.msc". Click on "disk management", decline any wizards asking to create a "dynamic volume". You should see your iSCSI volume at the bottom, you should be able to do the following things by right-clicking on it:
    • Initialize
    • Create basic volume
    • Format to NTFS(quick format)
    • Assign a drive letter
    • Now you've completed the basic setup.

Step 4. Testing. To be continued....

comment:11 by Frank Mehnert, 12 years ago

Your setup is quite complex. When you are talking about guest, you always mean the VM process running the guest, right? So 2.1GB memory for the Ubuntu Samba Server means that the VirtualBox process consumes 2.1GB memory at this time, right? How did you measure the memory consumption, probably with 'ps', so which column did you report, VSZ or RSS?

comment:12 by jeffh, 12 years ago

I'll try to simplify it a little bit:

  1. Ignore the iSCSI portion of it, the Samba file server part shows the problem just fine, I don't think that the more elaborate iSCSI part of the testing is going to show you anything that Samba won't.
  1. Ignore the Windows part, it seems to actually be fixed in the latest version.
  1. To answer your question: Whenever I refer to memory usage, it's using Ubuntu's System Monitor utility, which I believe is using ps and then pmap to get it's numbers. That would be memory for the host's process that is running that particular VM, as reported from the host.

  1. The key to replicating the leak is hammering it with constant network file I/O, such as in a real world file server scenario. The new Ubuntu Samba VM I created last week for testing on the latest version of Vbox was at 2.2GB of memory usage for the host process when I came in this morning (according to System Monitor). Given enough weeks or months of steady network file I/O, I've seen them hit 4 to 6GB of memory usage for the process before I had to shut them down and restart.

I have a few more bits to add, I'll post them later...

comment:13 by Frank Mehnert, 12 years ago

Well, the Samba VM was configured to have 2GB of guest RAM. Please be aware that the RAM is allocated on demand, that is, as long as the guest does not need the whole RAM, the VM will allocate only a part of the configured memory (allocation on demand).

comment:14 by jeffh, 12 years ago

I'm not sure I understand, are you saying that the memory should be freed once the VM is done with it? The VM quickly allocates to ~2GB under heavy file I/O, but it never returns that memory to the host. From my observations, I've never noticed any VM returning memory to the host, but most also don't exceed their alotted memory.

The real problem is that after weeks of heavy real world style usage, the host will have slowly allocated perhaps 4GB or more to the VM's process, and none of it ever gets returned to the host. The fact that I can't detect a memory leak inside of the VM itself makes me think it's happening at the hypervisor level.

The easiest way to simulate this is to write a robocopy script like this to constantly thrash the VM's network shares by performing large copies, deleting the files, and copying them again in an infinite loop. Run it from any Windows machine:

cd C:\
::Add your information here
set vmip=192.168.1.26
set sharename=share1
:loop
::create a folder called "c" on the share
mkdir \%vmip%\%sharename%\c
::give it a little bit of time before you start trying to copy
choice /c 1 /d 1 /t 30 > nul
::copy the entire contents of this machine's C: drive, ignoring errors
robocopy C:\ \%vmip%\%sharename%\c /mir /r:0
::delete the entire "c" directory you just copied
rmdir /s /q \%vmip%\%sharename%\c 
::Now wait for the file server to finish deleting everything
choice /c 1 /d 1 /t 300 > nul
::infinite loop
goto loop

Add the actual ip address and share name of your Ubuntu/Samba VM, paste it all into a .bat file, and let it run as long as you need to, and kill it with CTRL+C when you're done. Please note that the VM must have enough hard drive space to hold the contents of your C:\ drive, and the share name shouldn't contain any spaces.

After a few days you should notice that it has well exceeded the memory alotted to the VM, and even if you stop all file activity for a few days, the VM's process will never return any of that memory to the host.

comment:15 by Frank Mehnert, 12 years ago

No, I only talk about allocating memory on demand. Even if you assigned 2GB to a guest, the VM process will not allocate more memory as required by the guest. During boot, a typical Linux guest does not need more than a few hundred MBs. When the guest is actually using all of its memory, the VM process will then allocate more host memory but that memory will not be freed before the VM process terminates.

A sane value for the maximum allocated memory is guest RAM + guest VRAM + 300...700MB. If you assigned 2GB RAM for your guest and 12MB VRAM the VM process should never require more than 3GB RAM, perhaps even less (this also depends a bit of the other VM settings).

comment:16 by Frank Mehnert, 12 years ago

In your statements above you said that you experience the memory leak with VirtualBox 4.1.6 as well. Did you really run this test with VirtualBox 4.1.6 for several days and did you observe a memory usage by the VM process which is constantly increasing? Please be aware that VBox 4.0.4 contains some leaks which were fixed in a later release and we are not aware of any such leak in VBox 4.1.6.

comment:17 by jeffh, 12 years ago

Yes, the latest round of testing I did was in 4.1.6, as you requested. The total host process memory for the VM had hit 2.3GB over a few days, which is pretty much what I expected. Given another week or 2 I'm sure it will eventually climb to the same value as in 4.04 would.

I was using command-line-only Ubuntu Server Edition for the VMs, which is exceptionally light on RAM usage anyways(between 250MB and 300MB with nothing running, where Ubuntu desktop I'm using for the host would average 700MB to 1GB). My decision to give the VMs 2GB memory each is because it is a 6-core server with 16GB of RAM, intended to run no more than 6 VMs at one time. If I installed the exact same Samba/iSCSI system on a physical server instead of Virtualbox, I would expect RAM usage to never exceed 1GB for the entire system(and typically not more than 500MB to 700MB), so 2GB should already be overkill.

I should also mention that the host VM servers themselves also have Samba installed to allow exported VMs and other files to be copied between them, and large host-to-host file copies never cause abnormal memory usage in the host during the copy, and never exhibit a memory leak after a copy. In order to help properly confirm the bug, I've rebooted everything and setup the following test:

Thrashing the VM's Samba shares from one PC using the above script
Thrashing the host's Samba shares from a different PC
The Ubuntu/Samba VM is the only VM running on the host

After a few hours, this is how the memory usage is looking:

Total Host Memory Used:  3.1GB of 15.7GB
Memory Used by the VM process:  2.1GB (up from around 300MB before copying began)

, and copying has caused no discernible increase in memory use on the host(not including the VM). My expectation is that if I let the script run for another week or two, the VM's memory use will exceed 3GB or 4GB, and the host's(minus the VM's process) will hold steady, even though they are both doing exactly the same thing.

comment:18 by Frank Mehnert, 12 years ago

Sorry, please don't get me wrong, but 2.3GB memory consumption after a few days for a VM which was configured for 2GB guest RAM is completely normal. So please, make 100% sure that the VM is really consuming too much memory, just a "given another week or 2 I'm sure it will eventually climb to the same value as in 4.04 would." is not enough, sorry!

Again: It is completely normal that the VM process consumes only 300MB before the copying starts and 2.1GB after a few hours. The VM memory consumption will increase up to the configured memory limit because the guest OS will use the memory for caching. So please try it really out and show me that the memory consumption of that VM process will really exceed 3GB or 4GB.

comment:19 by jeffh, 12 years ago

That's fine Frank, I already have a simulation running on the latest Vbox right now, but it's going to take some time.

I apologize if this isn't the easiest bug to re-create in an hour, but smb/iscsi filers are an important business application(and I'm probably one of the few that's even attempted it with Virtualbox in a production environment), so I thought I should go ahead and get a bug report out there, rather than spending a year of my life trying to debug the problem before I told somebody about it.

I'll report back when I have some better results in the latest Virtualbox, but it will probably take another week or two.

comment:20 by Frank Mehnert, 12 years ago

Description: modified (diff)
Resolution: worksforme
Status: newclosed

No response, closing.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use