IDEA: Testing tool that fills up memory

[Notok]

Another tool that would be good for beta/QA testing would be a small tool that just fills up your system's RAM, so I/we could test applications under low memory conditions. This would be like those sketchy tools that "free up" system memory by filling up memory with something big (but probably essentially empty) and then unloading it, but in this case it would just keep it there until you tell it to unload. It would be nice to be able to select how much RAM it should try to take by both percentage and MB. I'm thinking it might also be nice if it could fill up memory with a lot of smaller (empty?) files instead of one big one so that it would (theoretically) fill up the page file as well.

Hopefully this isn't too big of a request.

[VideoInPicture]

What you are thinking of are stressor tools and they exists to test a variety of system functions. One memory stressor I've found is from the MSDN magazine: http://msdn.microsoft.com/en-us/magazine/cc163613.aspx

It's called EatMem and is a command line tool written in C# with the source code available in that article. I've compiled the source code and attached it along with the source code in the attachment below. The program is hard coded to stress test the memory by randomly allocating and deallocation between 10%-70% of the memory. You can specify how long it runs for in the command line parameters.

The exe is in the attached file under the \bin\release folders. You need to start up the command line (CMD) in Windows and type in the path to the exe file. For example:
C:\Desktop\TestRun\bin\release\EatMem.exe -d1 will run the program for 1 minute.

Let me know if you need this wrapped up in a graphical interface.

[Notok]

Aha! Excellent, thank you much! A wrapper might actually be nice.. maybe something that minimizes to the tray with a red "!" to indicate that it's running? If that would take more than a little while then don't worry about it, but it would be nice indeed I'm familliar with commandline operation, I just know that I'll end up running it and forgetting about it 

[Notok]

So it looks like this pretty much just eats virtual memory. Is there something that will eat up "physical" memory?

[f0dder]

I'm thinking it might also be nice if it could fill up memory with a lot of smaller (empty?) files instead of one big one so that it would (theoretically) fill up the page file as well.

Huh?

Pagefile is utilized when you try to use more memory than is physically available in your system - it doesn't really have to do with "using files".

So it looks like this pretty much just eats virtual memory. Is there something that will eat up "physical" memory?

Nope, not really doable without writing a driver.

But iirc there's a boot.ini switch for limiting the amount of physical memory Windows will use - that's probably close enough to what you want. Yeah, obviously does require a reboot.

[VideoInPicture]

So it looks like this pretty much just eats virtual memory. Is there something that will eat up "physical" memory?

Hmm, there should be something else out there that could stress both the virtual and physical memory. I'll do a search.

If nothing else, I could just modify that C# stressor tool so that it repeatedly loads an image into memory. That will eat up your ram quick! I had to put in a check for Custom Desktop Logo when I wrote it so that it wouldn't eat up all your system memory if the user tried to load a whole bunch of images into memory so I know it's easily doable.

[VideoInPicture]

[attachthumb=#]1
[attachthumb=#]2

Attached is the modified version of the memory stressor tool I posted above. I have made it so that this version is able to consume both virtual and physical memory at the same time. I have also changed it so that it consumes between 50%-100% of the available memory, which I think is more relevant for stress testing applications.

It is still command line based. Usage is the same as before. Use the Windows CMD window to run it.

I have tested the program on my computer with about 2GB of ram. The results are shown in the screenshots above. Note the sinusoidal-like pattern of the memory usage in the Task Manager.

Note that I'm not sure what the program will do if you have more than 2GB of ram on your system and the program itself tries to consume more than 2GB of memory. There is a limit to the amount of physical memory the program can access on a 32-bit system so the memory stressor tool itself may shutdown if it runs into this memory limitation. However, I think it is unlikely you will run into this bug on a 32-bit system. It should run fine on a 64-bit system and should be able to access all the physical memory since there is a larger memory address space in 64-bit.

I wasn't able to find a memory stressor tool that would work for application testing. There were too many memory error checking tools listed on Google that made the search results useless. Perhaps someone knows of an already built tool that can do what the attached program does?

[f0dder]

VideoInPicture: you can't "consume physical memory" - for usermode windows applications, you're always¹ dealing with virtual memory. Virtual memory isn't the same as "stuff that goes in the paging file"...

Really, if you need to check how your application deals with low-memory situations, either use the boot.ini flag, or (if I'm not confusing the tool with another), gflags.exe, which lets you specify evil things like making memory allocations fail etc.

1: there's stuff like the address-windowing extensions which let you (indirectly) deal with physical memory, but that's outside the scope of this rant

[VideoInPicture]

Perhaps we have different definitions of physical memory. The task manager screenshot does show that I'm consuming physical memory by the task manager's definition.

[f0dder]

Perhaps we have different definitions of physical memory. The task manager screenshot does show that I'm consuming physical memory by the task manager's definition.

Slightly, yes

The thing is that when you're dealing with memory in usermode Windows, you're dealing with virtual memory. What this means is, basically, that you don't have any control of how this is mapped to physical memory - including whether it's paged out to disk. So you can't really make a tool to "consume physical memory", because windows might very well decided not to give you the memory you're asking for.

Sure, you can stress a system by doing usermode virtual memory allocations, but it's not going to be a reliable test of anything.