sp_PerfCheck Phase 2+3: real wait analysis, sane thresholds, trace-flag interpretation, tunable parameters - #837
Merged
Conversation
…lds, trace-flag interpretation Health-check depth on the cumulative/config signals (live problems remain sp_PressureDetector's job). Wait stats (6001): stop labeling every wait a flat "High Impact Wait Type". Name the finding by category so the list reads as a diagnosis (Storage / Lock / Memory / TempDB / CPU / Transaction Log / Parallelism ...), put the wait type and its meaning in object_name, and calibrate severity by category: resource-pressure waits earn High by dominating uptime OR by long average waits; parallelism tops out at Medium (it's a cost-threshold/MAXDOP symptom); the rest stay Low. Idle-box CXCONSUMER drops from a flagged wait to a Low "Parallelism Waits" note. Storage (3001/3002/3003): the slow-read/write thresholds defaulted to 500ms, which is catastrophic-storage territory, so real latency never surfaced. Drop to 20ms (data-file I/O should be under 20ms), with High at 5x (100ms). Memory grants (4101/4103): these are cumulative counts since startup, so firing High on any count > 0 over-reacts to a handful of transient events. Scale severity with magnitude instead. Trace flags (1012, new): the global flags were only listed in server-info. Interpret the notable ones with per-flag meaning and severity -- 1211/3608/ 3609 High, 1224/834 Medium, redundant-on-2016+ ones (1117/1118/2371) and behavior-changers (4199/8048) Low -- leaving benign flags in the list only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The inaccessible-database tests took a database OFFLINE without ROLLBACK IMMEDIATE, so any open connection made the ALTER wait indefinitely and the suite hung (300s subprocess timeout). Force it, so the transition is immediate and the test can't hang in CI. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The values calibrated in Phase 2 were still hardcoded. Expose the tunable ones as parameters (defaults = the Phase 2 values, so default behavior is unchanged), letting a caller adjust to their environment: @slow_read_ms / @slow_write_ms storage latency (ms) @significant_wait_threshold_pct floor for a wait to be reported @wait_high_pct / @wait_medium_pct resource-wait severity bands @memory_grant_warning / _critical forced-grant severity bands Each defaults NULL or negative back to its documented value, so a caller can override just the ones they care about. Help text (description / valid inputs / defaults) covers all seven. The secondary avg-ms wait bands and the grant- timeout bands stay internal for now. Compiles on all five versions; the assertion harness passes 39/39. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
erikdarlingdata
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Making sp_PerfCheck useful, as a health check (cumulative/config signals). Live problems stay sp_PressureDetector's job. Three phases, held for a HammerDB validation on 2025 before merge.
Phase 1 (already merged, #836)
Cut the checklist noise and inverted the backwards config logic — a 27-finding run dropped to 10, all meaningful.
Phase 2 — depth on the signals
Storage-Related Waits,Lock / Blocking Waits,Memory-Related Waits,TempDB Contention Waits,CPU / Scheduling Waits,Transaction Log Waits,Parallelism Waits), the wait type + meaning inobject_name, severity calibrated per category.Phase 3 — tunable thresholds
The calibrated values are now parameters (defaults unchanged, so default behavior is identical):
@slow_read_ms,@slow_write_ms,@significant_wait_threshold_pct,@wait_high_pct,@wait_medium_pct,@memory_grant_warning,@memory_grant_critical. Each defaults NULL/negative back to its documented value;@helpdocuments all seven.Plus a harness fix: force
SET OFFLINEwithROLLBACK IMMEDIATEso the inaccessible-database tests can't hang.Compiles on all five versions; assertion harness 39/39. Storage/memory behavior is best seen under load — that's the HammerDB run.
🤖 Generated with Claude Code