Início / server / Perguntas / 1159190
Accepted
MikeKulls
Asked: 2024-05-10 16:50:25 +0800 CST

Como descobrir o que está desgastando meus SSDs

  • 772

Temos 8 servidores Cisco com 12 discos giratórios para dados e 2 SSDs para sistema operacional. Os 2 SSDs estão no software Linux RAID 1. Todos os SSDs têm seu indicador de desgaste em um dígito e alguns daqueles que atingiram o valor 1 falharam. Estou trocando todos eles pelas peças sobressalentes (um processo longo e cansativo), mas notei que o indicador de desgaste está caindo 1 ou 2% por semana (não fiz medições exatas). Há um único aplicativo em execução nesses servidores e o fornecedor me deu algumas ideias vagas, mas eu realmente preciso encontrar os diretórios nos quais ele está gravando. Dessa forma, posso realmente destacar o problema e pressionar o fornecedor para uma solução. Pesquisei um pouco, mas não consegui encontrar muito. iotop, por exemplo, mostra a taxa de transferência completa do disco, incluindo os 12 discos giratórios. O SO é Redhat 7.9

Em resposta a algumas das perguntas:

  • os discos são "SSD SATA de 480 GB e 2,5 polegadas Enterprise Value 6 Gb"
  • o ID do produto é "UCS-SD480GBKS4-EB"
  • os discos foram fornecidos como padrão com os servidores em 2018
  • O desgaste parece ter acelerado recentemente (agora estou registrando o desgaste, então terei uma resposta melhor sobre isso em alguns dias)
  • Substituí a maioria dos discos por discos idênticos adquiridos talvez alguns anos depois.
  • iotop está mostrando uma gravação constante de 8 MB/s.
  • o sistema está executando o hadoop em 8 servidores. O sistema de arquivos hadoop está em discos giratórios, portanto não deve tocar nos SSDs
  • Reduzi consideravelmente o IO do disco por sugestão do fornecedor, embora ainda pareça alto (8 MB/s)
redhat

4 respostas

  1. É difícil ter certeza sem mais detalhes sobre a idade dos sistemas, o modelo exato e a idade dos SSDs e vários outros fatores.

    Supondo SSDs de boa qualidade, 1-2% no indicador de desgaste em uma semana significa que você está gravando alguns terabytes (mínimo) de dados neles em uma semana. É uma enorme quantidade de dados para um volume de sistema operacional. Os principais culpados que eu examinaria são, em ordem:

    • SSDs baratos. Simplificando, parece que você não tem SSDs de qualidade particularmente boa neste sistema, o que invalidaria a suposição de que 1-2% da expectativa de vida útil se traduz em vários TB de dados. Sugiro fazer algumas pesquisas sobre o modelo exato de SSDs que você está usando para confirmar qual é a durabilidade real de gravação e se não há problemas de firmware documentados. Os bons dos últimos cinco anos ou mais devem ser avaliados para pelo menos 100 vezes a capacidade listada (ou seja, pelo menos 100 TB em um SSD de 1 TB), mas idealmente mais do que isso (como ponto de comparação, os atuais consumidores de última geração Atualmente, os SSDs de 1 TB são normalmente classificados para cerca de 300 TB de gravações).
    • Bloqueie o cache do dispositivo. Se você tiver bcache, dm-cache, ZFS L2ARC ou alguma outra configuração de cache de dispositivo de bloco que esteja usando espaço nos SSDs, esse provavelmente é o culpado, tente desligá-lo e veja o que acontece (bem, além de provavelmente um golpe desagradável para desempenho).
    • Exploração madeireira. A maioria dos seus logs provavelmente está no volume do seu sistema operacional. Se você tiver o registro detalhado ativado e seu aplicativo estiver muito ocupado, isso poderá facilmente atingir a faixa de terabytes em uma semana. Mas também pode ser outra coisa, como logs do SELinux, ou contabilidade de processos, ou o daemon de auditoria.
    • Cache sem bloco. Essencialmente, coisas em /var/cacheou outros locais onde os caches podem ser armazenados (como ~/.cachenos diretórios iniciais dos usuários). Isso não deveria atingir os números necessários, a menos que seja um servidor de terminal muito ativo, mas vale a pena verificar.
    • Troca. Provavelmente não é um contribuidor importante, porque atingir os números necessários significaria trocar com frequência suficiente para causar outros problemas de desempenho no sistema.
    • 13

  2. Verifique a troca - esse é um indicador típico. Verifique se você executa algum arquivo temporário para qualquer software - pode ser outro. Ambos precisam que você verifique e dado que os arquivos temporários dependem de software - nenhuma ajuda real é possível. Os diretórios do servidor de construção foram onde observei isso da última vez - tecnicamente uma estrutura temporária, já que cada execução baixa o repositório (ok, atualiza-o), em seguida, inicializa a árvore de origem e constrói - isso é MUITAS gravações. O SSD do usuário final não foi feito para isso. Realmente depende do software - nenhuma resposta genérica é possível.

    Caso contrário, considere se o uso de SSD de baixo custo é adequado para começar - isso parece mais queda do que deveria ser possível

    • 11
  3. Best Answer

    Você pode usar o ProcMon para Linux para rastrear chamadas do sistema de arquivos.

    https://github.com/Sysinternals/ProcMon-for-Linux

    • 5

  4. Você pode abordar esse problema de cima para baixo.

    Isso significa primeiro configurar um monitoramento como o netdata que grava continuamente todas as métricas de IO relevantes em um banco de dados para todos os servidores.

    Usando esses dados, você pode verificar a atividade de troca e a quantidade de volume de gravações que seus SSDs estão vendo e como isso muda ao longo do tempo.

    Dessa forma, você pode verificar se a alteração do indicador de desgaste é realmente plausível. Quero dizer, bugs no firmware de SSDs que influenciam os relatórios SMART não são inéditos.

    Para identificar diretórios e arquivos que são gravados em alta velocidade, você pode executar filetopa partir do pacote bcc-tools , por exemplo:

    # /usr/share/bcc/tools/filetop
23:56:12 loadavg: 1.32 0.83 0.60 4/1273 563644

TID     COMM             READS  WRITES R_Kb    W_Kb    T FILE
563614  yes              0      36757  0       294056  R foo.bar
[..]
    • 2

relate perguntas