I'm developing a VC++ NT service that is meant to operate continuously for many months. It uses VC++ runtime heap intensively. Clearly heap fragmentation can at some point cause it malfunctioning (thinking it's out of memory).
What tests can I run on my service to estimate the degree it is prone to heap fragmentation?
You've gotten a couple of answers that talk about how to prevent problems for heap fragmentation, but neither really addressed your question directly. Nearly the only way to estimate how likely it is to suffer problems for fragmentation is to simulate lots of use, and measure the fragmentation you get.
Since it's an NT service, simulating months of use mostly consists of making a lot of requests in a hurry. Chances are that you can make requests faster than it's normally expected to receive them, so you can probably simulate several months worth of requests in only a few hours, and quite possibly even less (depending on the rate at which you normally expect to receive requests).
Once you simulate months worth of work (or even as you're doing so) you then need to look at the heap to see how much fragmentation you're getting. This isn't easy, but it's normally possible. You'll start by injecting a thread into the service process (Googling on "thread injection" or something on that order should get a fair amount of info). Then you'll need to walk the heap, looking (in particular) for blocks that are free, but too small to be likely to satisfy most requests. Assuming you're using MS VC++, you walk the heap with _heapwalk, and it'll walk through the heap telling you the address, size, and status (free or in-use) of each block in the heap.
One last detail: for this to produce meaningful results, both the executable AND the DLL containing your injected thread have to be linked to the run-time library in a DLL. This means there will be one heap for the whole process, so your injected thread will walk the heap being used by your service. If you link the standard library statically, the DLL and the service will each have its own heap. The DLL will walk its own heap, which will tell you nothing about the heap being used by the service process.
I guess the best way would be writing your own memory manager (or buying one) that offers this data. Any other way would change the heap itself and thus invalidating the result.
A strategy that is easier to implement is to allocate memory blocks of different sizes and wait for a failure - but I don't think that's a good way. Anyway - the larger the blocksize was, that did not fail, the less the fragmentation. But depending on the memory manager, allocating the block can change the result.
Edit: I found a link about the slab allocator (thx for the comment) showing the statistics. It's in German though and the english version of the article does not contain that much information. Use babelfish for translation.
http://de.wikipedia.org/wiki/Slab_allocator (babelfish version)
http://www.usenix.org/event/usenix01/full_papers/bonwick/bonwick.pdf
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With