Wiki Home

sys 3050

Namespace: WIN_COM_API
Category Needs Refactoring

I had a long-time client upgrade his machines to 64-bit Windows 7 with >= 8GB RAM and the logic I'd used from this post below starting failing (error 11). Turns out the value returned was NEGATIVE in some instances. Using ABS() on the 2nd part of the MINIMUM function would prevent the problem (although I'm not sure how low that number would go since this was an apparent overflow condition returned by SYS(3050,x,y) calls).

See Pro Fox thread here for conversation:

Michael Babcock

Sys(3050) solved a problem with our web app that has been nagging me for years now. It would run fine for months on our 2GB machine (Windows Server 2003), and suddenly, the IIS w3wp process would start to hog memory like crazy (1+ GB), and then crash so hard that even iisreset would not help. Only a complete reboot got it starting again. There was no uncommon activity or heavy load, no indication whatsoever as to what would cause this behaviour. Using the worker process recycling option of iis did improve (restarting the w3wp process every 2 hours or so), but still it would happen from time to time. Debugging my app showed that even with complicated queries my app only uses a few MB.

After a lot of digging I stumbled upon the sys(3050) call, and gave it a try. It seems under certain circumstances, VFP has a memory leak on machines with "a lot" of memory (by the standards of yesteryear). Before, the w3wp process would normally use 300-800 MB, even when there was no crash, and >1GB before it crashed. After using sys(3050) in all application objects allowing VFP only 12MB the w3wp process normally uses 20-100 MB, and never goes beyond around 300MB of RAM. The web app now runs stable for a month or so. I did not notice any decrease in performance, actually the contrary. It seems the issue has been fixed by this call.

W.S. (Aug 2012)

The FoxPro help file says:

"SYS(3050) makes it possible for you to optimize Visual FoxPro performance by adjusting the amount of memory Visual FoxPro allocates for the foreground and background buffers. The foreground memory buffer is the memory available to Visual FoxPro when it is operating in the foreground as the currently active application. The background memory buffer is the memory available to Visual FoxPro when it is operating in the background when another application is the foreground application."

Unfortunately, it doesn't point out that increasing the amount of memory actually degrades performance in many cases. What's more, FoxPro's algorithm for setting the default value for SYS(3050) is not appropriate if the computer has 1GB or more of memory. So, it's a good idea to call sys(3050) at the start of all your apps. But what value should you use?

The degree of performance degradation is application-dependent because SYS(3050) does not really affect "the memory available to Visual FoxPro", it only affects the memory used for things like caching tables and indexes. (See Christof's explanation) If you have control over the environment, including amount of installed RAM and other apps that may run while your app is running, you can find the best value by trial and error. Otherwise use the following, as suggested by Paul Lee (and others):

SYS(3050, 1, MIN(536870912, VAL(SYS(3050, 1, 0))))
SYS(3050, 2, MIN(536870912, VAL(SYS(3050, 1, 0))))

It turns out that a value higher than 512M, no matter how much RAM is installed, does not speed things up, and will probably slow things down.

DO NOT USE the old 1/3 rule of thumb. This can cause an error if the machine has more than 6GB of RAM. Although SYS(3050) can return values over 2GB, it will not accept a value that large.
-- Jim Wiggins
Can someone provide a way to prove that SYS(3050) is helping. Can you monitor the page file or something external to VFP? -- Mike Yearwood

General rule of thumb is to use 1/3 of available memory like:

SYS(3050, 1, VAL(SYS(3050, 1, 0)) / 3)

Otherwise (unless something has changed), VFP will try to grab all available memory. This will be especially obvious in long batch like jobs where the system will tend to freeze up unless you use this... -- Claude Fox

I've read all I can find on this. I've not seen a single line of code that PROVES this helps. Seems there should be a little PJX that can be compiled and run on a Citrix box that demonstrates things freezing without SYS(3050) and not freezing with it. -- Mike Yearwood

I don't have an exact test case for you, only experience where it has worked with SYS(3050, 1, VAL(SYS (3050, 1, 0)) / 3) where it didn't before or improved performance, in several cases.

02/07/2008 - Seems to be working well for me with large or small tables sys 3050 largedbf... Stacy Violett

02/07/2008 - VFP8/9 Random memory problem: Paul Lee,
We have documented a problem with VFP8/9 memory handling. One of our fairly involved inventory apps uses lot of memory, strings and complicated functions gave occasional strange random calculations or printing problems on certain customer PCs.

One of my customer has two PCs: one with 384 KB RAM memory (no problem) and the other with 1.25GB (YES random problem). I never had any problems on my PCs - but none of my PCs had RAM memory over 1GB. It seems that VFP8/9 does not manage memory properly with PCs over 1GB.

Here is the way I resolved it. I put the following code at beginning of my program:

SYS(3050, 1, MIN(536870912, VAL(SYS(3050, 1, 0))))
SYS(3050, 2, MIN(536870912, VAL(SYS(3050, 1, 0))))

That limits VFP buffer memory to lesser of available and 1/2 GB.

My desktop 1GB RAM PC had no problems and its VFP had about 0.75 GB available memory, so I put it at 1/2 GB max to be safe.

14/08/2006 - We have got a problem with VFP 6 sessions under Citrix because each VFP session intends to use as much memory as it can, and while running they keep using more memory each time. That limits the amount of PCs that can connect to Citrix Servers (Win 2003).
The problem is resolved using this SYS setting, and now we are limiting to 20 MB for each session. That really limits the "user" memory, and you must add the VFP internal memory (under 25 more MB), so with this 20 MB setting, each session currently consumes no more than 45 MB total and many more clients can connect at the same time.

-- Fernando D Bozzo
So if a VFP app is hitting a SQL backend, it wouldn't actually need as much RAM as if it was trying to build the Rushmore bitmaps itself. So could it be a rule of thumb to reduce the foreground and background caches even further? -- Mike Yearwood

14/08/2006 -
Fernando, we have the same problem with Citrix.
� There is anyway to set the memory limit using Config.FPW?
Fernando Puyuelo
You should at least experiment with SYS(3050). What is happening is that VFP is grabbing system resources as well, which is reponsible for running out of memory. If you limit VFP's memory use, the system will have more memory to work with...

21/08/2006 - Yes, you can put a line like this in Config.FPW:

*-- in Config.FPW
COMMAND = DO Set_Memory.Prg

*-- Set_Memory.Prg
SYS(3050, 1, YourSettingInBytes) && Foreground memory
SYS(3050, 2, YourSettingInBytes) && Background memory

-- Fernando D Bozzo

What exactly is kept in these buffers? Are cursors included? If buffer space runs out, does it just start paging to swapfile?
-- [(William J Johnson)]

VFP 3.0/5.0/6.0 was originally written to work under Windows 9x OSs and its internal memory manager Doesn't Play Well with NT-based OSs. The SYS(3050) hack can help under certain circumstances. It doesn't help if your client doesn't have much memory to begin with. It doesn't help if (for some odd reason) you're still using a Windows 9x OS - and can actually reduce performance in rare cases. It's possible newer versions of VFP than 6.0 have improved memory management but I haven't used those versions.

To test whether the hack works, start VFP w/o the hack, run a complex program with lots of loops, and while it's running try to open a couple of memory-hogging application like Outlook or Word. If the new apps won't open or tend to freeze (more so than usual), then VFP is probably to blame. Close all applications and add the SYS(3050) hack listed above to the Config.FPW file and run the test again. If system performance is noticeably better then the hack worked.

I use the 1/3rd rule but you may want to tweak this if you have GBs of memory available. VFP works OK with a minimum of 50-60 MB memory and probably should never need more than 512MB unless you're working with extremely large databases.

See also Citrix Hints Visual Foxpro Environment Memory Management Function Sys 1101
Category VFP Functions
( Topic last updated: 2013.11.04 11:40:05 AM )