152
152
Quando devo usar /dev/shm/ e quando devo usar /tmp/?
Quando devo usar /dev/shm/ e quando devo usar /tmp/? Posso sempre contar com a presença de ambos em Unices?
Quando devo usar /dev/shm/ e quando devo usar /tmp/? Posso sempre contar com a presença de ambos em Unices?
Por ordem decrescente de tmpfs probabilidade:
┌───────────┬──────────────┬────────────────┐
│ /dev/shm │ always tmpfs │ Linux specific │
├───────────┼──────────────┼────────────────┤
│ /tmp │ can be tmpfs │ FHS 1.0 │
├───────────┼──────────────┼────────────────┤
│ /var/tmp │ never tmpfs │ FHS 1.0 │
└───────────┴──────────────┴────────────────┘
Uma vez que está a perguntar sobre um tmpfs ponto de montagem específico do Linux versus um directório definido de forma portátil que pode ser tmpfs (dependendo do seu sysadmin e do que está por defeito para a sua distro), a sua pergunta tem dois aspectos, que outras respostas enfatizaram de forma diferente:
edição conservadora (mistura de convenções de FHS e uso comum):
& - Em caso de dúvida, use /tmp.
& - Usar /var/tmp para grandes dados que podem não caber facilmente no carneiro.
& - Usar /var/tmp para dados que são benéficos para manter através de reinicializações (como uma cache).
& - Usar /dev/shm como um efeito secundário de chamar shm_open(). O público pretendido é limitado por buffers que são infinitamente sobreescritos. Portanto, isto é para ficheiros de longa duração, cujo conteúdo é volátil e não terrivelmente grande.
& - Se ainda estiver em dúvida, fornecer uma forma de o utilizador anular. Por exemplo, o programa mktemp homenageia a variável TMPDIR ambiente.
Edição pragmática:
Usar /dev/shm quando é importante usar tmpfs, /var/tmp quando é importante não o fazer, senão /tmp.
fsync é um no-op em tmpfs. Este syscall é o inimigo número um do desempenho (IO) (e da longevidade do flash, se isso lhe interessa), embora se se encontrar a usar tmpfs (ou eatmydata ) apenas para derrotar o fsync, então você (ou algum outro programador na cadeia) está a fazer algo de errado. Isto significa que as transacções em direcção ao dispositivo de armazenamento são desnecessariamente finas para o seu propósito - está claramente disposto a saltar alguns pontos de poupança para o desempenho, uma vez que agora chegou ao extremo de sabotar todos eles - raramente o melhor compromisso. Além disso, é aqui no terreno do desempenho da transacção que se encontram alguns dos maiores benefícios de ter um SSD - qualquer SSD decente vai ter um desempenho fora deste mundo, em comparação com o que um disco giratório pode possivelmente ter (7200 rpm = 120 Hz, se outra coisa estiver a aceder), para não mencionar os cartões de memória flash, que variam muito nesta métrica (até porque é uma troca com desempenho sequencial, que é o que eles são classificados, por exemplo, a classificação da classe do cartão SD). Portanto, tenha cuidado, programadores com SSDs rápidos em chamas, para não forçar os seus utilizadores a entrarem neste caso de utilização!
Querem ouvir uma história ridícula? A minha primeira fsync lição: tive um trabalho que envolvia rotineiramente “actualizar” um monte de bases de dados Sqlite (guardadas como casos de teste) para um formato actual em constante mudança. A estrutura de “actualização” executaria um monte de scripts, fazendo pelo menos uma transacção cada, para actualizar uma base de dados. Evidentemente, actualizei as minhas bases de dados em paralelo (8 em paralelo, uma vez que fui abençoado com um poderoso CPU de 8 núcleos). Mas como descobri, não houve qualquer velocidade de paralelização (um pouco de hit) porque o processo estava inteiramente ligado ao IO. Hilariantemente, envolver a estrutura de actualização num guião que copiava cada base de dados para /dev/shm, actualizava-a lá, e copiava-a de volta para o disco era 100 vezes mais rápido (ainda com 8 em paralelo). Como bónus, o PC era usável também, enquanto actualizava as bases de dados.
A utilização apropriada de tmpfs é para evitar a escrita desnecessária de dados voláteis. Desactivar eficazmente writeback, como definir /proc/sys/vm/dirty_writeback_centisecs para infinito num sistema de ficheiros normal.
Isto tem muito pouco a ver com o desempenho, e, caso contrário, esta é uma preocupação muito menor do que abusar do fsync: O tempo limite de gravação determina como o conteúdo do disco é actualizado preguiçosamente após o conteúdo do pagecache, e o padrão de 5 segundos é muito tempo para um computador - uma aplicação pode sobrescrever um ficheiro com a frequência que quiser, no pagecache, mas o conteúdo do disco só é actualizado cerca de uma vez a cada 5 segundos. A menos que a aplicação a force com o fsync, ou seja. Pense em quantas vezes uma aplicação pode produzir um pequeno ficheiro neste tempo, e verá porque é que fsyncar cada um deles seria um problema muito maior.
fsync&, claro. Mantendo dados frios. Poderá ser tentado a pensar que servir ficheiros fora de swap é tão eficiente como um sistema de ficheiros normal, mas há algumas razões pelas quais não é:
Muito bem, eis a realidade.
Tanto tmpfs como um sistema de ficheiros normal são um cache de memória sobre disco.
O tmpfs usa memória e espaço swap, uma vez que o seu backing store um sistema de ficheiros usa uma área específica do disco, nenhum deles é limitado no tamanho que o sistema de ficheiros pode ser, é bastante possível ter um tmpfs de 200GB numa máquina com menos de um GB de ram se tiver espaço swap suficiente.
A diferença está em quando os dados são escritos no disco. Para um tmpfs os dados são escritos APENAS quando a memória fica demasiado cheia ou quando é pouco provável que os dados sejam utilizados em breve. OTOH a maioria dos sistemas de ficheiros Linux normais são concebidos para ter sempre um conjunto de dados mais ou menos consistente no disco, para que se o utilizador puxar a ficha, não perca tudo.
Pessoalmente, estou habituado a ter sistemas operativos que não falham e sistemas UPS (por exemplo: baterias de portáteis) por isso penso que os sistemas de ficheiros ext2/3 são demasiado paranóicos com o seu intervalo de 5-10 segundos de ponto de verificação. O sistema de ficheiros ext4 é melhor com um ponto de verificação de 10 minutos, excepto que trata os dados do utilizador como segunda classe e não os protege. (ext3 é o mesmo, mas não se nota por causa do ponto de verificação de 5 segundos)
Este ponto de verificação frequente significa que os dados desnecessários estão continuamente a ser escritos em disco, mesmo para /tmp.
Então o resultado é que precisa de criar um espaço swap tão grande como precisa que o seu /tmp seja (mesmo que tenha de criar um ficheiro swap) e usar esse espaço para montar um tmpfs do tamanho exigido no /tmp.
NUNCA utilize /dev/shm.
A menos que o utilize para ficheiros IPC muito pequenos (provavelmente mmap’d) e tenha a certeza de que existe (não é um padrão) e de que a máquina tem memória + swap mais do que suficiente disponível.
Utilizar /tmp/ para ficheiros temporários. Utilizar /dev/shm/ quando quiser memória partilhada (ou seja, comunicação interprocessada através de ficheiros).
Pode confiar em /tmp/ estar lá, mas /dev/shm/ é uma coisa relativamente recente apenas no Linux.
Outra altura em que deve utilizar /dev/shm (para Linux 2.6 e superior) é quando precisa de um sistema de ficheiros tmpfs garantido porque não sabe se can escreve em disco.
Um sistema de monitorização que estou familiarizado com as necessidades de escrever ficheiros temporários enquanto constrói o seu relatório para submissão a um servidor central. É muito mais provável na prática que algo impeça a gravação num sistema de ficheiros (ou fora do espaço em disco ou uma falha de RAID subjacente empurrou o sistema para um modo só de leitura de hardware), mas ainda assim será capaz de coxear para alertar sobre isso do que se alguma coisa espiraisse toda a memória disponível de modo a que os tmpfs fiquem inutilizáveis (e a caixa não esteja morta). Em casos como este, um sistema de monitorização preferirá escrever para a RAM de modo a poder potencialmente enviar um alerta sobre um disco completo ou hardware morto/dormente.
/dev/shm é utilizado para drivers e programas de dispositivos específicos de sistemas de memória virtual partilhada.
Se está a criar um programa que requer uma pilha de memória virtual que deve ser mapeada para memória virtual. Isto vai para o dobro, se precisar de múltiplos processos ou fios para poder aceder a essa memória em segurança.
O facto é que só porque o condutor utiliza uma versão especial de tmpfs para ele, não significa que o deva utilizar como uma partição genérica de tmpfs. Em vez disso, deve apenas criar outra partição tmpfs se quiser uma para o seu directório temporário.
Em PERL, tendo 8GB mínimos em qualquer máquina (todas a correr Linux Mint), sou do que penso ser um bom hábito de fazer algoritmos complexos DB_File-based (estrutura de dados num ficheiro) com milhões de leituras e escritas usando /dev/shm
Em outras línguas, não tendo gigether em todo o lado, para evitar os inícios e paragens na transferência de rede (trabalhando localmente num ficheiro localizado num servidor numa atmosfera cliente-servidor), utilizando um ficheiro batch de algum tipo, copiarei todo o ficheiro (300-900MB) de uma só vez para /dev/shm, executar o programa com saída para /dev/shm, escrever os resultados de volta para o servidor, e apagar de /dev/shm
Naturalmente, se eu tivesse menos RAM, não estaria a fazer isto. Normalmente, o sistema de ficheiros in-memory do /dev/shm lê como um tamanho sendo metade da sua RAM disponível. No entanto, o uso normal de RAM é constante. Por isso, não poderia realmente fazer isto num dispositivo com 2GB ou menos. Para transformar a paráfrase em hiperbole, há muitas vezes coisas na RAM que mesmo o sistema não reporta bem.