Ubuntu trava com leitura excessiva no ssd kingston

SergioGAC
(usa Ubuntu)

Enviado em 02/05/2019 - 22:49h

Possuo uma notebook samsung serie 5 Ultra com a configuração i7-3517u de 1.9Ghz 6Gbs de memoria e para dar uma melhorada troquei o hd por um HD SSD KINGSTON SA400S37 480GB instalando o ubuntu 19.4. Desdo inicio noto que o ubuntu trava aleatoriamente e o led de acesso ao disco se acende neste período. Alguém tem ideia do que pode ser. Na KINGSTON só tem suporte de driver para windows.

Grinder
(usa Slackware)

Enviado em 02/05/2019 - 23:18h

Já testou esse ssd em outro sistema operacional como windows pra ver se esse problema ocorre?
- - - - -
www.gitlab.com/grinder
www.github.com/ericfernandesferreira
www.youtube.com/candelabrus1

matroot
(usa Debian)

Enviado em 02/05/2019 - 23:18h

A máquina trava, você precisa desligar no botão?

Ou ela fica lenta por um período e volta a funcionar?

Dá uma olhada com o comando journalctl -xe se aparece algum erro.

SergioGAC
(usa Ubuntu)

Enviado em 03/05/2019 - 10:01h

Ela fica lenta por um período e volta a funcionar.

removido
(usa Nenhuma)

Enviado em 03/05/2019 - 10:48h

Sugiro rever suas conexões
Caso problema persista sugiro solicitar troca do SSD
Aqui tenho SSD Kingston rodando Ubuntu e Fedora sem problemas

niquelnausea
(usa Arch Linux)

Enviado em 03/05/2019 - 12:40h

possuo três ssd comuns (não topo de linha), e durante momentos de pico, principalmente transferência de muitos arquivos (exemplo diretório com 5000 arquivos de 5mb cada), o sistema da uma congelada mesmo. sempre acreditei que a causa era firmware genérico (talvez construído para ssd com maior velocidade de escrita), ou excesso de recursos alocados para esta tarefa. transferência de arquivos consome muitos recursos do processador.
usando versões do kernel mais responsáveis ou com um scheduler diferente, ou mesmo apenas sistemas de arquivo diferente, percebia diferenças, mas nada muito grande. o trim habilitado também faz uma grande diferença positiva.

uns três anos atrás, no ssd mais antigo um sandisk de 120gb, fiz alguns testes entre windows e linux (arch), o teste foi transferir um diretório aproximadamente 6300 arquivos e 21gb de tamanho total, de um disco externo mecânico 5400rpm para o ssd. o resultado foi windows sem travamentos mas com transferência mais lenta (o sistema apresentava lentidão), e linux com congelamento e transferência mais rápida (sistema também apresentou lentidão).
uma curiosidade foi o windows se mostrar mais responsivo se o ssd estivesse desfragmentado (em teoria isso não deveria ser verdade), mas isso é difícil de afirmar já que este sistema costuma ter muita atividade pesada em segundo plano e em momentos aleatórios.

aguamole
(usa KUbuntu)

Enviado em 03/05/2019 - 14:28h

Você tem razão isso não faz sentido para um SSD já que não contem um braço mecânico para andar entre os setores.
Isso deve ser uma limitação do NTFS que não tem recurso de busca aprimorado em memoria flash.

CPU Q6600 GTX 750 SofRaid 4xSSD 4Gb DDR2 mesmo assim uso Lubuntu.

FurretUber
(usa Ubuntu)

Enviado em 03/05/2019 - 16:14h

Pela descrição dos sintomas, parece que quando o updatedb.mlocate executa ele acaba degradando o desempenho do sistema. Mesmo um SSD tem um limite na velocidade de leitura e, se o agendador (scheduler) do SSD não for bem configurado, o updatedb.mlocate pode usar toda a capacidade do SSD enquanto roda, fazendo com que qualquer tarefa diferente que precise de acesso ao SSD trave.

Considerando que o SSD seja o dispositivo /dev/sda:

cat /sys/block/sda/queue/scheduler 

Deve mostrar quais são os agendadores disponíveis para o seu sistema. Você poderia enviar a saída do comando acima? Devem haver três ou quatro opções por padrão, além de outras que podem ser configuradas por parâmetros do kernel. Eu configurei o meu sistema com HDD para torná-lo mais responsivo. Por isso, no meu computador, a saída é:

cat /sys/block/sda/queue/scheduler 
[bfq] none 

A seguinte página, em inglês, possui uma comparação entre os vários agendadores disponíveis para os discos, com resultados para HDDs e SSDs. Não é uma das mais fáceis, mas dá uma boa ideia de como agendadores do disco influenciam grandemente na experiência do usuário: https://algo.ing.unimo.it/people/paolo/disk_sched/results.php

Pelos sintomas descritos, a fonte do problema parece ser o updatedb.mlocate.

paulo1205
(usa Ubuntu)

Enviado em 03/05/2019 - 23:15h

Mas, por outro lado, muitos sistemas de arquivo têm o problema de considerar setores de 512 bytes, enquanto o drive trabalha com setores (ou, melhor dizendo, com blocos) de 4096 bytes, o que implica que cada operação de escrita pode se transformar em leitura+escrita.

Em tempo: isso afeta HDs também.


... “Principium sapientiae timor Domini, et scientia sanctorum prudentia.” (Proverbia 9:10)