What Data Solves Most IBM i Performance Problems?

Based on many real cases, a fairly simple conclusion can be drawn: to solve the majority of application performance problems, you do not need every possible kind of diagnostic data. What you usually need is resource usage data for all jobs at regular intervals, call stack data for jobs using significant CPU, and open file data for jobs using significant CPU.

According to the experience summarized in the GiAPA material, this is sufficient for more than 80% of common performance issues. The remaining cases are often SQL-related, which is why SQL needs its own dedicated analysis path. But for a large part of everyday application performance work, these three kinds of data are enough to move from suspicion to explanation.

You do not need every possible kind of data

This matters because many performance investigations begin with the wrong question. People ask: what should we collect, and can we collect it while the problem is still happening? But if the right data is already being gathered continuously, the whole nature of the investigation changes. You no longer begin by discussing tools, switches, or emergency tracing. You begin by asking what the job was actually doing.

That shift matters. It changes application performance analysis from a reactive, specialist-driven exercise into a much more practical discipline. Of course, continuous collection only makes sense if the overhead is negligible. That is why efficiency matters so much in the collection mechanism itself. One of the key ideas in the GiAPA material is precisely this: collect the relevant data continuously, but do it so efficiently that the overhead remains very small. The documented target here is less than 0.1% CPU, combined with strong compression of the collected data.

Resource usage shows where to begin

Resource usage data gives the broad view. It shows which jobs are active, which jobs consume CPU, which jobs wait, and which parts of the workload behave differently from normal. Without that view, it is very easy to focus on the wrong place. A team may investigate the job that appears slow from the outside, while the actual cause lies elsewhere in the workload.

This kind of data is especially important because performance problems often involve interaction. A delayed job is not always the job creating the problem. Sometimes another job is consuming CPU, creating memory pressure, or triggering storage activity that affects the first one indirectly. Resource usage data makes those relationships much easier to see.

Call stack data shows where the CPU time went

Once a job is identified as CPU-intensive, call stack data becomes extremely valuable. It shows where time is actually being spent inside the job. That often leads much more quickly to the relevant program or routine than general workload data alone.

This matters because many application inefficiencies are not caused by dramatic architectural failures. They are caused by very specific pieces of logic being executed far too often, or in the wrong place, or under the wrong conditions. A job may appear expensive at the surface, but the real issue can be concentrated in one routine, one loop, or one repeated call. Call stack data helps make that visible.

Open file data shows how the job interacts with data

Open file data adds another layer that is often decisive. It shows which files a job is using while the resource usage is taking place. That can expose repeated reads, unnecessary file access, poor access patterns, or interactions with temporary files that would otherwise remain hidden.

This is particularly important because many IBM i performance problems are not purely computational. They arise in the way a job uses data. A job may not consume extreme CPU, but it may still behave inefficiently because it performs a huge number of reads, reopens files unnecessarily, or repeatedly accesses data in a way that creates avoidable cost. Open file data helps explain why the job used resources the way it did.

Together, the three views become much more powerful

The real value appears when these three kinds of data are available together. Resource usage tells you where to look. Call stack data helps show what the CPU-intensive jobs were doing internally. Open file data shows how those jobs interacted with files while that activity took place.

That combination is often enough to answer the practical questions that matter most: where is the inefficiency, how important is it, which issue should be addressed first, and how much runtime or CPU might be saved? This is where application performance work becomes much more useful to programmers, operations staff, and management alike. The point is not simply to produce more reports. The point is to make it easier to move from observation to improvement.

Why this changes the economics of performance work

When the right data is continuously available, performance analysis becomes faster and more focused. You do not have to wait for the problem to happen again under controlled conditions. You do not have to enable heavy tracing only after the fact. And you do not have to rely on memory, intuition, or guesswork to reconstruct what happened.

That is why these three kinds of data matter so much. Not because they are theoretically complete, but because in practice they solve most of the cases that organizations actually struggle with. The result is not just better explanations. It is better prioritization, quicker correction, and a much more realistic way to work continuously with application performance on IBM i.

This article is part of GiAPA’s guide: Why IBM i Application Performance Analysis Feels Hard.

If you want the broader context — why IBM i performance problems often seem difficult, what data makes them easier to explain, and how real cases point to practical improvements — the full guide brings the pieces together.