Rendimiento del servidor SQL: PREEMPTIVE_OS_DELETESECURITYCONTEXT tipo de espera dominante

Ayer recibí una llamada de un cliente que se quejaba del uso elevado de la CPU en su SQL Server. Estamos utilizando SQL Server 2012 64 bit SE. El servidor ejecuta Windows Server 2008 R2 Standard, 2.20 GHz Intel Xeon (4 núcleos), 16 GB de RAM.

Después de asegurarme de que el culpable era de hecho SQL Server, eché un vistazo a las esperas superiores para la instancia usando la consulta DMV aquí . Las dos esperas principales fueron: (1) PREEMPTIVE_OS_DELETESECURITYCONTEXTy (2) SOS_SCHEDULER_YIELD.

EDITAR : Aquí están los resultados de la "consulta de espera superior" (aunque alguien reinició el servidor esta mañana en contra de mis deseos):

Hacemos muchos cálculos / conversiones intensas, así que puedo entender SOS_SCHEDULER_YIELD. Sin embargo, tengo mucha curiosidad sobre el PREEMPTIVE_OS_DELETESECURITYCONTEXTtipo de espera y por qué podría ser el más alto.

La mejor descripción / discusión que puedo encontrar sobre este tipo de espera se puede encontrar aquí . Menciona:

Los tipos de espera PREEMPTIVE_OS_ son llamadas que abandonaron el motor de la base de datos, generalmente a una API Win32, y realizan código fuera de SQL Server para diversas tareas. En este caso, está eliminando un contexto de seguridad utilizado anteriormente para el acceso a recursos remotos. La API relacionada en realidad se llama DeleteSecurityContext ()

Que yo sepa, no tenemos recursos externos como servidores vinculados o tablas de archivos. Y no hacemos ninguna suplantación, etc. ¿Podría una copia de seguridad haber causado que esto aumentara o tal vez un controlador de dominio defectuoso?

¿Qué diablos podría hacer que este sea el tipo de espera dominante? ¿Cómo puedo seguir este tipo de espera?

Edición 2: Revisé el contenido del Registro de seguridad de Windows. Veo algunas entradas que pueden ser de interés, pero no estoy seguro de si son normales:

Special privileges assigned to new logon.

Subject:
    Security ID:        NT SERVICE\MSSQLServerOLAPService
    Account Name:       MSSQLServerOLAPService
    Account Domain:     NT Service
    Logon ID:       0x3143c

Privileges:     SeImpersonatePrivilege

Special privileges assigned to new logon.

Subject:
    Security ID:        NT SERVICE\MSSQLSERVER
    Account Name:       MSSQLSERVER
    Account Domain:     NT Service
    Logon ID:       0x2f872

Privileges:     SeAssignPrimaryTokenPrivilege
            SeImpersonatePrivilege

Edición 3 : @Jon Seigel, como solicitó, aquí están los resultados de su consulta. Un poco diferente al de Paul:

Edición 4: Lo admito, soy el primer usuario de Extended Events. Agregué este tipo de espera al evento wait_info_external y vi cientos de entradas. No hay texto sql o identificador de plan, solo una pila de llamadas. ¿Cómo puedo seguir rastreando la fuente?

Sé que esta pregunta, basada en el Título, se refiere principalmente al tipo de espera PREEMPTIVE_OS_DELETESECURITYCONTEXT, pero creo que es una mala dirección del verdadero problema que es " un cliente que se quejaba de un alto uso de CPU en su servidor SQL ".

La razón por la que creo que centrarse en este tipo de espera específico es una búsqueda inútil es porque aumenta con cada conexión realizada. Estoy ejecutando la siguiente consulta en mi computadora portátil (lo que significa que soy el único usuario):

SELECT * 
FROM sys.dm_os_wait_stats
WHERE wait_type = N'PREEMPTIVE_OS_DELETESECURITYCONTEXT'

Y luego hago lo siguiente y vuelvo a ejecutar esta consulta:

• abrir una nueva pestaña de consulta
• cierre la nueva pestaña de consulta
• ejecute lo siguiente desde un indicador de DOS: SQLCMD -E -Q "select 1"

Ahora, sabemos que la CPU es alta, por lo que debemos ver qué se está ejecutando para ver qué sesiones tienen una CPU alta:

SELECT req.session_id AS [SPID],
       req.blocking_session_id AS [BlockedBy],
       req.logical_reads AS [LogReads],
       DB_NAME(req.database_id) AS [DatabaseName],
       SUBSTRING(txt.[text],
                 (req.statement_start_offset / 2) + 1,
                 CASE
                     WHEN req.statement_end_offset > 0
                        THEN (req.statement_end_offset - req.statement_start_offset) / 2
                     ELSE LEN(txt.[text])
                 END
                ) AS [CurrentStatement],
       txt.[text] AS [CurrentBatch],
       CONVERT(XML, qplan.query_plan) AS [StatementQueryPlan],
       OBJECT_NAME(qplan.objectid, qplan.[dbid]) AS [ObjectName],
       sess.[program_name],
       sess.[host_name],
       sess.nt_user_name,
       sess.total_scheduled_time,
       sess.memory_usage,
       req.*
FROM sys.dm_exec_requests req
INNER JOIN sys.dm_exec_sessions sess
        ON sess.session_id = req.session_id
CROSS APPLY sys.dm_exec_sql_text(req.[sql_handle]) txt
OUTER APPLY sys.dm_exec_text_query_plan(req.plan_handle,
                                        req.statement_start_offset,
                                        req.statement_end_offset) qplan
WHERE req.session_id <> @@SPID
ORDER BY req.logical_reads DESC, req.cpu_time DESC
--ORDER BY req.cpu_time DESC, req.logical_reads DESC

Normalmente ejecuto la consulta anterior tal como está, pero también podría cambiar qué cláusula ORDER BY se comenta para ver si eso da resultados más interesantes / útiles.

Alternativamente, puede ejecutar lo siguiente, basado en dm_exec_query_stats, para encontrar las consultas de mayor costo. La primera consulta a continuación le mostrará consultas individuales (incluso si tienen varios planes) y está ordenada por Tiempo promedio de CPU, pero puede cambiarla fácilmente para que sea Lecturas lógicas promedio. Una vez que encuentre una consulta que parece que está tomando muchos recursos, copie el "sql_handle" y el "Statement_start_offset" en la condición WHERE de la segunda consulta a continuación para ver los planes individuales (puede ser más de 1). Desplácese hacia el extremo derecho y suponiendo que haya un plan XML, se mostrará como un enlace (en modo de cuadrícula) que lo llevará al visor del plan si hace clic en él.

Consulta # 1: Obtener información de consulta

;WITH cte AS
(
   SELECT qstat.[sql_handle],
          qstat.statement_start_offset,
          qstat.statement_end_offset,
          COUNT(*) AS [NumberOfPlans],
          SUM(qstat.execution_count) AS [TotalExecutions],

          SUM(qstat.total_worker_time) AS [TotalCPU],
          (SUM(qstat.total_worker_time * 1.0) / SUM(qstat.execution_count)) AS [AvgCPUtime],
          MAX(qstat.max_worker_time) AS [MaxCPU],

          SUM(qstat.total_logical_reads) AS [TotalLogicalReads],
   (SUM(qstat.total_logical_reads * 1.0) / SUM(qstat.execution_count)) AS [AvgLogicalReads],
          MAX(qstat.max_logical_reads) AS [MaxLogicalReads],

          SUM(qstat.total_rows) AS [TotalRows],
          (SUM(qstat.total_rows * 1.0) / SUM(qstat.execution_count)) AS [AvgRows],
          MAX(qstat.max_rows) AS [MaxRows]
   FROM sys.dm_exec_query_stats  qstat
   GROUP BY qstat.[sql_handle], qstat.statement_start_offset, qstat.statement_end_offset
)
SELECT  cte.*,
        DB_NAME(txt.[dbid]) AS [DatabaseName],
        SUBSTRING(txt.[text],
                  (cte.statement_start_offset / 2) + 1,
                  CASE
                      WHEN cte.statement_end_offset > 0
                          THEN (cte.statement_end_offset - cte.statement_start_offset) / 2
                      ELSE LEN(txt.[text])
                  END
                 ) AS [CurrentStatement],
        txt.[text] AS [CurrentBatch]
FROM cte
CROSS APPLY sys.dm_exec_sql_text(cte.[sql_handle]) txt
ORDER BY cte.AvgCPUtime DESC

Consulta # 2: Obtener información del plan

SELECT  *,
        DB_NAME(qplan.[dbid]) AS [DatabaseName],
        CONVERT(XML, qplan.query_plan) AS [StatementQueryPlan],
        SUBSTRING(txt.[text],
                  (qstat.statement_start_offset / 2) + 1,
                  CASE
                        WHEN qstat.statement_end_offset > 0
                        THEN (qstat.statement_end_offset - qstat.statement_start_offset) / 2
                        ELSE LEN(txt.[text])
                  END
                 ) AS [CurrentStatement],
        txt.[text] AS [CurrentBatch]
FROM sys.dm_exec_query_stats  qstat
CROSS APPLY sys.dm_exec_sql_text(qstat.[sql_handle]) txt
OUTER APPLY sys.dm_exec_text_query_plan(qstat.plan_handle,
                                        qstat.statement_start_offset,
                                        qstat.statement_end_offset) qplan
-- paste info from Query #1 below
WHERE qstat.[sql_handle] = 0x020000001C70C614D261C85875D4EF3C90BD18D02D62453800....
AND qstat.statement_start_offset = 164
-- paste info from Query #1 above
ORDER BY qstat.total_worker_time DESC

SecurityContext es utilizado por el servidor sql en varios lugares. Un ejemplo que ha nombrado son los servidores vinculados y las tablas de archivos. ¿Quizás estás usando cmdexec? ¿Trabajos del Agente SQL Server con cuentas proxy? ¿Llamar a un servicio web? Los recursos remotos pueden ser muchas cosas divertidas.

Los eventos de suplantación pueden registrarse en el evento de seguridad de Windows. Podría ser que estás encontrando una pista allí. Además, es posible que desee comprobar la grabadora de blackbox, también conocida como eventos extendidos.

¿Ha verificado si estos tipos de espera son nuevos (y en conexión con la CPU alta) o si son normales para su servidor?