VMware Communities
0WayneH0
Hot Shot
Hot Shot

Probably thinking too much (RAMDisk use in a VM)

I've recently set myself up with a machine that is much more capable of running multiple VMs at once and as such instead of having "just enough" RAM I now have probably more than I need atleast for the foreseeable future.

I have set up a RAMDisk on the host as a ReadyBoost host as an experiment; I have also set up performance counters to watch the ReadyBoost cache to see how much it is utilized instead of just relying on anecdotal evidence which seems to be the norm for most information on the internet. I have a feeling, even though the performance counters are showing the cache getting hit pretty often (which seems weird in a system with the amount of memory I now have) that the overall user experience value will be limited, but time will tell; that experiment has only just begun.

This RAMDisk experiment on the host has me wondering whether a similar thing might be of value in a VM? Many people claim that ReadyBoost works better for systems with less memory (although other articles claim its more to do with primary hard disk speed for small files and overall memory has nothing to do with it - i.e., fast scratch space). In theory I could assign all my VMs with an extra 1GB or 2GB, set up a RAM disk and use that for ReadyBoost (or alternatively as TMP/TEMP) or both.

At this point I have not tried this in any of my VMs and am curious whether anyone else may have tried this, or am I just insane?

Cheers.

Reply
0 Kudos
18 Replies
continuum
Immortal
Immortal

the more RAM you assign to a VM the slower it becomes - so I would expect that adding RAM to a VM to use it as Readyboost would rather slow it down


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
0WayneH0
Hot Shot
Hot Shot

Slower in general use (with memory trimming disabled) or just start-up/shut-down/suspend/resume?

Reply
0 Kudos
continuum
Immortal
Immortal

in my experience its slower in general


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

0WayneH0
Hot Shot
Hot Shot

OK; well I appreciate the input.

I was just investigating whether I could use a RAMDisk for %temp% on the VM that I use for development (which should in theory improve build times) and I found that my %temp% folder is 14.5GB in size with all the guff that has built up, so I don't really think that making a RAMDisk that large (although I could) would be a wise idea even if general use was OK since start-up/shut-down/suspend/resume would not be pretty and would probably negate any build time benefits.

In the meantime the experiment on my host continues.

Cheers.

Reply
0 Kudos
Bernd_Nowak
Hot Shot
Hot Shot

The %temp% or %tmp% should be "cleaned" when a user logs in, strange that MS hasn't created a small script and runs it when a user log in. I have seen strange effects when this folder contains to much stuff so first thing I do when I have some strange errors is to clean it up.

In Vista/Windows 7 this could be done automatically with the task scheduler via a trigger user login.

Reply
0 Kudos
WoodyZ
Immortal
Immortal

0WayneH0 wrote: I found that my %temp% folder is 14.5GB in size with all the guff that has built up

%TEMP% and or %TMP% are meant to be temporary and programs are supposed to clean up behind themselves however its a known fact that these locations over time contain orphaned files/folders that just do not need to be wasting space on the hard disk.  There is really no good reason to allow an accumulation at these locations as it is very easy to have a script run at startup to clear the contents of these locations.  Additionally one can add to the script to clear out web browser caches as well.  Also there are programs available that automatically take care of the trash, so to speak although I'd never pay for something that I can write a few lines of code to do for free. Smiley Wink

Bernd_Nowak
Hot Shot
Hot Shot

Found a nice way to do it Smiley Wink

Look here: http://www.makeuseof.com/tag/automatically-windows-7-clean-obsolete-files/

Sorry for OT Smiley Wink

And sorry for editing Smiley Wink I checked it and it didn't work like I would like it. So I found this vbs script http://gallery.technet.microsoft.com/scriptcenter/Delete-Temp-files-2f2438f1 which is a nice start.

Reply
0 Kudos
0WayneH0
Hot Shot
Hot Shot

Yeah what you say is true. Turns out 12.4GB of the trash is from my own company's applications through the fact its a development VM and crashes (in other people's code, cough cough) can leave behind rather large data orphaned data sets, so it doesn't take long to add up.

In fact this could be a good reason for me to experiment with a small RAMDisk (Continuum's advice noted and not forgotten) just to see what happens - maybe 2-3GB, although I'd have to make sure that I kept expected data set sizes down for that to work. The plus of a RAMDisk here would be that it could be set not to persist and thereby %temp% is purged automatically upon restart.

That said, a script to purge on start up is equally easy to implement, so I may consider that too.

Reply
0 Kudos
0WayneH0
Hot Shot
Hot Shot

Thanks for the info.

I checked that script and this part makes me feel a little nauseous.

'delete all subfolders 
For i=0 To 10 
    For Each objDir In objFolder.SubFolders 
    objDir.Delete True 
    Next 
Next 
 

The 0 to 10 is a bit mysterious, plus the fact the code doesn't seem to recurse into sub-directories (maybe the Delete method on a folder will do that).

Either way I have a few options up my sleeve; I appreciate all the input.

Reply
0 Kudos
WoodyZ
Immortal
Immortal

0WayneH0 wrote: a script to purge on start up is equally easy to implement, so I may consider that too.

Just a word of caution about using cleanup scripts on startup... Some programs when installing/updating require a reboot and can/will hold files in %TEMP% and or %TMP% to be moved into final place upon reboot... So keep this in mind if an install or update doesn't go as expected and or temporarily disable such cleanup scripts as needed before installing/updating software. Smiley Wink

Reply
0 Kudos
Bernd_Nowak
Hot Shot
Hot Shot

WoodyZ wrote:

0WayneH0 wrote: a script to purge on start up is equally easy to implement, so I may consider that too.

Just a word of caution about using cleanup scripts on startup... Some programs when installing/updating require a reboot and can/will hold files in %TEMP% and or %TMP% to be moved into final place upon reboot... So keep this in mind if an install or update doesn't go as expected and or temporarily disable such cleanup scripts as needed before installing/updating software. Smiley Wink

Arghhhh. Totally forget that so thanks for this reminder so I will stay with doing it manually Smiley Happy Typing %tmp% in explorer and then delete all files isn't that much work Smiley Wink

Reply
0 Kudos
0WayneH0
Hot Shot
Hot Shot

WoodyZ wrote: Just a word of caution about using cleanup scripts on startup...

Another good point (although could easily factor in creation/modified date in the clean up logic and allow a reasonable buffer period).

I just discovered that 9GB of that trash has deliberately been placed in %temp% by another developer in my group to facilitate running of automated tests on large data sets for certain products. That 9GB is a local cache if you like. I'm not all that enamoured by the concept and am currently challenging it, but my bet is that I'll be stuck with it, so for now it may be the customary perioidic manual purge when i remember to do it.

Reply
0 Kudos
0WayneH0
Hot Shot
Hot Shot

Here's a funny (geek funny, not real person funny) story related to this.

With one of my important VMs (this one in fact) I changed the allocated memory from 3GB to 4GB (3GB is about the max I normally use; usually only 1GB for most VMs) and then of course Windows Experience index wanted to refresh. So I did the refresh and the memory score went from 7.2 to 7.9. Then I noticed, that since this VM is 32-bit only 3GB is actually available to the OS! So according to the M$ experience index, my Windows memory score is significantly better by adding 1GB of memory that I can't even use! Go figure.

I have since gone back to 3GB for this VM, 3GB for another heavily used VM, and 1GB for most others.

All dreams of RAMDisks and the like have been relegated to Wonderland along with Alice and company. Smiley Wink

Reply
0 Kudos
mfelker
Expert
Expert

One of  the first hings I do when instaling  a Windows OS (virtual or not) is to go to System in the Control Panel, then go to advanced settings.

1)  Don't let Windows manage a swap file (you don't need one at all with that  amount of RAM!).  If you want a small swap file becasue youj want to debug the kernel then make it a fixed size so Windows doesn't spend resources  expanding or contracting it.

2)   In Windows Explorer I create a folder  C:\temp.  Then  I change the environmental variables for TEMP and TMP files to c:\temp instead  of the obscure Window default locations.  It is way easier to clean up one folder (c:\Temp then 2 weird  nested folders  Just like with VMware don't just let Windows (or any other program) choose default settings for you.

If you have already done this  then I'm sorry to be redundant

Reply
0 Kudos
WhiteKnight
Hot Shot
Hot Shot

@0WayneH0:

Strange... As I read your first posting I got the impression that you don't know the purpose and functionality of ReadyBoost very well.

Did you already read this article at Wikipedia?

To cut a long story short: ReadyBoost speeds up disk access, not RAM access. So the amount of RAM does not have any influence on anything in regard to ReadyBoost.

I guess you get the picture... Smiley Wink



[VMware]: Workstation 17 Pro; --
[host]: Windows 10x64 host; --
[guests]: Windows 10x64, Windows 8x64.
Reply
0 Kudos
0WayneH0
Hot Shot
Hot Shot

WhiteKnight wrote:

@0WayneH0:

Strange... As I read your first posting I got the impression that you don't know the purpose and functionality of ReadyBoost very well.

Did you already read this article at Wikipedia?

To cut a long story short: ReadyBoost speeds up disk access, not RAM access. So the amount of RAM does not have any influence on anything in regard to ReadyBoost.

I guess you get the picture... Smiley Wink

Hi WhiteKnight,

ReadyBoost definitely does speed up disk access (for random access on small files), however, the action of ReadyBoost must be considered in the overall workings of the entire system. If you have a lot of RAM and Superfetch enabled (which it must be to enable ReadyBoost; they are complimentary) then those disk reads that ReadyBoost saves the day on, may not even get that far. It stands to reason that a Superfetch based memory cache will be used before a typically flash drive based ReadyBoost cache (in my experiement I was using RAMDisk, but I'm sure the OS prioritization for the ReadyBoost cache would not change due to that).

My experiment seemed to confirm this; there were some reads/writes over the course of general usage, but not enough in practice to make a measurable difference in user experience. Had I only 1GB of system RAM say, I'm sure that my disk would be hit much more often and that's where ReadyBoost can make a noticeable difference in system performance because it acts as a faster cache at that level. This is in consensus with the literature. So to disgaree with your point; the amount of RAM does play a role in the effectiveness of ReadyBoost.

I've read quite a lot of information on this including articles written by Matt Ayres (the M$ Program Manager for ReadyBoost). One of Matt's comments is:

... the feature is designed to improve small random I/O for people who  lack the expansion slots, money, and or technical expertise to add  additional RAM

After doing my experiment and doing further reading I rationalized that taking xGB away from system memory to use as ReadyBoost was robbing Peter to pay Paul. Just allowing the system to fully utlize memory and cache the appropriate data seems the sanest approach since memory cache will always be preferred even to ReadyBoost cache.

From what I have read M$ also disable ReadyBoost if the system drive is SSD; it makes sense.

If you have some links or information that would contradict my current understanding then please drop them into this thread; I always have an open mind to these things (a prerequisite to learning something new Smiley Wink).

Cheers.

Reply
0 Kudos
WhiteKnight
Hot Shot
Hot Shot

Ok, I can see your point now...

In the context of SuperFetch (which is the same for dynamic RAM what ReadyBoost is for static RAM) taking priority over using ReadyBoost, more RAM is supposed to result in utilizing SuperFetch to a larger extent until no more of that cache is available to pre-fetch data. Then ReadyBoost will be used for pre-fetching and caching additional disk data. A disk would only be accessed if none of the previous caches had paged the requested data. - I presume this is the statement you wanted to get confirmed for VMs. Am I correct with this assumption?

I believe (not having technical insight to Workstation code), since VM RAM is mapped to the host machine's VMM, VM USB devices are mapped to host USB devices, and VM drives are mapped either to files on disk or physical disks, all the pre-fetching mechanisms apply to VMs as well, perhaps being a little bit slower for SuperFetch since there is an additional VMM layer involved. VM drive files are usually rather large, so ReadyBoost won't be used for them. I guess SuperFetch won't be used here, either.

Cheers,

Axel



[VMware]: Workstation 17 Pro; --
[host]: Windows 10x64 host; --
[guests]: Windows 10x64, Windows 8x64.
Reply
0 Kudos
0WayneH0
Hot Shot
Hot Shot

WhiteKnight wrote:

In the context of SuperFetch (which is the same for dynamic RAM what ReadyBoost is for static RAM) taking priority over using ReadyBoost, more RAM is supposed to result in utilizing SuperFetch to a larger extent until no more of that cache is available to pre-fetch data. Then ReadyBoost will be used for pre-fetching and caching additional disk data. A disk would only be accessed if none of the previous caches had paged the requested data. - I presume this is the statement you wanted to get confirmed for VMs. Am I correct with this assumption?

I'm not sure I wanted that specifically confirmed for VMs; I just assumed it would be the same process as for the host system (maybe naively?). My original question (first post) was motivated by the fact that VMs typically have low amounts of memory so my twisted knee jerk logic told me that ReadyBoost has a greater impact in that low memory condition (less SuperFetch cache to compete with) so maybe the VM could benefit from ReadyBoost in that context.

The twisted logic so follows that rather than messing around with a real USB drive (in the context of multiple VMs) I could simplify things by allocating more RAM to the VM and using a RAMDisk for ReadyBoost. Based on the epiphany I had later that is precisely the part where Peter gets shafted since that XGB I allocated to RAMDisk/ReadyBoost would in theory do better as SuperFetch cache (assuming M$ got their ducks lined in a row with that order of caching precedence).

WhiteKnight wrote:

I believe (not having technical insight to Workstation code), since VM RAM is mapped to the host machine's VMM, VM USB devices are mapped to host USB devices, and VM drives are mapped either to files on disk or physical disks, all the pre-fetching mechanisms apply to VMs as well, perhaps being a little bit slower for SuperFetch since there is an additional VMM layer involved. VM drive files are usually rather large, so ReadyBoost won't be used for them. I guess SuperFetch won't be used here, either.

Right, the same mechanisms should apply so in theory a low memory VM could benefit from ReadyBoost if I was perhaps willing to mess around with multiple VMs/USB sticks (and assuming the USB mapping doesn't steal all the potential gains). Just allocating more memory to the VM for SuperFetch seems like the cleanest solution, but Continuum argues that adding more RAM to a VM slows it down in general and that's where the arguments go full circle!

I think I have settled on allocating a bit more RAM to VMs that have more applications running and enabling SuperFetch on those VMs. For most other VMs I have the memory 1GB or lower and no SuperFetch, but having said that most VMs I use are XP anyway.

For laughs, later this week I may test out one VM with a real USB stick allocated for ReadyBoost and see what happens.

Cheers.

Reply
0 Kudos