By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,021 Members | 912 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,021 IT Pros & Developers. It's quick & easy.

Stored Procedures (db2dari.exe) sucking up memory

P: n/a
Helpful folks,

Platform: DB2 UDB v7.2, Win2000, KEEPDARI=YES
I am trying to reduce memory usage of our SP's. We only have 80 or so
SP's but in the Task Manager/Processes display, there are over 200
entries for DB2DARI.EXE. Interestingly, there are many sets of these
entries which have the exact same memory usage size. It would appear
that for many of the SP's, there are multiple copies in memory.
Is there any way I can correlate the PID in this display to find (or
verify) just which SP is spawning multiple times?
Is there any way I can stop this behavior? If only one occurance of
each of the 80 SP's lived in memory, that would make my server much
happier.

Any help or pointers would be much appreciated.

Thanks
Sean

Nov 12 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a

"Scav" <db*****@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
Helpful folks,

Platform: DB2 UDB v7.2, Win2000, KEEPDARI=YES

I am trying to reduce memory usage of our SP's. We only have 80 or so
SP's but in the Task Manager/Processes display, there are over 200
entries for DB2DARI.EXE. Interestingly, there are many sets of these
entries which have the exact same memory usage size. It would appear
that for many of the SP's, there are multiple copies in memory.
Is there any way I can correlate the PID in this display to find (or
verify) just which SP is spawning multiple times?
Is there any way I can stop this behavior? If only one occurance of
each of the 80 SP's lived in memory, that would make my server much
happier.


The fact that some groups of these processes have the same memory size is
definitely related to the particular SP that the DARI process last executed.
But since these DARI processes are shared across all the agents, an agent
needing to run a SP will just pick an idle DARI to run the SP. So the
memory usage of these DARI processes may change over time.

The maximum number of these DARI processes will be the same as the maximum
number of agents that you have configured. This would only occur if every
one of your agents was running a SP at the same time though.

--
Matt Emmerton
Nov 12 '05 #2

P: n/a
Matt,

Thanks a lot for the feedback.
I always thought the MAXDARI dbm cfg parameter controlled how many dari
processes were allowed to run concurrently. I seem to remember getting
an error to this effect, that was resolved when I bumped this value up.

Sean

Nov 12 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.