Ir ao conteúdo
  • Cadastre-se

SSD fica mais lento quando está cheio?


     99.900 visualizações    Armazenamento    26 comentários
SSD fica mais lento quando está cheio?

Introdução

Uma dos mitos que costumamos ler e ouvir sobre SSDs é que o SSD perde desempenho na medida em que vai tendo mais dados armazenados. Mas será que há algum fundo de verdade neste mito? Fizemos vários testes para confirmar (ou refutar) esta ideia. Está curioso? Confira!
A ideia de que um SSD é mais lento quando está mais cheio do que quando está com muito espaço livre faz algum sentido, por conta da forma como um SSD funciona. Assim, antes de prosseguirmos com este teste, sugerimos a leitura do tutorial “Anatomia das unidades SSD”, onde você encontrará informações aprofundadas sobre essas unidades.

Um SSD não grava os arquivos de forma sequencial. Suas memórias são divididas em blocos e, quando o sistema operacional pede para gravar um arquivo, o controlador da unidade procura o melhor bloco para gravar cada "pedaço" do arquivo original.

Isso se dá por dois motivos: primeiro, porque as memórias flash NAND precisam primeiro apagar um bloco para depois escrever novos dados nele, e isso toma tempo. Assim, quando você apaga um arquivo em um SSD, os blocos onde ele estava não são realmente apagados, e sim marcados como livres em uma tabela. Ao gravar um arquivo, o controlador dá preferência em utilizar blocos que já estejam realmente apagados, para acelerar o processo. O sistema operacional periodicamente (quando o computador está ocioso) envia ao SSD um comando chamado TRIM, que faz uma "faxina" no SSD, limpando blocos que estão desocupados e deixando-os prontos para gravação.

O segundo motivo é o controle de desgaste: cada bloco de memória NAND tem um certo desgaste ao ser apagado, e depois de um certo número (muito alto) de apagamentos, ele deixa de funcionar. Em nosso vídeo "Mitos do hardware #13: durabilidade de SSDs" explicamos isto em mais detalhes. Assim, o controlador do SSD dá preferência em gravar os arquivos nos blocos que já sofreram menos ciclos de apagamento e gravação, como forma de ir desgastando a unidade da forma mais uniforme possível.

Assim, em teoria, quando a maior parte dos blocos do SSD está livre, o controlador teria maior facilidade em encontrar blocos "ideais" para gravar os arquivos, enquanto em um SSD muito cheio, teria de gravar utilizando blocos mais desgastados ou que precisariam de apagamento.

Porém, sabemos que nem sempre as coisas funcionam como é previsto em teorias mais simples, principalmente em se tratando de um dispositivo complexo como um SSD. Assim, rodamos testes de leitura e escrita com o SSD vazio, depois com metade do espaço disponível ocupado por arquivos e, finalmente, com 90% do SSD cheio.

Para que não pegássemos os dados de apenas um modelo de SSD, repetimos os testes em quatro SSDs de características bem diferentes: o Kingston UV500 de 120 GiB (formato 2,5 polegadas, interface SATA-600), o Seagate Barracuda SSD de 250 GiB (2,5 polegadas, SATA-600), o Kingston A1000 de 240 GiB (formato M.2, interface PCI Express 3.0 x2) e o Samsung 960 EVO de 500 GiB ((formato M.2, interface PCI Express 3.0 x4).

Com isso, vamos analisar cada um dos SSDs em três estados diferentes e descobrir se o desempenho muda.

Na próxima página, vamos detalhar o sistema utilizado para os testes.

  • Curtir 20
  • Obrigado 4
  • Amei 1

Artigos similares


Comentários de usuários

Respostas recomendadas



Belo teste. Mas fico com a pulga atrás da orelha em certa situação, pois o impacto pode haver sim quando há uma gigante utilização de memória virtual/arquivo de paginação. 1GB de arquivo mesmo para uma unidade de 120GB (10% = 12GB sobrando na teoria) é quase insignificante. Em um jogo moderno, por exemplo FFXV, poderia dificultar e muito a jogabilidade já que extrapolaria a capacidade total.

Claro que citei uma situação específica a parte, e talvez não condiz com a proposta do teste feito.

Link para o comentário
Compartilhar em outros sites

  • Membro VIP

 

40 minutos atrás, Lost Byte disse:

Belo teste. Mas fico com a pulga atrás da orelha em certa situação, pois o impacto pode haver sim quando há uma gigante utilização de memória virtual/arquivo de paginação. 1GB de arquivo mesmo para uma unidade de 120GB (10% = 12GB sobrando na teoria) é quase insignificante. Em um jogo moderno, por exemplo FFXV, poderia dificultar e muito a jogabilidade já que extrapolaria a capacidade total.

Claro que citei uma situação específica a parte, e talvez não condiz com a proposta do teste feito.

Também fiquei com a mesma impressão. Talvez um teste com dados de volume maior pudesse mostrar um efeito mais impactante.

O ideal seria usar uma maquina com menos memória RAM também e desligar o SWAP para maximizar o efeito dos testes.

E por ultimo, um teste da vida real seria legal, como copiar da unidade principal um filme em full HD ou 4K (entre 5 e 10 GB) e calcular o tempo de copia que o Windows tomaria.

 

@Rafael Coelho sabe nos dizer qual o tamanho da memória de SWAP do Windows?

 

 

Link para o comentário
Compartilhar em outros sites

  • Membro VIP
27 minutos atrás, sdriver disse:

 

Também fiquei com a mesma impressão. Talvez um teste com dados de volume maior pudesse mostrar um efeito mais impactante.

O ideal seria usar uma maquina com menos memória RAM também e desligar o SWAP para maximizar o efeito dos testes.

E por ultimo, um teste da vida real seria legal, como copiar da unidade principal um filme em full HD ou 4K (entre 5 e 10 GB) e calcular o tempo de copia que o Windows tomaria.

 

@Rafael Coelho sabe nos dizer qual o tamanho da memória de SWAP do Windows?

 

 

O arquivo de swap está no automático e, como estamos utilizando um computador com 32 GiB de RAM e rodando apenas o crystaldiskmark, posso afirmar que ele não está utilizando o arquivo de swap durante os testes, além de que o SSD testado não era a unidade principal, ou seja, o arquivo de swap não estaria nele de qualquer forma.

Óbvio que, se você estiver com a unidade de armazenamento principal totalmente cheia, pouca memória e o sistema tentar utilizar o arquivo de troca, isso vai gerar uma lentidão no sistema, como sempre acontece quando o arquivo de troca é utilizado.

  • Curtir 1
Link para o comentário
Compartilhar em outros sites

Eu estava vendo semanas atrás uns vídeos daquele Baboo, e segundo ele, aquele problema de fragmentação (que a principio só afetava HDs convencionais) pode afetar o desempenho de SSDs também, caso estes estejam muito fragmentados.

 

O windows pelo que sei, desativa a desfragmentação em SSDs, e talvez ela chegue em um ponto, onde mesmo num ssd (que tem tempo de acesso ridiculamente baixo) haverá alguma queda de desempenho caso ele também esteja cheio.

Link para o comentário
Compartilhar em outros sites

  • Membro VIP
12 minutos atrás, =insane= disse:

pode afetar o desempenho de SSDs também, caso estes estejam muito fragmentados.

 

Foi exatamente o que eu disse.

 

Seria interessante esse tipo de teste, até para determinar quando e até quanto isso pode afetar a performance.

Link para o comentário
Compartilhar em outros sites

  • Membro VIP
18 horas atrás, =insane= disse:

Eu estava vendo semanas atrás uns vídeos daquele Baboo, e segundo ele, aquele problema de fragmentação (que a principio só afetava HDs convencionais) pode afetar o desempenho de SSDs também, caso estes estejam muito fragmentados.

 

O windows pelo que sei, desativa a desfragmentação em SSDs, e talvez ela chegue em um ponto, onde mesmo num ssd (que tem tempo de acesso ridiculamente baixo) haverá alguma queda de desempenho caso ele também esteja cheio.

 

O Windows (não sei ao certo a partir de qual versão) trata diferentemente as unidades de estado sólido (SSD) das unidades de disco rígido (HD). Você pode verificar isso executando o dfrgui.

 

dfrgui.png.22aabc67ea5b535f12b3e7b949106d1a.png

 

Ao executar a otimização em um SSD, o Windows executará na verdade um comando TRIM e não a desfragmentação como em um HD.

 

A fragmentação ocorre nos SSD, porém o seu impacto é muito pequeno. Até onde eu sei apenas um e outro software de desfragmentação* se arriscam a desfragmentar de fato um SSD. Porém o ganho de desempenho com isso também é muito pequeno.

 

Lembrando que o Windows também efetua ajustes em alguns de seus serviços e funções caso a unidade em que ele esteja instalado seja um SSD.

 

* PS: O Windows também executaria uma desfragmentação de fato, caso necessário, através de uma rotina mensal:

https://www.hanselman.com/blog/TheRealAndCompleteStoryDoesWindowsDefragmentYourSSD.aspx

Link para o comentário
Compartilhar em outros sites

  • Membro VIP

No Linux (Debian e derivados), o TRIM é feito toda semana por padrão. 
A questão não é a desfragmentação, pois os dados não são enfileirados sequencialmente em disco como um HD, mas sim o estado "ligado e desligado", binário. Quando você apaga um dado ele não é "zerado", apenas marcado como disponível para alocação. Na hora que você vai gravar um dado é que será feita a limpeza do setor, causando certa lentidão no processo.

 

O TRIM serve justamente para "zerar" estes setores e agilizar o processo. Porquê isto não ocorre toda vez que se apaga um dado? Porque isto desgasta as células. Então é preferível ir utilizando todas as células gradualmente para só depois apagar os dados. Não é bom um SSD lotado justamente pelo desgaste das mesmas células continuamente.

 

Só achei curioso o fato que a leitura tmb está sendo afetada. Provavelmente o arquivo está espalhado em diversos chips NAND e a controladora não é eficiente o suficiente para coletar todos os dados ao mesmo tempo.

  • Curtir 2
Link para o comentário
Compartilhar em outros sites

  • Membro VIP
59 minutos atrás, Gabriel Torres disse:

@Darkmana @Phoenyx Em teoria, penso que a desfragmentação diminui a vida útil do SSD, pois haverá ciclos de apagamento envolvido. Mas alguém aqui (não me lembro também onde, sorry), falou que isto não ocorria ou que era irrelevante. Enfim...

Se não me engano, essa série explica. https://www.youtube.com/watch?v=gE5bWnzNuB8

 

  • Curtir 1
  • Obrigado 1
Link para o comentário
Compartilhar em outros sites

 

22 horas atrás, Rafael Coelho disse:

Se não me engano, essa série explica.

 

11 horas atrás, lnpott disse:

A mesma fonte que usei para citar o caso de desfragmentação. Não sei se foi esse mesmo "episódio" mas é da série "SSD a fundo".

Isso. Eu vi tempos atrás a serie inteira e é justo nesse primeiro vídeo que ele cita o caso que vivenciou. Bem interessante por sinal, apesar do Baboo ser meio "mala". kkkk

  • Curtir 1
Link para o comentário
Compartilhar em outros sites

Uma coisa que não mencionaram é o fato de que se usar o SSD sempre cheio pode acelerar o desgaste das células que ficam vazias. Vamos supor que você compre o SSD , instale o Windows , programas;jogos que usa e sobre os outros 10 % livres. Em teorias somente esses 10% restantes seriam usados por arquivos temporários, cache, swap e etc. 

 Creio que isso seria o mais perigoso do que a perda de algum desempenho !

Concordam com a minha teoria ? 

Link para o comentário
Compartilhar em outros sites

Parabéns, excelente trabalho. Vocês são incríveis. 😍

 

Desfragmentação desgasta muito pouco o SSD e não causa aumento de desempenho na maioria das vezes, somente em poucos casos, como banco de dados muito fragmentado, por exemplo. TRIM é muito importante, eu desativei algumas vezes para testar e prejudica o desempenho, a diferença é notável com muitos arquivos gravados.

Tenho um Samsung 960 EVO 250 GiB. Se eu deixar ele com 10% livre, eu percebo a diferença de velocidade no TEMPO DE ACESSO, ocorre pouquíssima lentidão, um pequeno travamento quase imperceptível, parece um "micro stuttering", mas ainda continua sendo muito mais rápido do que um SSD SATA. Mesmo com Samsung Magician instalado e Over Provisioning ligado ocorre isso, se encher ele.

Com programas sintéticos, eu nunca fiz o teste, mas fiquei curioso agora.

Já enchi o SSD dezenas de vezes ultrapassando 16 TiB e continua funcionando muito rápido.

W1yrjJS.jpg

 

Formatei o computador nessa semana e estou fazendo uns testes com o Over Provisioning desligado, por uns dias.
 

 

pMBpDSU.jpg

 

5 horas atrás, jota.be disse:

Uma coisa que não mencionaram é o fato de que se usar o SSD sempre cheio pode acelerar o desgaste das células que ficam vazias. Vamos supor que você compre o SSD , instale o Windows , programas;jogos que usa e sobre os outros 10 % livres. Em teorias somente esses 10% restantes seriam usados por arquivos temporários, cache, swap e etc. 

 Creio que isso seria o mais perigoso do que a perda de algum desempenho !

Concordam com a minha teoria ? 


Meu amigo, a maioria dos SSDs atuais usa static wear leveling, tecnologia que muda os dados que ficam salvos muito tempo em uma célula para outra que foi pouco usada evitando o desgaste, leia sobre isso.

 

https://en.wikipedia.org/wiki/Wear_leveling

  • Curtir 1
  • Obrigado 1
Link para o comentário
Compartilhar em outros sites

  • Membro VIP
8 minutos atrás, Agnaldo.Reis disse:

Meu amigo, a maioria dos SSDs atuais usa static wear leveling, tecnologia que muda os dados que ficam salvos muito tempo em uma célula para outra que foi pouco usada evitando o desgaste, leia sobre isso.

 

https://en.wikipedia.org/wiki/Wear_leveling

Legal, não tinha ouvido falar sobre.

 

Bem vindo ao fórum, chegou para somar.

  • Curtir 1
Link para o comentário
Compartilhar em outros sites

22 horas atrás, lnpott disse:

Legal, não tinha ouvido falar sobre.

 

Bem vindo ao fórum, chegou para somar.

Eu sou bem antigo aqui. Fiquei doente, excluí minha conta e tive que me afastar por um bom tempo para cuidar da minha saúde. Mas estou excelente agora! 😍

Que bom que ajudou, tenho bastante conhecimento para agregar, mas vou aprender muito também, porque a vida é um aprendizado eterno e nós todos sempre aprenderemos uns com os outros. Vocês todos são demais. 😉

OFF TOPIC: Acredito que FPGA, ARM, blockchain, distributed ledger technology e IoT (juntamente com token IOTA) vão mudar muito o mercado, em breve. Quem sabe a gente veja isso aqui no site, somente o futuro pode nos dizer.

Eu comecei a ler o artigo de 1º de abril, já tava caindo e pensando que a blockchain do Bitcoin já seria hackeada, pois não tem proteção contra ataque de computador quântico, diferente da DLT Tangle da IOTA. Daí eu li o resto e ri muito. 😂🤣

Muito sucesso ao @Gabriel Torres, @Rafael Coelho e demais integrantes dessa excelente equipe do Clube do Hardware. ❤️

  • Curtir 2
  • Obrigado 1
Link para o comentário
Compartilhar em outros sites

O pessoal sempre fala das vantagens e da velocidade do SSD, mas essas unidades mais em conta, tipo Kingston 400 não têm grande desempenho, não.   Quando novas, da mesma forma que um HD, é tudo uma maravilha.   Depois, pode ser que sejam mais rápidas nesses programas de testes, mas no dia a dia, observo que o desempenho parece a mesma coisa que o HD.  

 

Deixo o Windows e os programas instalados no SSD, ocupando menos de 1/4 da capacidade e os arquivos, imagens, bases de dados no HD, mas a demora não parece ser ao acessar esses dados, ela já começa com a carga do SO e dos programas.

Link para o comentário
Compartilhar em outros sites

Uma outra questão que pode ser levantada é se a quantidade de arquivos influencia no desempenho  por serem dram-less. Olha... vendo esses resultados fiquei em dúvida comigo mesmo... pois podia jurar que um samsung evo 860 deixou no chinelo o meu antigo wd green 240gb. Ambos perto de 200gb usados e muito arquivo pequeno. HAhhaha, aquele momento que você fica com cara de ***** por achar algo e pelo visto só ter dado uma viajada e tanto!

Link para o comentário
Compartilhar em outros sites




Crie uma conta ou entre para comentar

Você precisa ser um usuário para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar agora

Sobre o Clube do Hardware

No ar desde 1996, o Clube do Hardware é uma das maiores, mais antigas e mais respeitadas comunidades sobre tecnologia do Brasil. Leia mais

Direitos autorais

Não permitimos a cópia ou reprodução do conteúdo do nosso site, fórum, newsletters e redes sociais, mesmo citando-se a fonte. Leia mais

×
×
  • Criar novo...