Tempo de disco alto no SQL Server

4

Temos um SQL Server 2008 R2 Enterprise Edition dedicado.

A configuração é:

  • D: (arquivos de dados) - armazenados em discos ssd locais (não são os mesmos discos dos arquivos de log) (invasão 10)
  • E: (arquivos de log) - armazenados em discos ssd locais (não são os mesmos discos dos arquivos de dados) (RAID 1)
  • F: (backup do log de transações) - remoto armazenado em uma SAN

Hoje nós movemos nossos arquivos de log para novos discos (de F: para E :). De um volume compartilhado (F: (SAN)) para discos locais dedicados (E :).

O que aconteceu foi que o "tempo de disco", "tempo médio de transferência" e "comprimento médio da fila de gravação de disco" aumentou no volume onde temos os arquivos de dados (D :) (não no volume em que o log arquivos estão localizados).

O volume de dados e o volume de log não compartilham discos, mas compartilham a mesma placa controladora.

"Tempo de inatividade do disco" é baixo para todos os volumes.

Um pensamento é claro que a placa controladora pode estar sobrecarregada. Mas precisamos de mais ideias sobre onde o problema pode estar.

ATUALIZAÇÃO:

O controlador RAID é o DELL PERC H700 (cache de 512 MB). O servidor é um DELL R910 .

Temos cerca de 2.500 transações / seg. nos horários de pico.

O contador "tempo de disco" está em 100% desde que movemos os arquivos de log (mesmo durante o tempo de tráfego baixo).

O "tempo ocioso do disco", no entanto, é de cerca de 98-99% para D: (arquivos de dados) e E: (arquivos de log)

Temos o cache de write-back ativado para o booth dos discos de dados e dos discos de log.

As estatísticas de espera são assim:

wait_type                     wait_time_s
---------                     ----------- 
BROKER_TASK_STOP               1283336.21 
FT_IFTS_SCHEDULER_IDLE_WAIT     101357.47 
PAGELATCH_EX                     89712.72 
BROKER_TRANSMITTER               75894.76
XE_TIMER_EVENT                   38778.35
REQUEST_FOR_DEADLOCK_SEARCH      38770.35
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 38767.03 
FT_IFTSHC_MUTEX                  38759.14
LOGMGR_QUEUE                     38632.87
CHECKPOINT_QUEUE                 38382.63
BROKER_EVENTHANDLER              35082.42   
XE_DISPATCHER_WAIT               34396.31  
DISPATCHER_QUEUE_SEMAPHORE       33578.68
    
por Patrik 09.02.2011 / 11:36

1 resposta

1

Após mais algumas pesquisas (a verificação aguarda e executa o site com o tráfego de pico), o "problema" descrito acima não foi realmente um problema.

O problema apareceu quando removemos um gargalo (o antigo armazenamento de log). Assim, quando obtivemos discos mais rápidos para os logs de transações, os discos de dados poderiam manipular mais transações / s e, portanto, o comprimento da fila aumentava.

Também explica por que o tempo ocioso do disco foi bom.

O contador "disk time" parece ser praticamente inútil para um sistema de disco rápido (usando cache, etc).

    
por 10.02.2011 / 08:50