I'm running Win/UDPE 7.2 for development. When running a program with a few hundred K of variables being tossed around, the connection running the process will die, sometimes just gasping out this message:
Size of memory requested (146157568, 35683 local pages) is too big! The same code (adjusted for platform-specific nuances) runs without a hitch on in another MV environment. It looks like Unidata is attempting to pre-allocate excessive amounts of memory as soon as it sees some volume of actual usage. I've tried tweaking my udtconfig values (restarting Unidata each time). I think the program runs a little longer before it dies but I know I'm not tuning properly and the issue hasn't been bypassed. This isn't isolated. One of our clients running a non-PE (6 user) environment reported the issue and luckily I was able to reproduce it here. I suspect none of the memory allocation values in udtconfig have been changed there either. I am careful to code without abusing resources, not pre-allocating massive arrays or leaving large unused buffers hanging around. I'll check for sloppy code but I'm hoping someone here might be able to point to a config issue. Here are my latest udtconfig values - I'm not cataloging the code for the test, so global cat SH size shouldn't matter. SBCS_SHM_SIZE=1048576 SHM_MAX_SIZE=8388608 SHM_ATT_ADD=0 SHM_LBA=4096 SHM_MIN_NATT=4 SHM_GNTBLS=40 SHM_GNPAGES=256 SHM_GPAGESZ=2048 SHM_LPINENTS=10 SHM_LMINENTS=100 SHM_LCINENTS=100 SHM_LPAGESZ=8 SHM_FREEPCT=25 SHM_NFREES=1 Thank you kindly for any guidance - even a link to a Unidata configuration doc. Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com Nebula R&D sells mv.NET and other Pick/MultiValue products worldwide, and provides related development and training services Visit the blog, lots of recent updates: remove.pleaseNebula-RnD.com/blog ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
