Memory fragmentation happens when a large portion of a computer's random access memory (RAM) is separated into many non-contiguous chunks. The fragmentation can leave a high percentage of RAM memory unused but also unusable resulting in memory issues. If RAM is low or unusable, an application will use the computer's hard drive as virtual memory (which slows operations) or report low or out of memory problems.
Memory fragmentation is common with data intensive applications such as ExtendSim, where the allocation, disposal, and reallocation of memory is ongoing during model runs. For example:
During a run, an ExtendSim model determines that it needs 10 bytes of memory to temporarily store data. In response, the computer's system allocates a 10 byte chunk of memory.
Later in the run, the model discards that data, which disposes of the allocated memory. This leaves a 10 byte empty slot.
The model next needs an 11 byte chunk of memory, which can't fit into that 10 byte empty slot. So the computer's system allocates a new 11 byte chunk.
Think about the case where the model gets 100mb chunk of memory and later disposes it, but then needs a 101mb chunk. If this happens repeatedly, you can see how memory gets clogged up!
There are two ways to deal with reports of memory issues:
Add more RAM memory to the computer. This gives the model more empty slots to choose from and avoids using the computer's hard drive as virtual memory. Also, more memory will be usable if additional slots become available and then join with adjacent empty slots to form larger empty slots.
If ExtendSim has been running models for a long time, and doing so won't interrupt your analysis, restart ExtendSim. When ExtendSim is restarted, the operating system removes all the memory allocations.
Memory leaks occur if some of the memory used in an operation doesn't get properly disposed of at the end of that operation. For example, this happens if a custom block's dynamic array is not properly disposed of in the code. A small memory leak won't cause a problem but memory leaks become significant if they accumulate. This could happen, for example, if the memory for that dynamic array is constantly being reallocated, but not disposed of, over multiple runs. While memory leaks can also occur from ExtendSim, most memory leaks are caused by the code in custom blocks.
There are two ways to deal with reports of memory leaks:
If ExtendSim has been running models for a long time, and doing so won't interrupt your analysis, restart ExtendSim. When ExtendSim is restarted, the operating system refreshes all the memory allocations.
Examine your blocks and models to search for memory leaks:
The RealTimer block (Utilities library) is helpful if you build custom blocks that might cause memory leaks. Temporarily place the RealTimer block in your model, enable block profiling on the Block Profile tab, select the settings you want, and run the model. This block provides a lot of information about the blocks, including the difference in memory usage at the end of the run compared to the beginning.
The Memory Usage block (Utilities library) looks for differences between all block components (libraries, hierarchical blocks, databases, and global arrays). Temporarily add the Memory Usage block to your model and copy the information it reports to Excel or some other location. Then run the model as you normally would. When the model run(s) are finished, compare the Memory Usage block's information to what was originally reported.
Since they will slow performance, remove these blocks from your models once you've finished using them.
You might notice that the second and subsequent runs of a simulation take longer to run and use more memory than the first run. Most often that is because a large amount of data has been stored in the model during the first run. In subsequent runs, that data has to be disposed of before it can be replaced with new data, causing longer processing times.
The RealTimer block, discussed above, is helpful for determining how much memory and simulation time specific blocks are using during runs.