por Roberto Cavalcanti

A performance do SQL Server depende grandemente da performance do subsistema de I/O. O SQL Server normalmente precisa constantemente fazer paginação da, e para a memória, o que pode gerar um tráfego de I/O significante. Além desse comportamento com a memória, os logs dos registros manipulados no banco de dados podem ser responsáveis por um nível ainda mais alto de transações de I/O devido à necessidade de se fazer um flush desses dados para disco antes do SQL Server poder declarar a transação como committed. Semelhantemente tempdb é usado para guardar informações de transações DDL (Data Definition Language) pelo engine do SQL Server e por muitas aplicações desenvolvidas para interagir com o SQL Server, causando um uso ainda maior do subsistema de I/O. Dessa forma, é crítico que o seu subsistema de I/O seja configurado para suportar a demanda da carga das suas aplicações. Caso contrário, sua aplicação sofrerá degradação de performance, como temos observado em diversos casos que temos trabalhado recentemente aqui no time de suporte a América Latina (LATAM).

Como saber se o gargalo de I/O está sendo causado pelo subsistema de I/O (muitíssimo bem definido nesses dois white papers escritos por nosso colega Bob Dorr sobre SQL Server 2000 e SQL Server 2005) é algo de fundamental importância, pois podem apenas ser sintomas de problemas em outras partes do SQL Server. Estaremos tratando desses detalhes em um próximo artigo.

Aqui vão algumas dicas de como detectar alguns gargalos de I/O usando contadores de perfmance do perfmon.

PhysicalDisk Object: Avg. Disk Queue Length – representa a média de requisições de leitura e escrita que estão no queue em um disco específico durante o período da coleta dos dados. Caso o seu sistema de I/O esteja sobrecarregado, haverá mais requisições de leitura e escrita esperando a vez deles nessa fila (queue). Se o disk queue length for maior que 2 por disco físico durante o pico de uso do SQL Server, então você deverá estar experimentando um gargalo de I/O

PhysicalDisk Object: Avg. Disk Sec/Read ou Avg. Disk Sec/Write – média de tempo em segundos de leitura ou escrita de data do/no disco. Alguns parâmetros genéricos:

  • Menos do que 10 ms é muito bom.
  • Entre 10 e 20 ms é ok
  • Entre 20 e 50 ms é lento e precisa de atenção
  • Maior que 50 ms é considerado um problema sério de gargalo de I/O

PhysicalDisk: Disk Reads/Sec ou Disk Writes/Sec – é a quantidade de leituras ou escritas no disco. Você precisa manter esse número abaixo de 85% da capacidade do disco, pois o tempo de acesso ao disco cresce exponencialmente além dessa capacidade de 85%.

Esses contadores mostram a performance de I/O a nível de disco físico, mas não a nível de sistema de arquivo. No nosso próximo blog estaremos dando algumas dicas de como fazer o troubleshooting de I/O usando DMVs e que dados devem ser coletados para que o suporte da Microsoft possa mais agilmente te ajudar a descobrir quais são os causadores de degradação da performance das suas aplicações que acessam o SQL Server.