Я запускаю процесс ETL с использованием cron ежедневно на моем сервере каждые 2 часа. Процесс ETL заполняет базу данных отчетов, в которой работает Greenplum. Я заметил, что процесс ETL обычно останавливается, и его задерживает "Idle in Transactions". Для такого рода процессов, как мне исследовать, из каких сервисов они были созданы? Я предполагаю, но не совсем уверен, так как когда я запускаю "sudo /etc/init.d/apache2 graceful", он обычно очищает транзакции Idle.
Я запускаю процесс ETL на сервере Ubuntu с использованием Sun Java. Был бы признателен за некоторые методы отладки или решения для улучшения процесса.
«Ожидание в транзакции» означает, что транзакция была запущена в соединении с базой данных, но не завершена и больше не выполняется никаких запросов.
В списке процессов сервера базы данных (например: ps -ef | grep "idle in") вы найдете соединение, которое находится в этом состоянии. Будет показано что-то вроде:
postgres 15268 12917 0 22:36 ? 00:00:03 postgres: user user x.x.x.x(59830) idle in transaction
В (59830) порт на x.x.x.x машина.
На x.x.x.x машины, вы можете запустить следующее, чтобы узнать, какой процесс установил это соединение с базой данных:
netstat -np | grep 59830
Это даст вам что-то вроде:
tcp6 0 0 x.x.x.x:59830 dbserver:5432 ESTABLISHED 25254/java
(или Apache, или как бы там ни было). В этом примере 25254 это PID процесса.
Итак, это ответ на ваш вопрос в теле вашего сообщения.
Разобраться, конечно, сложнее. Почему это соединение запускает транзакцию, а не завершает ее = плохое кодирование. Решение: кодируйте правильно.
Примечание:
У Pentaho PDI есть плохая привычка также оставлять транзакции простаивающими в течение длительного времени. Допустим, у вас есть шаг в PDI, который обновляет некоторые строки. Это идет:
input step --> filter step --> update step
Допустим, вы установили для пакета фиксации значение 100 на update step. Скажем, 75 строк на этапе обновления и input step все еще тянет рядами, а filter step фильтрация строк, но из-за условия ничего не переходит в update step на некоторое время, потому что ни одна строка не соответствует вашим критериям в filter step. Так что у вас есть? Подключение к базе данных, которое idle in transaction (75 строк обновлены, но не зафиксированы).
Так что все в порядке, за исключением того, что это раздражает администратора базы данных, который получает предупреждение об этой длительной транзакции.
Но теперь, допустим, у вас есть еще один шаг, ответвляющийся filter step и обновляет ту же таблицу, но по-разному, и что так или иначе одна запись является частью 75 обновленных строк (но не зафиксирована), и что update step 2 теперь необходимо обновить эту строку. Что случается? Прилавок. update step 2 не могу обновить строку, пока update step совершил партию.
Я не говорю, что это то, что вы испытываете, поскольку вы, кажется, обнаружили, но не подтвердили, что ваша блокирующая транзакция выполняется под Apache, а не PDI. Но приведенное выше описание проблемы, которая может возникнуть, чтобы проиллюстрировать, что обычно происходит.