memória virtual não mapeada e número total de conexões

Question

Temos dois nós de dados do MongoDB (conjunto de réplicas) - Primary & Secundário. Notei que non-mapped virtual memory é relativamente alto e imagino se eles estão prejudicando nosso desempenho do MongoDB (O servidor geralmente atingia o pico em torno de 6-7K consultas por segundo).

No MMS, foi declarado: "O caso mais comum de uso de uma grande quantidade de memória para não-mapeado é que existem muitas conexões com o banco de dados."

Por isso, verificamos o uso de memória com db.serverStatus().mem em nosso secundário:

{
    "bits" : 64,
    "resident" : 6846,
    "virtual" : 416797,
    "supported" : true,
    "mapped" : 205549,
    "mappedWithJournal" : 411098,
    "note" : "virtual minus mapped is large. could indicate a memory leak"
}

Nota: Estamos usando a versão 2.0.4 e agora o tamanho da pilha padrão deve ser de 1 MB por conexão.

O número atual de conexões é em torno de 1,1 K, mas a memória virtual não mapeada (virtual-mappedWithJournal) está em torno de 5699 MB. A tendência é bastante estável, então não posso dizer que há um vazamento aqui, mas para onde a memória foi?

Alguma ideia?

    

Answer 1

Primeiro, deixe-me dizer que, se for relativamente estável, você não tem vazamento de memória, e essa observação em serverStatus () foi removida do 2.2 devido à frequência de falsos positivos.

Memória virtual não mapeada são as estruturas de dados internas e as pilhas de threads do MongoDB, essencialmente qualquer coisa que não seja suportada por arquivos no disco. Isso geralmente é conduzido, como você mencionou, pela pilha de conexão a 1 MB por conexão. No seu caso, parece que deve ser em torno da marca de 1,1-1,2 GB (a menos que você tenha um pico de conexão e a memória ainda não tenha sido recuperada).

Se você estiver fazendo muitos mapeamentos / reduções in-line, classificações na memória, etc., eles também podem aumentar o uso de memória não mapeada. Se você instalar o MMS (que é gratuito), a memória não mapeada é uma das estatísticas rastreadas ao longo do tempo e você pode correlacionar aumentos no estatística não mapeada com a atividade em seu banco de dados facilmente. No entanto, se você não tiver executado, talvez seja necessário reiniciar o processo para rastrear o uso a partir do zero novamente.

Esse tipo de análise de uso costuma ser mais fácil do que usar o pmap (ou semelhante) para tentar amarrar a memória para peças específicas dentro de um processo

Finalmente, se o uso não-mapeado estiver fora de controle, ocasionalmente pode ser causado por problemas com libc malloc em 2.0 - isso, entre outras razões, foi o motivo da versão 2.2 enviado com TCMalloc em vez disso. Então, pode valer a pena verificar se isso permanece alto sem uma razão óbvia.