Histórico da Página

CONTEÚDO

...

01. VISÃO GERAL

Neste documento serão citadas as melhorias que estão sendo feitas no funcionamento do Job, com o intuito de melhorar a sua performance.  

...

• Qual é o servidor controlador, que distribui os processos da fila (gjobserver.controlador)
• Quantos Jobs são executados simultaneamente pelo Host (gjobserver.maxjobs ou alias.dat:<JobServerMaxThreads>) 

• Qual o intervalo de leitura da fila de processos (gjobserver.tempopool ou alias.dat: <JobServerPollingInterval>)

• Quantos Jobs estão sendo executados (gjobserver.numjobs)  (Em Tempo de execução)

Buscando melhorar a performance, o campo gjobserver.numjobs não mostrará mais quantos jobs estão sendo executados. E o campo gjobserver. Mas fulljobs será preenchido com a regra:

WITH CTE_GJOBXEXECUCAO (NUMJOBS, SERVIDOR) AS

(

SELECT COUNT(GJOBXEXECUCAO.STATUS) AS NUMJOBS,

GJOBXEXECUCAO.SERVIDOR

FROM GJOBXEXECUCAO

WHERE (GJOBXEXECUCAO.STATUS IN (0,1)

OR GJOBXEXECUCAO.STATUS IS NULL)

AND PRIORITY <> 1

GROUP BY GJOBXEXECUCAO.SERVIDOR

)

SELECT GJOBSERVER.NOMESERVIDOR,

GJOBSERVER.DATAULTATIV,

GJOBSERVER.MAXJOBS,

GJOBSERVER.TEMPOPOOL,

GJOBSERVER.CONTROLADOR,

GJOBSERVER.FULLJOBS,

CTE_GJOBXEXECUCAO.NUMJOBS

FROM GJOBSERVER

LEFT JOIN CTE_GJOBXEXECUCAO

ON (GJOBSERVER.NOMESERVIDOR = CTE_GJOBXEXECUCAO.SERVIDOR)

0 - quando a quantidade de jobs em execução por aquele servidor forem igual a zero ou menor que a quantidade máxima que aquele server puder executar (maxjobs).

...

O processo acima ocorrerá quando o próprio host da execução inicial do job não conseguir finalizá-lo antes de cair e após o controlador remover esse host da GJOBSERVER.Exemplo do fluxo:
O job 103746 começou sua execução às 12:00 pelo host Teste1:8050.
As 12:10 o host Teste1:8050 cai e não responde mais. Depois de um tempo de tentativas com o servidor, se ele não responder o controlador removerá esse server da GJOBSERVER.

Em ambiente 3 camadas, em cenários onde o host cair, se algum jobRunner estiver executando um job, esse jobRunner vai tentar finalizar a sua execução antes de se matar. Para evitar que a melhoria citada acima finalize esse job que está em execução e que continua comunicando com o banco, foi feito com que o jobrunner assuma o papel de atualizar a GJOBSERVER.DATAULTATIV e GJOBSERVER.FULLJOBS = 1, até finalizar o seu job. Assim, será adiado que o controlador remova esse host da GJOBSERVER e finalize seus jobs em execução, e com o campo fulljobs = 1 esse host não receberá mais jobs para serem executados.  

04. ARMAZENAMENTO DO HISTÓRICO DE EXECUÇÃO DE JOBS NA TABELA GJOBXEXECUCAOHST

A partir da versão 12.1.31, em ambiente 3 camadas, o histórico de execução de jobs ficará armazenado na tabela GJOBXEXECUCAOHST.

...

• No atualizador da versão 12.1.31 será criada a tabela GJOBXEXECUCAOHST e ao executá-lo grande parte dos jobs finalizados serão migrados da tabela GJOBXEXECUCAO e deletados da mesma. Por esse motivo, o atualizador pode demorar um tempo maior para ser executado, dependendo da quantidade de registros a serem migrados.
• [LEGADO → Ver tópico 06] Após a atualização da base e migração dos registros, os próximos jobs finalizados serão migrados para a tabela de histórico em até 1 dia após sua execução. Foi criada uma rotina no sistema onde são escolhidos 3 horários do dia que normalmente existe o menor número de execução de jobs. E durante essas 3 horas os jobs finalizados podem ser migrados da tabela GJOBXEXECUCAO para a tabela GJOBXEXECUCAOHST.

...

Em ambiente 3 camadas = false, os registros serão migrados para a GJOBXEXECUCAOHST pelo atualizador.

Novidades do atualizador , mas a rotina que continua executando a migração dos jobs não será executada. Nesse cenário os jobs finalizados posteriormente continuarão na tabela GJOBXEXECUCAO.da 12.1.31: 

• Ao atualizar a base, os jobs que estiverem sendo executados no momento da atualização serão encerrados da seguinte forma:
  • Quando a data de início de execução do job for mais antiga que 1 dia à execução do atualizador, o job será cancelado. Nesse cenário se o job for recorrente ele não será reagendado. 
  • Quando a data de início de execução do job for de até 1 dia à execução do atualizador, o status do job será falha. Nesse cenário se o job for recorrente ele será reagendado. 
• Em bases inconsistentes, jobs que apresentarem registro apenas na tabela GJOBXEXECUCAO e não tiver registro na tabela GJOBX serão excluídos.  

05. LIMPEZA DE JOB SERVERS DA TABELA GKNOWNJOBSERVER

A partir da versão 12.1.2306, foi adicionado um mecanismo para realizar a limpeza de JobServers da tabela GKNOWNJOBSERVER, mantendo a saúde e sanitização.

Para que um JobServer seja removido, será seguida a seguinte regra:

• • Não deve estar presente a tabela GJOBSERVER.
  • Não deve estar em GKNOWNJOBSERVERAPPSERVERRULES, ser definido como um Servidor de Aplicação.
  • Não deve estar em GKNOWNJOBSERVERRULE, ter afinidade com um processo.

06. MIGRAR JOBS FINALIZADOS PARA A TABELA DE HISTÓRICO

A partir das versões 12.1.2406.232, 12.1.2410.165 e 12.1.2502.100, foi adicionada uma forma manual de se migrar jobs finalizados para a tabela de histórico.

Este processo é de extrema importância para o ambiente pois um acumulo de registros na tabela GJOBXEXECUCAO pode deixar a execução de processos cada vez mais lenta.

É recomendado o agendamento deste processo para uma execução regular, com o intuito de manter a saúde do ambiente.

Segue a documentação: Migrar jobs finalizados para tabela de histórico