Kitroot Analyzer
Ahead of a critical launch, performance testing exposed severe CPU pressure on SQL Server. The software vendor attributed it to the database; the internal IT team attributed it to the application. Both positions were reasonable. Neither could be proven.
The pattern will be familiar to CTOs, IT managers and DBAs. When a problem crosses the boundary between application and infrastructure, troubleshooting becomes a debate about responsibility rather than a technical investigation.
High CPU is a symptom, not a diagnosis
A CPU graph shows that a server is busy. It does not show which statements consumed the resources, how often they ran, or whether the cause lies in application logic, indexing or configuration. Intermittent problems make this harder still: by the time engineers investigate, the workload may have returned to normal, and cached plans, transient metrics and the context lost in a restart may be gone.
SQL Server provides capable tools — Extended Events, Dynamic Management Views and Query Store.
The challenge is capturing, correlating and retaining the right information before it is needed.
What the evidence showed
Kitroot Analyzer captured SQL Server activity throughout performance testing. Four contributing factors emerged:
A few queries dominated CPU
Execution-level statistics showed a small number of statements consuming a disproportionate share of processing time.
Excessive database calls
One statement was executed thousands of times without need — a fix for the application team.
Configuration and indexing
Server configuration and index design required corrections on the database side.
Failures outside SQL Server
Further diagnostics separated SQL Server behaviour from failures originating elsewhere in the environment.
With a shared set of facts, the conversation moved from who was responsible to what needed to change.
The outcome
Unnecessary database calls fell substantially, and the teams could distinguish database bottlenecks from application and external-system issues. The improvements were implemented by the responsible engineering teams, guided by the evidence.
Kitroot made the problems visible. The teams made the fixes.
Four questions every team should be able to answer
- Execution history — what ran, how many times, and for how long?
- Resource consumption — which statements used the most CPU, time and logical reads, and what do their execution plans show?
- Attribution — which application, host or login generated the workload?
- Correlation — which errors, deadlocks, waits or resource-pressure patterns occurred at the same time?
Three steps to take before the next incident
- Make applications identifiable. Ask software vendors to set a meaningful Application Name in their SQL Server connection strings.
- Capture evidence in advance. Configure monitoring and retention so that a temporary slowdown leaves a usable diagnostic record.
- Agree on facts before responsibility. Bring application and database teams to the same timeline and statistics — the root cause often involves changes on both sides.
Where Kitroot fits
Kitroot Analyzer collects SQL Server telemetry through Extended Events and performance metrics and retains it on a separate monitoring platform, so a restart does not erase the history. Teams can investigate expensive and repeated queries, deadlocks, errors and workload trends across searchable historical data.
For sensitive environments, Kitroot can run fully on-premises, and collection can be configured to avoid unnecessary business data — although SQL text and diagnostic events should still be treated as sensitive. Specialist SQL Server engineering and virtual DBA services are available when teams want help interpreting the findings.
The aim is not to replace your DBA or your application vendor. It is to give both the same evidence.