Servidor de banco de dados (MySQL) no comando SSD - trim

Question

Não consigo encontrar muita informação especializada sobre o uso de servidores de banco de dados no SSD no que diz respeito a aparar. Eu sei que posso habilitar RAID e LVM descartar, e usar um trabalho fstrim / cron ou a opção discard mount para ext4 (qual deles depende do comportamento de gravação), mas por exemplo os arquivos de dados do MySQL só encolhem com optimize table e então você tem que ter inno_db_file_per_table habilitado. Em tabelas de vários 100 GBs, optimize table vai demorar um pouco e não é algo que se faça facilmente.

Os bancos de dados, principalmente o MySQL, lidam com descarte adequadamente? Eles podem até mesmo enviar o descarte sobre arquivos que o sistema de arquivos ainda acha que contém dados?

Eu sei que, sem cortes, o seu desempenho pode realmente diminuir depois de alguns meses e dar-lhe uma amplificação de escrita, daí as minhas preocupações.

    

Answer 1

A menos que você esteja usando os SSDs mais baratos no mercado consumidor e com bancos de dados de 100 GB + provavelmente não, isso provavelmente não será um problema para você.

Escrever Amplificação
Você teria que estar fazendo uma quantidade muito grande de escrita para chegar perto de limitar a vida útil de um SSD moderno (como, fabricado nos últimos 12 meses). A indústria como um todo conseguiu tirar a resistência da célula o suficiente, descobriu quanto espaço livre é necessário para compensar as células que falharam e otimizações de firmware definitivas que você deve conseguir pelo menos 3 anos de vida com desempenho de punição mesmo no consumidor hardware de nível Para SSDs antigos isso era verdade, mas isso não é mais o caso; na maioria dos casos é sobra mitologia de uma era mais antiga.

Para ser justo, a resistência da MLC ainda é um fator em altas cargas de gravação. E por alto estamos falando do equivalente a várias gravações em disco completo por dia ao longo dos anos. Se você está nesta classe de desempenho, você provavelmente não está mais no mercado de 'consumidor' de qualquer maneira.

Resultados de desempenho de reprogramação de células
Ou, o que você disse que você precisa TRIM / Descartar para. Esse é o conhecido 'defeito' dos SSDs de estilo MLC. No entanto, os ajustes de firmware ao longo dos anos diminuíram a maior parte do impacto no desempenho de gravações nesse estilo de SSD. Os drives SLC ainda estão disponíveis e, graças aos ajustes para fazer com que os drives MLC durem mais, o grande motivo para usar o SLC não está mais lá, então eles são bem incomuns agora. Mas, se você estiver fazendo pequenas gravações em disco suficientes para empurrar a vida útil de um MLC, um dispositivo SLC começará a fazer sentido.

Se você alocar espaço não utilizado suficiente em suas unidades DB, a maioria dos firmwares SSD é inteligente o suficiente para perceber que certos blocos não são alocados e tratá-los como área sobressalente adicional. Quando os processos de desfragmentação do plano de fundo são iniciados, a área sobressalente é reprovisionada. Isso manterá o desempenho alto. Portanto, a falta de suporte ao descarte em nível de bloco no MySQL não importa muito.

    

Answer 2

Para o desempenho do SSD, um bom resumo e algumas excelentes referências podem ser encontradas em esta série de posts no blog.

As recomendações genéricas do capítulo 6 podem ser relevantes para você, pois duvido que o TRIM o ajude muito com bancos de dados, eu acho que um banco de dados normalmente irá sobrescrever blocos e não excluir muitos arquivos. Uma boa dica de ajuste de desempenho genérico é:

26. Over-provisioning is useful for wear leveling and performance

A drive can be over-provisioned simply by formatting it to a logical partition capacity smaller than the maximum physical capacity. The remaining space, invisible to the user, will still be visible and used by the SSD controller. Over-provisioning helps the wear leveling mechanisms to cope with the inherent limited lifespan of NAND-flash cells. For workloads in which writes are not so heavy, 10% to 15% of over-provisioning is enough. For workloads of sustained random writes, keeping up to 25% of over-provisioning will improve performance. The over-provisioning will act as a buffer of NAND-flash blocks, helping the garbage collection process to absorb peaks of writes.