Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Memory Management of VFP cursor 1

Status
Not open for further replies.

Saurabh.hom

Programmer
Jun 6, 2017
3
0
0
IN
If in the cursor there are 2 fields with c(15) for 'uniqueId' and 'newUniqueId' and
* total no of fields in the cursor may exceed 50 in many cases &
* over 2 lac records
Current Scenario:
At present we have 15 users logged in and the cpu usage shows 27 gb ram being consumed and no. of users is expected to rise above 50.
Please tell me about the memory management in case of cursor taking into account
* memory allocaton ,
* rushmore optimization and
* how will it affect the overall performance?
Thank you.
 
It depends.

Rushmore needs memory per optimized clause and index usage, also the amount of RAM needed depends on the number of records of queried tables, number of queried tables and used fields, so you can predict knowing DBF sizes and exact SQL statements but not without. Get an understanding of the low-level Rushmore mechanism to calculate that, we can't do that for you. Rushmore bitmaps used to be combined with bitwise logic mean 1 bit per record per table per single clause, eg where firstname="A" and lastname="B" means two clauses, two bitmaps of records*1bit size later bit-anded. records here mean all records, not just records fetched, the final bitmap is used to decide what records to fetch, the build up, therefore, has a bit per record, even if some clause already is limiting it to one record anyway. But that calculation will just be the bitmaps, you also need memory for objects and caches, so the predictability of this is quite worthless not knowing the size of tables, too, including all fields. VFP does cache all files of a table; DBF, FPT, and CDX.

27GB is a nice terminal server, each VFP session will take 2GB at max. Since you have 15 users and there also is a session to maintain and perhaps other automated processes like office/outlook, I would just take 1GB of RAM per process, making use of 15GB of the 27GB and leaving the other 12GB for OS and other processes. See how it goes from there. 1GB should be sufficient for many things and VFP will not grab all 1GB at once anyway. See SYS(3054). If you have a bad performance and exceed memory usage, have a logging mechanism to find out what is causing so much memory consumption or even a memory leak of not freeing allocated memory. You can manually trigger garbage collection with SYS(1104) and you can look at allocated memory with SYS(1016). You might find any other reason for stalled processes, eg ActiveX usage, OLE automation. You're never alone on the system, too, and I don't only mean parallel user sessions with that.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top