Managing RAM Memory allocation

Controlling Omniscope RAM memory usage

Omniscope is an in-memory data management appliication, and should always be given access to as much (now relatively inexpensive) RAM memory as possible. By default, Omniscope limits itself to 75% of the physical intalled RAM memory it finds on the machine. This default value was chosen conservatively to ensure there is sufficient free memory in the system for the Operating System (OS) itself to perform other system tasks and to run other applications without degrading overall system performance.

The 32-bit version of Omniscope is subject to an additional OS-imposed cap of 1100MB, due to a limitation of 32-bit Windows where larger values cause Omniscope not to start due to lack of contiguous RAM memory. This default 32-bit upper limit cap has been set to cover 99% of 32-bit Windows PCs, but it could safely be set higher on many 32-bit PCs.

When you start Omniscope, the application launcher determines how much memory it should allow Omniscope to use.  In very rare cases the setting may be too high relative to the situation on the specific machine, and this can cause Omniscope not to start, as discussed here.  More commonly, the defaults may cause Omniscope to start with less memory than would be otherwise possible, and you may wish to change change towards the upper limits if your data sets will be pushing the boundaries of accessible RAM on your machine. You can control how Omniscope manages RAM memory on both 64-bit and 32-bit installations by changing a setting found in the intallconfig.properties file as described below.

Warnings and disclaimers

This is for advanced use only, as incorrect settings in the installation configuration files may stop your Omniscope installation from working.

With 32-bit Omniscope, if you specify too high a required contiguous memory setting, Omniscope will not start. If this happens, reduce the value (perhaps in 100MB steps) until Omniscope starts successfully. Depending on your machine, you may be able to go as high as 1900MB of RAM on a 32-bit machine, but it is unlikely you can go any further without changing to running 64-bit Omniscope on a 64-bit operating system.

With both 32-bit and 64-bit Omniscope, you should never specify more than the installed physical RAM memory, and you should ideally leave some 'headroom' for the operating system and other applications... otherwise machine performance will be degraded. Vista is particularly memory hungry, and if you are still running this OS, Vista should always be left at least 2 GB of memory of its own when allocating allowable memory to Omniscope.

If you will have more than one Omniscope user account operating concurrently on the same (cloud-based) machine, please see the section below on managing RAM allocations for multiple installations on the same machine.

How to increase/decrease available RAM memory

To change default behaviors, you can edit the Omniscope installconfig.properties text file which can typically be found in one of the following locations, depending on type of PC and type of installation: 

• 32-bit: C:\Program Files\Visokio Omniscope\installconfig.properties
• 64-bit: C:\Program Files (x86)\Visokio Omniscope\installconfig.properties

• C:\Users\[Username]\AppData\Local\Visokio Omniscope app\installconfig.properties
   (Windows 7+ and some servers)
• C:\Documents and Settings\[Username]\Local Settings\Application Data\Visokio Omniscope app\installconfig.properties
   (XP & some servers)

Open the installconfig.properties  file in Notepad (it should look similar to the example below) and look for the line starting #MAX_MEMORY_MB= (highlighted below). By default, this line is commented out with a #.  Remove the # in front (and leave no spaces at the beginning of the line or anywhere in the value), and enter the value in MB (e.g. 3500 for approximately 3.5GB) at the end of the line. Save the file with this change. You will need administrative permissions to edit this file.  If using Vista or another Windows OS with user account control, you will find it easier if you copy this file onto your desktop before editing it, then copy it back after editing.

To revert back to the default 75% maximum memory allocation, replace the # sign at the start of the line to comment it out again.

Examples for reference

On a 32-bit PC with 2GB installed RAM memory, we recommend pushing the limit up to 1750MB, providing Omniscope will still start. On some PCs this will give a significant boost to the capability of Omniscope. On a 64-bit Windows PC with a larger 12GB memory, we recommend going up from 75% (9GB) to at least 10GB(10000MB). This will give a moderate boost in file size capacity and reduce any paging to rotating disk memory which slows performance.

Example: 64-bit OS, 12GB physical RAM installed; increasing RAM available to Omniscope to 10GB or 10000MB

(make sure there are no spaces in the uncommented line before you save the change) 

Multi-user machine memory management

Omniscope's default configuration is designed to allow ONE forefront Omniscope instance to take everything it can from the OS if it needs.  In the extreme case of large data sets where Omniscope does take all memory up to the cap, all other apps, including other instances of Omniscope running concurrently on the same machine will be forced to page to disk, which can really slow down performance, unless SSD disks are on the machine.

In a multi-Omniscope user environment, unless the machine has high-speed solid state disk (SSD) memory, it is very important to make sure that Omniscope paging to disk doesn't happen in the middle of an active Omniscope user session, only when users log in or out, switch apps, or wake up an inactive app by starting to use it (the next day, for example).

To avoid this, all accounts on the same machine should have #MAX_MEMORY_MB= settings that ensure that no one session can take more RAM than it should to accomodate the data sets running concurrently on other accounts on the same machine.

Here are the calculations needed.

• Overhead

The amount of free memory you want to leave for other non-Omniscope processes and the OS. (e.g. on a multi-tenant server you may want more than 2GB per user) plus a minimum of 2Gb for the OS itself.

• Max_instances    

The max number of simultaneous Omniscope instances

• Pagefile

The Windows page file size (if present) 

• RAM

The total RAM installed on your server.

e.g. 96GB RAM, 2GB overhead, 6 Omniscope instances:

Overhead = 14 GB (2GB x 6 users + 2GB OS)

Max_instances = 6

Pagefile = 82 GB see notes below

RAM = 96  

Min ( 96 - 14, (96 + 82 - 14) / 6 ) = 27.3GB

MAX_MEMORY_MB=27300

• Pagefile

Windows system page file size needed = Total of memory needed by paged applications    

Those apps which are open but not being used in a given instant - to ensure there's enough page file to hold all inactive apps, without which you may find Omniscope hangs.

e.g 96GB RAM with 6 concurrent users of Omniscope.

• Default max-memory setting: 82GB  ( RAM(96GB) - overhead (2GB x 6 users + 2GB OS) )

• Omniscope max-memory setting: 82GB / 6 concurrent Omniscope = 13.6 GB  

• Page file size needed: 6 * Omniscope max-memory = 82GB  

Shared machine performance may be further  improved if you can reduce Omniscope max-memory further.  So, if you know that for your data sets Omniscope will be fine within a 4GB RAM upper limit for each of the machine users, you can reduce the max limit even further since there is no chance of paging to disk, and in so doing less page file space will be needed.

wrapper.java.maxmemory=14500

The defaults will allocate the lesser of 75% of physical RAM memory on smaller machines up to 8GB RAM, or physical memory less 2GB on larger machines with over 8 GB RAM. So, on a 64-bit PC with 16GB, both the installconfig and wrapper.config maxmemory values will automatically be set to 14GB. You may choose to edit this to provide a bit more RAM if your data sets are larger, or a bit less if you wish to guarantee more memory to other applications and services running on the same machine(s) which is probably acceptable on dev/test and fail-over machines, but not ideal for production servers.