Memory Usage Dialog

Select Show memory usage from the Window menu to see this information. It shows you how much computer memory your model is using, and how much is available. Analytica keeps all data in memory to maximize computation speed, which means that a large model can use a lot of memory. Use the Performance Profiler library if you want to see how much memory and CPU time is used by each variable and function.

The terse view shows you just the essentials:

The expanded view shows you details of virtual memory and working set:

These following sections explain the meaning of the fields in each pane of this Expanded dialog box.

Memory Utilization

The model must fit in total memory available, which may include physical RAM and Virtual Memory if available. The Memory Utilization pane in the expanded view, and the Memory usage reflects this information.

In use: Amount of memory currently being used by Analytica (this process), including RAM and Virtual Memory.

Max available: Maximum amount of memory available to Analytica.

For Analytica 64-bit, the maximum memory available is the total virtual memory allocated less the memory used by other processes, including the Windows Operating System. When the total system virtual memory reaches capacity, Windows usually attempts to allocate more space on disk for the page file (depending on system settings). This means that your model will not necessarily run out of memory when it reaches this maximum -- but, all applications on Windows may become unresponsive (hang) for a while (usually 1 to 2 minutes) while it expands the page file. When it comes back to life, the maximum available will be larger. System administrators can adjust the initial and maximum page file sizes in the Control Panel → System → Advanced → Performance Settings → Advanced → Virtual Memory → Change.

In Analytica 32-bit, like any 32-bit application, this maximum is usually limited by the 32-bit address space to 2 GB, 3 GB or 4 GB. It depends 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. If you have less than that amount of physical RAM memory, it can use virtual memory, using hard disk. But, the total available is still limited by the address space.
Total System Virtual

The amount of virtual memory available given the allocated page file size. This memory is shared among all processes running on your computer.

RAM Utilization

Like any Windows application, Analytica can use virtual memory -- i.e., if it runs out of RAM (random access memory) it may supplement it with page file memory, usually on a hard drive. Accessing data in RAM is around 1,000 times faster than a hard drive disk, or 30 times faster than SSD (solid state drive). So using a page file can dramatically slow down computational speed. But, it's much better to use SSD than a standard hard disk.

If you are running a 64-bit edition of Analytica, it can use up to 128 GB of memory (Windows older than version 10 may not support so much memory.)

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 to allow for each process. The working set is the amount of RAM granted to a process. The sum of working set sizes across all processes cannot exceed the amount of physical RAM. Windows may give a process a larger working set than it needs, larger than the amount of RAM its currently using. For example, Windows may grant your Analytica process a working set size of 500MB, even though it is using only 100MB for now. This lets Analytica quickly allocate more data 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 minimum 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 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 responsive. 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 allotted 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 allotted 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

A page fault occurs when an application tries to access a block of memory, finds that it is in virtual memory and so needs to be paged back into RAM. The page fault rate is the number of page faults per second averaged over the previous 10-15 seconds. 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 too 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. A large page fault rate over a long periods indicates thrashing.

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.