Memory Usage Dialog

Expanded view:

Terse view:

Memory Utilization

The size of the computation possible from within Analytica is limited by the amount of memory required to complete the computation, relative to the maximum amount of memory available. The Memory Utilization pane in the expanded view, and the Memory usage reflects this information.

In use

Shows the amount of memory currently being consumed by the Analytica process.

Max available

This is the maximum amount of memory that your model can make use of. Several factors may influence the size of this number.

In Analytica 32-bit, the maximum available is often limited by the maximum size of the 32-bit address space, which is either 2GB, 3GB or 4GB, depending on which operating system you are using, and whether you have configured your boot.ini file with the /3GB flag to allow 32-bit processes to utilize more than 2GB of memory.

When the size of the address space is not the limiting factor (as is almost always the case is Analytica 64-bit), the maximum memory available to Analytica is to total amount of virtual memory available on your computer at the current allocated page file size, reduced by the amount of virtual memory consumed by other processes running on your computer. When the total system virtual memory reaches capacity, Windows will usually attempt to allocate more space on disk for the page file (although whether it does this is configurable in the system settings). This means that your model will not necessarily run out of memory when the maximum limit is hit -- instead, all applications on Windows will appear to hang for a period of time (usually 1 to 2 minutes) while it enlarges the page file, then when things come back to life, the maximum available will suddenly be larger than previously. System administrators can adjust the initial and maximum page file sizes in the Control Panel → System → Advanced → Performance Settings → Advanced → Virtual Memory → Change.

Total System Virtual

Displays the total amount of virtual memory available on your computer at the currently allocated page file size. This total space must be shared among all processes running on your computer.

RAM Utilization

The memory that can be utilized by your Analytica process (and other processes on your computer) is split between random-access memory (RAM) and page file memory (usually on the hard disk). RAM is typically 1,000 times faster than page file memory, and thus the RAM utilization has a dramatic impact on computation speed.

If your computer has 8GB of RAM, but you have 20 processes running on your computer, the Windows operating system must decide how much of the 8GB each process is allowed to utilize. The amount granted to a process is called its working set, and the sum of all working set sizes across all processes never exceeds the amount of physical RAM. At any given moment, the size of the working set is a slightly different concept from the amount of RAM actually used by the process. For example, Windows may grant your Analytica process a working set size of 500MB, even though at the moment it is utilizing only 100MB. This might give Analytica the flexibility to quickly allocate intermediate values without having to swap to page file memory.

Windows continually balances the working set sizes of all running processes to match their computational needs. To achieve acceptable performance, Analytica requires a working set of about 3 times the size required to hold the largest array (including the Run index for uncertain samples). However, if you have thousands of different arrays in your model, the working set can be much less than the total memory in use without substantially impacting evaluation speed. A cap on the maximum working set for a process can ensure that other processes don't get swapped out of RAM during long intense model evaluations, but keeping the rest of your computer response. On the operating systems that allow caps on the maximum working set size, Analytica 64-bit limits its maximum working set size for this reason, to keep other applications response. For information on how to adjust this, see Working_Set_Size.

RAM Usage

The RAM currently being consumed by your Analytica process. The difference between this number and in-use is the amount of the process memory current residing in page-file memory.

Working set size

The amount of RAM currently alloted by the operating system to the Analytica process. When this number is larger than the number shown for RAM Usage, the process has space to rapidly allocate new memory. If RAM usage passes this number, either the operating system will increase the working set size alloted to this process, or some memory will need to be swapped into page file memory.

Peak working set

The largest working set size that has been alloted to the processes since the Analytica process was started up. This generally coincides with the peak RAM usage (but not peak memory usage).

Max working set

Shown on operating systems that support a maximum cap on working set size, this shows the cap that has been placed on the largest working set that the operating system should allot to this Analytica process.

Keeping this number less than the total system RAM can help to ensure that other applications remain responsive when you launch a long memory-intensive model evaluation. See Working Set Size.

Total System RAM

The total physical RAM installed on your computer.

Unused RAM

RAM not currently in use by any running process.

System RAM load

This value, between 0% and 100%, provides an indication of the level of memory demands among all processes on the system relative to the amount of available RAM. When this is near 100%, all available RAM is in use and use of the page file is required to keep things running. At levels near 100%, performance may taper off.

= Performance

Page fault rate

Shows the number of page faults per second, time averaged over the previous 10-15 seconds, experienced by this Analytica process. Page faults seen here can occur from two sources. First, every page of memory used by the process is initially faulted into existence. This is a very inexpensive operation that occurs frequently during initial start up, and as your model evaluation begins before the RAM utilization is high. Later, when it is necessary to make use of page file memory, a page fault occurs whenever a memory page is required that happens to currently be in page file memory. These page faults are expensive and usually require the least recently accessed page to be written to the page file, and then the required page to be brought into RAM. When this page fault rate becomes to high, we say that thrashing occurs. At that time, the % of CPU utilization of Analytica as seen in Task Manager may drop to much less than a full processor. Trashing conditions are detectable by noticing large page fault rates sustained over long periods of time.

Model

Objects in use

The number of objects currently in use by your model. Each shape (except arrows) that appears on a diagram, including each input or output node, counts as one object. In addition, each local index, and each graph template, counts as an object. Your model may utilize a bit over 31,000 objects maximum.

Sample Size

The Uncertainty Settings sample size, used for Monte Carlo simulation, etc. Total memory usage for probabilistic models is roughly linear in this sample size, as is the working set size required for acceptable performance.

Show object being evaluated

When checked, the object currently being evaluated is displayed here, along with the Dynamic context of the evaluation. Checking this option slows computation times down dramatically, in many cases a slowdown of 10 to 100 fold. Typically the identifiers fly by in a blur during evaluation; however, its value may be in noticing those variables that linger for extended periods of time. You may also find it educational to watch the evaluation proceed, especially with Dynamic models.

Other Fields

Expanded view

When unchecked, the terse memory dialog is displayed. When checked, the expanded view is displayed.

Stop Computing

This button appears only when a computation is in progress. Pressing the button is equivalent to pressing the CTRL-Break key combination, causing the in-progress computation to abort.

Information on fields

Jumps to this Wiki page.