谷歌云计算引擎随机变得无法访问答案

【问题标题】：Google Cloud compute engine randomly becomes unaccessable谷歌云计算引擎随机变得无法访问
【发布时间】：2026-02-18 18:30:02
【问题描述】：

我有一个运行 Apache 和 3 个 python 脚本的自定义（1 个 vCPU，2 GB 内存）计算实例的问题，它基本上等待消息并运行一些 SQL 查询并创建报告。有时，整个实例对 Apache、SSH 甚至对串行控制台的访问都没有响应。看起来整个实例都被冻结了。唯一的解决方案是主动登录我的 Google Cloud 帐户并重新启动实例。

我已经检查了磁盘空间，因为 Google 在他们的一个页面中建议这可能会导致实例冻结，但我仍然有 6GB 可用磁盘空间，所以这应该不是问题。

我已添加来自“串行端口 1（控制台）”的日志，以防它有助于诊断问题。

有人可以帮助我找出发生这种情况的原因吗？提前谢谢你。

串行控制台日志输出：

https://pastebin.com/raw/Z9gADmCn

Nov 18 19:14:24 web-server systemd[1]: Stopping System Logging Service...

Nov 18 19:14:24 web-server systemd[1]: Stopped System Logging Service.

Nov 18 19:14:24 web-server systemd[1]: Starting System Logging Service...

Nov 18 19:14:24 web-server systemd[1]: Started System Logging Service.

Nov 18 19:14:25 web-server dhclient[558]: bound to 10.166.0.10 -- renewal in 1434 seconds.

Nov 18 19:14:25 web-server ifup[516]: bound to 10.166.0.10 -- renewal in 1434 seconds.

【问题讨论】：

您好，欢迎来到 *。我的建议是添加 Stackdriver 代理，以便在您的 VM 中进行日志记录和监控。下次出现挂起时，请仔细查看 Stackdriver Logging，并通过 Stackdriver 指标检查机器的历史记录。查找可能的资源中断，例如内存或文件句柄或网络连接。 Stackdriver 是您分析的好朋友。控制台日志包含启动启动信息，但不多（意见）。
感谢您的建议！我已经添加了它。好像我已经在我的实例上激活了某种类型的日志记录。据我所知，它们没有问题。也许你能看到一些东西？ prnt.sc/pyqxyk prnt.sc/pyqy7g prnt.sc/pyqyf9
这些日志看起来不错......但把自己想象成医生。如果患者生病并且您进行了测试（查看一组日志）并且他们没有显示任何内容，那么您继续前进。我在想内存使用和 CPU 使用可能是下一个。如果一台机器只是“放弃”经验，我会指出它已经耗尽了一些资源。您的解决方案在挂起之前运行了多长时间？我正在嗅探最终耗尽机器的资源泄漏。内存泄漏会表现为内存利用率的增加。
这是一个很好的类比！由于我直到现在才登录，我不确定每次重新启动之间间隔了多长时间，但每周说一次并不是一件容易的事。我检查了内存利用率，似乎可能存在缓慢的内存泄漏（在一小时内从 18% 增长到 21%），明天我会再次检查它是否真的在增长。我会告诉你发生了什么，谢谢！图片：prnt.sc/pyrrmz

标签： google-cloud-platform linux-kernel debian google-compute-engine

【解决方案1】：

最好在 Serverfault 上问这个问题，以引起系统管理员而不是开发人员的注意。

在您使用上述 Kolban 评论中的建议之前，我建议您检查一些简单的事情。

1- 检查实例是否处于维护状态（在实例详细信息页面中，您可以找到您的维护窗口）

2- 同样在实例详细信息页面下，您应该能够检查 CPU 和内存利用率，并查看冻结时是否出现峰值。这应该会让你朝着正确的方向前进。

3- 检查系统/应用程序日志：例如，我建议检查 /var/log/syslog 和 /var/log/nginx/error.log（如果适用）。

【讨论】：

感谢您的回复。恐怕我找不到您所说的维护窗口。我已启用 Stackdriver 和正常运行时间检查，因此我可以获得有关机器的长期统计信息，并在下次发生时获取相关的 syslog 条目。当我再次偶然发现这一点时（有更好的数据），如果我在 Sysadmins 中创建一个线程并让这个线程不理会会更好吗？
支持Notauser所说的，您可能需要检查VM的操作日志中是否记录了hosterror。配置live migration，可能有助于避免某些主机系统事件的停机例如软件或硬件更新。
我还想向您推荐these articles，它解释了如何构建“弹性应用程序”和“强大的系统”以避免在您的虚拟机 (VM) 实例受到影响时出现这种情况意外故障/停机。
我所说的 Sysadmins vs Devs 是 System Administrators vs Developers 。在此处查看更多信息[1] [1] meta.serverfault.com/questions/2602/…

【解决方案2】：

我在我的一个谷歌计算引擎实例中遇到了同样的问题，它在启动一段时间后变得冻结。当我重置实例时，它又开始正常工作了。所以我发现的问题是实例上的 CPU/RAM 较少，而该实例上的进程需要更多的 CPU/RAM。因此，当将 CPU/RAM 从 1CPU/3.75 GB RAM 更改为 4 CPU/16 GB RAM 时，它开始工作永久好。

在这个问题的核心，机器是从磁盘快照创建的，其中不同的应用程序，如 tomcat，postgres 被配置为高 CPU/内存等。所以看起来当机器完全运行时，它面临的内存更少导致实例运行缓慢和冻结的所需进程。

【讨论】：