我的虚拟机通常在晚上 7 点到午夜之间无事可做，然后它们会重新安排当天剩余时间的大量工作。调度从从 MySQL 数据库获取任务和时间列表开始。虚拟机是否可能在午夜时分变冷，然后难以连接到数据库？我似乎在午夜时分无法持续连接到数据库，但在白天虚拟机有稳定的任务要执行时，它通常可以正常工作。
我是否应该每 10 分钟进行一次“预热”过程来执行一个简单的数据库调用来保持虚拟机和数据库“温暖”？
还有人发现类似的东西吗？我知道 Azure 网站有类似的概念，并且会根据使用情况“变冷/变热”，因此第一个用户在网站启动时通常会遇到糟糕的加载时间。
答案1
您是否使用标准存储来存储 VHD？我想知道这是否是长时间不活动后的存储预热。高级存储不会具有相同的特性。
这白皮书标准存储说明：
预热对数据磁盘的影响 使用 Azure 磁盘时，我们观察到“预热效应”，这会导致短时间内吞吐量和带宽降低。在一段时间内（大约 20 分钟）未访问数据磁盘的情况下，自适应分区和负载平衡机制将启动。如果在这些算法处于活动状态时访问磁盘，您可能会注意到吞吐量和带宽在短时间内（大约 10 分钟）有所下降，之后它们会恢复到正常水平。这种预热效应是由于 Azure 的自适应分区和负载平衡机制而发生的，该机制会根据多租户存储环境中的工作负载变化进行动态调整。您可能还会在其他广为人知的云存储系统中观察到类似的效果。有关详细信息，请参阅Azure 存储：具有强一致性的高可用性云存储服务。对于持续使用的系统，这种预热效果不太可能被注意到。但我们建议您在性能测试期间或访问一段时间不活动的系统时考虑这一点。
答案2
我想到的一件事是使用端点监控来预热您的网站/数据库。您可以使用简单的代码来测试数据库，甚至可以创建多个查询来重新缓存主要内容，然后如果一切按预期进行，则返回 http 状态 200。您可以设置监控以从不同位置运行。适用于虚拟机和 Web 应用程序（经典门户）。
话虽如此，除非出于某种原因重新启动服务器，否则预热通常与数据库无关。请记住，转储也可以冷却服务器，因为您的工作负载最常使用的数据不一定是要缓存/缓冲以完成备份过程的数据。
最后，调整计划任务的超时值应该可以解决午夜维护期间的连接问题（MySQL 超时变量也可能会丢弃长时间运行的进程）。