我们已经建立了一个网站并将其运营将近3年。 直到大约2-3个月前，我们才实现了一项新功能“多语言”。在那之后，我们开始注意到一些滞后问题。第一个非常严重，几乎导致整个服务器瘫痪，我们在我们的某个地方发现了一个无限循环（我们认为这是由卡在其中并占据所有资源的搜索机器人拾取的）服务器崩溃）。
但是，该问题已解决，我们（完全）确定不再有代码发布引起此问题。但是我们不是100％肯定的。
偶尔（注意：一天中不止几次），我们的服务器（托管在Microsoft Azure上）将随机花费大约2-3分钟，然后再执行任何操作。从显示网页到查询数据库（使用mysql工作台）。加载任何内容仅需2-3分钟。
我们已经查看了Google Analytics（分析）和我们的Apache日志，以尝试找出导致此问题的模式。但是我们找不到任何模式。在出现滞后问题之前，Apache日志中没有发生任何异常情况。最重要的是，当我们的网站上有0位访问者时（根据Google Analytics（分析），在深夜），我们甚至遇到了这些滞后问题。
我们最大的mysql表包含大约5万条记录，因此它实际上甚至没有数据库那么大。我们总共有大约100张桌子。
当服务器运行良好时，我转到mysql并在其中手动执行一些“较重”查询，以查看它们是否真的很慢，但是它们都不超过0.5秒。但是，当服务器落后时，它可能很容易花费30-60秒。
我们在后台运行了一些CRON作业，尤其是其中两个作业可能会导致我们遇到问题，但是我对此也非常不确定。 第一个是邮寄的CRON。我们的数据库中有一个队列，其中包含所有电子邮件，以及布尔值0或1（指示是否已发送）。此CRON作业每5分钟运行一次，并提取发送至0的电子邮件，然后尝试发送。 接下来，我们还有另一个CRON作业，该作业会生成电子邮件并将其发送到我们的用户数据库。一次最多可以发送500封电子邮件（每2周仅发送一次）。有时我们会达到Outlook设置的每天发送的最大电子邮件数量限制。这会使我们的电子邮件停止发送一天，但是第二天将再次发送出去。
起初我想，也许这是通过电子邮件发送CRON作业的问题，该作业执行时间更长，并且2个Cron作业重叠。但是，我已经进行了一次测试，知道CRON作业应该发送500封电子邮件，因为我们知道我们已经处于限制状态，并且都不应该发送出去。因此，我让CRON作业手动运行，大约15秒钟后，它结束了，没有发送任何作业。在这15秒钟内，网站运行得非常流畅。 另一个测试是发送100封电子邮件（知道我们尚未达到每日限制）。生成和发送所有电子邮件大约花费了20秒。因此，这些CRON职位几乎不可能重叠。
我现在完全被困住了。我们正在尝试与Microsoft联系，以查看他们是否可以确定他们是否有问题，但到目前为止还没有运气。