LogoLogo
ReleasesHomepageBlogSlack
3.0
3.0
  • Welcome
  • Concept
  • SQLWATCH Database
    • Requirements
      • Permissions
      • Performance Overhead
      • Storage Utilisation
    • Installation
      • Install with dbatools
      • Install with SqlPackage
      • Install with SSMS
      • Deploy from source code
      • Optional Components
      • Upgrade
      • Removal
      • Downgrade
    • Configuration
    • Known Issues
      • Collation conflict
      • Database drift
      • Login failed error when running disk logger
      • Deadlock when creating database
    • Notifications
      • Checks
      • Actions
      • Reports
      • How To
        • Add or modify check
        • Add or modify action
        • Add or modify report
      • Process Flow
    • Large Environments
  • Central Repository
    • Requirements
      • Performance overhead on the remote instance
      • Permissions
    • Installation
      • Removal
      • Upgrade
    • Configuration
    • Known Issues
  • Power BI Dashboard
    • Requirements
      • Permissions
    • Installation
    • Configuration
    • Known Issues
      • Power BI Load Errors
    • Performance
  • Grafana Dashboard
    • Requirements
    • Installation
    • Configuration
  • Azure Log Analytics Dashboard
    • Concept
    • Requirements
    • Installation
    • Configuration
  • Design Decision
    • Relations
    • Trend Tables
    • Data Types
      • Real Type
    • Primary Keys
    • Data Compression
    • Configuration Items
    • Using Apply instead of Join
  • Reference
    • Data-Tier Application Package
  • Integrations
    • Send notifications to Slack and Teams
    • dbachecks
  • FAQ
    • How do I check if SQLWATCH is running OK?
    • I am not seeing any data in Power BI
    • Can I modify default checks?
    • The app_log is growing fast
Powered by GitBook
On this page

Was this helpful?

  1. SQLWATCH Database
  2. Requirements

Performance Overhead

PreviousPermissionsNextStorage Utilisation

Last updated 5 years ago

Was this helpful?

SQLWATCH is designed with minimum overhead. It utilises where possible and collectors that run every minute by default.

SQL Server The Extended Events architecture enables users to collect as much or as little data as is necessary to troubleshoot or identify a performance problem. Extended Events is configurable, and it scales very well.

I have not observed any performance overhead or increased CPU utilisation over a long period of time. It has also not been reported to me. If you notice anything suspicious please feed back ASAP.

The frequent data collectors such as performance run every minute and take less than a second to execute. There are areas for improvement in the way the XML output from XE sessions is being parsed which will be addressed in the future releases.

The below screenshot shows a 60 seconds window of CPU utilisation of the sqlservr.exe process. The spike is the performance collection which lasts few milliseconds:

Additional Reading:

SQL Server Extended Events (XES)
Dynamic Management Views (DMV)
LogoXEvents overview - SQL Serverdocsmsft
LogoDynamic Management Views (Transact-SQL) - SQL Serverdocsmsft