Thanks for the suggestions. A few thoughts on your reply:
Mark A. Parsons wrote:
Not a lot to go on at this point. Off the top of my head ...
- a logic 'bug' in your monProcessWaits-based monitoring code
That's crazy talk! Actually, I'll look at it and try to add some assertions to ensure correctness. The logic is simple:
Query monProcessWaits and stored data in a local data structure in the C++ program
Wait 5 seconds
Re-query and store in a second data structure
Loop through the second structure, find corresponding entry in initial structure, check for differences in waits and time
print out data for processes with > .5 seconds wait time
clear out data structures and repeat process
Arguing against this possibility is that the phenomena I'm seeing is for particular stored procs
- long-running proc's session disconnects from ASE thus removing all entries for said session from monProcessWaits
This isn't happening. I'd see the disconnect/reconnect in the application log
- long-running proc runs a query that takes ~1 second of cpu time to process a query (eg, logical IOs and/or a merge/hash join); there are a ton of reasons why the same exact proc could have wide-ranging performance metrics based on differeing input parameters and/or uneven distribution of indexed data [would suggest monitoring monSysStatement, looking for cpu/wait times per statement]
Unlikely. I can run the same stored procedure by hand with the same parameters and it runs quickly
- long-running proc invokes a (re)compilation cycle (eg, proc is recompiled, exec() statement is compiled, etc) that requires ~1 second of cpu time [assuming this is a ASE 15.x dataserver => (re)compilation overhead can show up in the form of excessive cpu utilization]
That's seems like a possibility. If I set statistics io, time on would this show me that this was happening? The particular stored proc which is called a lot by multiple concurrent processes. Wouldn't I see waits for this type of occurrence? I'll post the stored proc.