php应用程序在AWS上突然慢下来

Question

我正在AWS上运行一个旧的PHP (7.1) / NGINX (1.10.2)应用程序。应用程序在AWS上运行了几个多月。自2天以来，我们经历了高延迟问题。但它不会影响整个页面。只有“密集”的PHP进程似乎存在交付内容的问题。

我现在查了那么多其他相关的话题，但没有任何东西指向正确的方向。

首先，延迟与网络无关，因为我在从服务器向本地主机发送请求时也会得到这些延迟。它似乎也与数据库无关(该网站能够在<3ms内连接到RDS，而DB ~20%和内存空闲>2GB看起来不错)。连接到数据库并运行the服务器所做的一些查询也很好。

2GB服务器本身并不消耗太多的硬件资源(CPU占10-25%，内存空闲~2GB)。此服务器上没有安装cron作业/计划任务。服务器上仍有超过50%的iNodes可用。网络网关正在检索/传输8-25MB/秒。我们根本不监控任何类型的DoS。

我已经检查并尝试调整PHP设置(memory_limit、进程管理、子进程等)。这里什么都帮不上忙。停用/激活OPCache并没有真正的影响。

即使在使用以前安装的AMI并启动新服务器时，同样的延迟问题也会再次发生。在多个可用性区域中运行应用程序时也会发生同样的情况。

为了了解PHP在哪里花费时间，我使用了blackfire.io，实际上它告诉我它在mysql交互上花费了大部分时间(这并不奇怪，因为应用程序发送了大量带有大量联接的脏查询等等，这是这里唯一性能昂贵的东西)。我还向代码本身添加了一些调试输出。它通常在不到6秒内完成(不幸的是，这是我们从搜索中知道的正常平均值。)

根据目标组，延迟平均在3-8秒之间，但我们也发现了很多请求超时的延迟(30-60秒)。

在这一点上，我甚至不知道在这里提供什么。我不想粘贴所有相关的配置等在这里。所以，请告诉我你需要什么才能在这里提供帮助:/

php/nginx日志不记录与此问题相关的任何内容。赛斯日志也是一样。唯一能找到的是Timed out waiting for reply from 91.189.89.199:123 (ntp.ubuntu.com)，但即使是date也是同步的。PHP慢速日志(超时设置为5秒)也是空的。ELB访问日志只监视高“backend_processing_time”。

Nginx实际上将请求路由到一个S3桶，除了一个S3挂载之外，服务器上没有任何大量的临时文件或其他东西。

发送到互联网的请求正在按预期执行。DNS似乎也不是问题(可以像往常一样到达db和其他互联网服务)。

有没有人有什么想法会导致这些延迟问题？还应该调查什么/？？我真的很感激每一个能为我指明正确方向的帮助或问题。

诚挚的问候。

Answer 1

你自己说的：

它告诉我，它将大部分时间花在mysql交互上(这并不奇怪，因为应用程序发送了大量带有大量联接的脏查询等等，这是这里唯一性能昂贵的东西)。

这是你的申请。它会导致你的“管道”堵塞，所以有些人会经历30-60等待。现在，我还要检查一下任何现在超时的file_get_contents，因为这是突然发生的。

另外，我遇到了一个类似于这个before on serverfault的问题，我想特别指出my comment

我不再为那家公司工作了，他们因为法律原因而破产了。但!当我离开的时候，我们30秒的加载站点下降到了3秒。我们的linode CPU就坏了。解决方案完全是缓存。我们的框架的初始化过程在性能上是非常昂贵的，而内部框架没有内置缓存。我能说的就是缓存对象缓存，页面缓存，使用清漆！这将解决您的问题(但您仍然会有一个糟糕的框架，当您无法缓存时，您将感到悲伤。)您必须修复执行错误的代码)。

希望这能帮到你。哦，也是this comment too

当你去看医生的时候，他告诉你吃某些药--因为他知道你不会听“停止喝苏打水和吃快餐”的声明--这就是为什么我没有很好的答案--因为事实是，没有设置或快速修复--只有可悲的事实:我们必须戏剧性地改变我们的网络应用程序本身。

Answer 2

在撰写本文时，我并没有真正意识到，也有CPU的学分，。

机器人的组合，一些来自云服务器的奇怪的请求，只请求我们的搜索(从几个月以来)，RDS Cpu的学分，平均来说，确实有太多的sql查询导致了这种现象。结果表明，t2介质实例的Cloudwatch度量显示了两个核心中每个核的平均CPU利用率(20%) (t2.media+的基线性能有时更高30-80%)，一旦丢失它们，就会不断地杀死所有的cpu学分，然后很难获得新的学分(例如在夜间)。