Durante o diagnóstico de problemas de desempenho com software de fornecedor que é executado no SQL Anywhere (9.0.2), me deparei com alguns dados interessantes em relação à largura de banda de E / S. De acordo com o manual 9.0.2, a propriedade do banco de dados "CurrIO" mostra "O número atual de I / Os de arquivo que foram emitidos pelo servidor, mas ainda não foram concluídos." No entanto, não está claro qual deve ser esse número, dada a configuração de hardware e / ou a utilização do banco de dados.
Após um pouco de pesquisa, descobri que o manual do SQL Anywhere 10.0.0 entra nessa configuração com mais detalhes em seu capítulo sobre desempenho:
To detect whether I/O bandwidth is a limiting factor, check the CurrIO database statistic. If this statistic is not present on the graph, click the Add Statistics button and select CurrIO. Look for the largest sustained number for this statistic. For example, look for a high plateau on the graph; the wider it is, the more significant the impact. If the graph has sustained values equal to, or greater than 3 + the number of physical disks used by database server, it may indicate that the disk system cannot keep up with the level of database server activity.
Isso está dizendo que, por exemplo, se eu tiver 5 discos no servidor, esse número deve estar idealmente abaixo de 8? O significado deste valor é o mesmo para a versão 9.0.2 como 10.0.0? A razão pela qual eu acho isso difícil de acreditar é que os resultados do comando a seguir estão um pouco fora do meu caso particular:
SELECT db_property ( 'CurrIO' ), db_property ( 'MaxIO' )
O comando acima retorna sobre 900 para o CurrIO e 1150 para o MaxIO. Tenho monitorado esse número por algumas horas e a média é de aproximadamente 950 (graças ao monitor Foxhound do RisingRoad). Essas leituras foram feitas sob o carregamento normal do banco de dados.
A minha largura de banda de E / S é realmente tão inadequada quanto parece, ou estou interpretando mal esses números?
Aqui está a configuração atual do servidor:
SO: Windows Server 2003 R2 de 32 bits
Versão do banco de dados: SQL Anywhere (Adaptive Server Anywhere) 9.0.2.3381
CPU: 4x Intel Xeon Dual Core 3.00GHz
RAM: 26 GB (22 GB alocado para o cache do SQL Anywhere)
HDD (C: /): SO + Localização de Arquivo Temporário
RAID 1
2x 36GB SCSI-320 (15k RPM)
HDD (D: /): Localização do Arquivo DB
RAID 5
4x 73GB SCSI-320 (15k RPM)
HDD (E: /): Arquivo OS Pagefile + localização do arquivo de log (não há registro de espelho)
RAID 5
4x 73GB SCSI-320 (15k RPM)
Notas: O RAID1 e o primeiro RAID5 (D: /) estão no mesmo controlador RAID. Estávamos planejando atualizar o RAID5 com unidades de 146 GB (15k RPM) no RAID10. Essa mudança ajudaria nosso aparente problema de largura de banda de E / S?
Ao lidar com RAIDs, os contadores de disco tradicionais no perfmon podem retornar resultados enganosos. Eles mostrarão E / S de cache em vez de E / S de disco. Portanto, verifique também o contador % Idle Time . Este será provavelmente o resultado mais preciso, mas será invertido (menor porcentagem é igual a discos mais ocupados)
A estatística CurrIO não é segura em SMP em SA. Você seria melhor olhar os contadores "PhysicalDisk" fornecidos pelo Windows perfmon. Em particular: "Comprimento atual da fila de disco", "Comprimento médio da fila de disco", "Comprimento médio da fila de gravação de disco" e "Comprimento médio da fila de leitura de disco".
Não sei de onde veio o valor "3 + # discos". Se você espera que muitos IO sejam feitos em uma unidade, é muito razoável ter várias IOs pendentes nessa unidade.
Outra maneira de ver o quanto a E / S está sendo executada pelo banco de dados é observar as estatísticas do cache. Se o banco de dados estiver lendo a partir do cache, ele não está fazendo tanta E / S de disco. As duas propriedades de db que podem ser visualizadas são "CacheRead" e "CacheHits", assim:
SELECT db_property ( 'CacheRead' ), db_property ( 'CacheHits' )
O manual do SQL Anywhere 10.0.0 recomenda pelo menos uma porcentagem de acertos de cache de 70%. Se estiver abaixo disso, talvez seja necessário alocar mais cache para o servidor. Você pode obter a porcentagem diretamente assim:
SELECT STRING(((db_property ( 'CacheHits' ) / db_property ( 'CacheRead' )) * 100), '%')
No meu caso particular, quando o banco de dados tinha um cache de 22 GB, a porcentagem de acertos era de aproximadamente 58%. Depois de definir o cache para 55 GB, a porcentagem de acertos foi de até 97%. Embora os números exatos da propriedade "CurrIO" e "MaxIO" possam estar incorretos, a queda relativa também foi drástica após essa alteração.
Tags performance sqlanywhere