SQL Server 2K / 2K5 / 2K8 e discos de estado sólido: otimizações específicas?

Question

Alguém aqui está executando o SQL Server em unidades de estado sólido? Você encontrou alguma dica de otimização específica? Eu estou especificamente interessado em maneiras de reduzir a frequência com que o SQL Server realiza pequenas operações de gravação aleatórias, já que elas são inimigas do desempenho do SSD, particularmente das unidades SSD MLC.

Existem algumas otimizações óbvias que uma pessoa pode fazer, é claro: os dados de leitura pesada devem ser fornecidos pelo SSD, e itens pesados para gravação devem ser deixados para os discos giratórios tradicionais. Isso inclui logs de transações, naturalmente!

Dado o orçamento suficiente, é claro, seria interessante usar discos SSD do SLC, como as séries X25-E ou Vertex Ex, ou várias ofertas em nível corporativo. Mas também estou interessado em dicas que possam beneficiar as configurações de SSD do MLC. Eu acho que é uma área interessante. Um dos clientes dos meus clientes tem um orçamento pequeno e um conjunto de dados que cresceram imenso e estão a enfrentar uma reescrita completa de quase cem consultas para manter um nível de desempenho decente. No entanto, tenho uma suspeita de que menos de US $ 500 de espaço em memória RAM e SSD podem gerar um ganho de desempenho maior do que milhares (possivelmente dezenas de milhares) de dólares em tempo de desenvolvedor.

    

Answer 1

Não tem certeza do que você quer dizer com a redução da quantidade de gravações aleatórias pequenas que o SQL Server faz. O SQL Server grava páginas de dados somente durante os pontos de verificação - portanto, a única maneira de limitar o número de gravações é alterar o intervalo do ponto de verificação ou não fazer tantas operações do DIU. Você quis dizer outra coisa?

Em todas as implementações de SSDs que eu vi (um punhado), é o oposto do que você está sugerindo - o melhor uso de SSDs parece ser para registros de transações com muita gravação e tempdb - basicamente onde está o maior afunilamento do subsistema de E / S e coloque os SSDs lá - como tempo de busca e latência são reduzidos a uma constante baixa.

Confira este artigo de pesquisa que o MS produziu (infelizmente não detalhadamente detalhado em detalhes do SQL Server): Migrando o Armazenamento do Servidor para SSDs: Análise de Tradeoffs .

Espero que isso ajude!

    

Answer 2

Você não pode modificar as características de IO dos Servidores SQL. Sua unidade básica de acesso ao disco, para arquivos de dados, é uma página de 8Kb. Ele irá escrevê-los principalmente durante um checkpoint, mas também irá preguiçosos quando for possível.
O SQL não espera que as gravações no disco de dados sejam concluídas antes de retornar, são apenas as gravações de log que devem ser concluídas. Se você puder manter apenas um log de banco de dados em um disco, ele será gravações sequenciais e ficará bem em discos rígidos rápidos normais.
O impacto do desempenho do ponto de vista do SQL é quando ele precisa ler os discos. Se você puder dar mais memória, o SQL armazenará mais páginas de dados na memória, o que é mais rápido que qualquer tipo de disco, SSD ou outro. Obviamente, você também pode reduzir o número de leituras de disco criando índices apropriados. Espero que um SSD também ajude com essas leituras porque elas provavelmente serão aleatórias e aguardarão que as cabeças dos drives se movam.
Eu não sei o tamanho do banco de dados que estamos falando aqui, mas você pode querer dar uma olhada no HyperOS. Eles fazem discos sata que são na verdade apenas uma carga de memória RAM DDR2, com um disco SSD ou de 2,5 polegadas como backup. O padrão de acesso do servidor não importará muito. Eu não colocaria os logs em nada assim. Logs são o que manter seus dados consistant, eles precisam ir em um meio confiável e apesar de seu back-up SSD e bateria e o servidor provavelmente tem um no-break etc, eu ainda me sinto pouco fácil sobre não ter meus logs em um disco rígido real em algum tipo de matriz RAID tolerante a falhas.

    

Answer 3

Pequenas operações aleatórias são o inimigo dos discos tradicionais, devido à latência de busca da cabeça ... Os SSDs são ótimos para lidar exatamente com isso.

Com operações sequenciais longas, os discos padrão funcionam muito bem, então não haveria propósito em usar SSDs (do ponto de vista do desempenho, é claro).

    

Answer 4

Não há um ponto ainda a ser adicionado ao segmento de comentário, mas se você definir o tamanho da página do banco de dados / contagem de leitura múltipla para qualquer coisa no SSD para um múltiplo do tamanho de página do SSD, isso não deve ser um problema.

Eu não trabalhei no SQL Server há muito tempo, então não tenho certeza se essas opções estão disponíveis lá. Eu tenho feito Oracle e DB2 para os últimos anos e isso resolveria suas preocupações como o banco de dados seria devidamente ajustado para as características do disco.

    

Answer 5

Eu recomendaria o alinhamento da partição onde os arquivos do banco de dados são armazenados.

Também recomendo decidir o que acontece no RAID 0 para o perf (ldf e TempDB) e colocar dados críticos no RAID 1 (mdf).

Em terceiro lugar, você deve atualizar o firmware da unidade, assim como o firmware / drivers do controlador SATA. Ao fazer isso, você dá à empresa de hardware e seus desenvolvedores a oportunidade de otimizar o perf para você.