xvda1 está 100% cheio, o que é? como consertar?

41

Estou executando uma instância do Linux no EC2 (tenho MongoDB e node.js instalado) e estou recebendo este erro:

Cannot write: No space left on device

Acho que rastreei esse arquivo, aqui está a saída df

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda1             1032088   1032088         0 100% /

O problema é que não sei o que é esse arquivo e também não sei se esse arquivo é o problema.

Portanto, minha pergunta é: como faço para corrigir o erro "Sem espaço restante no dispositivo"?

linux amazon-ec2 xen Chris Biscardi
fonte

Respostas:

67

Esse arquivo /é o seu diretório raiz. Se é o único sistema de arquivos que você vê df, então é tudo. Você tem um sistema de arquivos de 1 GB e está 100% cheio. Você pode começar a descobrir como é usado assim:

sudo du -x / | sort -n | tail -40

Você pode substituir /pelos caminhos que ocupam mais espaço. (Eles estarão no final, graças ao sort. O comando pode demorar um pouco.)

David Schwartz
fonte
19
Para obter a saída em um formato legível por humanos, você pode usar sudo du -x -h / | sort -h | tail -40( nesta resposta ).
Mkobit
Para aqueles em instâncias de micro AWS AMI, isso pode levar um minuto ou mais para ser executado. Seja paciente!
Dr. Rob Lang
o que fazer com isso:sort: write failed: /tmp/sortGmL8oF: No space left on device
dOM
11
@dOM Ouch. Tente limpar algum espaço /tmp. Ou, se necessário, reduza passo a passo com comandos como du -xhs /*.
David Schwartz
du -x -h / | sort -h | tail -40 | sort -h -rpode ser usado para classificar em ordem decrescente ao usar saída legível por humanos.
Vigs
14

Eu sei que estou respondendo neste segmento após quase 5 anos, mas pode ajudar alguém, tive o mesmo problema, tive m4.xlarge instance df -h disse que o / dev / xvda1 estava cheio, - 100%

Filesystem      Size  Used Avail Use% Mounted on
udev            7.9G     0  7.9G   0% /dev
tmpfs           1.6G  177M  1.4G  12% /run
/dev/xvda1      7.7G  7.7G     0 100% /
tmpfs           7.9G     0  7.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup
tmpfs           1.6G     0  1.6G   0% /run/user/1000

eu tentei resolvê-lo aqui estão os passos

sudo find / -type f -printf '%12s %p\n' 2>/dev/null|awk '{if($1>999999999)print $0;}'

Ajudou-me a saber que era o contêiner do docker que estava falando todo o meu espaço, então eu empurrei todo o meu contêiner para o meu registro do docker e fiz sudo rm -rf / var / lib / docker / limpou meu espaço :) espero que ajude alguém :)

Golpe
fonte
8

Se você estiver executando uma instância de inicialização do EBS (recomendado), poderá aumentar o tamanho do volume raiz (/) usando o procedimento descrito neste artigo:

Redimensionando o disco raiz em uma instância EC2 de inicialização do EBS em execução
http://alestic.com/2010/02/ec2-resize-running-ebs-root

Se você estiver executando uma instância de armazenamento de instância (não recomendado), não poderá alterar o tamanho do disco raiz. Você precisa excluir ou mover arquivos para armazenamento efêmero (por exemplo, / mnt) ou anexar volumes EBS e mover arquivos para lá.

Aqui está um artigo que escrevi que descreve como mover um banco de dados MySQL do disco raiz para um volume EBS:

Executando o MySQL no Amazon EC2 com EBS
http://aws.amazon.com/articles/1663

... e considere mudar para instâncias de inicialização do EBS. Há muitas razões pelas quais você se agradecerá mais tarde.

Eric Hammond
fonte
Estou rodando no EBS, é bastante barato expandir o disco raiz, certo? Felizmente, não tenho que lidar com o MySQL. Meus projetos são atualmente Mongo / Redis. algum ótimo material aqui. +1
2

Recentemente, deparei com esse problema no Amazon Linux. Minha fila de e-mail de saída do crontab /var/spool/clientmqueueera de 4,5 GB.

Eu resolvi isso por:

  1. Localizando arquivos grandes: sudo find / -type f -size +10M -exec ls -lh {} \;
  2. Excluindo arquivos grandes: /bin/rm -f <path-to-large-file>
  3. Reinicie a instância do servidor

Problema resolvido!

Gabe Karkanis
fonte
1

Acabei de resolver esse problema executando este comando:

sudo apt autoremove

e muitos pacotes antigos foram removidos, liberando 5 gigabytes, por exemplo, havia muitos pacotes como este "linux-aws-headers-4.4.0-1028"

Paulo
fonte