O que poderia causar "ocioso na transação" em um processo pentaho pdi?

Question

Estou executando um processo ETL usando o cron diariamente em meu servidor a cada 2 horas. O processo ETL preenche um banco de dados de relatórios que executa o Greenplum. Tenho notado que o processo de ETL normalmente fica parado e "Idle in Transactions" normalmente é o que o sustenta. Para esses tipos de processos, como faço para investigar de que tipos de serviços se originaram? Eu estou supondo, mas não tenho certeza, como quando eu corro "sudo /etc/init.d/apache2 gracioso", normalmente, apaga as transações ociosas.

Estou executando o processo ETL em um servidor Ubuntu usando o Sun Java. Apreciaria algumas técnicas ou soluções de depuração para melhorar o processo.

    

Answer 1

"Inativo na transação" significa que uma transação foi iniciada em uma conexão de banco de dados e não foi concluída e não há mais nenhuma consulta em execução.

Na lista de processos do servidor de banco de dados (por exemplo: ps -ef | grep "idle in" ), você encontrará a conexão que está nesse estado. Vai mostrar algo como:

postgres 15268 12917 0 22:36 ? 00:00:03 postgres: user user x.x.x.x(59830) idle in transaction

O (59830) é a porta na máquina x.x.x.x .

Na máquina x.x.x.x , você pode executar o seguinte para descobrir qual processo estabeleceu essa conexão com o banco de dados:

netstat -np | grep 59830

Isso lhe dará algo como:

tcp6 0 0 x.x.x.x:59830 dbserver:5432 ESTABLISHED 25254/java

(ou Apache, ou qualquer que seja o processo). Neste exemplo, 25254 é o PID do processo.

Para que responda à sua pergunta no corpo da sua postagem.

Para lidar, claro, é um assunto mais complicado. Por que esta conexão inicia uma transação e não a completa = codificação incorreta. Resolução: codifique corretamente.

Nota:

O PDI da Pentaho tem o péssimo hábito de também deixar as transações ociosas por um longo tempo. Digamos que você tenha uma etapa no PDI que atualize algumas linhas. Vai:

input step --> filter step --> update step

E digamos que você defina o lote de confirmação como 100 no update step . Você disse, 75 linhas na etapa de atualização e as linhas input step ainda estão sendo inseridas e as linhas filter step de filtragem, mas devido à condição, nada é transferido para update step por pouco tempo porque nenhuma linha corresponde seus critérios no filter step . Então o que você tem? Uma conexão de banco de dados que é idle in transaction (75 linhas atualizadas, mas não confirmadas).

Então está tudo bem, exceto que é chato para o DBA que é alertado sobre essa longa transação.

Mas agora, digamos que você tenha outra etapa que ramifica o filter step e atualiza a mesma tabela, mas de forma diferente e que, de alguma forma, um registro faz parte das 75 linhas atualizadas (mas não confirmadas) e update step 2 precisa atualizar essa linha. O que acontece? Uma tenda. update step 2 não pode atualizar a linha até update step confirmar o lote.

Não está dizendo que é o que você está enfrentando, já que parece ter descoberto, mas não confirmado, que sua transação de bloqueio está sendo executada com o Apache, não com o PDI. Mas a descrição acima é uma descrição de um problema que pode ocorrer para ilustrar o que geralmente está acontecendo.