Melhor maneira de melhorar o desempenho do disco (SQL Server 2000)

1

Estou tendo alguns problemas de acesso ao disco em um aplicativo da Web.

A carga principal é muitas inserções / atualizações / seleções simultâneas em tabelas grandes.

Atualmente, é um único rack 2ru executando o SQL Server 2000 e o IIS, executando um RAID5 com SAS 4x15k para o banco de dados; e 6 GB de ram / 8 núcleos físicos. Os usos da CPU e da memória parecem bons.

Coisas que estou considerando ...

  • passar de nossa invasão atual para uma SAN de muitos discos
  • Ram Drive para arquivos tempdb
  • Agrupar o servidor
  • Atualize o SQL-Server (Acontecerá, eventualmente, independentemente; mas novas palavras-chave úteis devem ajudar muito, no mínimo)
  • ?

Qualquer coisa que eu deveria estar olhando / considerando?

Obrigado     Chris

    
por wom 18.10.2010 / 19:25

5 respostas

2

Algumas coisas. Primeiramente, o armazenamento em cluster do servidor não oferece nenhum benefício de desempenho, apenas aumenta a disponibilidade.

Provavelmente, a coisa mais fácil que você pode fazer para aliviar a E / S de disco é aumentar a memória em seu servidor. À medida que mais páginas de dados são armazenadas na RAM, menos E / S física precisa acontecer para que as consultas sejam executadas.

Dependendo da sua carga de trabalho, se você puder se mudar para uma SAN, provavelmente desejará dividir seu TempDB, logs e arquivos de dados em discos físicos separados (talvez você queira examinar este artigo da MS em torno das 10 melhores práticas de armazenamento do SQL Server: link ). Como Hutch declarou, mova-se para fora do RAID 5, especialmente para logs e TempDB, pois eles possuem grandes quantidades de gravações (o RAID 5 tem uma penalidade de gravação para a paridade).

Como diz Chopper3, as unidades FusionIO são algumas das unidades mais rápidas atualmente. Se você tiver o orçamento para eles, essa é definitivamente uma área a ser explorada (especialmente para seus TempDBs).

HTH, Dan

    
por 18.10.2010 / 20:02
5

Mova seus dados e registros para uma unidade FusionIO , muito muito cara, mas, até onde eu sei, você pode ' t obter armazenamento persistente mais rápido agora.

Ah, e você deve se mudar para 2008R2 de 64 bits, é claro, além de carregar na memória.

    
por 18.10.2010 / 19:32
3

A coisa imediata que vem à mente é procurar converter esse RAID5 para um RAID10 ou um par de RAID1.

    
por 18.10.2010 / 19:31
2

Este é um tópico muito importante, mas posso oferecer algumas dicas para ajudar você a começar. Em geral, acho que é seguro dizer que você precisará coletar informações mais precisas antes de decidir como atacar melhor seu problema. No final, provavelmente será um problema de memória ou de disco.

(Eu ignorarei a possibilidade de examinar as consultas que estão sendo executadas lentamente e tentar descobrir se há maneiras de melhorá-las. Este é um tópico enorme , mas usar o analisador de consulta pode ajudá-lo a determinar se você está faltando um índice ou de uma consulta deve ser completamente reescrito.)

Gostaria de começar usando a Ferramenta administrativa de desempenho para analisar algumas métricas principais. Os contadores de desempenho do SQL Server são um bom local para procurar. As estatísticas fila de disco também podem ser muito reveladoras. Os aplicativos (ou seja, o SQL Server) estão aguardando a E / S do disco para executar operações? Nesse caso, você sabe que precisará atualizar os discos (ou corrigir as consultas, possivelmente). A @Hutch está certa de que o RAID 10 oferecerá melhor desempenho do que o RAID 5 para um servidor de banco de dados, mas na verdade isso só vai entrar em jogo se você estiver esperando por gravações. 4 unidades de 15k RPM em um RAID 5 devem ser capazes de lidar com uma carga razoavelmente razoável com uma placa RAID decente (obviamente, o que é razoável e / ou decente é relativo).

Eu também gostaria de verificar a memória . O servidor está executando o SQL Server 2000, então vou assumir que é um sistema operacional de servidor de 32 bits. O SQL Server realmente é capaz de usar toda essa memória? Em um sistema de 32 bits, você precisará usar PAE para usar todos os 6 GB e, mesmo assim, acredito que o próprio processo do SQL Server só poderá aumentar para 4 GB. Você pode usar um programa como o explorador de processos sysinternals para ver quanta memória está realmente sendo usada. Você pode até ver a quantidade de memória que o SQL Server "quer" - confira os contadores do SQL Server: Gerenciador de memória (se eles estiverem disponíveis em 2000, não consigo me lembrar do topo da minha cabeça).

Você também menciona que o servidor está executando o IIS. Se você estiver executando o MS SQL Server em um servidor que também esteja executando outros serviços altamente carregados, convém examinar manualmente a quantidade de memória que deve ser usada. Por padrão, o SQL Server assume o seu em um servidor dedicado e tenta alocar dinamicamente a maior quantidade de memória possível; dependendo das necessidades de seus processos do IIS, isso pode não ser uma coisa boa. Em servidores que executam vários aplicativos, geralmente, gosto de configurar o SQL Server para usar exatamente uma certa quantidade de RAM, definindo o mínimo e o máximo para o mesmo valor (por exemplo, 4 GB, 10 GB, qualquer).

Por fim, você pode considerar a atualização do SQL Server. O SQL Server 2005 introduziu alguns aprimoramentos de grande velocidade em determinadas áreas que podem beneficiar você, dependendo da sua configuração. Sem mencionar o fato de que você pode obter uma versão de 64 bits do SQL Server 2005/2008 e executá-la em um sistema operacional de 64 bits para dar ainda mais memória, e a memória é de longe uma das coisas mais importantes para um SQL servidor.

    
por 18.10.2010 / 21:00
0

Este tópico precisa de um enorme "Depende" para a resposta. Enquanto as respostas postadas até agora são boas e corretas para determinadas condições, há muito mais.

Sim, sair do RAID-5 para o RAID-10 é uma enorme marca de seleção na coluna "Faça isso agora", mas e as partes que não nos foram contadas?

Pensando nisso, eu venho com os seguintes itens:   Layout de disco:
    Quais arquivos estão em quais drives?       Onde está o TempDb e quantos arquivos estão associados ao TempDb       Os DBs e T-Logs estão em drives diferentes?

Gerenciamento e otimização de consultas:
    As consultas mais pesadas foram identificadas e otimizadas? Como?     As atualizações estão causando realocações de linha ou elas são capazes de "atualizar no local"?       As realocações de linha durante uma atualização causam todos os tipos de problemas de desempenho.     Gerenciamento de índice: os índices necessários estão em vigor e estão corretamente definidos?       para ser utilizado pelas consultas que precisam deles?     O índice é reconstruído:       Os índices tornam-se fragmentados ao longo do tempo e precisam ser reorganizados ou reconstruídos. Não       isso afetará o desempenho.

Ambiente:     A fragmentação do drive pode levar à fragmentação de arquivos. Mesmo quando a unidade é mantida       limpo, um grande número de extensões para qualquer arquivo DB ou T-Log tem um efeito negativo.     Atualizando do SQL 2000 para o SQL 2005 ou (melhor ainda) 2008 ou 2008 R2     é uma ótima sugestão.       A execução no Windows Server 2008 x64 ou no Windows Server 2008 R2 x64 complementa       6GB de memória em modo nativo.       O SQL Server 2008 e 2008 R2 possuem ferramentas internas para ajudar a identificar problemas       consultas. Em um ambiente estressado com um DBA estressado, isso vale a atualização.     Memória Cache do Controlador de Unidade:       É suficiente? O cache é compartilhado entre várias unidades lógicas?

Competição de recursos (pressão):
    Além do IIS, que outros processos no sistema SQL Server estão competindo para o     recursos do sistema?

Adicionar uma SAN não é uma má ideia, mas você precisa entender o ambiente. Sabendo se a causa de seu desempenho é devido a varreduras de tabela, o gerenciamento inadequado de chaves estrangeiras, a realocação de linha durante a atualização, algum outro problema ou "todas as opções acima" é muito importante. Sem conhecer a (s) causa (s) subjacente (s) significa que a adição de uma SAN será apenas uma benção temporária. Além disso, conhecer o seu ambiente é obrigatório para o dimensionamento adequado de uma SAN - não se trata apenas do espaço disponível.

Eu não conheço o seu ambiente e não pude dar uma resposta razoável sobre o que você deve fazer; Também a minha lista acima é realmente a dica de um tópico para o qual muitos livros pensativos foram dedicados.

    
por 24.10.2010 / 14:17