none
Rendimiento lento RRS feed

  • Pregunta

  • ola a todos, 

    una pregunta :

    He abierto el activity monitor y encuentro que el network I/O esta por encima de los 1476 cumulative wait time,  el buffer I/O entre los 883 y el logging  por encima de los 1200 cumulative wait .

    Algunos usuarios dicen que esta lento el sistema ?

    que me recomiendan verificar para dar una sugerencia a esta solucion?

    saludos,

     


    Indet
    lunes, 12 de diciembre de 2011 14:45

Respuestas

  • Eso no aporta mucho porque son valores acumulados desde el último reinicio. Deberías tomar valores delta de los tiempos de espera cuando los usuarios se estén quejando para ver qué es exactamente lo que está provocando más retrasos en la ejecución de las instrucciones.

    De todos modos, te puede venir bien la lectura de este artículo (http://www.sqlserversi.com/2011/12/sql-server-va-lento-rendimiento.html) como una primera aproximación

    lunes, 12 de diciembre de 2011 14:59
  • Añádiendo al comentario de Carlos...

    Cuando tengas los problemas en tu base puedes ejecutar esto:

    SELECT tx.[text] AS [Executing SQL], wt.session_id, wt.wait_duration_ms,
    wt.wait_type,             case
                            when wt.wait_type like N'LCK_M_%' then N'Lock'
                            when wt.wait_type like N'LATCH_%' then N'Latch'
                            when wt.wait_type like N'PAGELATCH_%' then N'Buffer Latch'
                            when wt.wait_type like N'PAGEIOLATCH_%' then N'Buffer IO'
                            when wt.wait_type like N'RESOURCE_SEMAPHORE_%' then N'Compilation'
                            when wt.wait_type = N'SOS_SCHEDULER_YIELD' then N'Scheduler Yield'
                            when wt.wait_type in (N'LOGMGR', N'LOGBUFFER', N'LOGMGR_RESERVE_APPEND', N'LOGMGR_FLUSH', N'WRITELOG') then N'Logging'
                            when wt.wait_type in (N'ASYNC_NETWORK_IO', N'NET_WAITFOR_PACKET') then N'Network IO'
                            when wt.wait_type in (N'CXPACKET', N'EXCHANGE') then N'Parallelism'
                            when wt.wait_type in (N'RESOURCE_SEMAPHORE', N'CMEMTHREAD', N'SOS_RESERVEDMEMBLOCKLIST') then N'Memory'
                            when wt.wait_type like N'CLR_%' or wt.wait_type like N'SQLCLR%' then N'CLR'
                            when wt.wait_type like N'DBMIRROR%' or wt.wait_type = N'MIRROR_SEND_MESSAGE' then N'Mirroring'
                            when wt.wait_type like N'XACT%' or wt.wait_type like N'DTC_%' or wt.wait_type like N'TRAN_MARKLATCH_%' or wt.wait_type like N'MSQL_XACT_%' or wt.wait_type = N'TRANSACTION_MUTEX' then N'Transaction'
                            when wt.wait_type like N'SLEEP_%' or wt.wait_type in(N'LAZYWRITER_SLEEP', N'SQLTRACE_BUFFER_FLUSH', N'WAITFOR', N'WAIT_FOR_RESULTS') then N'Sleep'
                            else N'Other'
                      end as wait_category,

          wt.resource_address, wt.blocking_session_id, wt.resource_description

    FROM sys.dm_os_waiting_tasks AS wt INNER JOIN sys.dm_exec_connections AS ec

       ON wt.session_id = ec.session_id

    CROSS APPLY

       (SELECT * FROM sys.dm_exec_sql_text(ec.most_recent_sql_handle)) AS tx

    WHERE wt.session_id > 50 AND wt.wait_duration_ms > 0

     

    O montar un proceso que guarde la salida en una tabla cada medio minuto... luego nos pasas el resultado y te ayudamos a entenderlo...


     Norman M. Pardell 

    ||Microsoft Certified IT Professional|| Database Administrator. Database Developer. SQL Server 2008


    lunes, 12 de diciembre de 2011 15:24
  • Hola. Revisa por favor, en el Activity Monitor, la parte de queries a ver si ves algo "anormal", desde la perspectiva de queries que tarden más de lo acostumbrado. Complementa el artículo que te sugiere Carlos con este otro: http://msdn.microsoft.com/en-us/library/dd672789(v=SQL.100).aspx.

    Nos cuentas...

    Saludos,

     

     


    Guillermo Taylor F.

    IT Pro & Xbox gamer

    My blog

    lunes, 12 de diciembre de 2011 15:40
  • Que tengas altos valores de CXPACKET indican que las consultas tienen que esperar por paralelismo. La solución a esto NO pasa por reducir directamente el nivel de paralelismo de la consulta o del servidor (como he leído en muchos sitios), sino en investigar porqué consultas que en principio deberían tratar con pocos datos (como suele ser en los sistemas OLTP), SQL Server decide que es más práctico "particionar" el tratamiento de los registros en distintos hilos porque de esa forma en principio es más óptimo.

    Es decir, deberías detectar estas consultas pesadas a nivel de CPU y tratar de optimizarlas, probablemente añadiendo índices útiles o reescribiéndolas para se pueda crear un plan de ejecución mejor.

    lunes, 12 de diciembre de 2011 15:54
  • Añadiendo a lo de Carlos, si no supieras determinar el paralelismo de tu servidor puedes ejecutar esta consulta para orientarte:

    Calculo del paralelismo:
    select case
             when cpu_count / hyperthread_ratio > 8 then 8
             else cpu_count / hyperthread_ratio
           end as optimal_maxdop_setting
    from sys.dm_os_sys_info;

    Pero no modifiques el paralelismo como primera instancia, coincido con Carlos, ajusta para las consultas pesadas que producen el problema el MAXDOP. tedejo un enlace: http://support.microsoft.com/kb/329204/es

    Cuidado con los ASYNC_NETWORK_IO, Los errores tipo: ASYNC_NETWORK_IO (observados en versiones, SQL Server 2005 y superiores) y

    NETWORKIO (observados en SQL Server 2000) suelen estar asociados con alguna aplicación que no es lo suficientemente rápida para

    procesar los resultados devueltos por SQL Server.

     


     Norman M. Pardell 

    ||Microsoft Certified IT Professional|| Database Administrator. Database Developer. SQL Server 2008

    lunes, 12 de diciembre de 2011 16:05

Todas las respuestas

  • Eso no aporta mucho porque son valores acumulados desde el último reinicio. Deberías tomar valores delta de los tiempos de espera cuando los usuarios se estén quejando para ver qué es exactamente lo que está provocando más retrasos en la ejecución de las instrucciones.

    De todos modos, te puede venir bien la lectura de este artículo (http://www.sqlserversi.com/2011/12/sql-server-va-lento-rendimiento.html) como una primera aproximación

    lunes, 12 de diciembre de 2011 14:59
  • ok gracias lo analisare entonces....

     


    Indet
    lunes, 12 de diciembre de 2011 15:23
  • Añádiendo al comentario de Carlos...

    Cuando tengas los problemas en tu base puedes ejecutar esto:

    SELECT tx.[text] AS [Executing SQL], wt.session_id, wt.wait_duration_ms,
    wt.wait_type,             case
                            when wt.wait_type like N'LCK_M_%' then N'Lock'
                            when wt.wait_type like N'LATCH_%' then N'Latch'
                            when wt.wait_type like N'PAGELATCH_%' then N'Buffer Latch'
                            when wt.wait_type like N'PAGEIOLATCH_%' then N'Buffer IO'
                            when wt.wait_type like N'RESOURCE_SEMAPHORE_%' then N'Compilation'
                            when wt.wait_type = N'SOS_SCHEDULER_YIELD' then N'Scheduler Yield'
                            when wt.wait_type in (N'LOGMGR', N'LOGBUFFER', N'LOGMGR_RESERVE_APPEND', N'LOGMGR_FLUSH', N'WRITELOG') then N'Logging'
                            when wt.wait_type in (N'ASYNC_NETWORK_IO', N'NET_WAITFOR_PACKET') then N'Network IO'
                            when wt.wait_type in (N'CXPACKET', N'EXCHANGE') then N'Parallelism'
                            when wt.wait_type in (N'RESOURCE_SEMAPHORE', N'CMEMTHREAD', N'SOS_RESERVEDMEMBLOCKLIST') then N'Memory'
                            when wt.wait_type like N'CLR_%' or wt.wait_type like N'SQLCLR%' then N'CLR'
                            when wt.wait_type like N'DBMIRROR%' or wt.wait_type = N'MIRROR_SEND_MESSAGE' then N'Mirroring'
                            when wt.wait_type like N'XACT%' or wt.wait_type like N'DTC_%' or wt.wait_type like N'TRAN_MARKLATCH_%' or wt.wait_type like N'MSQL_XACT_%' or wt.wait_type = N'TRANSACTION_MUTEX' then N'Transaction'
                            when wt.wait_type like N'SLEEP_%' or wt.wait_type in(N'LAZYWRITER_SLEEP', N'SQLTRACE_BUFFER_FLUSH', N'WAITFOR', N'WAIT_FOR_RESULTS') then N'Sleep'
                            else N'Other'
                      end as wait_category,

          wt.resource_address, wt.blocking_session_id, wt.resource_description

    FROM sys.dm_os_waiting_tasks AS wt INNER JOIN sys.dm_exec_connections AS ec

       ON wt.session_id = ec.session_id

    CROSS APPLY

       (SELECT * FROM sys.dm_exec_sql_text(ec.most_recent_sql_handle)) AS tx

    WHERE wt.session_id > 50 AND wt.wait_duration_ms > 0

     

    O montar un proceso que guarde la salida en una tabla cada medio minuto... luego nos pasas el resultado y te ayudamos a entenderlo...


     Norman M. Pardell 

    ||Microsoft Certified IT Professional|| Database Administrator. Database Developer. SQL Server 2008


    lunes, 12 de diciembre de 2011 15:24
  • Hola. Revisa por favor, en el Activity Monitor, la parte de queries a ver si ves algo "anormal", desde la perspectiva de queries que tarden más de lo acostumbrado. Complementa el artículo que te sugiere Carlos con este otro: http://msdn.microsoft.com/en-us/library/dd672789(v=SQL.100).aspx.

    Nos cuentas...

    Saludos,

     

     


    Guillermo Taylor F.

    IT Pro & Xbox gamer

    My blog

    lunes, 12 de diciembre de 2011 15:40
  • wait_type                              wait_time_s     
     CXPACKET                          5770.31
    WRITELOG                         1347.41
    ASYNC_NETWORK_IO         1324.20
    PREEMPTIVE_OS_PIPEOPS 721.18
    PAGEIOLATCH_SH 699.26
    ok chekea estos son los mas altos que he detectado segun un query que tengo 
    que recomiendas entonces ?

    Indet
    lunes, 12 de diciembre de 2011 15:47
  • Que tengas altos valores de CXPACKET indican que las consultas tienen que esperar por paralelismo. La solución a esto NO pasa por reducir directamente el nivel de paralelismo de la consulta o del servidor (como he leído en muchos sitios), sino en investigar porqué consultas que en principio deberían tratar con pocos datos (como suele ser en los sistemas OLTP), SQL Server decide que es más práctico "particionar" el tratamiento de los registros en distintos hilos porque de esa forma en principio es más óptimo.

    Es decir, deberías detectar estas consultas pesadas a nivel de CPU y tratar de optimizarlas, probablemente añadiendo índices útiles o reescribiéndolas para se pueda crear un plan de ejecución mejor.

    lunes, 12 de diciembre de 2011 15:54
  • Añadiendo a lo de Carlos, si no supieras determinar el paralelismo de tu servidor puedes ejecutar esta consulta para orientarte:

    Calculo del paralelismo:
    select case
             when cpu_count / hyperthread_ratio > 8 then 8
             else cpu_count / hyperthread_ratio
           end as optimal_maxdop_setting
    from sys.dm_os_sys_info;

    Pero no modifiques el paralelismo como primera instancia, coincido con Carlos, ajusta para las consultas pesadas que producen el problema el MAXDOP. tedejo un enlace: http://support.microsoft.com/kb/329204/es

    Cuidado con los ASYNC_NETWORK_IO, Los errores tipo: ASYNC_NETWORK_IO (observados en versiones, SQL Server 2005 y superiores) y

    NETWORKIO (observados en SQL Server 2000) suelen estar asociados con alguna aplicación que no es lo suficientemente rápida para

    procesar los resultados devueltos por SQL Server.

     


     Norman M. Pardell 

    ||Microsoft Certified IT Professional|| Database Administrator. Database Developer. SQL Server 2008

    lunes, 12 de diciembre de 2011 16:05
  • ok en unos minutos les respondo , 

    aunque el resultado anterior lo saque de esta:

     

     

    WITH Waits AS

    (SELECT wait_type, wait_time_ms / 1000. AS wait_time_s,

    100. * wait_time_ms / SUM(wait_time_ms) OVER() AS pct,

    ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS rn

    FROM sys.dm_os_wait_stats

    WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK'

    ,'SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR', 'LOGMGR_QUEUE','CHECKPOINT_QUEUE'

    ,'REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH','BROKER_TASK_STOP','CLR_MANUAL_EVENT'

    ,'CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE', 'FT_IFTS_SCHEDULER_IDLE_WAIT'

    ,'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP'))

    SELECT W1.wait_type,

    CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,

    CAST(W1.pct AS DECIMAL(12, 2)) AS pct,

    CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct

    FROM Waits AS W1

    INNER JOIN Waits AS W2

    ON W2.rn <= W1.rn

    GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct

    HAVING SUM(W2.pct) - W1.pct < 99 OPTION (RECOMPILE); -- percentage threshold

     

    GO


    Indet
    lunes, 12 de diciembre de 2011 16:15