Assessment em Ambientes Siebel – Parte 2

A primeira parte desse artigo com a introdução, descrição dos acessos e as primeiras coletas pode ser acessado aqui (Assessment em Ambientes Siebel – Parte I).

Coletas adicionais para Assessment em Ambientes SIebel

Aqui continuamos a elencar algumas coletas fundamentais para um eficiente Assessment em Ambientes Siebel que facilitarão o trabalho de qualquer troubleshooter ou arquiteto.

Habilitar o Siebel ARM granularidade 1 (g1) nos Siebel Servers

O Siebel ARM captura tempos de resposta em pontos chave de monitoramento dentro da infraestrutura do Siebel Server. Poderíamos habilitar a coleta em todo servidor, mas num primeiro momento, é interessante coletarmos apenas dados dos principais componentes utilizados no Siebel no ambiente produtivo do cliente. Aqui, sigo utilizando como exemplo o WfProcMgr, EAIObjMgr_ptb, EIM e eCommunicationsObjMgr_ptb (AOM).

Atenção: É importante destacar que o SARM g1 pode impactar a performance geral dos componentes entre 0 (ambientes Vanilla) e o máximo de 5% (ambientes altamente customizados) negativamente, segundo o Suporte Global da Oracle. Contudo, segundo minhas experiências prévias, qualquer impacto existente é imperceptível.

SBLSERVER_ROOT\bin\srvrmgr.exe /g GTW /e ENT / SBL_SERVER /u USER /p PASS
change param SARMLevel=1 for comp WfProcMgr
change param SARMPeriod=5 for comp WfProcMgr
change param SARMMaxFiles=20 for comp WfProcMgr
change param SARMFileSize= 10485760 for comp WfProcMgr
change param SARMLevel=1 for comp EAIObjMgr_ptb
change param SARMPeriod=5 for comp EAIObjMgr_ptb
change param SARMMaxFiles=20 for comp EAIObjMgr_ptb
change param SARMFileSize= 10485760 for comp EAIObjMgr_ptb
change param SARMLevel=1 for comp eCommunicationsObjMgr_ptb
change param SARMPeriod=5 for comp eCommunicationsObjMgr_ptb
change param SARMMaxFiles=20 for comp eCommunicationsObjMgr_ptb
change param SARMFileSize= 10485760 for comp eCommunicationsObjMgr_ptb

exit

Onde:

SBLSERVER_ROOT é o diretório de instalação de algum dos Siebel Servers;

GTW é o alias/Name Server do Siebel Gateway;

ENT é o nome lógico do Siebel Enterprise;

USER é o usuário com privilégio de acesso às telas administrativas do Siebel;

PASS é a senha do usuário privilegiado;

SBL_SERVER é o nome lógico de cada Siebel Server do ambiente;

Atenção: Com as configurações acima é possível saber a quantidade de espaço em disco necessário no server para guardar os arquivos bastando seguir a seguinte lógica:

Espaço Máximo por Comp. = MaxMThreads X SARMMaxFiles X (SARMFileSize/1048576)

Supondo que no num Siebel Server os 3 componentes estejam habilitados e 2 deles têm MaxMThreads=20 um deles têm MaxMThreads=10, temos:

Espaço Máximo necessário no SERVER = ((20 X 20 X 10) *2) + (20 X 10 X 10)

Espaço Máximo necessário no SERVER = 10000 Megabytes aproximadamente (10Gb)

Quando a limite máximo de arquivos definidos em SARMMaxFiles é atingido, os arquivos SARM gerados mais antigo é sobre-escrito pelo mais novo. Portanto, não há possibilidade do espaço consumido pelos arquivos do SARM g1 ultrapassarem as estimativas feitas pra cada um dos Siebel Servers.

Não há como antecipar a frequência um novo arquivo será gerado (depende da carga do MThread), logo o ideal é fazer uma cópia dos arquivos já gerados para outro local de forma a mantermos o histórico por pelo menos uns 15 dias consecutivos sem o risco de perdermos os SARMs files mais antigos. Para esse objetivo, podemos utilizar o seguinte script de cópia de arquivos:

FOR /L %%A IN (1,1,336) DO (
copy "SBLSERVER_ROOT/log/*.sarm" "CUSTOM_PATH/SBL_SERVER /" /Y
TIMEOUT 1800
)

Onde:

SBLSERVER_ROOT é o diretório de instalação de cada um dos Siebel Servers que tem o componente operacional;

CUSTOM_PATH é o path com permissão de escrita para reter temporariamente os outputs das coletas;

SBL_SERVER é o nome lógico de cada Siebel Server do ambiente;

Essa cópia está programada para executar à cada 30 minutos durante 7 dias seguidos. O filesystem destino no CUSTOM_PATH deverá ter espaço suficiente para reter todos os arquivos .sarm gerados pelos 3 componentes à partir de todos os Siebel Servers onde eles estão em execução.

É claro que há todo o trabalho de processamento desses SARMs files para transformá-los em informação útil ao Assessment em Ambientes Siebel. Esse processamento merece um artigo exclusivo (loading…).

Habilitar o Siebel ARM g1 nos Siebel Web Servers

Como já falado anteriormente, Siebel ARM captura tempos de resposta em pontos chave de monitoramento dentro da infraestrutura do Siebel Server.

No caso dos Siebel Web Servers, a configuração é feita através da configuração de variáveis de ambiente conforme abaixo:

SIEBEL_SARMLevel = 1
SIEBEL_SARMBufferSize = 5000000
SIEBEL_SARMMaxFiles = 10
SIEBEL_SARMFileSize = 5242880
SIEBEL_SARMThreshold = 0

A mesma lógica de escrita e sobre-escrita de arquivos é aplicável, dessa forma, também é altamente recomendável copiar os arquivos já gerados para outro local de forma a mantermos o histórico por pelo menos 7 dias consecutivos sem o risco de perdermos os SARMs files mais antigos. Para esse objetivo, podemos utilizar o seguinte script de cópia de arquivos:

FOR /L %%A IN (1,1,336) DO (
copy " SWSE_ROOT/log/*.sarm" "CUSTOM_PATH/NS_SWS/" /Y
TIMEOUT 1800
)

onde:

SWSE_ROOT são os diretórios de instalação de todos os Siebel Web Servers;

CUSTOM_PATH é o path com permissão de escrita para reter temporariamente os outputs das coletas;

NS_SWS é o Name Server do Siebel Web Server

Perfil de Consumo de Memória e CPU dos Siebel Servers

Para fins de cruzamento de informações e identificação de picos de processamento, memory leaks, crashs ou anomalias impactando os Siebel Servers, é necessário coletar informações de consumo de CPU e Memória durante X dias a cada Y minutos (depende da operação e perfil de uso da aplicação) . A ferramenta que será utilizada para a coleta não faz diferença deste que possamos analisar nos outputs as seguintes variáveis:

Geral (Por server):

• Available bytes

Memória (Por processo e Geral):

• Private Bytes
• Handle Count
• Pool Nonpaged Bytes
• Pool Paged Bytes
• Virtual Bytes

CPU

• % Processor Time
• “% Privileged Time

Exemplo usando WMI (do windows):

wmic OS get /format:csv >> %OUT_PATH%\%TIMESTAMP%_%SERVER%_OS_GET.log

wmic cpu get /format:csv >> %OUT_PATH%\%TIMESTAMP%_%SERVER%_CPU_GET.log

wmic path win32_perfformatteddata_perfproc_process where (Name like ‘%%sieb%%’) get /format:csv >> %OUT_PATH%\%TIMESTAMP%_%SERVER%_SIEB_GET_PID.log

Continua após a publicidade 

Spool Cíclicos

Alguns outputs precisam ser gerados ciclicamente durante X dias com frequência de Y minutos (depende da operação e perfil de uso da aplicação) através da execução dos seguintes comandos:

FOR /L %%A IN (1,1,336) DO (
SBLSERVER_ROOT\BIN\ srvrmgr.exe /g GTW /e ENT /u USER /p PASS /i CUSTOM_PATH\srvrmgr_commands.txt /o CUSTOM_PATH \output\list_%%A.log
TIMEOUT 1800
)

O arquivo “srvrmgr_commands.txt” deve ser criado em CUSTOM_PATH\ com o seguinte conteúdo:

list comp
list tasks
list stats for comp eCommunicationsObjMgr_ptb server SBL_SERVER show STAT_NAME, CURR_VAL
list stats for comp EAIObjMgr_ptb server SBL_SERVER show STAT_NAME, CURR_VAL
list stats for comp WfProcMgr server SBL_SERVER show STAT_NAME, CURR_VAL

… o bloco em azul se repete para cada Servidor Siebel com o respectivo componente habilitado

Onde:

SBLSERVER_ROOT é o diretório de instalação de um dos Siebel Servers;

CUSTOM_PATH é o path com permissão de escrita para reter temporariamente os outputs das coletas;

SBL_SERVER é o nome lógico de cada Siebel Server do ambiente;

SBLSERVER_ROOT é o diretório de instalação de algum dos Siebel Servers;

GTW é o alias/Name Server do Siebel Gateway;

ENT é o nome lógico do Siebel Enterprise;

USER é o usuário com privilégio de acesso às telas administrativas do Siebel;

PASS é a senha do usuário privilegiado;

Contagem de Produtos Complexos

Essas contagens são importantes para guiar a estratégia de configuração de cache de produtos, parte fundamental do Assessment em Ambientes Siebel.

--CPS USADOS POR HORA NOS ÚLTIMOS 30 DIAS / EXPORTAR O RESULTADOS

SELECT  P.NAME,
TO_CHAR (O.CREATED, 'dd/mm/yyyy hh24') || '00:00',
COUNT ( * )
FROM  SIEBEL.S_PROD_INT P, SIEBEL.S_ORDER_ITEM O
WHERE      P.ROW_ID = O.PROD_ID
AND O.ROOT_ORDER_ITEM_ID = O.ROW_ID
AND P.PROD_TYPE_CD = :VALOR
AND O.CREATED >= TRUNC (SYSDATE - 30)
GROUP BY  P.NAME, TO_CHAR (O.CREATED, 'dd/mm/yyyy hh24') || '00:00';

--QUANTIDADE TOTAL CPS ÚLTIMOS 30 DIAS / EXPORTAR OS RESULTADOS

SELECT  P.NAME, COUNT ( * )
FROM  SIEBEL.S_PROD_INT P, SIEBEL.S_ORDER_ITEM O
WHERE      P.ROW_ID = O.PROD_ID
AND O.ROOT_ORDER_ITEM_ID = O.ROW_ID
AND P.PROD_TYPE_CD = :VALOR
AND O.CREATED >= TRUNC (SYSDATE - 30)
GROUP BY  P.NAME;

Onde:

:VALOR pode ser ‘Customizable’, ‘Personalizável’, etc., dependendo do idioma utilizado pelo configurador de produtos.

A contagem abaixo requer o auxílio de um Desenvolvedor Siebel que vai precisar fazer medições de consumo de memória do Siebel Web Client Dedicado (siebel.exe) para cada um dos Produtos Complexos retornados na query acima.

Após iniciar o Siebel Web Client Dedicado (SWCD) é preciso fazer uma medição da quantidade de memória consumida em 3 momentos:

1. Imediatamente antes de clicar no botão “Customize” (ou “Personalizar” ou “Configurar” dependendo da tradução) – Momento X;
2. Imediatamente após o produto complexo ser carregado na tela – Momento Y.
3. Imediatamente após fazer uma configuração normal no produto complexo – Momento Z.

Atenção: Como trata-se de medições aproximadas, é altamente recomendável que cada produto complexo seja testado 3x para eliminar distorções.

Após cada ciclo de teste de 1 produto complexo, o SWCD deve ser desligado e religado novamente para o refazer o teste com o mesmo produto ou com o próximo produto complexo do ambiente.

A tabela abaixo pode ser utilizada para as medições: