“冻结”谷歌计算引擎实例 PostgreSQL

Question

我们在 Google 计算引擎上运行了几个 Debian 实例和 PostgreSQL，最近我们已经看到了以下问题的多次出现。

实例突然变得无响应。 我们不能 ssh 它，我们不能连接到数据库。 使用 telegraf 的内部监控在此期间也没有运行，没有收集到监控数据。

Google 对 CPU 活动的监控显示该期间的使用率非常低。 GCP 日志不显示任何迁移，实际上根本不显示任何内容。 此外，所有内部日志（例如 postgresql 日志、系统日志、来自定期 cronjobs 的日志）也显示出相同的差距。 看起来该实例在那段时间有点冻结。 到目前为止，我们只注意到 PostgreSQL 个实例，因为这些实例被大量使用。

实例运行这些操作系统和 PG 的变体：

• Debian 9 PG 11.9
• Debian 9 PG 10.13

这些事件通常需要 10-15 分钟，但在一个案例中需要 1:20 小时。 在事件结束时，一些 PG 进程被 OOM 杀手杀死，但在事件开始之前数据库上的活动通常相对较低，CPU 使用率和 memory 使用率也是如此。 所以它看起来更像是一个实例在再次启动时资源有限？ 如果可能的话……

知道这些问题的原因是什么或者我们应该寻找什么吗？ 正如我提到的，在事件发生期间，Debian 的内部日志中通常没有任何信息。

更新：为避免误解 - 有问题的实例是运行在 N1-highmen-8 机器（8 个 CPU 和 52 GB 内存）和 5 TB SSD 上的数据仓库数据库。 或者从 inte.net 收集指标的数据库——定制机器 20 个 CPU，90 GB RAM 和 3 TB SSD。 所有软件都是最新的。

更新 2：系统日志、kern.log 和消息在实例无响应期间的时间间隔内均未显示任何内容。 事件发生后，telegraf 立即记录了 CPU 上的巨大平均负载，但实际上 CPU 使用率非常低，谷歌监控显示在整个事件期间 CPU 使用率非常低。 同样在事件结束后，postgresql 进程中的一个立即被 OOM 杀手杀死，导致数据库 go 进入恢复模式。

至于 PG work_mem 参数 - 实例收集指标（20 个 CPU 90 GB RAM，3 TB SSD）使用 8MB - 它仅插入数据但通常运行 500 - 1000 个连接。

第二个实例是数据仓库分析数据库并使用 work_mem 128MB，因为较低的数字会导致大多数查询的查询计划非常糟糕，并且通常只运行 10 - 30 个连接。

在两个数据库上发生事件之前，没有异常数量的连接。

更新 3：分析数据库今天发生了几起具有相同特征的小事件。 在最后一个过程中，我们从 GCP GUI 停止了实例，并在几分钟后再次启动它。 也许它导致迁移到不同的硬件。 由于此操作实例运行正常。

Answer 1

我遇到了类似的问题，但是在 GCP 中有一个 MySQL 实例，第一个问题与我使用的 VM 实例的类型有关，我在这个 VM 实例上有一个 f1-micro 机器类型，突然我无法访问ssh。由于这种类型的VM Instance只有memory的0.6GB，所以很快就用完了memory，我把它换成了默认值的e2-medium，这次解决了我的问题。 由于实例不在 memory 中，实例中的服务开始失败，这是我无法访问我的实例的原因。

另一次我又开始了类似的问题，但这一次，问题是磁盘，我只有 10 GB 并且有一个进程填满了我的磁盘，当一个分区空间不足时，实例又开始失败了。 我只调整了我的磁盘大小，现在我的实例磁盘是 20GB 并且工作正常。

话虽如此，我建议根据您的方便增加资源以提高性能，因为出现您描述的问题是一个很好的指标，表明您现有的机器类型不适合您在该实例上运行的工作负载。

如果你的情况和我一样，你可以更改机器类型来调整你的 memory 并且你可以按照这些任务的后续步骤，请访问以下链接以获取更多信息。

更改机器类型

1.- Go 到VM 实例页面。

2.- 在“名称”列中，单击您的实例。

3. 在实例详细信息页面中，完成以下步骤：

   a) 如果您尚未停止实例，请单击停止按钮以停止该实例。

   b) 实例停止后，点击页面顶部的编辑按钮。

   c) 在 Machine configuration 部分下，select 您要使用的机器类型，或创建自定义机器类型以仅增加 Memory。

   d) 保存您的更改并重新启动您的 VM 实例。

您可以按照本指南或使用以下命令调整磁盘大小：

gcloud compute disks resize DISK_NAME --size DISK_SIZE

或者使用控制台：

1. Go 到磁盘页面以查看项目中的区域永久性磁盘列表。
2. 单击要调整大小的磁盘的名称。
3. 在磁盘详细信息页面上，单击编辑。
4. 在“大小”字段中，输入磁盘的新大小。
5. 单击“保存”将更改应用到磁盘。

调整磁盘大小后，必须调整文件系统的大小，以便操作系统可以访问额外的空间。

注意：请勿将引导磁盘的大小调整为超过 2 TB，因为这是限制。

编辑1

您提到当实例被冻结时，日志不会显示有关该问题的信息。 您是否尝试使用 kernel 日志？ 我认为它可以提供有关此问题的大量诊断信息。

对于 Debian，此日志应位于以下路径中：

/var/log/kern.log

消息日志也可以提供帮助

/var/log/messages

您可以在此链接中获取有关日志的更多信息。

此外，我认为这可能是 PostgreSQL 配置问题，例如您可以查看“work_mem”，此参数指定内部排序操作使用的 memory 的数量和写入临时磁盘文件之前的 hash 表。 默认值是四兆字节 (4MB)。

您可以咨询此URL以获取更多信息。

我还找到了一篇很好的文章，解释了如何为数据仓库使用配置 PostgreSQL

另一种选择可能是 kernel 进程负责识别可以调出的 memory。 您可以将流程配置为更频繁地检查较小的块。

此链接更好地解释了此配置。

此外，据我所知，数据仓库服务器会消耗大量资源，因此最好检查您的实例是否有足够的资源来满足您的工作负载。

编辑2

我找到了一篇描述类似问题的文章，它说：

当您消耗的 memory 多于计算机上可用的数量时，您可以开始在 Postgres 日志中看到out of memory错误，或者在更糟糕的情况下，OOM 杀手可以开始随机终止正在运行的进程以释放 memory 。 Postgres 中的 memory 错误只是您正在运行的查询的错误，而 Linux 中的 OOM 杀手开始杀死正在运行的进程，在某些情况下甚至可能包括 Postgres 本身。

这是他们给出的建议。

当您看到out of memory错误时，您要么想要通过升级到更大的实例来增加机器本身的整体 RAM，要么想要减少 work_mem 使用的work_mem的数量。 是的，您没看错：内存不足时，最好减少work_mem而不是增加，因为这是每个进程可以消耗的 memory 的数量，而太多的操作正在利用 memory。

你可以在这里看到这篇文章“Configuring memory for Postgres”的完整解释，它可能会帮助你解决这个问题。