Nesta continuação da minha série de 'ajuste de desempenho instintivo', gostaria de discutir discos de estado sólido (SSDs) e alguns dos problemas que vejo com seu uso em um ambiente SQL Server. Para uma descrição detalhada dos SSDs, confira este artigo da Wikipedia.
O que os SSDs fazem para o desempenho do SQL Server?
Os SSDs não possuem partes móveis, portanto, quando ocorre uma leitura ou gravação, quase não há latência de E/S. A latência em uma unidade giratória vem de duas coisas:
- Mover o cabeçote do disco para o caminho certo na superfície do disco (conhecido como tempo de busca)
- Aguardando o disco girar para o ponto certo da trilha (conhecido como latência rotacional)
Isso significa que os SSDs fornecem um grande aumento de desempenho quando há um gargalo de E/S.
É simples assim.
Há um pouco de complicação que vale a pena mencionar, mas além do escopo deste artigo para se aprofundar:o desempenho do SSD pode começar a degradar à medida que a unidade fica realmente cheia (investigada e explicada em detalhes neste artigo da AnandTech). Também pode haver alguma memória do sistema necessária para o driver SSD para ajudar no nivelamento de desgaste (prolongando a vida útil das células NAND no SSD), e isso varia de acordo com o fornecedor. Chega disso – de volta ao material do SQL Server.
Evite conselhos ruins sobre a Internet
Há dois conselhos muito ruins que vejo na Internet sobre SQL Server e SSDs.
O primeiro é sobre o que colocar no SSD, onde o conselho é sempre colocar tempdb e seus logs de transação em SSDs. À primeira vista, isso parece um bom conselho, pois logs de transações e tempdb são geralmente gargalos no sistema.
Mas e se não forem?
Sua carga de trabalho pode ser lida principalmente, caso em que o log de transações provavelmente não será um gargalo de carga de trabalho e, portanto, colocá-lo em um SSD pode ser um desperdício de um SSD caro.
Seu tempdb pode não ser muito usado por sua carga de trabalho, portanto, colocá-lo em um SSD pode ser um desperdício de um SSD caro.
Ao considerar qual parte do ambiente do SQL Server deve ser movida para o SSD, você deseja investigar onde estão os gargalos de E/S. Isso pode ser feito com muita facilidade usando o código que postei na semana passada que usa a DMV sys.dm_io_virtual_file_stats para fornecer um instantâneo das latências de E/S para todos os arquivos em todos os bancos de dados na instância. Para entender seus números de latência e compará-los com valores bons/ruins, leia este longo post que fiz especificamente sobre latências de E/S de log de transações e tempdb.
E então, mesmo que você tenha latências altas, não pense que a única solução é mover o(s) arquivo(s) com baixo desempenho para um SSD:
- Para latências de leitura de arquivos de dados, investigue por que ocorrem tantas leituras. Eu abordo isso aqui.
- Para latências de gravação do arquivo de log, considere todas as maneiras de ajustar o desempenho do log e o que está sendo registrado. Eu abordo isso aqui, aqui e aqui.
O pior caso possível é quando você recebe um monte de SSDs, segue os conselhos da Internet para mover o tempdb e seus arquivos de log para eles e não há ganho de desempenho da carga de trabalho. Isso não vai encorajar seu gerenciamento a fornecer SSDs mais caros.
O segundo conselho ruim é sobre a fragmentação do índice, onde o conselho é que, como os SSDs são tão rápidos, você não precisa se preocupar com a fragmentação do índice ao usar SSDs.
Que absurdo!
Há três maneiras de refutar esse mau conselho:
- Os SSDs não interrompem de forma alguma a causa da fragmentação do índice:a página se divide de páginas que precisam de espaço livre para uma inserção aleatória ou aumento do tamanho da linha. Uma divisão de página gera a mesma quantidade de log de transações, uso de recursos e possíveis esperas de encadeamento, independentemente de onde os dados/arquivos de log estão armazenados.
- A fragmentação de índice inclui ter muitas páginas de dados/índice com baixa densidade de página (ou seja, muito espaço livre e vazio). Você realmente quer que seus SSDs caros armazenem muito espaço vazio? Os SSDs não ajudam em nada.
- Meu colega Jonathan Kehayias fez uma investigação aprofundada, usando Extended Events, de padrões de E/S em torno da fragmentação de índice especificamente para resolver esse mau conselho e descobriu que ainda há um impacto no desempenho por ter fragmentação de índice ao usar SSDs. Você pode ler seu longo post aqui.
A única coisa que os SSDs fazem em relação à fragmentação do índice é tornar as leituras mais rápidas, portanto, há menos penalidade de desempenho para varreduras de intervalo de índice quando existe fragmentação de índice, mas o ponto 3 acima mostra que ainda há uma penalidade.
Os SSDs não alteram a forma como você lida com e/ou evita a fragmentação de índice em seu ambiente SQL Server.
Certifique-se de proteger seus dados
Um dos pecados capitais que vejo as pessoas cometendo usando SSDs é usar apenas um deles. Com apenas uma unidade, qual nível de RAID você está usando? Zero. RAID-0 não oferece redundância.
Se você for usar um SSD, precisará usar pelo menos dois, em uma configuração RAID-1 (espelhamento). Não faz sentido ter um aumento de desempenho se você está sacrificando a disponibilidade do sistema como compensação.
Um push back que às vezes consigo usar pelo menos dois SSDs é que o cartão SSD fornece duas unidades para o Windows e, portanto, certamente criar um volume espelhado do Windows nas duas unidades é o mesmo que RAID-1 em dois SSDs fisicamente separados?
Não, não é. Ainda é um SSD físico, sem redundância. Você já viu metade de um cartão SSD falhar? Não, nem eu. Faça certo e use dois deles e obtenha redundância real para seus dados.
O outro empurrão que recebo é que eles são SSDs, não unidades giratórias, então não vão falhar. Isto é errado. Os SSDs podem falhar e falham, assim como as unidades giratórias. Eu pessoalmente vi dois SSDs de nível empresarial falharem durante os testes em nosso ambiente de laboratório. De acordo com este artigo no StorageReview.com, os SSDs de nível de consumidor têm um MTBF de 2 milhões de horas contra 1,5 milhão de horas para unidades giratórias de nível de consumidor, e eu esperaria resultados semelhantes para unidades de nível empresarial, mas os SSDs falham.
Resumo
Não caia na armadilha de pensar que o que você colocar no SSD significa que você terá um aumento no desempenho - você deve escolher com cuidado. E também não acredite no absurdo de ignorar a fragmentação do índice ao usar SSDs.
Os SSDs são uma maneira muito útil de aumentar o desempenho, mas pelo custo, você quer ter certeza de que está maximizando o retorno do investimento da sua empresa usando-os corretamente e somente quando apropriado.
No próximo artigo da série, discutirei outra causa comum de ajuste de desempenho instintivo. Até então, feliz solução de problemas!
