Problema - Consulta de Lote

[Former Member]

Pessoal,

Estou com dificuldades em conseguir visualizar qual o problema na consulta de resultado do lote.

(na moni está tudo ok)

As notas estão demorando geralmente 30/40min para receber o protocolo de aprovação.

De imediato eu parei o job de envio do lote, para o sap "respirar" mas continua lentooooo...

(pois avisa muitasss queues na smq2 e agora está ok limpa)

O server hardware, tem 8 processadores e 16gb ram... e não está com sinal algum de lentidão!

O Sap não está respondendo a altura do hardware, deve ter alguma tabela que seja preciso limpar ou algo do tipo que não estou conseguindo ver.

Consigo monitorar as chamadas ou consumo de banda que está usando esses lotes? Ou qtas chamadas pendentes tem..

Pois achei a conexão do server um pouco baixa(rjnet velocimentro)... 500kbps

Alguem tem alguma dica/idéia? Será muito bem vinda.

Grato,

Bruno Lima

[Former Member]

Bruno, essa lentidão é só na consulta do resultado do lote?

Todas os outros serviços estão funcionando normalmente sem lentidão?

At.,

Bernardo Braga

[Former Member]

Bernardo,

A principio achei que era só na consulta do lote, mas depois acabei vendo que na assinatura quando vem varias ao mesmo tempo o server "chora" e a mesma coisa para consulta do lote.

Acabei de aumentar os DWP para ver se ajuda em algo(não custa...rs), visto que o hardware é robusto. (conforme opinião do Henrique)

Você tem alguma outra idéia?

Obrigado,

Bruno

[Former Member]

ó..ja tive um problema similar que nenhuma nota saia do lugar. Esporadicamente depois de muito tempo algumas continuavam o processamento....depois de muita analise, o pessoal de banco de dados achou um problema em algumas tabelas que não estavam fazendo um balanceamento que deveria (não me explicaram...rs)....

Outro problema que tive foi a tabela /XNFE/ACKNOWLEDG estar com milhares de registros após um problema de inutilização em massa que teve aqui (limpando a tabela, o programa /XNFE/PROCESS_REPORT voltou a funcionar normalmente).

At.,

Bernardo Braga

[former_member182114]

Bom dia Bruno,

Pelo visto está acontecendo uma mistura de problemas aí.

Você tem pouquissimos workprocess DIA habilitados, então não dá pra sair fazendo o paralelismo pois não terá como rodar.

O paralelismo irá criar várias filas, veja na SMQ2 quantas filas você tem (não entradas... filas). Cada fila precisa de um WorkProcess.

Uma lógica tosca pra chutar quantos DIA você precisa seria verificar quantos processos paralelos você rodará. Ex.:

5 SIGNN + 5 BATCH + 5 BATSR + B2B + NFESC + paralelismo do PI na SXMB_ADM.... só aí já teríamos algo como quase 30 necessários. Vc tem 16G na máquina mas não sei o que mais você tem nela. Pergunta tem como aumentar e fazer o restart? mude o parm rdisp/wp_no_dia para 25 e faça um teste. E vá ajustando o paralismo à quantidade de WP's DIA.

Antes do reboot faça um CPA Full cache refresh, quando após várias mexidas nos objetos o java fica lento quanto tem todo o histórico dos objetos e configurações inativos em memória. E este procedimento limpa tudo, e dita uma vida nova.

Outra coisa, você disse 200 notas disparadas de uma vez, então como está a configuração de lotes? Está gerando os lotes com bastante notas ou cada lote sai com uma ou poucas notas ? (verifique o resultado da geração pela tabela /xnfe/batsta campo quantidade NFe). Na configuração de lote (monitor webdynpro), a melhor configuração é deixar APENAS A LINHA DEFAULT. Para sua necessidade imagino os valores:

Tempo=50segundos, Tamanho=500.000, Quantidade=50, Tentativas=5, Tempo Consulta=120 (tempo consulta é usado caso a sefaz não responda o resultado do lote na primeira vez). Depois acompanha o resultado das criações de lote também pela /xnfe/batsta

Estas leituras sequenciais que você menciona para o usuário WF-BATCH é falta de estatísticas atualizadas, verifique as estatísticas destas duas tabelas pela DB20, e peça ao DBA para atualizar as estatísticas desta e das outras de PI no sistema.

Atenciosamente, Fernando Da Ró

[former_member182503]

Aproveitando a deixa, na nota 1380855 é citado que para o paralelismo funcionar o sistema DEVE ter WP DIA disponível para processar as novas solicitações.

Aliás, você se baseou na nota citada acima para o tunning? Essa nota vai muito alem do tunning de paralelismo de BPE.

Segundo a nota 1375656, o parâmetro rdisp/wp_no_dia é igual a 6x o número de CPU's + 10. Ou seja, se seu server tem 6 processadores são 46 WP DIA.

[]'s

Edited by: Jose Nunes on Aug 20, 2010 10:03 AM

[former_member182114]

Bom dia José Nunes,

Aliás, você se baseou na nota citada acima para o tunning? Essa nota vai muito alem do tunning de paralelismo de BPE.

Na verdade não fiz um cálculo, apenas uma soma, chute mesmo com objetivo ao entendimento do processo.

Tunning pode chegar a ser bem complexo às vezes.

Além desta Nota que você postou, tem no SDN alguns artigos How to, sobre o tópico performance excelentes:

SAP NetWeaver Process Integration Tuning Guide

SAP Exchange Infrastructure Tuning Guide XI 3.0

Process Integration Performance Check - Analysis of performance problems and possible solution strat...

How To Fine Tune the J2EE Engine Performance

RFC tunning - Note 1115861 To ensure fast processing in qRFC queues

Atenciosamente, Fernando Da Ró

[former_member182503]

Fernando,

na verdade a resposta era para o criador do tópico, pois nessa nota que citei ele comenta que para que as melhorias funcionem, é necessário que tenham WP disponíveis.

[]'s

[henrique_pinto]

Bruno,

vc tem o paralelismo de filas parametrizado na SWF_INB_CONF, para os BPMs de NFe (ao menos os de envio)?

Ainda, qtos dialog work processes vc tem nessa instancia?

Pela "parrudez" do hardware, nao seria o caso de adicionar um outro app server node pra desafogar o atual e fazer melhor proveito do hardware?

Abs,

Henrique.

[Former Member]

Henrique / Carlos,

SWF_INB_CONF está parametrizado... conforme as notas 1247831, 1243471.

Na instance só tem o NW 7.0 acredito que só um dialog work, como confirmo isso?

Esse outro app server, um basis faria sem problemas, correto?

Agora pouco dispararam 200 notas, para tudo no processamento... estava monitorando na SM50 e na hora de assinar está perdendo muito tempo nisso...

CL_SWF_XI_INSTANCE============CP 001 WF-BATCH Leitura seqüêncial SWFRXIHDR

CL_SWF_XI_PROCESS_EXIT========CP 001 WF-BATCH Leitura seqüêncial SWW_WI2OBJ

em média 40s-60s nesses processos...

(o server parece que incha, depois de algum tempo respira e vai processando)

Verifiquei a tabela /xnfe/acknowledg e não tem nada perdido nela que poderia estar deixando lento. (haviam 4 registros apenas)

Existe mais algum lugar que eu consiga verificar, pois acho muito hardware para "chorar" com 200 notas em assinatura ou em consulta, a ponto de deixar o acesso ao sistema com lentidão...

Agradeço pela ajuda!

Bruno

[henrique_pinto]

Veja qtas queues estao configuradas para os BPMs SIGNN, BATCH & BATSR na SWF_INB_CONF.

E se tiver só um dialog work process vc está morto. rs.

Verifique na SM50 qtas linhas do tipo "DIA" tem no total.

Abs,

Henrique.

[Former Member]

Só alterei esses 3 mesmo... estava sem alteração alguma e mudei por volta de meio dia para 5 nos SIGNN, BATSR, BATCH.

Delivery Mode - Without buffering

Queue Assigment - Multiple

Number of Queue - 5

SM50 - 9 linhas com tipo de processo DIA.

Morto ou não? rsrsrs

Obrigado,

Bruno

[henrique_pinto]

9 DWP eu acho pouco pra um ambiente de producao, mas nao sei se é isso tb a causa dos seus gargalos.

Abs,

Henrique.

[former_member193386]

ola

da uma olhada na SMQR e veja se todas as filas estao ativadas.

caso nao esteja:

sxmb_adm->manage queues - Registre as filas e depois as ative

[Former Member]

Já fiz isso..

E vendo o process_reports, não posso deixar ele parado... e rodei o batch_request direto via se38 e buscou as notas paradas, agora preciso achar onde está o problema na lentidão.

Grato,

Bruno

[former_member193386]

vc ja deu uma olhada na St22 para possiveis dumps e os logs na sm21?