10.0/vBox eating up 8-GB mem to swap

Believe me, I hate to overstay my welcome but about 10.0 and vBox at this point ...

7194-M Free: The result after booting and doing nothing else
7159-M Free: The result after running a script to mount partition.
7112-M Free: The result after opening the Virtualbox Manager.
4060-M Free: The result after running Windows-7 under Virtualbox.

me:
We gave Windows a whopping 2048M of memory, and it use the host cache as recommended by Virtualbox. Now things get really hairy. I am not doing absolutely anything under FreeBSD, other than to minimize the Win-7 window so to see what the TOP results are under FreeBSD after each event is completed under Windows... I may peep from time to time and watch the host memory drop like a rock before my very eyes.

3951-M Free: Result of doing nothing for15 minutes since logging into Windows.

2686-M Free: Result for simply coping a 605MB file from d-drive to c-drive, to be installed.

118-M Free: This is after installing Office-13, the 605MB file.

me:
Is this the way it worked in previous versions of FreeBSD-10.0 running vBox? I never notice until now? Now I want to try 9.3 or it may be better to go to 9.2 or even back to 8.2... I’m so confused after all of this that no one else claims to have seen, but did saw somewhere in the back of his mind or no investigate to fix that make him forget it.
2315-M Free: This is after shutting down Windows and the Virtualbox Manager.
me:
FreeBSD-10 only recovered 2197MB of Windows memory. What happen to the rest of the near 8GB of memory that FreeBSD had a start up. And why is FreeBSD memory being gobbled-up as Windows-7 with its 2048MB of memory is happily using only 400-800MB all of the time? This is the most freaky thing I ever seen. Windows is running well, with plenty of memory to spare, as FreeBSD live on swap! I can’t believe I’m the only one who notices this or that these many strange things only happen to me. So I post results?

Beginning with:
Code:
Mem: 166M Active...86M Inact....244M Wired....83M Buf....7194M Free

Ending with:
Code:
Mem: 211M Active...4689M Inact....444M Wired....46M Cache....801M Buf....2300M Free

I first, second or third, notice these things after installing Adobe Suite and 20 other large programs. Windows got slower than a dog, so I went to FreeBSD TOP ... I seen memory go all the way down to zero and start using swap. ... and FreeBSD mouse was jittery under GNOME. I tried to open up gedit and FreeBSD-10.0 crashed. I had to pull the plug! After a week, it all kicked in. Now I got Bug-Buddy who would never have a clue anyway other than to say, [zero-memory]. And I’m not smart enoght to trace a dump-kernel who may say the same after a millon bytes. So, I traced my steps (3x with 3 backup replacements over time).

I don’t think it’s a bug, I think it is a known fact concerning recovery of system memory that never got fixed, or that it is a FreeBSD-10.0 issue only. I would think it was VirtualBox causing the problem but it’s a top FreeBSD port. I once read that FreeBSD is known to be the best at s system memory recovery, which may not be true (out the box). So that mean I got a lot more to learn (before learn what I want to learn). How do we configure the system to over-come this more-than-serious problem? Is it possible? Is it a bug?
 
max21 said:
I first, second or third, notice these things after installing Adobe Suite and 20 other large programs. Windows got slower than a dog
I'm not surprised with only 2 GB of memory. That may have sufficed with XP, on Windows 7 you really want to give it at least 4 GB.
 
I once bought a 2GB RAM netbook with a Windows7 installation,it lasted for about 45 minutes before I zapped it and put Linux on it. It would struggle to do anything, such as load Explorer or I.E., but after putting Linux on it, it flew along in comparison. That same machine is now running PC-BSD 10 very happily. :)
 
Free memory is wasted memory. Why else would you have purchased the hardware you did? So it can sit around doing nothing useful? FreeBSD will try to use all the memory it has for something useful.
 
The memory statistics from top(1) are never really useful for finding out suspected memory leaks because they are just top level summaries that don't tell what the memory is actully used for and even if it looks like free memory is being "eaten away" it's just the OS doing what its supposed to do and using free memory for caching and other useful things. For better diagnostics look into for example vmstat(8).
 
Back
Top