SQL Server性能监控工具

Setup

1. Enable the MCP server in Settings (checkbox + port, default 5151) - The port must be between 1024 and 65535. Ports 0–1023 are well-known privileged ports reserved by the operating system. - On save, the app checks whether the chosen port is already in use and warns you if there is a conflict. - On startup, the app verifies the port is available before starting the MCP server. 2. Register with Claude Code:

claude mcp add --transport http --scope user sql-monitor http://localhost:5151/

3. Open a new Claude Code session and ask questions like: - "What servers are being monitored?" - "What are the top wait types on my server?" - "Are there any blocking or deadlock issues?" - "Show me CPU utilization for the last 4 hours" - "What are the most expensive queries by CPU?"

Building from Source

All projects target .NET 10.0.

```

Full Edition (deprecated) — Dashboard app + CLI installer

dotnet build deprecated/Dashboard/Dashboard.csproj dotnet publish deprecated/Installer/PerformanceMonitorInstaller.csproj -c Release ```

---

Quick Start — Lite

1. Download PerformanceMonitorLite-win-Setup.exe — a self-contained build, so there is no .NET runtime to install first.
2. Run the installer — it installs to %LocalAppData%\PerformanceMonitorLite, adds Start Menu and Desktop shortcuts, and registers the app under Apps & Features so it shows up in Windows search and can be uninstalled normally. Auto-update is wired in. Your data goes in %LocalAppData%\PerformanceMonitorLite-Data, a separate folder the installer never touches.
3. Launch from the Start Menu or Desktop shortcut.
4. Click + Add Server, enter connection details, test, save.
5. Double-click the server in the sidebar to connect.

Data starts flowing within 1–5 minutes. That's it. No installation on your server, no Agent jobs, no sysadmin required.

Taking the portable ZIP (PerformanceMonitorLite-<version>.zip) instead? It is a self-contained win-x64 build too, so there is nothing to install first — unzip it anywhere and run PerformanceMonitorLite.exe. A stock Windows Server with no .NET on it at all is fine.

That was not always true: through 3.5.0 the ZIP was a portable build with no runtime of its own, and on a machine without .NET it died on the host’s own You must install .NET to run this application before a line of Lite’s code ran. Pinning the ZIP to win-x64 removed the requirement and halved the download — the old build shipped ~537 MB of runtimes\ for macOS, Linux, ARM and musl targets Windows can never load, which cost far more than bundling the runtime does. See Lite/README.md for the detail.

Upgrading from zip? Click Import Settings then Import Data in the sidebar and point both at your old Lite folder. Settings imports server connections, alert thresholds, SMTP config, and schedules. Data imports historical DuckDB + Parquet archives. Auto-update users (installed via Setup.exe) get updates automatically — no manual import needed.

Warning — upgrading an install older than the data-relocation fix: on those versions Lite kept its data inside the install directory, and re-running Setup.exe over an existing install deletes that directory before the new build ever runs. It takes the DuckDB store, the Parquet archive, the logs, and settings.json with it. Upgrade in place instead: the About button in the left sidebar downloads and applies the update without touching your data, or extract the portable ZIP over your existing copy. From this release on, data lives outside the install directory and is moved there automatically on first start, so Setup.exe is safe again. (Your monitored-server list is unaffected either way — it lives in %ProgramData%\PerformanceMonitorLite\config — and so are the passwords in Windows Credential Manager.)

Always On AG? Enable ReadOnlyIntent in the connection settings to route Lite's monitoring queries to a readable secondary, keeping the primary clear. Enable MultiSubnetFailover for multi-subnet failover scenarios.

Quick Start — Darling (headless)

Darling is the always-on edition for teams that want 24/7 collection without a desktop app driving it: a Windows service collects from your servers around the clock into a central PostgreSQL store (TimescaleDB is detected and adopted automatically for compression and chunk-based retention), and a detached WPF viewer reads that store from any seat. It runs the same monitoring brain as Lite — collectors, alert engine, and analysis pipeline shared at the library level — with alerts over email and webhooks (Teams, Slack, PagerDuty, and generic HTTP POST) and the same MCP tool surface available on request. An optional built-in read-only web dashboard (off by default, its own port 5153) serves the fleet overview, per-server drill-down, and alert history to any browser, so operators can watch the fleet without installing the viewer.

1. Download PerformanceMonitorDarling-<version>.zip from the latest release — the signed service and viewer with the bundled PostgreSQL + TimescaleDB runtime beside the service exe, so a from-zero install needs no database provisioning.
2. Copy darling.sample.json to darling.json and add your servers (and optional SMTP / webhook delivery). In managed mode the service unpacks and runs its own PostgreSQL — no external database to set up.
3. Run the service (console for a trial, or install it as a Windows service). It seeds the store and begins collecting on the same default cadences and retention horizons as a fresh Lite install.
4. Start the Darling Viewer. It is in the same zip, under viewer\, and install-darling.ps1 leaves a Desktop shortcut. On the service host there is nothing to point at anything: it finds the same darling.json, derives the store connection, and opens on the fleet. For a seat on another machine, run --export-viewer-config on the service host and copy the folder it writes.
5. Optionally turn on the two off-by-default surfaces: --enable-web serves the browser dashboard on port 5153, --enable-mcp serves the MCP endpoint on 5152. Both take effect live, no restart.

Never done this before? docs/uat-onboarding.md is the ordered path from a downloaded zip to all three surfaces — the WPF viewer, the web dashboard, and MCP — with the log line, HTTP response, or screen that proves each step worked, and the handful of things that reliably catch people out.

Configuration is a single JSON file with no schedule knobs. See the Darling operator guide for the configuration reference, permissions, and operations.

---

More Screenshots

Lite Configuration

When a second Windows user on the same machine launches Lite, they see the shared servers.json immediately. SQL Auth and Entra MFA passwords are scoped to each user's own Credential Manager, so they'll be prompted once per server; Windows Auth works without any prompt.

---

AWS RDS Parameter Group Configuration

sp_configure is not available on AWS RDS for SQL Server. Features that depend on server-level configuration must be set through AWS RDS Parameter Groups instead.

Blocked process threshold — Enables blocked-process-report collection (the richer XE-sourced blocking detail). Without it the blocked-process-report XE will not fire on RDS, but blocking is still captured by the always-on dmv_blocking_snapshot collector, so the blocking grid and block-chain viewer stay populated regardless.

1. Open the AWS RDS Console and navigate to Parameter groups
2. Create a new parameter group (or modify the one attached to your instance) — Family sqlserver-ee-16.0 (or your edition/version), Type DB Parameter Group
3. Search for blocked process threshold (s) and set it to 5 (seconds)
4. Apply the parameter group to your RDS instance (may require a reboot if the parameter is static)
5. Verify: SELECT c.name, c.value_in_use FROM sys.configurations AS c WHERE c.name = N'blocked process threshold (s)';

Deadlocks — No parameter group configuration is required. The SQL Server deadlock monitor runs automatically on all platforms, and the xml_deadlock_report Extended Event fires without any threshold setting.

Azure SQL Database — The blocked process threshold is fixed at 20 seconds and cannot be changed. The blocked_process_report event fires automatically when blocking exceeds this duration.

---

MCP Server (LLM Integration)

Every edition includes an embedded Model Context Protocol server that exposes monitoring data to LLM clients like Claude Code and Cursor.

The tools answer from the monitor's own collected store, and that is the boundary worth stating up front: no MCP tool runs SQL an AI client wrote against your monitored servers. The handful of write-capable tools (Darling's view authoring, alert tuning, and server onboarding) change the monitor's own configuration, and the only live contact with a monitored server — the analysis plan fetch and the onboarding connection probe — runs the product's own fixed, read-only queries under the same least-privilege monitoring login the collectors use.

Third-Party Components

Edition Comparison

---

Troubleshooting