Questão Quando devo usar / dev / shm / e quando devo usar / tmp /?


Quando devo usar /dev/shm/ e quando devo usar /tmp/? Posso sempre confiar em que ambos estejam lá no Unices?


104


origem




Respostas:


/dev/shm é um sistema de arquivos de armazenamento temporário de arquivos, ou seja, tmpfs, que usa RAM para o armazenamento de apoio. Pode funcionar como uma implementação de memória compartilhada que facilita IPC.

Da Wikipedia:

Construções recentes do kernel Linux 2.6 começaram a oferecer / dev / shm como memória compartilhada na forma de um ramdisk, mais especificamente como um diretório gravável pelo mundo que é armazenado na memória com um limite definido em / etc / default / tmpfs.    O suporte a / dev / shm é completamente opcional no arquivo de configuração do kernel.   Está incluído por padrão nas distribuições Fedora e Ubuntu, onde é mais amplamente utilizado pelo aplicativo Pulseaudio.   (Enfase adicionada.)

/tmp é o local dos arquivos temporários, conforme definido no Padrão de Hierarquia do Sistema de Arquivos, que é seguido por quase todas as distribuições Unix e Linux.

Como a RAM é significativamente mais rápida que o armazenamento em disco, você pode usar /dev/shm ao invés de /tmp para o aumento de desempenho, se o seu processo é intensivo de I / O e usa extensivamente arquivos temporários.

Para responder às suas perguntas: Não, você não pode confiar sempre /dev/shm estar presente, certamente não em máquinas com memória. Você deveria usar /tmp a menos que você tenha uma boa razão para usar /dev/shm.

Lembre-se disso /tmp pode fazer parte do / sistema de arquivos em vez de uma montagem separada e, portanto, pode crescer conforme necessário. O tamanho de /dev/shm é limitado pelo excesso de RAM no sistema e, portanto, é mais provável que você fique sem espaço nesse sistema de arquivos.


79



Eu vou usá-lo para redirecionar a saída da saída de erro padrão de um comando para um arquivo. Então eu vou ler esse arquivo e processá-lo. Eu farei isso milhares de vezes (é parte da condição de uma construção de loop). Eu achava que a memória seria legal nesse caso. Mas também quero que seja portátil. Eu acho que vou verificar se /dev/shm existe, use-o se isso acontecer ou /tmp. Isso soa bem? - Deleted
Eu também adicionaria uma verificação do tamanho mínimo e do nível de uso atual de / dev / shm para evitar o preenchimento inadvertido. - nagul
No Linux 2.6 e posterior, o / dev / shm deve ser montado para que as chamadas do sistema de memória compartilhada POSIX, como shm_open (), funcionem. Em outras palavras, alguns programas serão quebrados se não estiverem montados - assim deve ser. Não é apenas um disco RAM. Então você deve se certificar de que alguns / dev / shm estejam livres. - EdH
Não há aumento de desempenho usando /dev/shm. /dev/shm é a memória (tmpfs) apoiada pelo disco (swap). /var/tmp é a memória (cache de disco) apoiada pelo disco (sistema de arquivos no disco). Na prática, o desempenho é quase o mesmo (o tmpfs tem uma ligeira vantagem, mas não o suficiente para importar). /tmp pode ser tmpfs ou não dependendo de como o administrador o configurou. Não há boas razões para usar /dev/shm em seus scripts. - Gilles
@GaretClaborn Há muitos bons motivos para usar memória suportada por swap, mas isso é chamado de memória de processo normal. Se você estiver usando um arquivo, ele é chamado de sistema de arquivos, e todos os sistemas de arquivos são memória (cache), que é suportada pela troca, se o sistema de arquivos for algo como o tmpfs. A alocação de espaço em disco entre a permuta e outras áreas de armazenamento geralmente é real do administrador. Se um aplicativo deseja arquivos que tendem a permanecer na RAM, /tmpé a localização normal (com $TMPDIR para substituir). A escolha de fazer /tmp suportado por swap, outro espaço em disco ou nada é do administrador. - Gilles


Em ordem decrescente de tmpfs provincia:

┌───────────┬──────────────┬────────────────┐
│ /dev/shm  │ always tmpfs │ Linux specific │
├───────────┼──────────────┼────────────────┤
│ /tmp      │ can be tmpfs │ FHS 1.0        │
├───────────┼──────────────┼────────────────┤
│ /var/tmp  │ never tmpfs  │ FHS 1.0        │
└───────────┴──────────────┴────────────────┘

Desde que você está perguntando sobre um Linux específico tmpfs ponto de montagem versus um diretório portably definido que pode seja tmpfs (dependendo do seu sysadmin e qual é o padrão para sua distro), sua pergunta tem dois aspectos, que outras respostas enfatizaram diferentemente:

  1. Quando usar esses diretórios, com base em boa prática
  2. Quando é apropriado usar tmpfs

Boas práticas

Edição conservadora (mistura de convenções de ESF e uso comum):

  • Em caso de dúvida, use /tmp.
  • Usar /var/tmp para grandes dados que podem não caber facilmente no RAM.
  • Usar /var/tmp para dados que é benéfico manter em reinicializações (como um cache).
  • Usar /dev/shm como um efeito colateral de chamar shm_open(). O público-alvo é buffers limitados que são indefinidamente sobrescritos. Portanto, isso é para arquivos de longa duração cujo conteúdo é volátil e não muito grande.
  • Se ainda estiver em dúvida, forneça uma maneira para o usuário substituir. Por exemplo, o mktemp programa homenageia o TMPDIR variável de ambiente.

Edição pragmática:

Usar /dev/shm quando é importante usar o tmpfs, /var/tmp quando é importante não, senão /tmp.

Onde tmpfs se destaca

fsync é um não-op em tmpfs. Este syscall é o inimigo número um do desempenho (IO) (e longevidade do flash, se você se preocupa com isso), embora se você estiver usando tmpfs (ou eatmydata) apenas para derrotar o fsync, então você (ou algum outro desenvolvedor na cadeia) está fazendo algo errado. Isso significa que as transações para o dispositivo de armazenamento são desnecessariamente refinadas para o seu propósito - você está claramente disposto a pular alguns pontos de salvamento para desempenho, pois agora você foi ao extremo de sabotar todos eles - raramente o melhor compromisso. Além disso, é aqui na área de desempenho de transações onde estão alguns dos maiores benefícios de ter um SSD - qualquer SSD decente será executado fora do mundo em comparação com o que um disco giratório pode ter (7200 rpm = 120 Hz , se mais nada estiver acessando), para não mencionar os cartões de memória flash, que variam muito nesta métrica (não menos importante, porque é uma compensação com desempenho seqüencial, que é o que eles classificam, por exemplo, classificação de classe de cartão SD). Portanto, tenha cuidado, desenvolvedores com SSDs rápidos, para não forçar seus usuários neste caso de uso!

Quer ouvir uma história ridícula? Meu primeiro fsync lição: Eu tinha um trabalho que envolvia rotineiramente "atualizar" um monte de bancos de dados Sqlite (mantidos como testcases) para um formato atual em constante mudança. O framework "upgrade" executaria um monte de scripts, fazendo pelo menos uma transação cada, para atualizar um banco de dados. Claro, eu atualizei meus bancos de dados em paralelo (8 em paralelo, desde que eu fui abençoado com um poderoso CPU de 8 núcleos). Mas como eu descobri, não houve aceleração de paralelização de qualquer forma acertar) porque o processo foi inteiramente IO ligado. Hilariamente, envolvendo a estrutura de atualização em um script que copiou cada banco de dados para /dev/shm, atualizei lá, e copiei de volta para o disco foi 100 vezes mais rápido (ainda com 8 em paralelo). Como um bônus, o PC foi utilizável também, ao atualizar bancos de dados.

Onde tmpfs é apropriado

O uso apropriado de tmpfs é evitar a escrita desnecessária de dados voláteis. Desativando efetivamente Escreva de voltacomo definir /proc/sys/vm/dirty_writeback_centisecs ao infinito em um sistema de arquivos regular.

Isso tem muito pouco a ver com desempenho, e falhar é uma preocupação muito menor do que abusar do fsync: O tempo limite de write-back determina o quanto o conteúdo do disco é atualizado após o conteúdo do pagecache e o padrão de 5 segundos é muito longo para um computador - um aplicativo pode sobrescrever um arquivo com a frequência desejada, no pagecache, mas o conteúdo no disco é atualizado apenas uma vez a cada 5 segundos. A menos que o aplicativo force isso com o fsync, isso é. Pense em quantas vezes um aplicativo pode produzir um arquivo pequeno nesse momento e você verá por que analisar cada um deles seria um problema muito maior.

O que tmpfs não pode ajudá-lo com

  • Leia o desempenho. Se os seus dados estão quentes (o que é melhor se você considerar mantê-los no tmpfs), você irá acessar o pagecache de qualquer maneira. A diferença é quando não se atinge o pagecache; Se este for o caso, vá para "Where tmpfs sux", abaixo.
  • Arquivos de curta duração. Estes podem viver suas vidas inteiras no pagecache (como sujo páginas) antes de serem escritas. A menos que você force com fsync claro.

Onde tmpfs sux

Guardando frio dados. Você pode se sentir tentado a pensar que servir arquivos de swap é tão eficiente quanto um sistema de arquivos normal, mas existem algumas razões para isso não ser:

  • A razão mais simples: não há nada que os dispositivos de armazenamento contemporâneos (seja disco rígido ou baseado em flash) gostem mais do que ler arquivos razoavelmente sequenciais ordenadamente organizados por um sistema de arquivos adequado. É improvável que a troca em blocos de 4KiB melhore isso.
  • O custo oculto: troca Fora. As páginas do Tmpfs são sujo - eles precisam ser escritos em algum lugar (para trocar) para serem despejados do pagecache, ao contrário do arquivo suportado limpar \ limpo páginas que podem ser descartadas instantaneamente. Essa é uma penalidade de gravação extra em tudo o mais que compete pela memória - afeta outra coisa em um horário diferente do que o uso dessas páginas tmpfs.

40



No meu Ubuntu 14.04 / dev / shm é link para / run / shm, que tem sistema de arquivos "none" de acordo com o comando df. O tamanho é de cerca de 2G, no entanto. - jarno
@jarno Primeiramente, economizando o número de pontos de montagem tmpfs, eu chamaria um detalhe de implementação. Em segundo lugar, não deixe o nome do dispositivo confundir você - veja / proc / mounts (esse é o lugar certo para procurar), e você verá que o tipo é "tmpfs" enquanto o nome dispositivo é o que "nenhum" aqui. Sim, o nome do dispositivo não significa nada no tmpfs - você pode mount -t tmpfs "jarno is great" /mnt/jarno se você gostar! Em terceiro lugar, o tamanho padrão é metade da quantidade de RAM - aposto que você tem 4GiB de RAM. - user2394284
Existe uma opção que aloca um tamanho de RAM fixo e promete nunca usar swap? - palswim
@palswim: Isso seria um ramdisk. Eu não vejo uma opção para isso em tmpfs, diferente do antecessor daquele tmpfs não suportava troca. Processos podem bloquear suas páginas em memória RAM, o que é possivelmente menos louco do que bloquear páginas tmpfs em memória RAM, considerando que o assassino de OOM não é capaz de liberar o último, se você ficar sem memória. - user2394284


Ok, aqui está a realidade.

Ambos tmpfs e um sistema de arquivos normal são um cache de memória sobre o disco.

O tmpfs usa memória e espaço de troca como armazenamento de backup, um sistema de arquivos usa uma área específica do disco, nem é limitado no tamanho do sistema de arquivos, é bem possível ter um tmpfs de 200GB em uma máquina com menos de um GB de memória RAM se você tem espaço suficiente.

A diferença está em quando os dados são gravados no disco. Para um tmpfs, os dados são escritos SOMENTE quando a memória fica muito cheia ou os dados dificilmente serão usados ​​em breve. Os sistemas de arquivos Linux mais normais do OTOH são projetados para sempre ter um conjunto de dados mais ou menos consistente no disco, então se o usuário puxar o plugue eles não perdem tudo.

Pessoalmente, eu estou acostumado a ter sistemas operacionais que não travam e sistemas UPS (por exemplo: baterias de laptop), então eu acho que os sistemas de arquivos ext2 / 3 são muito paranóicos com seu intervalo de 5-10 segundo ponto de verificação. O sistema de arquivos ext4 é melhor com um ponto de verificação de 10 minutos, exceto que ele trata os dados do usuário como segunda classe e não os protege. (ext3 é o mesmo, mas você não percebe isso por causa do ponto de verificação de 5 segundos)

Essa verificação freqüente significa que dados desnecessários estão sendo continuamente gravados no disco, mesmo para / tmp.

Portanto, o resultado é que você precisa criar um espaço de troca tão grande quanto você precisa que seu / tmp seja (mesmo se você tiver que criar um arquivo de swap) e usar esse espaço para montar um tmpfs do tamanho necessário em / tmp.

NUNCA use / dev / shm.

A menos que você o esteja usando para arquivos IPC muito pequenos (provavelmente com mmap) e você tem certeza de que ele existe (não é um padrão) e a máquina tem mais que memória suficiente + swap disponível.


16



De acordo, exceto pela conclusão, "NUNCA use / dev / shm". Você deseja usar / dev / shm nos casos em que não deseja que um arquivo seja gravado no disco e deseja minimizar a i / o do disco. Por exemplo, preciso baixar arquivos zip muito grandes de um servidor FTP, descompactá-los e importá-los para um banco de dados. Descompacte em / dev / shm para que, para as operações de descompactação e importação, o HDD precise executar apenas metade da operação, em vez de alternar entre a origem e o destino. Acelera o processo imensamente. Esse é um exemplo de muitos, mas eu concordo que é uma ferramenta de nicho. - Nathan Stretch


Use / tmp / para arquivos temporários. Use / dev / shm / quando quiser memória compartilhada (ou seja, comunicação entre processos através de arquivos).

Você pode confiar em / tmp / estar lá, mas / dev / shm / é uma coisa relativamente recente no Linux.


4



Não há um aspecto de desempenho também? Como / dev / shm é mais frequentemente montado como um volume tmpfs e essencialmente um disco RAM? - Deleted
Você também pode montar / tmp como um sistema de arquivos tmpfs, eu faço isso no meu netbook para acelerar algumas coisas reduzindo as gravações no SSD (lento). Há desvantagens em fazer isso, é claro (principalmente o uso de RAM, mas meu netbook tem muito mais memória RAM do que geralmente precisa). - David Spillett
Para o meu caso específico, eu usaria isso para uma espécie de comunicação de processo. Eu capturei a saída do erro padrão de um aplicativo e aumentei o conteúdo (e ainda preciso da saída padrão intocada, por isso não posso fazer 1>/dev/null 2>&1. Eu faria isso milhares de vezes, então um tmpfs seria legal. No entanto, se eu lançar o script, não posso confiar em tmpfs sendo usado para /tmp como eu acho que não é tão comum. Se é mais comum /dev/shm então isso é melhor para mim. Mas estou procurando diretrizes sobre portabilidade, etc. - Deleted


/ dev / shm é usado para drivers e programas de dispositivos específicos do sistema de memória virtual compartilhada.

Se você estiver criando um programa que requer um heap de memória virtual que deve ser mapeado para a memória virtual. Isso vale em dobro, se você precisar de vários processos ou threads para poder acessar com segurança essa memória.

O fato é que só porque o driver usa uma versão especial do tmpfs para isso, não significa que você deva usá-lo como uma partição tmpfs genérica. Em vez disso, você deve apenas criar outra partição tmpfs se quiser uma para seu diretório temporário.


0





Em PERL, tendo no mínimo 8GB em qualquer máquina (todos rodando Linux Mint), eu sou do que eu acho que é um bom hábito de fazer algoritmos complexos baseados em DB_File (estrutura de dados em um arquivo) com milhões de leituras e gravações usando / dev / shm

Em outros idiomas, não tendo gigether em todos os lugares, para evitar o início e a parada na transferência de rede (trabalhando localmente em um arquivo localizado em um servidor em uma atmosfera cliente-servidor), usando um arquivo de lote de algum tipo, copio todo (300-900MB) arquivo de uma vez para / dev / shm, execute o programa com saída para / dev / shm, grave os resultados de volta para o servidor e exclua de / dev / shm

Naturalmente, se eu tivesse menos RAM, eu não estaria fazendo isso. Normalmente, o sistema de arquivos na memória do / dev / shm lê como um tamanho sendo metade da sua RAM disponível. No entanto, o uso ordinário de RAM é constante. Então você realmente não poderia fazer isso em um dispositivo com 2 GB ou menos. Para transformar a paráfrase em hipérbole, muitas vezes há coisas na RAM que até o sistema não relata bem.


0



(Eu acho que isso está no espírito do que foi originalmente perguntado.) O que eu quero dizer basicamente é que estou confortável usando / dev / shm como um disco RAM, desde que eu tenha memória suficiente. Se for ineficiente fazer isso de alguma forma, isso não deve dissuadi-lo de fazê-lo, mas deve disparar uma pergunta como "Como posso ter um disco RAM no linux?". A resposta é / dev / shm - David Grove