Neste documento serão citadas as melhorias que estão sendo feitas no funcionamento do Job, com o intuito de melhorar a sua performance.
Veja mais sobre a Configuração N Camadas, Configuração do Jobserver na Linha RM.
Na verão 12.1.31, foi feito um ajuste no tempo de escrita nessa tabela.
Essa tabela possui informações dos servidores de job em atividade. Alguns de seus dados são obtidos pelo arquivo de alias.dat e outros o sistema atualiza de forma dinâmica, de acordo com o ambiente.
Pode-se consultar:
Qual o intervalo de leitura da fila de processos (gjobserver.tempopool ou alias.dat: <JobServerPollingInterval>)
Buscando melhorar a performance, o campo gjobserver.numjobs não mostrará mais quantos jobs estão sendo executados. Mas será preenchido com a regra:
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).
1 - quando o servidor estiver executando a quantidade máxima de jobs configurada para ele (maxjobs).
A escrita no campo gjobserver.dataultativ também foi alterada.
Antes este campo era atualizado sempre que era feita uma verificação da fila de jobs pelo sistema. Essa verificação é feita de acordo com o valor configurado em gjobserver.tempopool.
Após a implementação da melhoria, o campo gjobserver.dataultativ será atualizado após 5 vezes o tempo configurado em gjobserver.tempopool.
Na verão 12.1.31, foi feita uma melhoria de 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 finalizará o processo com status de falha.
Caso o job não tenha recorrência, o controlador irá atualizar o processo que estava em execução com status de falha.
Se o job for recorrente, o 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 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.
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.
Com o intuito de melhorar a performance do sistema, ao que se refere a jobs, foi criada a tabela GJOBXEXECUCAOHST. Em versões anteriores, quaisquer jobs finalizados, agendados ou em execução eram armazenados na tabela GJOBXEXECUCAO.
O que mudou:
A migração dos dados é feita via banco de dados e não é gerado um job para isso.
Além disso, foi criada a view GJOBXEXECUCAOVIEW para listar todos os jobs, da tabela GJOBXEXECUCAO e GJOBXEXECUCAOHST.
Em ambiente 3 camadas = false, os registros serão migrados para a GJOBXEXECUCAOHST pelo 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.