Aumentando o tamanho disponível para, ou alterando a localização de / tmp

2

Atualmente, sou responsável por um servidor rodando Red Hat e um webapp de bioinformática que lida com arquivos enormes, alguns dos quais com mais de 100 GB quando não compactados. O ato de descomprimir esses arquivos é feito por vários programas diferentes, todos usando o diretório temporário do sistema, / tmp. Quando um arquivo enorme está sendo descompactado, o / tmp enche e interrompe a operação em andamento, causando erros de recebimento de dados no aplicativo da Web. Eu tenho que ir e excluir o arquivo de problema de / tmp.

O sistema de arquivos do servidor é configurado assim:

/*output of df-h follows*/
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_root-LogVol01 83G   34G   45G  43% /
tmpfs                  95G     0   95G   0% /dev/shm
/dev/sda1             485M   81M  379M  18% /boot
/dev/sdb1             8.0T  6.2T  1.5T  82% /data

/*output of blkid follows*/
/dev/sda1: UUID="5f489589-0678-46c1-9f0f-e4e66c6a9e04" TYPE="ext4" 

/dev/sda2: UUID="k2rP0k-1YhK-72D9-fRrQ-BxUW-3gaC-6KF0nh" TYPE="LVM2_member" 

/dev/sdb1: UUID="4e54bee3-6450-446f-af80-70ca6268e12f" TYPE="ext4" 

/dev/mapper/vg_root-LogVol01: UUID="b6f228dc-fa6c-43c1-b88e-3b43a75e980b" TYPE="ext4" 

/dev/mapper/vg_root-LogVol00: UUID="80c6863d-c9f8-4abe-a353-a6a6818dc82d" TYPE="swap"

/*output of fstab*/
/dev/mapper/vg_root-LogVol01 /   ext4    defaults   1 1
UUID=5f489589-0678-46c1-9f0f-e4e66c6a9e04 /boot   ext4   defaults   1 2
/dev/mapper/vg_root-LogVol00 swap    swap    defaults    0 0
/dev/sdb1   /data   ext4    defaults    1 1
tmpfs        /dev/shm   tmpfs   defaults        0 0
devpts      /dev/pts    devpts  gid=5,mode=620  0 0
sysfs       /sys        sysfs   defaults        0 0
proc        /proc       proc    defaults        0 0

Eu sei o básico do Linux, mas não sei muito sobre sistemas de arquivos. O que eu gostaria de fazer é aprovar uma solução permanente para alocar mais espaço para o diretório temporário. Eu estaria aberto para definir a variável de ambiente TMPDIR para apontar para outro sistema de arquivos com mais espaço. Ou, se for possível, eu estaria igualmente satisfeito alocando mais do espaço existente para o LogVol-01.

Minha pergunta é como, considerando meus detalhes atuais do sistema de arquivos, alocar permanentemente mais espaço para o diretório temporário. Como você pode ver pela saída do df, eu tenho espaço em disco de sobra. Não configurei o servidor, mas agora estou encarregado disso e tenho acesso root, para melhor ou para pior!

    
por DeeDee 13.03.2012 / 22:52

2 respostas

4

Atualização:

Desde que você tenha confirmado que / tmp não é um link simbólico e que não há montagens em / tmp. Está basicamente dizendo que está se enchendo. como você conserta aquilo? 2 opções.

  1. Eu gostaria de inserir outro disco rígido e montá-lo em / tmp, inserindo uma entrada apropriada em / etc / fstab.
  2. Ou como medida temporária, mova / tmp para outra unidade como / dev / sdb1, que atualmente possui centenas de GB livres. É simplesmente uma questão de criar um diretório tmp em / dev / sdb1

ou seja,

sudo mkdir /data/tmp
sudo chmod 1777 /data/tmp
sudo rm /tmp
sudo ln -s /data/tmp /tmp

Se você preferir adicionar mais armazenamento (que é uma solução melhor a longo prazo), há muitos tutoriais na net sobre como adicionar unidades extras ao Linux.

Resposta original ...

tmpfs pode ser o culpado. É baseado em ram e ele usa swap quando precisa também. Isso significa que continuará crescendo e crescendo até que nenhum outro RAM possa ser usado para o tmpfs. Você está terminando com uma descompressão incompleta.

O que você precisa fazer é editar / etc / fstab e comentar (com um '#') a linha que começa com '/ tmp' e reiniciar ou desmontar / tmp (com 'sudo umount / tmp')

Parece que você tem toda a unidade usando o LVM, por isso é seguro não montar um substituto para / tmp.

Editar :

Gostaria de ver um arquivo fstab padrão do redhat ou do seu. De qualquer forma ... É possível que / tmp não exista no fstab porque pode ser um link simbólico.
Para descobrir, execute "ls -ld / tmp". Se é um link simbólico, você o verá listado com / tmp - > / dev / shm ou algo assim.

Se, na verdade, for um link para / dev / shm ou para um diretório montado como tmpfs, corrija-o com:

sudo rm /tmp
sudo mkdir /tmp
sudo chmod 1777 /tmp

EDIT2: No segundo pensamento, poderia outras razões.

  1. Ou / tmp está sendo preenchido ou
  2. As ferramentas de descompressão não estão funcionando muito bem em seus arquivos grandes. 100GB de dados descompactados é provavelmente um grande arquivo! Quais ferramentas você está usando para extrair o arquivo? Qual é o formato? Eu sei que algumas versões do tar têm problemas ou
  3. O tipo de sistema de arquivos não permite que alguns arquivos sejam extraídos porque excedem o limite do sistema de arquivos. Qual tipo é o sistema de arquivos de destino? é ext3 ou 4 ou algo mais?
  4. Ou o sistema de arquivos está realmente cheio.
por 13.03.2012 / 23:23
2

Tenho certeza de que / tmp e tmpfs são baseados em RAM, portanto, descompactá-los e armazená-los na RAM pode ser a razão pela qual as coisas ficam paralisadas. O sistema operacional começa a trocar como um louco, então você começa a notar o impacto no desempenho.

Essa operação deve ocorrer em / tmp?

Adicionando uma resposta real:

link

    
por 13.03.2012 / 23:09