Desvinculando arquivos em / dev / shm não liberando memória?

Question

Tenho a sensação de que estou ficando louco ou o tmpfs está muito quebrado para uso a longo prazo.

Eu tenho uma carga de trabalho que cria e desassocia muito rapidamente arquivos em / dev / shm / [alguma árvore de diretórios]. O uso do Linux Slab (em tamanho -64 e tamanho -128) aumenta linearmente com inodes alocados / desvinculados e nunca cai (a memória é listada como irrecuperável via meminfo, e o slabinfo mostra muitos milhões de objetos ativos).

Esta memória nunca é recuperada, e se permitido continuar, OOM. A única correção é desmontar e remontar / dev / shm.

Outro usuário fez essa pergunta há alguns anos, mas a resposta na verdade não cobriu o problema em questão ( operação em / dev / shm causa estouro ).

Isso é simplesmente uma decisão de design para o tmpfs ou há algo mais acontecendo aqui? Parece terrivelmente quebrado que os inodes nunca seriam libertados depois de alocados.

Linha do tempo: o processo cria 5 milhões de arquivos, um de cada vez, e os desvincula imediatamente após a criação. Todos os processos do usuário foram mortos neste momento. O uso de memória é como se 5 milhões de inodes ainda estivessem em / dev / shm, embora df -i e df -h relatem que / dev / shm está essencialmente vazio. Outras iterações do loop de processo aumentam linearmente o uso da memória até que o sistema fique totalmente sem memória e OOMs.

EDIT: Para alguém tropeçando nisso mais tarde, isso parece ser um artefato do kernel mais antigo que eu estava rodando (SLES 11, 2.6.32-alguma coisa). Novos kernels não podem reproduzir o problema.

    

Answer 1

Por uma questão de clareza, estou adicionando um teste mais ou menos roteiro do que falamos nos comentários. Isto está no kernel 4.7.2 onde o problema não acontece:

$ cd /dev/shm
$ free
              total        used        free      shared  buff/cache   available
Mem:        1794788      673948      873668       19300      247172      963316
Swap:       2097148           0     2097148
$ for i in 'seq 100000'; do touch node$i; done
$ ls -1|wc -l  # oops, there are extra three pulseaudio files here
 100003
$ free
              total        used        free      shared  buff/cache   available
Mem:        1794788      738240      811944       19300      244604      890184
Swap:       2097148           0     2097148

OK, obtemos a pegada de memória. Mas rm limpa isso

$ rm node*
$ free
              total        used        free      shared  buff/cache   available
Mem:        1794788      671484      896524       19300      226780      965884
Swap:       2097148           0     2097148

A partida não é perfeita porque eu limpei alguns caches enquanto isso. Mas a quantidade de memória livre e memória no cache é a mesma no início e no final desta pequena experiência.

Portanto, sim, o problema ocorre apenas em uma versão antiga do kernel. O que indicaria que houve um bug, mas já foi corrigido.

    

Answer 2

Parece que isso é apenas um bug no kernel antigo que é executado nessa máquina em particular. Não consigo reproduzi-lo em uma máquina RHEL 6 mais recente com os patches de kernel mais recentes.