What’s the issue?
Extended Events (XE) is SQL Server’s built-in diagnostic and tracing framework, used to capture detailed information about server activity. SQL Server ships with several system sessions such as system_health and AlwaysOn_health that are designed to run continuously with minimal overhead. This issue refers to custom, user created XE sessions that are actively running on the instance, often left over from past troubleshooting efforts, performance investigations, or temporary audits.Why is this a problem?
Custom XE sessions vary widely in cost depending on which events they capture, how they filter data, and where they write output. Sessions that capture high frequency events (such as sql_statement_completed or lock acquisition events) without proper filtering can generate enormous volumes of data, consume significant CPU and memory, and fill disk volumes if they write to files.Forgotten sessions are particularly dangerous because they continue accumulating overhead and storage long after the original investigation ended. In some cases, poorly configured sessions can degrade performance enough to affect production workloads, which is exactly the opposite of their intended purpose.
What should you do about this?
Identify all running sessions by querying sys.dm_xe_sessions and compare against sys.server_event_sessions to see which are configured to auto start. Filter out the known system sessions and review each custom session with the team or individual who created it to determine whether it is still needed. Stop and drop any sessions that are no longer required, using ALTER EVENT SESSION [SessionName] ON SERVER STATE = STOP; followed by DROP EVENT SESSION [SessionName] ON SERVER;.For sessions that must remain, review their definitions to confirm they use appropriate filters, capture only necessary events, and have reasonable file size and rollover settings.