O que pode estar causando repetidos resultados de mmap / munmap in strace?

Question

Eu tenho um aplicativo (node.js) que ocasionalmente está causando 100% de uso da CPU. Eu anexei o processo com strace quando ele está nesse estado - mas não sei o que fazer se a saída da strace. Os resultados se repetem entre esses dois padrões (encurtados):

mmap(0x30c3ac700000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x30c3ac700000
mmap(0x3364514ba000, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x3364514ba000
munmap(0x3364514ba000, 286720)          = 0
munmap(0x336451600000, 761856)          = 0
mmap(0x336451500000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x336451500000
mmap(0x2b9c33880000, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2b9c33880000
munmap(0x2b9c33880000, 524288)          = 0
munmap(0x2b9c33a00000, 524288)          = 0
...

E ...

munmap(0x2b9c33900000, 1048576)         = 0
munmap(0x336451500000, 1048576)         = 0
munmap(0x30c3ac700000, 1048576)         = 0
munmap(0x247e37500000, 1048576)         = 0
munmap(0x20d76c800000, 1048576)         = 0
munmap(0x1cae0d600000, 1048576)         = 0
munmap(0x163545100000, 1048576)         = 0
munmap(0x32dcfe700000, 1048576)         = 0
munmap(0x1a1feff00000, 1048576)         = 0
munmap(0x3fb72f00000, 1048576)          = 0
munmap(0x366536900000, 1048576)         = 0
...

Alguém pode lançar alguma luz sobre o que pode estar acontecendo aqui? Obrigada!

    

Answer 1

Tudo o que pode ser deduzido dessa saída é que o aplicativo está alocando e liberando memória. Portanto, deve haver algumas estruturas de dados que estão crescendo e diminuindo.

Isso infelizmente não diz muito sobre o que está acontecendo em uma camada superior do aplicativo.

Também podemos deduzir algo sobre como a implementação de gerenciamento de memória em node.js é implementada, pois há duas variações diferentes dos argumentos para mmap .

PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE

Esses argumentos alocam o espaço de endereçamento, mas PROT_NONE significa que o espaço de endereçamento reservado não pode ser usado (a menos que outra chamada posterior o torne acessível).

PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS

Esses argumentos alocam a memória real para um intervalo específico de endereços (que, presumivelmente, era um anteriormente alocado com a outra combinação de argumentos) e a transforma em uma região de leitura / gravação.

Por que fazemos isso, podemos adivinhar ao observar essa sequência de quatro chamadas de sistema:

mmap(0x3364514ba000, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x3364514ba000
munmap(0x3364514ba000, 286720)          = 0
munmap(0x336451600000, 761856)          = 0
mmap(0x336451500000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x336451500000

Isso aloca 2 MB de espaço de endereço. Em seguida, libere o início e o final desse espaço de endereço e, finalmente, aloque 1 MB de memória para a parte central do espaço de endereço alocado.

Efetivamente, essas quatro chamadas alocam 1 MB de memória com um endereço alinhado em um múltiplo de 1 MB. Então, estamos olhando para um padrão que deseja explicitamente endereços alinhados.

As últimas chamadas de munmap simplesmente liberam os blocos de 1 MB alocados anteriormente. Em particular, noto

munmap(0x336451500000, 1048576)         = 0

Isso libera o bloco de 1 MB alocado nas quatro chamadas de sistema acima.

Tudo isso provavelmente não é o que você queria saber. Mas infelizmente isso é o que pode ser deduzido da saída strace , então você terá que encontrar outras maneiras de encontrar as informações que realmente deseja conhecer.

Você pode estar interessado nesta solicitação de recurso para um sinal para despejar uma pilha traço, que presumivelmente seria muito útil para você agora.

Outra possibilidade é adicionar mais código de log ao seu aplicativo.