none
Performace counter % Disk Time RRS feed

  • Pregunta

  • Buenos días

    Estoy registrando en el performance de Windows la actividad del disco físico de mi base de datos, entre ésta actividad existe un contador llamado

    Physical Disk: % Disk Time

    Pero los valores que me está registrando son raros, según yo, no deberían de sobrepasar 1, que es el 100%, porque está en porcentaje.

    Alguien sabe porque arroja estos datos. He hecho y deshecho el contador una y otra vez por si había estado cometiendo errores pero nada!.


    saludos

    miércoles, 11 de febrero de 2015 13:53

Respuestas

  • En el primero estas teniendo unos índices muy fragmentados, lo cual se traduce en un mal performance, usa scripts como los de ola para dar mantenimiento a los índices (recuerda es constante no solo lo hagas ahorita, haz un job).

    http://ola.hallengren.com/

    De lo segundo veo que tienes problemas de paralelismo, si es una base transaccional al 100% posiblemente seria bueno que lo pongas en 1 a nivel global

    https://technet.microsoft.com/en-us/library/aa196725(v=sql.80).aspx

    Veo el Pageiolatch pero este ya es mas difícil de decir a simple vista, esto puede ser falta de memoria, presión de memoria, alta paginación o simplemente lentitud de los discos.

    • Marcado como respuesta kakaroto2012 miércoles, 18 de febrero de 2015 15:31
    miércoles, 18 de febrero de 2015 15:22
  • Hola.

    Mi consejo es que monitorices las esperas y las interpretes, empleando los contadores de rendimiento como apoyo para una posterior investigación. Que el disco tenga un problema de rendimiento, cuando está todo en el mismo sitio (sistema operativo, logs, data, tempdb) no permitirá ser muy certero en la identificación del problema. 


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.com
    Sígueme en twitter en http://twitter.com/qwalgrande

    domingo, 15 de febrero de 2015 10:53
    Moderador
  • Mira, la gente parte solo por lecturas, pero no ha comentado lo siguiente: que tipo de sql es? tienes los UPDATE al día? como no vamos a entrar en consumo de memoria y procesador, mi consulta sobre disco duro seria:

    tienes el sistema operativo aparte de la instalación del SQL?

    tienes las bases de datos en particiones diferentes a los de los LOGs?

    tienes la base de datos TEMPDB en una partición diferentes a la de los anteriormente mencionados?

    Cuando hiciste el formateo de la particiones(No donde instalo en sistema operativo) se hizo en formato NTFS y en 64KB, ya que siempre el formateo la gente no lo hace a la recomendación de microsoft:

    Te dejo un link donde te puede apoyar para esto:

    http://builddocs.com/database_servers/building-a-sql-server-2008-r2-database-server/

    Debido a esto solo queda primero mejorar esto para poder después volver a verificar las I/O del disco duro.

    Saludos,

     


    Edwin Duran Ospina

    • Marcado como respuesta kakaroto2012 martes, 17 de febrero de 2015 20:33
    martes, 17 de febrero de 2015 20:22

Todas las respuestas

  • Son milisegundos y tus tiempos están muy altos, tienes el avg disk bytes/sec, avg disk sec/read avg disk sec/write?
    miércoles, 11 de febrero de 2015 14:38
  • Tengo el Avg Disk Queue Length

    y también tengo: Writing Bytes /sec  y Reading Bytes /sec (los que me pides son diferentes)

    Recomiendas que los cambie en mi configuración por los que me indicas?


    saludos



    • Editado kakaroto2012 miércoles, 11 de febrero de 2015 15:04
    miércoles, 11 de febrero de 2015 15:00
  • Esos son los encolamientos, no los tiempos de lectura.
    miércoles, 11 de febrero de 2015 15:01
  • Writing Bytes / Sec

    Reading Bytes / Sec


    saludos

    miércoles, 11 de febrero de 2015 15:15
  • Buenos dias,

    Tambien tenes esta herramienta muy facil de usar que facilmente lo podes comparar con otros server:

    http://www.microsoft.com/en-us/download/details.aspx?id=20163

    Yo la uso mucho con los SQL Servers.

    Saludos.

    miércoles, 11 de febrero de 2015 15:26
  • El problema es que tienes cuanto estas transfiriendo pero sin los tiempos esto no me dice mucho tendras que tomar otra taza para poder ver que esta pasando. Que es lo que estas experimentando?.
    miércoles, 11 de febrero de 2015 15:34
  • De repente hay lentitud, el server tarda en responder.

    Podrías indicarme qué contadores debo agregar pls

    1.-

    % Disk Read Time is the percentage of elapsed time that the selected disk drive was busy servicing read requests.

    % Disk Write Time is the percentage of elapsed time that the selected disk drive was busy servicing write requests.

    2.-

    Avg. Disk sec/Read is the average time, in seconds, of a read of data from the disk.

    Avg. Disk sec/Write is the average time, in seconds, of a write of data to the disk.


    saludos

    miércoles, 11 de febrero de 2015 15:52
  • La captura debe de ser cuando tienes los problemas

    Avg. Disk sec/read

    Avg. Disk sec/write

    Avg. Disk Queue Lenght

    Avg. Disk Bytes/read

    Avg. Disk Bytes/write

    Split IO/Sec

    miércoles, 11 de febrero de 2015 16:05
  • Los voy a colocar, y posteriormente les mando las gráficas

    Saludos


    saludos

    miércoles, 11 de febrero de 2015 16:29
  • Ya los agregue, me queda una duda,

    Los archivos se están escribiendo en otro servidor en red,

    afecta tener varios contadores sobre el servidor de base de datos?


    saludos

    miércoles, 11 de febrero de 2015 19:07
  • Puede llegar a afectar pero no debe de ser un impacto importante.
    miércoles, 11 de febrero de 2015 19:10
  • A verts, ya los tengo° =p

    % Disk Read Time

    % Disk Write Time


    saludos

    viernes, 13 de febrero de 2015 15:24
  • Avg Disk Sec Read

    Avg. Disk Sec Write


    saludos

    viernes, 13 de febrero de 2015 15:26
  • Disk Read Bytes / Sec

    Disk Write Byes / Sec

    A LAS 10 SE GENERAN LOS BACKUPS

    SE TIENEN 10 BASES DE DATOS EN ESE SERVIDOR


    saludos

    viernes, 13 de febrero de 2015 15:30
  • Transacciones x segundo

    Disk Queue Length


    saludos

    viernes, 13 de febrero de 2015 15:33
  • Memory Page / sec

    % Procesor Time Used / sec


    saludos

    viernes, 13 de febrero de 2015 15:35
  • Ahora si Enrrique AA,podrías ayudarme a interpretarlas pls, 

    Lamentablemente el servidor en rack solo tiene un disco duro en espejo con failover, en el cual

    se soporta no solamente las bases de datos de usuarios, temporales, también soporta el sistema operativo

    no tenemos unidades en red.

    =(


    saludos

    viernes, 13 de febrero de 2015 15:38
  • mmmmm que es tu storage (SAN, o discos locales, si es SAN el enlance es por fibra?), en que haces el backup y como estas la distribución de tus archivos, tus tiempos de lectura no son muy bueno .3 segundos para la cantidad de datos que tienes.
    viernes, 13 de febrero de 2015 15:39
  • Hola.

    Mi consejo es que monitorices las esperas y las interpretes, empleando los contadores de rendimiento como apoyo para una posterior investigación. Que el disco tenga un problema de rendimiento, cuando está todo en el mismo sitio (sistema operativo, logs, data, tempdb) no permitirá ser muy certero en la identificación del problema. 


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.com
    Sígueme en twitter en http://twitter.com/qwalgrande

    domingo, 15 de febrero de 2015 10:53
    Moderador
  • Mira, la gente parte solo por lecturas, pero no ha comentado lo siguiente: que tipo de sql es? tienes los UPDATE al día? como no vamos a entrar en consumo de memoria y procesador, mi consulta sobre disco duro seria:

    tienes el sistema operativo aparte de la instalación del SQL?

    tienes las bases de datos en particiones diferentes a los de los LOGs?

    tienes la base de datos TEMPDB en una partición diferentes a la de los anteriormente mencionados?

    Cuando hiciste el formateo de la particiones(No donde instalo en sistema operativo) se hizo en formato NTFS y en 64KB, ya que siempre el formateo la gente no lo hace a la recomendación de microsoft:

    Te dejo un link donde te puede apoyar para esto:

    http://builddocs.com/database_servers/building-a-sql-server-2008-r2-database-server/

    Debido a esto solo queda primero mejorar esto para poder después volver a verificar las I/O del disco duro.

    Saludos,

     


    Edwin Duran Ospina

    • Marcado como respuesta kakaroto2012 martes, 17 de febrero de 2015 20:33
    martes, 17 de febrero de 2015 20:22
  • Bueno aquí unas cosas Edwin lo que dices esta muy bien pero son 60mb de lectura en un pico y 30mb de escritura en una unidad como pico lo cual no es mucho para una unidad de 5400 revoluciones, no al nivel para que este en .3segundos de tiempo de reacción, también la grafica esta tomada en 24 horas y esto dificulta el saber bien los putos.

    Como bien nos dice falta mucha información y saber si existen mas unidades, la distribución lógica de las bases de datos, etc.


    • Editado Enrique AA martes, 17 de febrero de 2015 22:01
    martes, 17 de febrero de 2015 22:01
  • Por supuesto les puedo dar más detalle.

    Sinceramente veo las gráficas y no las puedo interpretar muy bien, no se si sea normal el comportamiento,

    Como lo mencioné anteriormente, es un servidor en rack con un solo disco duro, en el cual, se encuentra el sistema operativo, las bases de datos del sistema, temporales y 10 dbs de usuarios, alli mismo están sus logs y no está particionado.

    No tenemos en capital para comprar una SAN, por lo cual, hemos estado sobreviviendo con esto. Solo tiene un disco espejo con failover automático.

    Tiene dos procesadores con 8 nucleos cada uno y 4GB en RAM.

    si ustedes me lo indican, puedo darles una gráfica en un tiempo determinado para que puedan ver más detalle.



    saludos


    • Editado kakaroto2012 miércoles, 18 de febrero de 2015 12:56
    miércoles, 18 de febrero de 2015 12:53
  • Ok, antes de hacer mas gráficas, revisaste la salud de los discos? alguno te esta reportando problemas? mira con el programa que trae los servidores, o si no lo tienes descarga un programa que trae Intel para ver la salud de los discos de los servidores.

    Después de esto veremos a mas detalle tu lectura. Primero saber el estado de salud del disco.


    Edwin Duran Ospina

    miércoles, 18 de febrero de 2015 13:42
  • Queria terminar algunas cosas antes de comentar.

    Primero, antes de hacer cualquier exploración de superficie, defragmentacion, etc, tendras que detener la base de datos ya que usar estas herramientas cuando la base esta funcionando puede causar corrupción en la misma. Un buen performance estará entre tiempos de respuesta de 5 a 15 milisegundos, un mal tiempo de respuesta se situa en 15 a 25 milesegundos, pero aquí en el peor de los casos tenemos un tiempo de 300 ms. No solo te guíes por estos valores ya que hay mas cosas a ver y puede ser esperado el número alto como picos en algunos momentos.

    Ahora bien como detectas la lentitud, a que le llaman lentitud? en que hora es y que esta pasando. Por lo que veo me supongo que tu actividad diaria empieza a las 7am y termina cerca de las 3pm, a las 10pm veo un pico que parece ser el backup o alguna actividad de alta lectura y escritura.

    Aunque no tengas una SAN seria bueno que tuvieras mas unidades de almacenamiento, mínimo 2 más aunque 3 serian mejor.

    Mover los mdf y ndf a la unidad más grande, los ldf a otra y la tempdb (tanto su mdf y su ldf a otra).


    • Editado Enrique AA miércoles, 18 de febrero de 2015 13:58
    miércoles, 18 de febrero de 2015 13:50
  • Está bien, sin problema alguno, bueno de hecho he estado revisando los discos duros porque yo creo que allí se genera un cuello de botella ya que las gráficas del procesador son bajas, la memoria RAM es estable, y porque sé que la arquitectura de almacenamiento no es la mejor.

    Entonces, por los resultados de algunas gráficas he movido el fill factor en las tablas que tienen updates constantes entre 85 y 90%.

    De lado de la programación, los desarrolladores también está trabajando para hacer algunas mejoras, sin embargo, sigo buscando eficiencia.

    Yo quisiera meter más discos duros, pero no es sencillo el asunto. 



    saludos

    miércoles, 18 de febrero de 2015 14:12
  • Saludos aun no me defines que es lentitud, un query que se tardaba n segundos y ahora se tarda más o que es lo que esta pasando que nos esta afectando.

    En la base que estas usando corre esto, cambia el db_id('ReportServer')

     

    SELECT a.index_id, name, avg_fragmentation_in_percent
    FROM sys.dm_db_index_physical_stats (DB_ID('ReportServer'), NULL, NULL, NULL , NULL) AS a
       
    JOIN sys.indexes AS b ON a.object_id = b.object_id AND a.index_id = b.index_id order by 3 desc;
    
    GO

    Y si puedes:

    select top 10 *
    from sys.dm_os_wait_stats
    where wait_type not in
    ( 
    'KSOURCE_WAKEUP', 'SLEEP_BPOOL_FLUSH', 'BROKER_TASK_STOP',
    'XE_TIMER_EVENT', 'XE_DISPATCHER_WAIT', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
    'SQLTRACE_BUFFER_FLUSH', 'CLR_AUTO_EVENT', 'BROKER_EVENTHANDLER',
    'LAZYWRITER_SLEEP', 'BAD_PAGE_PROCESS', 'BROKER_TRANSMITTER', 
    'CHECKPOINT_QUEUE', 'DBMIRROR_EVENTS_QUEUE', 'LAZYWRITER_SLEEP', 
    'ONDEMAND_TASK_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'LOGMGR_QUEUE', 
    'SLEEP_TASK', 'SQLTRACE_BUFFER_FLUSH', 'CLR_MANUAL_EVENT',
    'BROKER_RECEIVE_WAITFOR', 'PREEMPTIVE_OS_GETPROCADDRESS', 
    'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'BROKER_TO_FLUSH'
    ) 
    order by wait_time_ms desc

    • Editado Enrique AA miércoles, 18 de febrero de 2015 14:20
    miércoles, 18 de febrero de 2015 14:19
  • Ok. Verifica lo ultimo para descartar totalmente que sea problema físico de disco duro.

    Abre la consola de SQL y abre una New Query y ejecuta el siguiente comando:

    EXEC master..xp_fixeddrives


    Esto te dirá si tienes el espacio suficiente para la instancia.

    Por otro lado me gustaría saber si solo tienes una instancia instalada en el servidor o si tiene varias.

    Ahora si luego de esto todas las prueba salen bien lo que debes ver es por parte del área de Desarrollo. Si tienes la versión de Enterprise en tu empresa trabaja con la herramienta Utility Explorer, SQL Tuning y SQL Perfomance. si no tienes esa versión si no la Standard, debes bajar programas similares.

    Diles al área de desarrollo que mire el numero de conexión por usuario:

       

    SELECT

         CPU            = SUM(cpu_time)

        ,WaitTime
    = SUM(total_scheduled_time)

        ,ElapsedTime
    = SUM(total_elapsed_time)

        ,Reads
    = SUM(num_reads)

        ,Writes
    = SUM(num_writes)

    ,Connections
    = COUNT(1)

        ,[login]
    = original_login_name

    from sys.dm_exec_connections con

    LEFT JOIN sys.dm_exec_sessions
     ses

    ON ses.session_id = con.session_id

    GROUP BY original_login_name

    Luego de esto que miren el numero de conexiones por aplicación:

    SELECT

         CPU            = SUM(cpu_time)

        ,WaitTime
    = SUM(total_scheduled_time)

        ,ElapsedTime
    = SUM(total_elapsed_time)

        ,Reads
    = SUM(num_reads)

        ,Writes
    = SUM(num_writes)

        ,Connections
    = COUNT(1)

        ,Program
    = program_name

    FROM sys.dm_exec_connections con

    LEFT JOIN sys.dm_exec_sessions
     ses

        ON ses.session_id = con.session_id

    GROUP BY program_name

    Revisa el uso del disco duro de las bases de datos:

    USE AdventureWorks2012;
    GO
    EXEC sp_spaceused N'Purchasing.Vendor';
    GO

    saludos,


    Edwin Duran Ospina

    miércoles, 18 de febrero de 2015 14:44
  • Si, estaba en eso, entré  a producción para sacar algunas estadísticas

    Existe un procedure que normalmente se tarda 300 ms, pero cuando reportan lentitud, se tarda 18 segundos.

    Lo sé, porque tengo un trace.trc corriendo, que va registrando todas los comandos ejecutados durante todo el día, (lamentablemente en el mismo disco duro)

    ya estoy ejecutando tus queries, en un momento te los muestro...


    saludos

    miércoles, 18 de febrero de 2015 15:12
  • aqui si no se interpretarlos


    saludos

    miércoles, 18 de febrero de 2015 15:14
  • En el primero estas teniendo unos índices muy fragmentados, lo cual se traduce en un mal performance, usa scripts como los de ola para dar mantenimiento a los índices (recuerda es constante no solo lo hagas ahorita, haz un job).

    http://ola.hallengren.com/

    De lo segundo veo que tienes problemas de paralelismo, si es una base transaccional al 100% posiblemente seria bueno que lo pongas en 1 a nivel global

    https://technet.microsoft.com/en-us/library/aa196725(v=sql.80).aspx

    Veo el Pageiolatch pero este ya es mas difícil de decir a simple vista, esto puede ser falta de memoria, presión de memoria, alta paginación o simplemente lentitud de los discos.

    • Marcado como respuesta kakaroto2012 miércoles, 18 de febrero de 2015 15:31
    miércoles, 18 de febrero de 2015 15:22
  • Es solo una instancia,

    hay espacio suficiente, y las conexiones por usuario y aplicación  se ven bien.


    saludos

    miércoles, 18 de febrero de 2015 15:23
  • Ok, voy a seguir tus consejos, muchas gracias por todo.


    saludos

    miércoles, 18 de febrero de 2015 15:31
  • Mantenme al tanto del performance, una vez hechos los cambios talvez reinicia o limpia el cache para que cree buenos planes. Veremos después de esto como se comporta.
    miércoles, 18 de febrero de 2015 15:33
  • sales!!

    saludos

    miércoles, 18 de febrero de 2015 15:36
  • Afirmo lo mismo que Enrique AA:

    tienes alguna tarea de mantencion?

    Lo puedes hacer parecido a este:

    En el problema de paralelismo lo puedes solución en las propiedades de la instancia.


    Edwin Duran Ospina

    miércoles, 18 de febrero de 2015 15:39
  • Ya empecé con la primera duda,

    Viendo la fragmentación de los índices, estoy reconstruyendo uno que está al 85%

    pero sigue igual, no cambia, eso por qué pasa?

    PK_ClientesTraders


    saludos

    miércoles, 18 de febrero de 2015 15:46
  • Saludos

    Por lo que veo es una PK, es posible que sea un índice clustered, estos no pueden ser defragmentados pues es el orden natural de la tabla, solo puedes hacer esto sobre lo no-clustered, mejor usa los scripts para hacer esto, ir uo por uno tomara tiempo (también a menos de 500 registros posiblemente sql no considere necesario hacerlo pues es mas rápido un scan que un seek).

    miércoles, 18 de febrero de 2015 15:51
  • =0  Okay!


    saludos

    miércoles, 18 de febrero de 2015 16:03
  • Haz una tarea de mantenimiento, esto lo hará por ti!!

    Edwin Duran Ospina

    miércoles, 18 de febrero de 2015 16:07