At 9:46 +0200 6/16/04, Uwe Frenz wrote: >Ann, >you asked on Tue, 15 Jun 2004 15:27:05 -0400: > >>I get this message sometimes when I run my program: System is low on >>virtual memory.... >If it is just a rare state it may well be worth just to increase the systems virtual >memory. This can be done by inserting some extra RAM (always a good idea, but with >some costs) or by changing some settings. These however depend on the machine >architecture (a PC, WS, Mac or whatever) and on the OS (Win, linux, OS X etc.). >Changing the virtual memory settings does not take no extra costs and uses just a >little time.
Amount of "Virtual" memory is independent of RAM unless one is drastically misusing the term virtual memory. Virtual memory is limited by DISK space and the basic addressing limitations of the CPU. Most CPUs can address at least 2 GB for a single process, so having a few GB of disk space available should make that available to LabVIEW. Adding RAM will make the use of the DISK for memory less frequent and give MUCH better performance but it should run without failing. The only other limitation is running out of internal registers to manage RAM but that is very rare and should not be happening unless you are doing some other very very odd stuff. As a couple steps, 1. Check that LabVIEW is really trying to use a lot of RAM. "Activity Monitor" works well for OS X and I assume that winders has a similar tool. 2. Find out where in LV you are chewing up massive amounts of memory and if this is necessary. The LV profiler works wonders! If you are chewing up a GB of ram in a particular VI it will be very obvious! >Windows nowadays has a default setting 'let windows handle this'. Allthough this is >foolproof in most situations, it has some drawbacks. One of the major culprits is >that AFAIK Windows will just use free space on drive C:. If this free space is >limited, Win has to limit the virtual memory. >So it is not the worst idea to do a system backup, clean the harddisk and defrag it >afterwards. And if one later adds a fixed area as swap file on this or another HD, >this swap file size is than fixed and cannot be limited by temporary files an >garbage. You can optimize to handle massive memory requirements like this, but it is best to decide if you really need all that resources in the first place! -Scott
