O mistério da falta de memória nas notas 11

Alguns de nossos clientes que fizeram upgrade para o Notes 11 tiveram erros de falta de memória no cliente do Notes.

Às vezes era uma caixa de mensagem que dizia que não havia memória livre suficiente, às vezes era um travamento com erros no log de rastreamento. Isso geralmente acontecia depois que o cliente estava aberto por um tempo e, muitas vezes, ao abrir e-mails MIME enviados da Internet ou clicar em links para abrir um navegador externo. Se os usuários estivessem conectados ao Sametime, era mais provável que isso acontecesse.

O estranho nisso:

O que diabos estava acontecendo, e o que podemos fazer para consertar isso?

A primeira pista é que o Gerenciador de Tarefas mostra apenas o Conjunto de trabalho memória para um aplicativo: essencialmente a quantidade de memória em uso. Esse é um bom número para saber e, na maioria dos casos, esse é o número importante, mas existem outras maneiras de ficar sem memória. Abrimos o Monitor de Desempenho do Windows para dar uma olhada mais de perto.

O Monitor de Desempenho tem uma seção de Processos com medições de memória adicionais que você pode acompanhar. Especificamente, analisamos “Bytes privados” (a quantidade de comprometido memória que o aplicativo está usando) e “Bytes Virtuais” (a quantidade de espaço de endereço virtual o aplicativo reservou). Aqui está uma captura de tela do Monitor de desempenho e do Gerenciador de tarefas lado a lado enquanto o cliente do Notes está em execução:

Você pode ver que enquanto o Gerenciador de Tarefas mostra 215 MB de memória em uso, o Monitor de Desempenho nos diz que há quase 2 GB de espaço de endereço virtual sendo reservado. Quando estávamos testando, descobrimos que estavam ocorrendo erros de falta de memória no momento em que o cliente atingiu a marca de 2 GB no monitor de espaço de endereço virtual.

Essa marca de 2 GB é importante porque o cliente do Notes ainda é um aplicativo de 32 bits. Um dos efeitos colaterais disso é que ele tem apenas 2 GB de espaço de endereço virtual para brincar (realmente 4 GB, mas metade disso é reivindicado pelo kernel). Os aplicativos de 64 bits têm um espaço de endereço virtual muito maior (às vezes reservam terabytes de espaço), mas os aplicativos de 32 bits precisam ser cuidadosos.

SIDEBAR: Alguns esclarecimentos sobre o espaço de endereçamento virtual:

Além disso, é um pouco difícil de explicar, e a maioria das pessoas não se importa, mas se você estiver interessado, este é um bom resumo: https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/virtual-address-spaces

De qualquer forma, sabendo o que sabemos, por que está usando tanto e como podemos corrigir o problema?

Alerta de spoiler: a correção imediata foi reduzir o tamanho de heap Java usado pelo cliente Notes. Isso parece contra-intuitivo – normalmente quando você tem um erro de falta de memória, você quer aumentar a memória – mas continue lendo.

O tamanho do heap Java para o cliente é controlado por um parâmetro no arquivo jvm.properties, no Diretório Notes/framework/rcp/deploy. Tem uma entrada assim:

vmarg.Xmx=-Xmx512m

Isso controla o tamanho máximo do heap Java, que é a quantidade de memória que o Java (e, neste caso, o cliente Notes) usa para executar o código. O valor padrão para o Notes é 512 MB, conforme mostrado no parâmetro acima. No entanto, muitos clientes gostam de aumentá-lo se estiverem fazendo coisas com uso intensivo de memória com seus clientes do Notes, especialmente se estiverem usando o Domino Designer.

Este é um parâmetro bastante comum para ajustar, e há até uma nota técnica sobre como alterá-lo SUA PARTICIPAÇÃO FAZ A DIFERENÇA.

Nossos clientes que estavam recebendo erros de memória tinham esse parâmetro definido como 1024 MB. Isso nunca foi um problema com o Notes 9, mas de repente com o Notes 11 era muita memória para atribuir ao heap.

Ao reduzir isso de volta para Xmx512m, os erros de falta de memória desapareceram.

Também pudemos confirmar no Performance Monitor que o uso de um heap de 512 MB reduziu o espaço de endereço virtual para cerca de 1.5 GB, o que deu ao cliente muito mais espaço para respirar quando precisou reservar alguns pedaços extras de espaço.

A próxima pergunta óbvia é: por que os clientes não tiveram esse problema com o cliente Notes 9?

Quando você compila um aplicativo de 32 bits, há um sinalizador que você pode definir chamado /LARGEADDRESSAWARE. Isso permite que o processo do aplicativo use 4 GB de espaço de endereço virtual completo em um sistema operacional de 64 bits, em vez dos 2 GB que vimos acima.

Acontece que o java.exe e notas2.exe os arquivos no cliente Notes 9 foram compilados com os sinalizadores /LARGEADDRESSAWARE, mas os arquivos java.exe e notes2.exe no cliente Notes 11 não foram.

O Notes 9 usou a versão IBM do Java JVM, mas o Notes 11 usa a versão OpenJDK OpenJ9. A distribuição OpenJ9 de 32 bits não foi compilada com /LARGEADDDRESSAWARE até recentemente (versão 8u262, de junho de 2020), portanto, o cliente Notes 11 também não compilou com esse sinalizador.

Em outras palavras, o Notes 9 tinha um espaço de endereço virtual completo de 4 GB, mas o Notes 11 tem apenas 2 GB.

Estamos conversando com a HCL sobre isso, e eles estão cientes do problema e estão planejando uma correção. Ram Krishnamurthy, Arquiteto Chefe do HCL Notes Cliente, nos deu esta orientação:

“Este é um defeito conhecido do OpenJDK para a versão 1.8 apenas no Windows. Uma correção para este problema foi encontrada pela equipe do OpenJDK e fará um release da correção em breve. Esta correção está sendo planejada para ser incluída em um próximo Fix Pack 1101. Isso afeta apenas as versões baseadas em v11, pois agrupa o OpenJDK. Até então, a solução documentada neste artigo pode ser usada.”

Uma vez que o cliente Notes usa uma versão mais recente do OpenJ9 e HCL for capaz de adicionar novamente o sinalizador do compilador, esse problema desaparecerá.