| |||||||||||||||
SYS(3050) deals with data buffers, not application memory. VFP uses about 17mb of memory for itself. When you run more than one instance of VFP the total application memory does not increase, just the instance count on the dll. Each instance of the application does, however, have its own data memory space and it's that that's controlled by SYS(3050), not the basic application memory although all of these things compete for the memory that's available in the pot.
Your problems do not sound like performance problems, but rather memory corruption problems. It would be best if you could allocate memory so that nobody ever steps on someone else's memory and forces it out to virtual memory on disk which is where both system slowdown and corruption occur.
The primary VFP application needs memory to run the queries and serve up the information to the Foxweb processes that are going to build the pages. It should have sufficient memory to handle that task in both the foreground and background modes. The Foxweb applications do not need much at all in the way of data buffers (which cover both data and variable memory) as they are not going after data at all, but rather massaging a relatively small set of data to make a presentation page to serve to the client application. It would be best if each process had the "sweet spot" amount of memory and that the total memory usage for all the processes were less than the total physical memory available on the machine for application usage.
Let's take your example of a single box running advanced server 2000 with two processors and 2 gb of memory. I think that the Operating system will take the same amount of memory for a one and a two processor box. This is actually easy to check. Just do a "? sys(3050,1) in VFP and you will get the answer. The default return for this is all memory on the machine not reserved for the OS. It should give you a value of about 1.35gb of memory available for application use.
The question then is, how do you best use that memory? Let's start first with the core data server VFP application that's doing the data work. You are right when you say that, beyond a certain point, incremental memory is of very little, if any value. 0.5gb is more than enough for almost everything that I've tested. In fact, 256mb is almost as good as a half gig. Let's stay with the half gig for the moment though. You should explicitly issue this command with that amount of memory for both foreground (sys(3050,1,x) and background (sys(3050,2,x) processing. (The default for background is only a quarter of the default foreground and this can cause some problems as things switch in and out of physical memory. Remember, the goal is to set up the box so that we can have a static physical memory allocation and stay away from the dreaded VM.)
Having taken out the 0.5gb for the basic VFP process we are no left with the foxweb processes. You have six to eight instances running. Let's just say ten to be on the safe side. You have 0.86gb left after making the prime data server process allocation. Ten processes gives you about 90 megs for each process. Even assuming that each Foxweb instance takes it's own memory (on this I'm not sure but let's assume that to be on the safe side), this still leaves available for data for each of ten instances of Foxweb. Again, to be on the safe side, I would limit each of the Foxweb processes using sys(3050,1) and sys(3050,2) to 64mb of memory each. This leaves about 100mb of "safety" space for things like IIS and other small processes. If you still have some problems, you can reduce the Foxweb processes to 48mb easily and probably not suffer any performance penalty at all. Again, their work is not data table intensive, only the data server's work is.
Malcolm Rubel
Director of Sales and Marketing
EPS Software Corp.
13810 Champion Forest Drive
Houston, TX 77069
917.226.4515
| FoxWeb Support Team support@foxweb.com email |