Usando tmpfs + uma partição de swap muito grande para / tmp em vez de um sistema de arquivos regular?

Eu tenho um servidor Linux e uma partição de disco extra de 500 GB. Eu queria formatá-lo e usá-lo para / tmp. Ocasionalmente, o servidor executa algumas tarefas grandes de processamento de dados para que possa acontecer que / tmp retenha GBs de dados temporários.

Então eu tive uma idéia de que, em vez disso, eu poderia adicioná-lo como uma partição swap e montar / tmp em tmpfs. Essa ideia é razoável?

O servidor possui 6 GB de RAM; portanto, na maioria dos casos, os dados em / tmp estariam apenas em RAM, com a óbvia vantagem de velocidade. A questão é: e se houver digamos de 10 a 20 GB de dados em / tmp, como o sistema será executado? Qual seria o desempenho comparado a ter simplesmente / tmp montado em uma partição ext4? Obrigado pela ajuda.

Edit: É claro que o sistema começará a trocar a memória quando o uso de tmpfs atingir o limite de RAM. Mas o Linux é inteligente o suficiente para trocar dados tmpfs e manter dados "regulares" na RAM? Se sim, acho que poderia se comportar razoavelmente. Caso contrário, todo o sistema será severamente afetado.

Esta não é uma boa ideia ^TM .

Você ficará bem com uma /tmppartição grande , montada assim (do seu /etc/fstab)

tmpfs  /dev/tmp  tmpfs  defaults,nosuid,nodev,noexec,noatime,nodiratime,size=6000M 0 0

E você pode adicionar sua unidade externa como uma partição de troca gigante

/dev/sdb1  swap  swap  defaults  0 0

Quando atingir o limite, sua máquina começará a trocar as páginas da RAM para o disco - nesse ponto, as médias de carga passarão pelo telhado e a máquina será interrompida.

É uma péssima idéia confiar no SWAP de qualquer forma, seria melhor vender seu disco de 500 GB e simplesmente comprar mais RAM - é barato.

Em suma

Se você realmente deseja usar seu disco de 500 GB, poderá montá-lo /tmpcom um sistema de arquivos não registrado em diário com o atime e o diratime desativados (por exemplo, ext2). Isso seria substancialmente mais rápido do que lidar com uma máquina que é SWAPing

Esta poderia ser uma ideia razoável.

A colocação de um sistema de arquivos real em / tmp acarreta sobrecargas, porque os sistemas de arquivos passam por grandes comprimentos para garantir que os dados no disco não sejam corrompidos em caso de falha do sistema. Para um / tmp limpo no momento da inicialização, isso obviamente é apenas uma sobrecarga. Usar um tmpfs evitaria essa sobrecarga.

Por outro lado, os sistemas de arquivos também garantem que os arquivos sejam organizados no disco de maneira a otimizar o tempo de acesso - ou seja, evitarão a fragmentação. Os acessos típicos a arquivos seqüenciais resultam (principalmente) em acessos seqüenciais a disco, que são mais eficientes do que os acessos aleatórios. Esse efeito é mais pronunciado em discos rígidos giratórios do que no SSD. A combinação swap + tmpfs não pode fazer isso facilmente, porque o swap não está ciente de qual parte da memória pertence a qual arquivo e o tmpfs não está ciente de como as páginas são mapeadas para a memória física ou para o disco. Para arquivos grandes, no entanto, deve funcionar bem, pois o tmpfs e o swap tentam manter as coisas contíguas nesse caso. Pelo menos, desde que haja muito espaço livre no swap (caso contrário, a fragmentação entra em ação), e as gravações acontecem lentamente o suficiente para que eles tenham a chance de serem trocados.

Portanto, a questão é: depende, você deve tentar as duas opções para ver qual delas funciona melhor.

Ao montar o tmpfs, lembre-se de definir o tamanho explicitamente. O padrão é metade da RAM física, então apenas 3 GB.

Na verdade, é uma boa idéia quando você normalmente não possui muitos dados /tmp, mas ocasionalmente consome gigabytes sem fim por tempo limitado. O problema é que o sistema de troca linux não sabe o suficiente sobre o seu caso de uso para fazer o certo. Geralmente, ele prioriza o dumping ou a troca de cache pelas páginas do programa, mas isso não ajuda muito. Pode ser possível usar o cgroups para atingir seu objetivo, é quando os dados temporários são mantidos na memória do programa, mas não tenho certeza de como configurar o cgroups nesse caso (suponho que você possa usar um FUSE tmpfs ...) . Felizmente, isso não é necessário. Você pode obter o comportamento desejado com o zram e um dispositivo de apoio.

zram-inité o programa que automatiza a configuração do zram, que é um dispositivo de bloco de ram compactado. Geralmente, há um exemplo na zram-initconfiguração para montagem /tmpcomo zram. Será algo como o seguinte

type0=/tmp
flag0= 
size0=524288 # 500G of logical space
mlim0=2G # 2G of memory
back0=/dev/loop0 # (or /dev/sdxN, your large slow drive)
notr0= 
maxs0=4 # maximum number of parallel processes for this device
algo0=zstd 
labl0=tmp # the label name
uuid0= 
args0= 

Isso comprimirá e armazenará na memória qualquer coisa gravada em / tmp. A compactação usual está em torno de 50%. Ele consumirá no máximo 2G de memória física. Se houver pouca memória física, os arquivos mais antigos serão coletados e enviados para o dispositivo de backup, ainda compactado. Observe que ocorre alguma sobrecarga da CPU para compactar e descompactar os arquivos, mas isso geralmente é compensado pela E / S reduzida.

Uma configuração semelhante pode ser usada em conjunto com o cgroups para permitir a troca de certos processos sem afetar adversamente o desempenho geral do sistema.