Linha RM

Atalhos

Páginas filhas
  • Melhorias no funcionamento do Job

Versões comparadas

Versão antiga 4

changes.mady.by.user Stella Gleyse Macedo Vilaca

Gravado em

comparado com

Nova versão Atual

changes.mady.by.user Bruno Angelo de Souza Rodrigues

Gravado em

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

CONTEÚDO

...

Índice

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:


Informações
titleAtenção

Para saber o numJobs em tempo de execução é necessário executar a seguinte consulta SQL:

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).

...

Na verão 12.1.31, foi feita uma melhoria de reovery recovery do job. 

Hoje um job em execução têm afinidade com o servidor que ele está em execução. A melhoria implementada afeta um cenário onde garantimos que se esse servidor cair durante a execução de um job e não retornar mais, outro servidor assumirá finalizará o processo com status de falha.

Caso o job não tenha recorrência, o novo servidor controlador irá assumir atualizar o processo (glbxexecucao.servidor) e atualizá-lo que estava em execução com status de falha. 

Se o job for recorrente, o novo servidor controlador além de finalizar o processo com status de falha, irá criar o agendamento da próxima execução, considerando as mesmas regras da recorrência programada no job.

O processo acima ocorrerá quando o próprio host da execução inicial do job não conseguir finalizá-lo antes de cair e a hora de início da execução do job tiver passado mais que 1 hora.

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

...

após o controlador remover esse host 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.

...

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 GJOBXEXECUCAOda 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.