| Hi Peter,
I've just entered note 2141 which describes how to use SQL/Services memory
debugging. We did some fairly extensive testing of both SQL/Services V7.0 and
Rdb V7.0 to find and fix some fairly bigs leaks in the field test kits, but
these were all fixed before the final kits were shipped. Unfortunately, it
seems you've uncovered something we didn't find in our tests.
I'd start out with the simple test first - turn on the statistics and dump-on-
no-memory flags ($ DEFINE SQLSRV$MEMORY_DEBUG_FLAGS 5 in a process init. file)
to see if SQL/Services is eating memory for each association to which an
executor is assigned. If you see the current count increase between each
association, then its SQL/Services problem. If not, its SQL's, Rdb dispatch's
or the Rdb exec's problem.
Things get tricky if the problem happens for a single association, because the
code only logs stats at the end of an association. If SQL/Services detects a
memory allocation failure, it'll dump a small chunk of all allocated memory to
the executor log file before it terminates. Unfortunately, this doesn't work if
another component detects the problem.
If it turns out that SQL/Services is the problem, then we get to fix it
(assuming it isn't the client that's at fault, eg, by preparing and not
releasing loads of statements). If you determine that SQL/Services isn't the
problem, then it has to be SQL, Rdb dispatch or the Rdb exec. One thing you
could try here is to use remote Rdb to the same system. This will force the Rdb
exec into a separate server process, which will then show whether its SQL or
Rdb client dispatch, or whether its Rdb server dispatch or the Rdb exec. Either
way, if its not SQL/Services, its going to be really hard to figure it out (I
spent a long time with the VAX/VMS heap analyzer and SDA to track down the
leaks in 7.0).
Hope this and note 2141 help get you going on this.
Si
|