Tips to help you manage model size and other issues dealing with memory.
|
Memory Usage Block (Utilities Library) 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. It is the first step to making models more manageable. |
History Blocks If a History block shows up in the Memory Usage list as a major consumer of memory, check out how many rows are in the history table. From time to time, you might want to set a History block up to record more than just 1000 rows (default). Maybe you've set it up for 10,000 rows or more so you can see all items that traveled through it. If you ever forget to reset this back down to 1000 rows or even delete the History block altogether, it can consume a bit of memory with an excessive row quantity. It's good practice to set up the History block so the data is not saved when the model is saved.Finally, using a temporary History block is good for debugging. This is the one that dangles off of an item output. It's good to use this one because every so often you can delete them all with a simple right-click selection on an item output connector. |
Contents of Activity Item and Queue Item If an Activity or Queue shows up in the Memory Usage block list, check out the block's Contents tab. The Contents tab on the Activity and Queue can get large under various conditions. For example, if you are showing the historical log that has had many items travel through it across the run, it does take up a great deal of memory. |
| Database Table/Log Tables If a database table shows up in the Memory Usage block list, check out how many records the table contains. Tables that contain a log of items or events that constantly grow can be pesky at times when it comes to consuming memory. The log tables are useful for debugging and analysis; however, when doing really long runs for multiple replications, they can become huge. It is suggested to add a flag as a user input that has the capability to turn off capturing the detailed log table in situations where the table isn’t necessary. The flag is useful when you are performing a large number of replications for a study, and you are really only interested in the high-level results and not a detailed log. |
|
RealTimer Block (Utilities library) 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. |
.BAK File By default, ExtendSim models make a backup copy of itself every time you save the model. This file has the same name but has an extension of .bak instead of .mox. The model will use this when you use the function File > Revert Model to revert the model to the last saved version. The backup file isn’t necessary for any other reason. For older version models, you can definitely delete their .bak. If you don’t want to create the .bak file in the first place, there is an option that you can set to turn it off in the Edit > Options > Misc tab. |
The Memory Usage block shows the amount of memory each block, each hierarchical block, and each database table is using. This list can be sorted (by clicking at the top of the column) to show you which ones are consuming the most. It looks for differences between all block components (libraries, hierarchical blocks, databases, and global arrays).
The RealTimer block is helpful if you've built custom blocks that might be causing 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.