Em linhas gerais, o que é um memory leak e como identificá-lo?
O memory leak (ML), em um ambiente Siebel, é um acúmulo de memória privada (PrivateBytes) protagonizado por um ou mais Object Managers (OM) de um ou mais Siebel Servers.
Pode ser observado acompanhando a evolução de alocação de PrivateBytes dos OMs diretamente no Sistema Operacional (SO) onde se encontram ativos e executando, mas frequentemente só se percebe o comportamento anormal após alguns dias de observação e coletas.
Não é raro, nos ambientes de 32bits, um OM atingir o limite de memória gerenciável e apresentar um crash. Em ambientes Siebel 7.x ou superior, esse crashes geram um arquivo “crash.txt” sem conteúdo e de tamanho zero bytes.
As causas mais comuns de memory leaks no Siebel CRM são:
- Server Scripts ou Product Scripts distantes das melhores práticas de programação;
- Fetches de quantidades absurdas de registros pro OM, seja em queries sem filtros adequados, seja em loops com queries em sequência;
- Configuração inadequada do sizing do ambiente causando overhead de consumo em poucos processos;
- Settings inadequados dos caches de SQL Data e SQL Cursor;
- Parâmetros de cache de produtos complexos superdimensionados;
- Bugs do produto;
A investigação das causas raízes para um problema de memory leak envolvem várias técnicas e análises que variam de ambiente pra ambiente. Em linhas gerais, é recomendável:
- Efetuar review dos servers scripts e product scripts em busca de falhas de lógica, loops que tendem ao infinito, queries mal formuladas e, principalmente, variáveis complexas que são instanciadas e não são destruídas.
- Efetuar um review de arquitetura e sizing do ambiente Siebel, dimensionando corretamente os parâmetros de determinam a carga máxima que um determinado componente será capaz de atender num determinado server;
- Um review dos parâmetros do configurador de produtos de forma a verificar que a melhor estratégia de caching está sendo adotada frente ao tamanho e complexidade dos modelos utilizados no ambiente.
- Verificar se os valores default para os caches de SQL estão adequados ou se faz sentido utilizar pool de sessões no database de forma a reduzir a quantidade de memória utilizada pelos OMs;
- Verificar se o comportamento do ML se enquadra em algum BUG já documentado pelo fornecedor do produto ou se é necessário abrir um Service Request solicitando apoio do Suporte Global do fornecedor.
Para todas as ações acima descritas, eu posso ajudá-los efetuando as coletas e análises ou orientando o time de suporte e desenvolvimento com as ações necessárias para resolver definitivamente o problema.
Nesse artigo, a ideia é abordar o Memory Based Recycle que é apenas uma contingência ou um paliativo para estabilizar um ambiente produtivo de Siebel CRM enquanto as causas de origem do ML ainda estão sendo investigadas e corrigidas.
Continua após a publicidade
Considerações sobre o Memory Based Recycle
O MBR foi introduzido à partir do Siebel 7.x de forma a forçar a reciclagem de memória dos Object Managers do Siebel e contingenciar problemas de Memory Leaks.
Nas versões mais antigas do produto (6.x ou inferior) existe o parâmetro RecycleFactor que possui característica de contingenciamento semelhantes ao MBR, mas que tem metodologia de setting completamente diferente.
Foi incorporado nos Object Managers do Siebel e recomendada apenas como workaround para problemas de Memory Leak. Ainda assim, o MBR deve ser habilitado apenas durante o período onde as correções da causa do Memory leak estão sendo providenciadas ou investigadas.
É basicamente configurado através de 3 parâmetros no nível do componente (apenas Object Managers): MemoryBasedRecycle, MemoryLimit e MemoryLimitPercent.
O primeiro parâmetro liga/desliga a engine de reciclagem de memória, o segundo indica a quantidade de MB que um OM deve atingir antes de recusar novas tarefas/sessões e o terceiro é o valor percentual sobre segundo que indica o limite máximo de consumo de memória que um OM deve atingir antes de fechar de forma abrupta.
Quando um OM atinge o MemoryLimit, um novo OM é lançado no SO (até o limite de OMs por componente definido através do parâmetro MaxMTServers do componente vezes 2) e o OM antigo não recebe mais tarefas/sessões.
Quando todas as tarefas/sessões finalizam – e por isso é importante configurar corretamente os parâmetros de SessionTimeout, TokenTimeout, ConnIdleTime e qualquer outro parâmetro que controle o tempo de vida de um tarefa/sessão dentro de um componente Siebel de modo a forçar o logoff por idletime – o OM antigo finaliza liberando a memória.
Cuidados com o Memory Based Recycle
Existe um limite de OMs que um componente pode criar no SO e o fato do MBR estar habilitado e os usuários não fazerem logoffs com frequência pode forçar o componente a chegar nesse limite e ficar “Unavailable”, ou seja, impossibilitado de receber novas tarefas/sessões.
Exemplo:
Se o componente, estiver configurado com MaxMTServer=1, ou seja, usa no máximo 1 OM do SO para si e habilitássemos a engine de MBR com os valores default dos parâmetros (1500MB de memória e 20% de limite máximo), quando o OM do componente chegar a 1500MB, irá recusar novas tarefas/sessões, mas as que estivessem logadas continuam funcionando normalmente até fazerem logoff ou serem forçadamente fechadas por idletime. Imediatamente um novo OM é lançado no SO e passa a receber tarefas/sessões no lugar do OM que está aguardando para reciclar.
Nesse momento, existem 2 OM para o componente, 1 Running (limite do MaxMTServer) e recebendo novas tarefas/sessões e 1 Unavailable (limite adicionado pela engine do MBR) aguardando o logoff de todas as tarefas/sessões dele para reciclar memória.
Se o segundo OM recém lançado no SO do ObjMgr também atingir 1500MB antes do OM anterior ter reciclado memória, teremos 2 OMs Unavailable aguardando o logoff de todas as tarefas/sessões dele para reciclar.
Nesse momento, enquanto nenhum dos 2 OMs reciclar memória porque restam tarefas em execução, quem estiver logado continua trabalhando normalmente, mas o componente desse servidor ficará com status “Unavailable” e estará completamente indisponível até que algum dos OMs “presos” comece a liberar memória, seja após logoff de todos os usuários ou após atingir o limite de 20% de memória adicional, conforme o default do parâmetro MemoryLimitPercent (1800MB).
Por isso é importante dimensionar os MThread do componente adequadamente caso a caso para evitar a possibilidade de indisponibilidade além de garantir que, em algum momento, as tarefas/sessões do mesmo finalizem de alguma forma.
Além do comportamento já exposto, se o MBR não for desativado após estabilização do ambiente, todo e qualquer problema mais grave relacionado a qualidade dos códigos que for a produção após algumas releases de configurações e customizações do Siebel, será mascarado e possivelmente só será analisado e corrigido quando a situação de gestão de recursos do ambiente estiver insustentável.
Os parâmetros recomendados para a engine de MBR variam conforme algumas variáveis presentes no ambiente Siebel analisado. Cada ambiente possui características e settings de MBR que podem precisar ser ajustados até 2 ou 3 vezes até chegar numa configuração ótima.
Para o exemplo a seguir:
1. MemoryBasedRecycle=True
2. MemoryLimit=800
3. MemoryLimitPercent=10
4. MaxMthreads = 2
Com essa configuração, quando um dos 2 OMs do componente chegar a 800mb, irá parar de receber novas tarefas/sessões e um 3º OM será lançados no SO. Quando todos os usuários fizerem logoff do OM “cheio”, ele “finaliza” naturalmente.
Se um OM “cheio” atingir 880mb (+10% do limite) antes de todos os usuários fazerem logoff ou finalizarem a tarefa por idletime, o OM “morre” na forçadamente e desconecta todos os usuários pendurados sem causar indisponibilidade no ambiente.
Se os 2 novos OMs lançados no SO ficarem “cheios” antes dos 2 OMs iniciais reciclarem memória, teremos o pior cenário: 4 OMs lotados de memória e o componente unavailable.
Por isso, use a engine com parcimônia e, se precisar de ajuda, conte comigo.
Abraço.
By Neilson Faria
Siebel Architect & Troubleshooter
