プロジェクト

全般

プロフィール

操作問い合わせ #3778

完了

【急ぎ対応希望】滞留しているジョブの強制停止方法について。

匿名ユーザー さんが約2ヶ月前に追加. 11日前に更新.

ステータス:
終了
優先度:
高め
担当者:
-
開始日:
2025/08/26

説明

急ぎ教えていただきたいことがあります。
可能なら本日か明日中にご回答いただけると幸いです。

◎教えていただきたいこと
Job Arranger for Zabbixにおいて。

滞留しているジョブが大量に作成されています。
これらのジョブをまとめて強制終了させたいと思っています。
こちらのやり方をご教授お願いできますでしょうか。

もしくは滞留してしまっているジョブを物理削除しようかと思っています。
物理削除を実施してもよろしいでしょうか。

上記どちらが良いかについても併せて
ご教授いただけると幸いです。

↓ja_run_job_table全件 115万件。

↓ja_run_job_table status=0のもの(未実行の状態と思われるもの) 89万件。
 昨年10月から滞留しているジョブがあります。

◎ご相談背景
こちらのサーバーがジョブを滞留していることにより
CPUのリソース消費量が増加を続けております。
本件急ぎ対応してCPU負荷率を下げたいと思っています。

◎その他
以下が類似のチケットかと思っています。
こちらの実行SQLと同様のSQLを実行するのが良いと思っています。
https://www.jobarranger.info/community/issues/3773


ファイル

clipboard-202508261601-vanto.png (122 KB) clipboard-202508261601-vanto.png 匿名ユーザー, 2025/08/26 16:01
clipboard-202508261614-uuunl.png (28.4 KB) clipboard-202508261614-uuunl.png 匿名ユーザー, 2025/08/26 16:14
clipboard-202508261615-gpsgt.png (109 KB) clipboard-202508261615-gpsgt.png 匿名ユーザー, 2025/08/26 16:15
clipboard-202509171212-ghzkg.png (45.7 KB) clipboard-202509171212-ghzkg.png 匿名ユーザー, 2025/09/17 12:12
clipboard-202509171212-hgems.png (26.7 KB) clipboard-202509171212-hgems.png 匿名ユーザー, 2025/09/17 12:12

匿名ユーザー さんが約2ヶ月前に更新

また本事象を踏まえてジョブの実行時間感覚を広げるなど
恒久対策も検討しようと考えています。

匿名ユーザー さんが約2ヶ月前に更新

また、目先すぐに何らかの対応措置を取りたいと思っています。
何卒よろしくお願いします。

保守サポート 担当360 さんが約2ヶ月前に更新

  • ステータス新規登録 から 回答中 に変更

コミュニティサイトでのお問い合わせについて、申し訳ありませんが個別の期日対応は承っておりません。
迅速な対応をご希望の場合は、サポート契約のご検討をお願いできればと思います。

匿名ユーザー さんが約2ヶ月前に更新

承知しました。
調査お願いします。
ひとまずは回答お待ちします。

保守サポート 担当360 さんが約2ヶ月前に更新

ご質問の内容に基づきますと、ja_run_job_table からジョブを強制停止することは可能です。
ただし、その場合でも該当するジョブネットのレコードは ja_run_jobnet_table に残る点にご注意ください。

もし目的が、停止したジョブを物理的に削除することであれば、ja_run_jobnet_table から直接レコードを削除する方法が適しています。

以下のようなクエリを使用できます:

■ 実行中のジョブネットの削除:

DELETE FROM ja_run_jobnet_table WHERE inner_jobnet_main_id = <your_management_id>;

■ 実行ログの削除:

DELETE FROM ja_run_log_table WHERE inner_jobnet_main_id = <your_management_id>;

この方法により、ジョブとそれに関連するジョブネットの両方が適切に削除されます。

匿名ユーザー さんが約2ヶ月前に更新

ご教授ありがとうございます。
念の為ご確認させてください。

ご確認①
以下3テーブルの位置づけが分かりませんでした。
それぞれどういう役割になりますでしょうか。
ja_run_job_table
ja_run_jobnet_table
ja_run_log_table

ご確認②
今回以下テーブルのレコードを削除する方法を教えていただいたと思います。
ja_run_jobnet_table
ja_run_log_table

以下テーブルのレコードは削除しなくてもよろしいでしょうか。
ja_run_job_table

Job Arranger for Zabbixについて
知見があまりなくご教授いただけると大変助かります。

匿名ユーザー さんが約2ヶ月前に更新

また、各テーブルの役割・各テーブルの項目の説明が
記載された資料のようなものあったりしますでしょうか。
もしあればいただきたいです。
(提供難しければその旨ご連絡いただければと思います。)

保守サポート 担当360 さんが約2ヶ月前に更新

  • ステータス回答中 から 担当者処理中 に変更
  • 担当者保守サポート 担当360 にセット

保守サポート 担当360 さんが約2ヶ月前に更新

  • 優先度通常 から 高め に変更

保守サポート 担当360 さんが約2ヶ月前に更新

  • ステータス担当者処理中 から 回答中 に変更
  • 担当者 を削除 (保守サポート 担当360)

ご確認①
以下3テーブルの位置づけが分かりませんでした。
それぞれどういう役割になりますでしょうか。
ja_run_job_table
ja_run_jobnet_table
ja_run_log_table

ja_run_jobnet_table:このテーブルは、ジョブネットおよびサブジョブネットの実行中のステータスや関連情報を保存します。
ja_run_job_table:このテーブルは、ジョブアイコンの実行中のステータスや関連情報を保存します。
ja_run_log_table:このテーブルは、ジョブネットおよびジョブに関連するすべてのステータスをログとして記録・保持するためのものです。

ご確認②
今回以下テーブルのレコードを削除する方法を教えていただいたと思います。
ja_run_jobnet_table
ja_run_log_table

以下テーブルのレコードは削除しなくてもよろしいでしょうか。
ja_run_job_table

ja_run_job_table のレコードを削除する必要はありません。 親テーブルである ja_run_jobnet_table のレコードを削除すれば、親子関係により、子テーブルである ja_run_job_table のレコードも自動的に削除されます。

また、各テーブルの役割・各テーブルの項目の説明が
記載された資料のようなものあったりしますでしょうか。
もしあればいただきたいです。
(提供難しければその旨ご連絡いただければと思います。)

→申し訳ありませんが、こちらのご提供は難しいです。

匿名ユーザー さんが約2ヶ月前に更新

承知しました。
調査・ご連絡ありがとうございます。
こちらの回答を踏まえて対応してみようと思います。

また進展ありましたらご連絡させてください。
以上よろしくお願いします。

匿名ユーザー さんが約1ヶ月前に更新

ご相談させていただきたいことがあります。
◎ご相談内容
以下テーブルに対してTRUNCATE文で全レコード削除することは問題ないでしょうか。
ja_run_jobnet_table

◎ご相談背景
今週から以下SQL文でレコード削除を行っています。
ただ、レコード数が多いためか一向に削除処理が終わりません。

具体的には16万レコードあるうちの2万レコードを
以下DELETE文で削除しようとしました。

DELETE FROM ja_run_jobnet_table WHERE inner_jobnet_main_id = <your_management_id>;

ただ、4時間30分かかっても一向に削除処理が終わらず
SQLを中断したという状況です。
もし問題なければTRUNCATE文でデータを一括削除しようと考えています。
(あらかじめデータのバックアップは取るようにします。)

保守サポート 担当360 さんが約1ヶ月前に更新

  • ステータス回答中 から 担当者処理中 に変更
  • 担当者保守サポート 担当360 にセット

保守サポート 担当360 さんが約1ヶ月前に更新

  • ステータス担当者処理中 から 回答中 に変更
  • 担当者 を削除 (保守サポート 担当360)

以下テーブルに対してTRUNCATE文で全レコード削除することは問題ないでしょうか。
ja_run_jobnet_table

→削除して問題ありません。念のため、削除前にバックアップの取得をお願いします。

匿名ユーザー さんが約1ヶ月前に更新

承知しました。
ありがとうございます。
TRUNCATE文試してみます。

また実行しましたらご連絡します。

匿名ユーザー さんが約1ヶ月前に更新

ご教授の通りTRUNCATE文を実行しました。
ただ、以下エラーとなりました。

こちらはいかがするのがよいでしょうか。
ご教授の程お願いできますでしょうか。

匿名ユーザー さんが約1ヶ月前に更新

例えば外部キー制約を一時的に無効にしてからTRUNCATE文を実行。
その後、外部キー制約を再度有効に戻すのがよろしいでしょうか。

ご教授いただけると幸いです。

保守サポート 担当360 さんが約1ヶ月前に更新

  • ステータス回答中 から 担当者処理中 に変更
  • 担当者保守サポート 担当360 にセット

保守サポート 担当360 さんが28日前に更新

  • ステータス担当者処理中 から 回答中 に変更
  • 担当者 を削除 (保守サポート 担当360)

こちらはいかがするのがよいでしょうか。
ご教授の程お願いできますでしょうか。

→ このエラーは、外部キー制約が原因で発生します。

例えば外部キー制約を一時的に無効にしてからTRUNCATE文を実行。
その後、外部キー制約を再度有効に戻すのがよろしいでしょうか。

→この場合、TRUNCATEの代わりに、より簡単で安全な方法として次のコマンドを使用することをおすすめします。

〇 MySQLの場合
①レコードをバッチで削除するための簡単なプロシージャを作成してください。

DELIMITER $$

CREATE PROCEDURE delete_all_jobnet()
BEGIN
  DECLARE rows_affected INT DEFAULT 1;

  WHILE rows_affected > 0 DO
    DELETE FROM ja_run_jobnet_table
    LIMIT 1000;

    SET rows_affected = ROW_COUNT();
  END WHILE;
END$$

DELIMITER ;

②すべてのレコードを削除するために、プロシージャを呼び出してください。

CALL delete_all_jobnet();

③削除が完了したら、そのプロシージャを削除してください。

DROP PROCEDURE IF EXISTS delete_in_chunks;

〇PostgresSQLの場合
レコードをバッチで削除するには、次のブロックを実行してください。

DO $$
DECLARE
  rows_affected INTEGER := 1;
BEGIN
  WHILE rows_affected > 0 LOOP
    DELETE FROM ja_run_jobnet_table
    WHERE ctid IN (
      SELECT ctid FROM ja_run_jobnet_table LIMIT 1000
    );

    GET DIAGNOSTICS rows_affected = ROW_COUNT;
  END LOOP;
END$$;

PostgreSQLを使用されている場合、parallel queryの利用が有効になっていますと、レコード件数が多くなることにより処理時間が大幅に伸びることがあります。
JobArrangerでは、Index検索が動作する前提で設計しています。
SHOW max_parallel_workers_per_gather; にて現在の設定を確認することが出来ます。

postgresql.conf にmax_parallel_workers_per_gather = 0 を設定する事で、無効にできます。

匿名ユーザー さんが21日前に更新

ご教授ありがとうございます。
上記教えていただいた方法で再度試してみます。

匿名ユーザー さんが11日前に更新

こちらご教授いただいた方法で解決したようです。
ジョブ削除できましてCPU負荷率下がりました。
ありがとうございます。

保守サポート 担当362 さんが11日前に更新

  • ステータス回答中 から 終了 に変更

他の形式にエクスポート: Atom PDF