FAQ – D3 NT MEMORY USAGE
There are 2 kinds of memory reported by Task Manager:
This is the amount of physical memory used by the process. The more active the process, the more memory it uses. If only one process is active, it will fill up the entire available memory if needed. This is normal and desirable. NT is responsible for sharing the physical memory among processes. If too many processes are active, causing paging to occur, there is not enough physical memory installed in the system.
- Virtual Memory
This is the total amount of space used by the process. Typically, it is significantly larger than the installed physical memory. The total of all virtual memory must fit within the swap space + the D3 file space, else undesirable things may happen.
Essentially 3 kinds of spaces require memory:
- The VME BLOB
The size of the BLOB is the Disk0.D3v size as seen in the D3Virtual directory in the Windows Explorer. The BLOB does not consume swap space, because it is a real NT file. However it does show up in the Virtual memory. It is therefore normal to have a large Virtual memory as soon as the BLOB is brought up. The BLOB does (should) not contain data. It should be only as large as the space required for a minimum workspace per process (small if the application is flashed), the spooler jobs (0 if using direct printers) and large items copied to virtual space during a save/restore. The BLOB can be quite small if all data is moved to the FSI, if all applications are flashed, and all printers are direct printers. It also becomes disposable.
- FSI Virtual File Cache (this is not the NT file cache)
FSI files are mapped by 64 K segments (16 frames) into memory. By default, the limit of how much data can be mapped is about 1.5 GB. This space shows up in the Virtual memory, but does not consume swap space, because it too is supported by real NT files. The size of this cache is controlled by the registry value MaxMemory in the key D3Fsi, expressed in K (1,000).
Note: On large systems, we are discovering it is a good idea to limit this cache to about 300,000K (300MB). On WIN95, because of a Windows 95 bug, it may have to be dropped much lower. We are still looking into some issues with WIN95.
Each running thread will carve a heap of at least 256K. This space shows up in the virtual memory and does consume swap space. There is no limit on the size of the heap for each thread. 100 users will consume up to 25M of memory. If they don’t use it, it goes away to the swap. If they use more, more physical memory will be needed. ‘Nt_pinfo’ gives an indication of how much memory a thread uses.
To help reduce memory foot print:
-The VME
The BLOB (VME) is the biggest offender. Reduce it as much as possible by moving data out to the FSI, Flash the application and use direct NT printers whenever possible. You will require overflow space in the VME for such operations as spooler space (when creating print hold files, or using the ‘STARTPTR’ command), general user workspace (sorts/selects), and Pick backup/restore operations (requires overflow the size of the largest item in a file). To help preserve your overflow space in the VME, ensure you perform proper D3 shutdowns, and if necessary, perform /restore operations to the VME to reclaim any lost (dirty) overflow space. Ideally, the VME should never be larger than 200MB (adequate for a 80 user system) and perhaps as little as 32 MB for 10 user system.
-The FSI
The amount of memory used by the FSI can be restricted by adding a string to the System Registry: HKEY_LOCAL_MACHINE> SOFTWARE> PickSystems> D3>CurrentVersion> D3fsi labeled ‘MaxMemory’. It is suggested to make MaxMemory a little larger than your physical memory. For example, if your system has 64MB of physical memory installed, create the string MaxMemory in the above path, and for ‘Value Data’ enter ‘68000’ (represented in K bytes) to represent 68 MB of memory that the FSI may use.