operação em / dev / shm causa estouro

Question

Estou repetindo dezenas de milhares de operações semelhantes em / dev / shm, cada uma com um diretório criado, arquivos gravados e depois removidos. Minha suposição costumava ser que eu estava realmente criando diretórios e removendo-os no lugar, então o consumo de memória tinha que ser bem baixo. No entanto, descobriu-se que o uso foi bastante alto e, finalmente, causou estouro de memória. Então, minhas perguntas são: com operações como

mkdir /dev/shm/foo
touch /dev/shm/foo/bar
[edit] /dev/shm/foo/bar
....
rm -rf /dev/shm/foo

Será que finalmente causará estouro de memória? e se isso acontece, porque é que, uma vez que parece removê-los no local.

Observação: essa é uma operação semelhante a dezenas de milhares.

    

Answer 1

Curioso, enquanto você está executando este aplicativo, o que df -h /dev/shm mostra seu uso de RAM?

tmpfs

Por padrão, normalmente é configurado com 50% da quantidade de RAM que o sistema possui fisicamente. Isso é documentado aqui no kernel.org, sob a documentação do sistema de arquivos para tmpfs. Também é mencionado na página mount man.

trecho da página de montagem do manual

The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a machine with highmem) the number of lowmem RAM pages, whichever is the lower.

confirmação

No meu laptop com 8 GB de RAM, tenho a seguinte configuração para /dev/shm :

$ df -h /dev/shm
Filesystem            Size  Used Avail Use% Mounted on
tmpfs                 3.9G  4.4M  3.9G   1% /dev/shm

O que está acontecendo?

Eu acho que o que está acontecendo é que, além de receber 50% da sua RAM para começar, você está consumindo os 50% ao longo do tempo e está empurrando o espaço /dev/shm para o swap, junto com os outros 50% de RAM.

Observe que uma outra característica de tmpfs vs. ramfs é que tmpfs pode ser enviado para troca, se necessário:

trecho de geekstuff.com

                    Table: Comparison of ramfs and tmpfs

Experimentation                          Tmpfs                Ramfs
---------------                          -----                -----
Fill maximum space and continue writing  Will display error   Will continue writing
Fixed Size                               Yes                  No
Uses Swap                                Yes                  No
Volatile Storage                         Yes                  Yes

No final do dia, é um sistema de arquivos implementado na RAM, então eu esperaria que ele agisse um pouco como os dois. O que quero dizer com isso é que, como os arquivos / diretórios são excluídos, você está usando algumas das páginas físicas da memória para a tabela de inodes, e algumas para o espaço real consumido por esses arquivos / diretórios.

Normalmente, quando você usa espaço em um HDD, na verdade não libera o espaço físico, apenas as entradas na tabela de inode, dizendo que o espaço consumido por um arquivo específico está disponível agora.

Portanto, da perspectiva da RAM, o espaço consumido pelos arquivos é apenas uma página suja na memória. Por isso, irá obedientemente trocá-los ao longo do tempo.

Não está claro se tmpfs faz algo de especial para limpar a RAM real usada pelo sistema de arquivos que está fornecendo. Eu vi menções em vários fóruns que as pessoas viram que estava levando mais de 15 minutos para o sistema deles "recuperar" espaço para arquivos que eles tinham deletado no /dev/shm .

Talvez este artigo tenha encontrado em tmpfs intitulado: tmpfs: um sistema de arquivos de memória virtual vai lançar mais luz sobre como ele é implementado no nível inferior e como ele funciona em relação ao VMM. O artigo foi escrito especificamente para o SunOS, mas pode conter algumas pistas.

experimentação

Os testes inventados a seguir parecem indicar que /dev/shm é capaz de se limpar.

experimento # 1

Crie um diretório com um único arquivo dentro dele e exclua o diretório 1000 vezes.

estado inicial de /dev/shm

$ df -k /dev/shm
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                  3993744      5500   3988244   1% /dev/shm

preencha com arquivos

$ for i in 'seq 1 1000';do mkdir /dev/shm/sam; echo "$i" \
      > /dev/shm/sam/file$i; rm -fr /dev/shm/sam;done

estado final de /dev/shm

$ df -k /dev/shm
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                  3993744      5528   3988216   1% /dev/shm

experimento # 2

Crie um diretório com um único arquivo de 50MB dentro dele e exclua o diretório 300 vezes.

preencha com 50MB de arquivos de lixo aleatório

$ start_time='date +%s'
$ for i in 'seq 1 300';do mkdir /dev/shm/sam;                     \
   dd if=/dev/random of=/dev/shm/sam/file$i bs=52428800 count=1 > \
   /dev/shm/sam/file$i.log; rm -fr /dev/shm/sam;done              \
   && echo run time is $(expr 'date +%s' - $start_time) s

...
8 bytes (8 B) copied, 0.247272 s, 0.0 kB/s
0+1 records in
0+1 records out
9 bytes (9 B) copied, 1.49836 s, 0.0 kB/s
run time is 213 s

estado final de /dev/shm

Novamente, não houve aumento perceptível no espaço consumido por /dev/shm .

$ df -k /dev/shm
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                  3993744      5500   3988244   1% /dev/shm

conclusão

Não notei nenhum efeito discernível com a adição de arquivos e diretórios com meu /dev/shm . Executando o acima várias vezes não parece ter qualquer efeito sobre isso também. Por isso, não vejo problema em usar /dev/shm da maneira que você descreveu.