O espaço de troca do Ubuntu 16.04 é preenchido, nunca é liberado

Question

Durante cerca de uma semana, o espaço de troca do nosso servidor Ubuntu 16.04 enche e nunca o libera, causando outros problemas em cascata no servidor. Ou seja, uma instância do Tomcat executando o Solr falhará periodicamente.

O servidor é uma VM de quatro núcleos, com 16g RAM e 16g swap. Atualmente, tem um valor swappiness de 60 .

Nós rodamos este servidor razoavelmente, com uma grande quantidade de chamadas HTTP internas para servidores locais para processamento de imagens, etc., muito disso através do Apache. Como temos encontrado esse problema de espaço de troca lentamente enchendo e nunca liberando, nós simplificamos outras áreas, mas sem nenhum efeito aparente. Uma reinicialização corrige as coisas, até que ela seja preenchida.

Eu poderia anexar números de gráficos do swap em declínio, mas não tenho certeza de quão útil isso seria (estar rastreando com nmon). Por exemplo, após uma reinicialização ontem, nossa saída free -m é:

              total        used        free      shared  buff/cache   available
Mem:          16047        4888        7621          32        3536       10729
Swap:         16380           0       16380

Como pode ser visto, 0 usado para swap. Mas uma vez que o sistema mergulha nele - por razões ainda a serem determinadas - ele nunca se recupera e você tem um declínio assim:

Eavancealgunsdiasatéchegaràs13h30:

Alguma sugestão? ou conselhos sobre como continuar investigando?

Pergunta de atualização

Com base em algum feedback nos comentários, atualize um pouco a questão.

Não parece ser um tamanho de heap para o Tomcat, nossas configurações atuais da JVM para o Tomcat são JAVA_OPTS=' -Xms4096m -Xmx4096m' , que aumentamos consideravelmente (geralmente, executamos em torno de 2g). catalina.out do Tomcat está nos dizendo Native memory allocation (mmap) failed to map 2863661056 bytes for committing reserved memory.

    

Answer 1

Isso parece um vazamento de memória, possivelmente em solr, ou você configurou incorretamente seus parâmetros da JVM. Eu acho que, como isso é um vm, é apenas runnig solr.

Você pode querer inspecionar seus parâmetros da JVM relacionados à memória.

-Xms
-Xmx

Observe que -Xmx especifica o tamanho máximo de heap.

Você também pode configurar sua JVM para criar dumps de heap em OOME, fazendo isso incluindo "-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/some/path/filename" em seus argumentos da JVM. Este arquivo será grande e, portanto, você provavelmente precisará de espaço em disco, no mínimo 32GB!

Depois disso, você verá onde o vazamento está acontecendo.

Atualização: como essa não parece ser a JVM, precisamos examinar todos os processos:

Execute isso, ele informará quais processos estão usando a maioria das conversões:

for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r

Extraído do link