如何解決 Amazon MWAA 環境中的 SIGTERM 和 SIGKILL 錯誤？

3 分的閱讀內容

我想要疑難排解並解決 Amazon Managed Workflow for Apache Airflow (Amazon MWAA) 環境中的 SIGTERM 和 SIGKILL 錯誤。

簡短說明

「SIGTERM」和「SIGKILL」錯誤可能會在任務執行期間持續或間歇出現。當任務所需資源超過可用資源時，作業系統 (OS) 會傳送 SIGTERM 訊號以正常關閉任務。當 SIGTERM 訊號無法關閉任務時，OS 會傳送 SIGKILL 訊號以強制關閉任務。

您會收到以下其中一則「SIGTERM」或「SIGKILL」錯誤訊息：

「Task exited with return code Negsignal.SIGKILL」
「{process_utils.py:133} INFO - Sending Signals.SIGTERM to group 198.PIDs of all processes in the group: [198]」
「{process_utils.py:84} INFO - Sending the signal Signals.SIGTERM to group 198」
「{taskinstance.py:1479} ERROR - Received SIGTERM.Terminating subprocesses.」
「2023-07-26 13:00:49,356: ERROR/MainProcess] Task handler raised error: WorkerLostError('Worker exited prematurely: signal 15 (SIGTERM) Job: 1049.')」
「Error: airflow.exceptions.AirflowException: Task received SIGTERM signal」

您可以在Apache Airflow 任務日誌和工作程序日誌中檢視上述錯誤訊息。如果失敗的任務缺少任務日誌，則工作程序日誌中可能有「SIGTERM」錯誤。

解決方法

降低工作程序上的資源使用量

將大型操作轉移到其他 AWS 服務

使用 Amazon CloudWatch 檢查工作程序的 CPUUtilization 是否高於 90%。當您在 MWAA 工作程序上執行操作，而不是透過 MWAA 環境執行操作時，可能會發生「SIGTERM」錯誤。若要解決此問題，請將大型操作轉移到不同的 AWS 服務進行運算，例如 AWS Glue、Amazon EMR 或 AWS Lambda，而不要使用 MWAA 工作程序。

**注意：**如果中繼資料資料庫的 CPU 使用量偏高，請使用 TABLES_TO_CLEAN 有向無環圖 (DAG) 程式碼範例，刪除中繼資料資料庫項目。

擴展環境

提高環境類別以配置更多資源。

**注意：**當您擴展環境時，任務仍可能因資源限制而失敗。任務在較大的類別環境中仍可能用盡所有資源。

修改 DAG 排程

當您同時啟動大量 DAG 時，工作程序 CPU 使用率可能會偏高。若要更平均地分散工作負載，請將 DAG 的開始時間錯開幾分鐘。如果多個 DAG 包含大型任務，請排程這些 DAG，避免同時執行。

**注意：**當您修改 DAG 排程時，任務仍可能因資源限制而失敗。

降低 core.parallellism

使用 MWAA 主控台降低工作程序上的 core.parallelism 值，讓較少任務可使用更多資源。

調整 celery.worker_autoscale 值

Apache Airflow 無法將任務指派給特定工作程序，工作程序在接受任務之前也不會檢查資源使用率。當您排程任務時，工作程序會依照您為 celery.worker_autoscale 設定的值接受任務。除非您將 celery.worker_autoscale 值設定為 (1, 1)，否則同一個工作程序仍可選取多個大型任務。當工作程序沒有足夠資源可完成任務時，任務會立即失敗。

使用 MWAA 主控台降低 celery.worker_autoscale 的最大值和最小值，使其低於您環境類別的預設值。例如，mw1.large 環境類別的預設並行任務數為 20，且最多可執行 500 個並行任務。如果您將最大值降至 10，則環境會並行執行 250 個任務。最佳實務是變更資源密集型任務的最大值和最小值，讓每個任務有更多工作程序容量。

工作程序可以執行最小數量的任務，並在需要時擴展到最大值。

解決失敗任務的「SIGTERM」錯誤

檢查任務執行個體活動訊號逾時

當執行任務的工作程序不再有資源可執行任務時，任務會失敗。由於任務執行個體與工作程序之間的連結中斷，工作程序無法將活動訊號傳送到中繼資料資料庫。當活動訊號中斷時間超過您為 scheduler_zombie_task_threshold 設定的值時，排程器會傳送 SIGTERM 訊號以關閉任務。

若要檢查排程器是否關閉沒有回應的任務，請使用 CloudWatch 主控台檢視 ZombiesKilled Apache Airflow 指標。或者，使用排程器日誌中的 scheduler_job.py。如需更多資訊，請參閱 GitHub 網站上的 scheduler_job.py。

若要避免此問題，請將 scheduler_zombie_task_threshold 的值從 5 分鐘提高到 20 分鐘或更長。此外，最佳實務是設定 core.default_task_retries。將任務重試參數設定為大於或等於 2。如需更多資訊，請參閱 Apache Airflow 網站上的 default_task_retries。

不要重複任務執行個體

當排程器偵測到重複任務時，會傳送 SIGTERM 訊號以終止重複項目。若要解決此問題，請不要重複任務執行個體。

檢查 DagFileProcessorManager 上的 SIGTERM 訊號

排程器可能會將 SIGTERM 訊號傳送到 DagFileProcessorManager 程序。

降低記憶體使用量

如果任務使用過多記憶體，則系統可能會終止任務，避免其他任務受到影響。

若要降低記憶體使用量，請採取以下動作：

修改任務和 DAG 程式碼，使其使用較少記憶體。如需更多資訊，請參閱 Apache Airflow 網站上的最佳實務。
將更多資源指派給您的環境。

修改 core.killed_task_cleanup_time

當 LocalTaskJob 偵測到沒有回應的任務時，會將活動訊號傳送到排程器，以正常關閉任務。您為 killed_task_cleanup_time 設定的值會決定任務在排程器強制關閉前，可用於清理的時間長度。

如需更多資訊，請參閱 Apache Airflow 網站上的 killed_task_cleanup_time。

資料庫連線逾時

在 MWAA 環境中執行 Airflow 任務並嘗試連線至 Snowflake、PostgreSQL 或 Amazon Redshift 等資料庫時，連線可能會逾時並導致「SIGTERM」錯誤。

若要解決此問題，請在 Airflow 組態中將 core.execute_tasks_new_python_interpreter 設定為 True。

注意： core.execute_tasks_new_python_interpreter 參數預設為啟用。

將長時間執行的任務拆分為較小的作業

MWAA 使用 Amazon Simple Queue Service (Amazon SQS) 作為 celery 代理程式，其可見性逾時上限為 12 小時。如果任務執行超過 12 小時，則其 Amazon SQS 訊息可能會逾時，並導致 Apache Airflow 強制關閉任務。在任務重試期間，任務會嘗試重新處理 SQS 訊息。若要解決此問題，請將長時間執行的任務拆分為較小的作業，以便在 12 小時內完成。

解決 CloudWatch PutLogEvents 限流

如果 PutLogEvents CloudWatch API 發生限流，Apache Airflow 可能會出現「SIGTERM」錯誤。

若要解決此問題，請找出 PutLogEvents API 呼叫發生限流的原因。PutLogEvents 動作會依每秒每帳戶配額受到限流。如有需要，您可以請求提高配額。

避免依賴傳輸閘道

網路延遲可能間歇性導致「SIGTERM」錯誤，尤其是在使用 Amazon VPC Transit Gateway 的 MWAA 環境中。若要將網路延遲降到最低，請建立 AWS PrivateLink 虛擬私有雲端 (VPC) 端點。

**注意：**您為私有 MWAA 環境設定的 VPC 端點，必須使用與 MWAA 環境的相同安全群組。或者，VPC 端點必須在 MWAA 安全群組與端點安全群組之間有路由。

確保 DAG 到達時間未超過 celery.task_adoption_timeout

如果到達時間大於您為 celery.task_adoption_timeout 設定的值，則任務會失敗。如需更多資訊，請參閱 Apache Airflow 網站上的到達時間和 task_adoption_timeout。

若要解決此問題，請確保到達時間未超過 task_queued_timeout 參數的預設值 600 秒。如需更多資訊，請參閱 Apache Airflow 網站上的 task_queued_timeout。

**注意：**在較早版本的 Apache Airflow 中，task_queue_timeout 是 task_adoption_timeout。