...I thought I would take a chance on guessing your email address to send you some of my experiences regarding IDS shared memory allocation and DLL's ...maybe something you could include in your blog series on the topic (part 1, part 2, part 3). I had planned to send this as a comment to your blog, but since comments are disabled...(hint, hint ;o)...Thanks Johan.
I'm working with a customer that just took the big step from 7.31 to10.00. The migration went fairly well, but after a week or so they gotproblems with onstat, onmode and oncheck. They got the standard error:
shmat: : operating system errorMapViewOfFileEx: w32ec=487 at nt_shm.c:663Unable to attach to shared memory.Invalid argument
and this seemed to occur when the total shared memory size had grown toaround 1.7GB. They are running 10.00.TC6X2 with /3GB turned on.
We tried applying the KB913409 hotfix and ran this with both 10.00.TC6X2and 10.00.TC7 (because of the fix for IC52767), but we could stillreproduce the problem.
After some experiments, I managed to pinpoint the exact segment causingthe problem and compared the set of DLL's loaded by oninit.exe with theDLL's loaded by the other utilities. I found that there were two DLL's inthe address space occupied by that segment: WINMM.DLL and PSAPI.DLL.
By increasing SHMADD to 34000, that particular address space wasn't usedby IDS and this allowed the customer to allocate all of their memorywithout causing problems for onstat et al.
So, this problem can actually occur even though DLL's are loaded in thecorrect address space and the best way to avoid it is to set SHMADD to ahigher value to make it stay away from those small areas in the system DLLaddress space. Also, I think Informix should consider to:
* make oninit.exe load the same DLL's as the shared memory based utilities. * have oninit.exe stay away from the system DLL address space altogether (not sure that Win32 API allows this in a simple way). * add documentation on the problem with suggestions on increasing SHMADD - maybe even set the minimum value to a higher value than now (like 64M).
About disabling comments. Unfortunately I had to disable comments on the blog the other weekend after getting 150 spam comments in the space of a couple of hours. Each one had to be manually removed. DeveloperWorks has since installed new a captcha mechanism, so I might re-enable them soon when I'm feeling brave. Comments have been temporarily switched off on IDS Experts too.
What Johan's comments show is that there is more than one approach to optimizing shared memory usage on the 32-bit Windows platform. You can rebase DLLs out of the way, but tuning the size of shared memory segments can be equally useful. Thanks to Microsoft not seeming to place a very high priority on DLL base address standards this problem needs to be revisited with almost every operating system service pack. At least 64-bit Windows gets over this problem with 8TB of addressable space.