Comprimento da fila de disco alto do Sybase ASE 12.5.2

2

Eu tenho um servidor Sybase ASE 12.5.2 em execução no Windows 2003 que é extremamente lento para a maioria das consultas selecionadas. O sistema é um 2 x Dual Core Xeon, 4GB de memória e 200GB Raid5 (10k SAS Discos) para dados em um controlador megaraid LSI com 128MB de cache + BBU.

A única indicação perceptível no servidor é que o "Comprimento de Fila de Leitura de Disco" fica em 100 no perfmon. Geralmente isso indica um problema com os discos, mas nada parece estar errado com eles.

Alguma idéia do que eu posso fazer para descobrir qual é o problema? Também devo dizer que estou muito mais familiarizado com o Sybase no Solaris, não com o Sybase no Windows.

Aqui está uma captura de tela:

texto alternativo http://img.skitch.com/20090722-t4sgfxd5fb2ck7bbsdjei38uu6.png

Aqui está uma saída sp_sysmon de 40 minutos.

EDIT: Aparentemente, a saída sp_sysmon é muito grande para a área de texto da pergunta de falha do servidor. Aqui está um link para a saída completa: [ link

EDIT: Eu mudei o Screenshot para um que reflete o que está acontecendo muito melhor.

    
por Mark Turner 21.07.2009 / 19:02

3 respostas

3

Olhando para o sysmon, você está tentando fazer 964,2 IOPS,

Total Requested Disk I/Os 964.2 2373.5 2314183

desses 99,2% são contabilizados por este dispositivo, todos os outros dispositivos estão fazendo muito pouco. Todos os seus dispositivos estão no mesmo array físico (D :), mas isso não é um problema se eles não estiverem fazendo nada.

Dispositivo:
    D: \ DTCLASS \ ads \ ads_data01
    ads_data01 por s por contagem de xactos% do total

Reads                                                                       
  APF                           459.9        1132.0     1103670      48.1 %
  Non-APF                       495.8        1220.3     1189821      51.8 %
Writes                            0.8           2.0        1978       0.1 %

Total de E / S 956,4 2354,3 2295469 99,2%

950 IOPS devem estar dentro das capacidades de um ataque a 10 discos 5, particularmente porque todas são leituras. Se permitirmos uma estimativa conservadora de 100IOPS por fuso, temos uma estimativa de 1000 IOPS para esse array. Edit: No entanto, parece que eu tenho interpretado mal o seu post original, assumindo que há 10 discos! Por favor, deixe-nos saber quantos discos estão nesta matriz.

Cache Search Summary Total Cache Hits 1283.3 3158.8 3079829 71.9 % Total Cache Misses 502.2 1236.3 1205348 28.1 %

Você está recebendo muitos erros de cache. Isso me levaria a pensar se você tem memória suficiente atribuída ao ASE. Em janelas com ASE 12.5 você está limitado a aproximadamente 2,6 GB de memória para ASE (seja em janelas de 64 ou 32 bits). Por favor, deixe-nos ver a saída de sp_configure 'memory'. Estou particularmente interessado nesta linha:

max memory 33792 2950000 1475000 1475000 memory pages(2k) dynamic

É possível que você tenha memória suficiente atribuída ao ASE, mas não a adicionou ao cache de dados. Você também pode nos deixar ver a saída de sp_cacheconfig.

Você pode ver desde o início da saída do sysmon que suas CPUs estão gastando a maior parte do tempo lidando com o IO:

Utilização Ocupada do Motor Ocupada pela CPU I / O Ocupada Inativa     Motor 0 2,4% 79,9% 17,7%
    Motor 1 2,0% 75,2% 22,8%

Você também só tem 2 mecanismos atribuídos ao ASE, em um dual dual-core, você pode ir até 4 se este for um servidor dedicado. Embora sua licença não permita isso, como a ASE é licenciada por núcleo .

    
por 29.07.2009 / 16:10
2

parece-me que o comprimento real da sua fila do disco do AVG é 3,554. A escala é configurada para representar graficamente a 100x o valor.

indicações típicas de problemas começam quando esse número é maior que o número de fusos no grupo de ataque.

Eu começaria com procmon do sysinternals para começar a determinar o uso do disco. Eu procuraria em ferramentas específicas para monitorar consultas (desculpe - não sei muito sobre sybase)

    
por 24.07.2009 / 16:10
0

Você pode tentar essa ferramenta de otimização para ajudar a rastrear e solucionar o problema. Ele tem uma avaliação de 14 dias.

    
por 25.07.2009 / 22:49