A couple of weeks ago I asked about the usefulness of a Memory Profiler for Database Sessions. While I want to have another blog post on that perhaps hashing out what application developers would really like I wanted to about what we have as an option right now if we are trying to profile memory. While it often seems like we have very little info, we really have quite a bit, just as the Feature Request suggest, not always useful. 

So what tools do we have at our disposal today for memory profiling?

onstat -g ses

You could probably make arguments for other onstat's but these really is it for memory profiling.

So let's take a quick look at  onstat -g ses

In this instance we are going to do the  following:

---

select * from customer;

On my server this happened to be session # 36, so let's take a quick peak.

.

So here we have the output. Make sure you see tid on line two of our output, happens to be 350. Thread ID, or tid, can be used for quite a few onstat commands all of which are useful.

Now where this can be useful from a memory profile section is the "Memory pools" section, specifically the list of the components. For all intents and purposes this is the breakout of you sessions memory. The bad news is that the components were all done based on internal structures instead of things that would make a little more sense to someone without code.

Still this at least give you something to pass to IBM Technical Support, to help you identify how Informix might actually be using memory.

This is helpful, but it also indicates why I've gotten as much feedback on the need for a session memory profiler.