时间戳

首页 > 解决方案 > 带有 mysql_to_gcp negsignal.sigkill 的气流

google-cloud-composer - 带有 mysql_to_gcp negsignal.sigkill 的气流

问题描述

我正在使用带有 composer (GCP) 的气流从云 sql 中为 gcs 提取数据，在 gcs 用于 bigquery 之后，我有一些介于 100 Mb 和 10 Gb 之间的表。我的 dag 有两个任务要做我之前提到的事情。对于较小的表，dag 运行平稳，但对于稍微大一点的表，云 sql 提取任务会在几秒钟内失败，但除了“negsignal.sigkill”之外没有带来任何日志，我已经尝试增加作曲家的容量，除其他外，但还没有任何效果。我正在使用 mysql_to_gcs 和 gcs_to_bigquery 运算符

标签： google-cloud-composerairflow

解决方案

negsinal.SIGKILL获取Kubernetes 资源时，您应该首先检查一下。这肯定是资源限制的问题。

我认为你应该监控你的 Kubernetes 集群节点。在 GCP 中，转到 Kubernetes Engine > 集群。您应该有一个包含 Cloud Composer 使用的环境的集群。

现在，前往集群的节点。每个节点都为您提供有关 CPU、内存和磁盘使用情况的指标。您还将看到每个节点使用的资源的限制。此外，您将看到每个节点具有的 pod。

如果你对 K8s 不是很熟悉，让我简单解释一下。Airflow 在节点内使用 Pod 来运行您的 Airflow 任务。这些 pod 被称为airflow-worker-[id]。这样您就可以在 Node.js 中识别您的工作 pod。

检查您的 pod 列表。如果您驱逐了气流工作人员 pod，那么 Kubernetes 会出于某种原因停止您的工作人员。由于 Composer 使用 CeleryExecutor，被驱逐的气流工作人员指出了一个问题。如果您使用 KubernetesExecutor，则情况并非如此，但 Composer 中尚不可用。

如果您单击某个被驱逐的 pod，您将看到驱逐的原因。那应该会给你答案。

如果您没有发现 pod 驱逐有问题，请不要惊慌，您仍然有一些选择。从那时起，你最好的朋友就是日志。请务必按顺序检查您的 pod 日志、节点日志和集群日志。

推荐阅读