ecs如何提高cpu缓存命中率

‘壹’ AWS - ECS + Application Load Balancer的思考

我们有一个前端应用项目，这个前端应用用来替换老的Web站点的部分页面，其结构如下：

用户的请穗橘或求首先会到Nginx，由Nginx做反向代理，根据请求路径转发到New Web App或者Legacy Website。

在部署这个应用的时候使用到了AWS ECS。下图为最开始时的部署结构：

从图中可以看到，应用的DNS（Route53）指向了一个外部可访问到的负载均衡器（External Classic Load Balancer）。负载均衡器暴露了80端口(用于Http请求)和443端口(用于Https请求)。负载均衡器将80端口和443端口都映射到了AWS EC2 Instance上的80端口。

而由ECS管理的Nginx容器，它将宿主机（EC2 Instance）的80端口映射到了容器的80端口。这样从External Classic Load Balancer来的请求都会转发到Nginx容器。

那么，当用户请求到达Nginx容器后，由Nginx做反向代理，根据请求路径将请求转发到New Web App或者Legacy Website（Legacy Website并不属于部署结构中，所以并没有在部署结构图中画出）。

假设，这个请求需要转发到New Web App中，那么应该怎么做呢？

由于AWS ECS并没伍侍有服务自动发现机制，所以我们需要给New Web App Container Cluster添加一个内部可访问到的负载均衡器（Internal Classic Load Balancer）。这个负载均衡器将80端口映射到了AWS EC2 Instance上的3000端口，而在创建Nginx Container的时候会将这个内部负载均衡器关联起来。所以在请求需要转发到New Web App中时，直接转发到这个内部负载均衡器即可。

到此为止，这个方案看似还不错，但是如果你细心研究，你就会发现它存在一些问题。

有没有发现，我们将ELB端口映射到了Instance上，而这个映射是固定的。一个Instance上的某个端口一旦被占用，就无法被其它进程绑定。这就意味着一个EC2 Instance上只能猜伍启动一个Nginx容器、一个New Web App容器，因为它们都需要绑定到特定的EC2 Instance端口号。

那么，如果说EC2 Instance上有足够的资源能够再启动一个New Web App容器或者Nginx容器，但是由于端口已经被占用所以这些资源只能被浪费掉。我们必须再启动一台EC2 Instance给ECS使用，ECS发现这个新的EC2 Instance上没有绑定过3000或者80端口，并且有足够的资源（CPU, Memory）启动New Web App或者Nginx容器，那么New Web App或者Nginx容器就会在新的EC2 Instance上启动。

由此，我们可以看到这种部署方式，给我们带来了这样的问题，即： 某种类型的容器只能在一个EC2 Instance上启动一个 。这对于我们来说是一个极大的限制，为了解决这个问题，我们找到了AWS Application Load Balancer（ALB）。

首先，我们将Classic Load Balancer换成了Application Load Balancer，如下图：

从图中看，好像并没有什么改变。是的，如果还是使用固定端口的话对我们并没有什么帮助。但是，ALB有一个特性它可以实现 动态端口绑定 ，这个特性正式我们想要的。

通过，实现动态端口绑定我们的架构变为如下图所示：

如图所示，通过动态端口绑定，我们实现了在 一个EC2 Instance上启动多个同类型的容器 。

‘贰’ 麻烦高手指点ecs g31t-m5主板怎么超频cpu(酷睿e5200)大概能超到多少

775平台用E5200就可以了，没必要再升级CPU，E7500价格能买I3或者AMD4核了，E5200也不是很垃圾的CPU，日常够用了，小超一下不见得比E7500慢多少。
要换就换个好点的显卡，以后换主板和CPU了还能用告渗余。显卡和你目前配置搭配就用个GT240或者HD4670之类500元以内的就成。
近期打算换主板和CPU的话喊改就买个GT450,GT460,HD5750,HD5770之类的。
最省钱的就是淘块二手7600GT,8600GT,HD2600这个档次要DDR3显存的一百左右，9600GSO，9600GT,HD3850这袜滚档次的能找到二手更好。都秒杀你的G210.

‘叁’ 综保与ecs后台有延迟

原因有数据传输速度和大量并发。综保（综合保障平台）和ECS（企业云服务平台）后台都有一定的延迟，数据需要在网络传输中进答巧行交换，速度慢则会导致延迟增加，有大量用户同时在使用综保或简举枯ECS后台，拦洞也会导致后台处理任务出现延迟。延迟是综保和ECS后台使用中的常见问题，但这并不意味着它们不能正常运行，通过合理规划和使用优化措施，可以有效地避免或减少延迟问题，提高平台的工作效率和稳定性。

‘肆’ ECS服务器CPU跑高，老是被这个safedogtray.exe程序占满，如何解决，可以直接删掉吗急！

safedog是安全狗的程序，删除后安全狗不能运营
如果你觉得安全狗占用过高，推荐你使用另一款更好用的服务器管理面板【云帮手】
云帮手是一款集中化服务器管理软件，提供全方位的云服务器管理服务。融合大数据分析、可视化、态势感知、威胁情报分析技术，为客户提供一站式云安全产品、服务和解决方案，实现服务器、网站及业务的安全稳定运行。

其全面支持所有主流云服务提供商，同时兼容Windows、CentOS、Ubuntu、Debian、OpenSUSE、Fedora等主流云服务器操作系统。支持多台服务器可视化管理，监控告警，日志分析等便捷功能，提供跨云多平台一站式批量云服务器安全管理服务。

‘伍’ ecs/ecr使用

安装aws cli参考 https://docs.aws.amazon.com/zh_cn/cli/latest/userguide/cli-chap-install.html

执行aws configure配置终端权限

上述操作羡吵成功后提示Login Succeeded
然后制作镜像修改镜像名称为 {docker-hub-url}/{存储库名称}:{版本}
执行上磨镇传:

准备好在ecr上传的镜像名称
481118635851.dkr.ecr.cn-north-1.amazonaws.com.cn/test:latest

1.创建新任务

我这里选择FARGATE

任务定义名称*：自己定
网络模式：选awsvpc
任务执行角色:没瞎派粗有的话选择创建新的
任务内存 (GB)：根据自己的服务来定
任务 CPU (vCPU):根据自己的服务来定

接下来添加容器:
主要配置容器名称和映像(image)其它自行配置

添加完容器后选择创建任务

启动类型: FARGATE
服务名称:自定
任务数:指启动的实例数量

网络配置
选择集群vpc
子网选择创建时分配

然后一直下一步即可

‘陆’ 如何处理阿里云ECS服务器CPU利用率过高

如果你选择的是t5类型的主机，那么这个问题是无解的，因为这个类型本身就是限制了CPU性能基线在10%~15%，不能超过这个数字。

也有一种可能用的是共享型实例，特点是多台小鸡共享一个母鸡的系统资源，小鸡之间存在了资源争抢。

关于这个内容有一些解释，长期建站和 windows 远程桌面慎用阿里云突发性能 t5 实例，我觉得写的挺实在的，建议怎么操作都有提供了

‘柒’ 阿里云服务ECS为什么那么慢.1 vCPU 2 GiB (I/O优化) ecs.t5-lc1m2.small 1Mbps

阿里云和其他云服务器不太一样，需要在管理面板控制组那里开启允许访问的端口
按说你这个配置用来挂机不应该卡的
你可以ping一下IP看看丢包率

‘捌’ unityecs没有绘制

性能；
减少不必要的内存使用
放一张图，之前写了demo测试，对于使用ecs，不使用ecs，做instancing优化3中情况下，性能的差别。

可以看到如果你渲染的object在500以内，ecs性能并没有显着提升，当超过1000后，ecs性能有显着的优势，在10000obj下，差不多100的性能差距。

所以对于200内obj的游戏，是不是用ecs差别不大。

另外ecs这是unity提出的一个系统化的方案和标准，我们自己也可以或多或少使用传统方法做出类似的结果，没必要非ecs不可。

demo是如下图（Instancing），根据自带的rotate demo完成对应的instancing和传统方法版本，这个demo是1000个cube，有一个sphere旋转，撞到cube后，cube会自转一段时间，逐渐停止，所以需要1001个物体不停的update：

=========补充公司内分享的完整文章：

不再需要MonoBehaviour、Component和GameObject
以前MonoBehaviour承载了游戏逻辑和数据两部分功能，我们通过创建GameObject然后销宏首添加MB（MonoBehaviour，下同）然后通过Update来更新游戏逻辑，往往我们Update里就是更新一些数据，而MB的实现非常复杂，有很多不需要的功能都一股脑的被继承下来，这导致我们一个非常简单的任务可能需要浪费很多内存去应付那些不需要的功能，如果再无节制的使用MB，那基本就是游戏运行效率的噩梦。

之前的Component是继承自MB，大部分时候Component的作用就是提供数据，但是通过Component组织的数组是对CPU cache不够友好的，因为它并没有把需要多次重复计算更新的数据组织到一起，使得CPU在做计算时可能cache miss，如果游戏逻辑需要大量对象亏数需要更新数据，可能这部分消耗是非常大的。

同时MB不能很好的解决执行顺序问题，对于动态创建的GameObject，MB的更新顺序是不确定的，我们往往系统某些MB的Update和Destroy在某些MB之后，以保证相互的依赖关系，但Unity的MB设计上没有更好的解决这个问题，通过调整Script Execution Order既麻烦也没啥卵用（之前测试对于动态创建的MB毫无作用，只能用于场景中静态的MB）。

还有，如果游戏中存在大量的GameObject，上面绑定大量的Component，那么执行大量的Update是非常耗时的，而且这些Update只能运行在主线程，无法并行。

为此，Unity 2018.2 引入了全新的ECS系统，用于解决上面提到的问题。

全数据化驱动
ECS的核心设计目标就是去掉传统的MB，GameObject，Component对象结构，而改为全数据化驱动的代码组织方式，通过这样的改变，可以解决2个问题：

1）将数据更有效的组织，提高CPU cache利用率；

2）并行化。

先简单看一个例子，这个是ECS sample自带的例子：

这个例子可以看到，虽然画面里有超过1000个物体，但并没有对应1000个GameObject，当球体碰到方块的时候，会产生自转后衰减，同时可以保持在300-600的fps运行帧率。这在以前，我们要实现类似的效果需要创建1000个GameObject，然后有1000个MB负责更新GameObject的transform信息，我按照这样的方法来实现，那么这个demo大概只有1/3的fps。

注意到上图会创建更多的GameObject，fps大概100-200fps之间，当然这么实现并不是最优化的，我们还可以使用Instancing优化drawcall，为了对比我又实现了Instancing的版本，对比如下：

fps大概150-300fps，可绝此以看到instancing大概提高了1倍的fps，在1000 objs测试下，不同实现方法之间差别大概1-2倍，貌似差别不是很大，于是我又测试了更高obj数量的fps，在更高的objs测试下，得到如下图表：

可以看到在更高的obj数量下，ECS方法的优势就体现出来了，在10000 obj下，ECS任然可以做到350的高fps，而即便Instance优化，也只剩下4fps，差距几乎100倍。

现在我们回到开头，ECS解决了如下2个问题：

1）将数据更有效的组织，提高CPU cache利用率；

2）并行化。

但是如何解决的呢？

将数据更有效的组织，提高CPU cache利用率
传统的方法是将gameobject的数据放在Components上，比如可能是这样（参考1）：

using Unity.Mathematics;
class PlayerData// 48 bytes
{
public string public int[]
public quaternion
public float3
string name; // 8 bytes
someValues; // 8 bytes
}
PlayerData players[];
他的内存布局是这样：

而这样的设计对cpu cache是极度不友好的，当你试图批量更新float3数据时，cpu cache预测总是失败的，因为他们被分配到了内存中不连续的区域，cpu需要几次寻址跳转才能找到对应的数据并操作，如果我们能够将需要批量更新的数据连续的存放到一起，这将大大提高cpu cache的命中率，提升计算速度。

按ECS设计规范，就是将批量的更新的数据抽取出来，在内存中连续排列，从而在cache预读中能够将后续的数据一次性读取进来，提高cpu操作的效率，

在实际计算的时候，通过间接索引，来更新全部entity的各个类型的数据，而不是更新每个entity的全部数据，如图：

可以看到这里，最大的变化是：

在一个system（相当于以前的component）更新计算中，是将所有的entity的position放在一起批量更新的，因为这些position的float3数据在内中是连续的，cpu操作起来是最快的。

并行化
将数据单独提取出来后，接下来的任务就是将这些数据计算并行化，充分利用多核。在以前，几乎逻辑代码都是跑在主线程，当然也有项目组意识到了这个问题，会将一些和显示无关的逻辑放入多线程中并行，但都没有彻底的在数据上抽象形成一套完整的开发框架，而ECS解决了这个问题。

ECS开放了底层的job system系统，在上层提供了c# job system，它是一套多线程调度系统。如果不同的数据是无相互依赖的，仅需要将这些数据通过c# job system放入多个线程并行化计算就可以了，如：

public class RotationSpeedSystem : JobComponentSystem
{
struct RotationSpeedRotation : IJobProcessComponentData<Rotation, RotationSpeed>
{
public float dt;

public void Execute(ref Rotation rotation, [ReadOnly]ref RotationSpeed speed)
{
rotation.Value = math.mul(math.normalize(rotation.Value), quaternion.axisAngle(math.up(), speed.Value * dt));
}
}

protected override JobHandle OnUpdate(JobHandle inputDeps)
{
var job = new RotationSpeedRotation() { dt = Time.deltaTime };
return job.Schele(this, 64, inputDeps);
}
}
如果不同的数据有依赖，需要其他的数据计算完才能完整计算，则可以设置任务依赖，c# job system会自动完成这样任务的调用和依赖关系排序。

混合模式
目前已经存在大量的传统方式开发的代码，如果想享受到ECS带来的高效，势必要将现有代码大幅改造，有没有相对简单的方法既能保持现有代码没有太大变动，又可以提高效率呢，答案是ECS提供一种兼容的混合模式。

例如如下代码（参考2）：

using Unity.Entities;using UnityEngine;
class Rotator : MonoBehaviour{
// The data - editable in the inspector public float Speed;
}
class RotatorSystem : ComponentSystem{
struct Group
{
// Define what components are required for this // ComponentSystem to handle them. public Transform Transform;
public Rotator Rotator;
}

override protected void OnUpdate()
{
float deltaTime = Time.deltaTime;

// ComponentSystem.GetEntities<Group> // lets us efficiently iterate over all GameObjects // that have both a Transform & Rotator component // (as defined above in Group struct). foreach (var e in GetEntities<Group>())
{
e.Transform.rotation *= Quaternion.AngleAxis(e.Rotator.Speed * deltaTime, Vector3.up);
}
}
}
主要的修改是把MB的Update函数移到了ComponentSystem的OnUpdate函数中，同时增加了一个Group的struct，用于在MB和ComponentSystem之间交换数据，同时在原GameObject上添加一个GameObjectEntity组件，这个组件的用途是将GameObject其他全部的Component抽取出来并创建一个Entity，这样就可以通过GetEntities函数在ComponentSystem中遍历对应的GameObject了。

Unity会在启动的时候，把所有挂载了GameObjectEntity组件的GameObject，都创建对应ComponentSystem，这样你任然可是使用以前的GameObject.Instantiate方法来创建GameObject。只是原本MB的Update函数被替换到了ComponentSystem的OnUpdate函数中。

通过这样的修改，你可以混合ECS的部分能力又相对保持原本的代码结果，总结来说：

混合模式可以分离数据和行为，可以批量化更新对象的数据，避免每个对象的virtual方法调用（抽象到了一个函数中），任然可以继续使用inspector来观察GameObject的属性和数据。

但是这样修改并没有彻底改善什么，创建、加载的时间没有改善，数据的访问任然是cache不友好的，并没有把数据在内存中连续排布，也没有并行化。

只能说这样修改是为了进一步靠近纯ECS做的阶段性代码重构，最终还是要完全使用纯ECS才能获得最大的性能提升。

‘玖’ 阿里云ECS的CPU100%排查

一、背景和现象

初创公司，架构lanmp，web前端和后端分开服务器，业务驱动主要是nginx和apache，nginx主要是处理静态文件和反向代理，前后端、搜索引擎、缓存、队列等附加的服务都是用docker容器部署。因为比较初级，上传文件和采集文件都是直接写在硬盘上，涉及到的目录共享，就在其中一台服务器存储并且nfs共享。我们暂且分为ECS1（apache1）、ECS2（apache2）、ECS3（nginx）。某天网站业务中断，但是没有报错。一直在等待响应，默认响应超时是一分钟，所以很基础高可用没有起到作用。中断10分钟左右，重启服务，提示“open too many files”，但是lsof统计没几个。因为初级处理不了，所以直接重启服务器，一段时间后一切恢复正常，可是第二天又来一次这种情况。

二、第一次出现后的排查思路

本来第一次发现这种问题的时候就要追查原因了，看了一下zabbix监控图像其中断了十分钟，包括网络、内存、CPU、硬盘、IO等监控数据。首先想到的是网络问题，结论是zabbix-servert获取不到了zabbix-agent采集的数据，估计就是网络不通了。

但是，这个结论站不住脚，因为我本身通过ssh登录服务器，并且命令输入无卡顿，不至于头文件都传不过来。后来一看阿里云的云监控，上面有数据，似乎也可以佐证网络这个说法，因为云监控是阿里云内部的监控，可以内网获取到监控数据。直到看CPU的使用率这项，发现有一段时间的CPU使用率100%。并且我重启的时候CPU恢复正常，不能说网络一定没问题，但系统肯定有问题。也可以解释因为CPU使用已经是100%，zabbix-agent和根本不能正常运行，所以没有监控数据。因为这个公司全部都是云服务器，没有使用IDC所以我们也没有安装smokeping来监控，接着我们就不把重心在网络上了。

目前掌握的信息就是:在毫无征兆的情况下，CPU暴涨到100%，重启之前一直保留，重启之后恢复原样。匆忙之中又看了一下系统各日志，因为太匆忙，没有总结，没有找到什么有价值的东西。现在有下面几种猜想：第一，程序的bug或者部署不当，触发之后耗尽资源。第二、docker容器的bug。第三、网络攻击。第四、病毒入侵。第五、阿里云方系统不稳定。

小总结了一下，现在问题还没有找出来。下次还有这个问题的可能，所以先尽量防范，但是又不能重启一刀切。所以在zabbix上面设置了自动化，当检测到ECS1获取不到数据的时候马上操作ECS3标记后端为ECS1的apache为down。保留异常现场。（请求停止的时候，CPU100%还在）

三、现场排查

1、相应的排查计划（想到这些信息需要获取的，实际上没有严格按照这样的步骤）

1）用htop和top命令监控CPU、内存使用大的进程。先看看哪个进程消耗资源较多,用户态、内核态、内存、IO……同时sar -b查io的 历史 定时抽样。

2）统计tcp连接数，看看有没有DDOS攻击。netstat -anp |grep tcp |wc -l 。用iftop-i eth1看看通讯。同时用tail -n 1200 /var/log/messages查看内核日志。

3）用pstree查看打开进程，ps aux|wc-l看看有没有特别多的进程。虽然zabbix监控上说没有，但是我们要检查一下看看有没有异常的进程名字。

4）查看全部容器的资源使用docker stats $(docker ps -a -q)，看看能不能从容器上排查。

5）有了“too many open files”的启发，计算打开文件数目lsof|wc -l，根据进程看看ll /proc/PID/fd文件描述符有没有可疑的打开文件、文件描述符。

6）关于用lsof打开文件数找到的线索，排序打开文件找出进程号 lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more

7）关于用lsof打开文件数找到的线索，用lsof -p PID查看进程打开的句柄。直接查看打开的文件。

8）启动容器的时候又总是“open too many files"。那就是打开文件数的问题，因为CPU的使用率是CPU的使用时间和空闲时间比，有可能因为打开文件数阻塞而导致CPU都在等待。针对连接数的问题，大不了最后一步试试echo 6553500 > /proc/sys/fs/file-max 测试打开文件对CPU的影响。

9）玩意测出来了消耗CPU的进程，可以使用strace最终程序。用户态的函数调用跟踪用“ltrace”，所以这里我们应该用“strace”-p PID

10）从程序里面看到调用系统底层的函数可以跟踪。跟踪操作 strace -T -e * -p PID，主要看看代码调用的函数有没有问题。

2、现场排查

第二天同样时间，ECS果然暴涨了CPU。这是时候zabbix的工作如希望进行保留了一台故障的ECS1给我。

1）用htop看到资源使用最大是，搜索引擎下我写的一个判断脚本xunsearch.sh。脚本里面很简单，判断索引和搜索服务缺一个就全部重启。就当是我的容器有问题我直接关掉搜索引擎容器。httpd顶上，我又关掉apache容器。rabbitmq相关进程又顶上。这时候我没心情周旋了，肯定不也是这个原因。sar -b查看的 历史 io也没有异常。

2）统计tcp连接，几百。先不用着重考虑攻击了。用tail -n 1200 /var/log/messages查看内核日志，是TCP TIME WAIT的错误。可以理解为CPU使用100%，程序无响应外面的tcp请求超时。这是结果，还是没有找到根本原因。

接着往下看系统内核日志，发现了和“open too many files”呼应的错误，“file-max limit 65535 reached”意思是，已到达了文件限制瓶颈。这里保持怀疑，继续收集其他信息。

3）查看进程数量，数量几百。列出来也看到都是熟悉的进程，可以先排除异常进程。

4）监控容器的资源使用，里面很不稳定，首先是xunsearch容器使用80%的CPU，关掉xunsearch，又变成了其他容器使用CPU最高。很大程度上可以排查容器的问题和执行程序的问题。

5）查看了最大连接数cat /proc/sys/fs/file-max是65535但是用lsof查到的连接数是10000多，完全没有达到连接数。

6）各项参数都正常，现在聚焦在打开的文件数这个问题上面。也可以用另外同一种方式查看一下内核统计文件 /proc/sys/fs/file-nr，比较一下差异，看看能不能找出问题。cat了一下，打开文件数是66080，果然超了！内核日志就以这个为标准。

但是看lsof怎么统计不出来，ll /proc/PID/fd也没几个。这个问题放在后面，先按照步骤echo 6553500 > /proc/sys/fs/file-max给连接数提高到100倍，CPU果然降了下来。原因确认了，但是必须找到根源，为什么忽然有这么大的打开文件数。关掉全部docker容器和docker引擎，打开文件数是少了一点，但是仍然在65535差不多。我就先排除一下业务的影响，把ECS3的nginx直接指向视频ECS2的apache，就等同于在ECS2上实现了ECS1的场景。查看一下ECS2的句柄数，才4000多，排除了业务相关应用对服务器的影响。那就能下个小结论，ECS1被神秘程序打开了6万多句柄数，打开业务就多了2000多的句柄数，然后就崩溃了。不过这个现象有点奇怪，ECS2和ECS1在一样的机房一样的配置一样的网络环境，一样的操作系统，一样的服务，一样的容器，为什么一个有问题，一个没问题呢？不同的只是有一台是共享nfs。难道是静态文件共享了，其他人读了，也算是本服务器打开的？

7）现在程序找不到，没法继续lsof -p了。排查之前的猜想。带着排查得到对的结论往下想。

程序的bug和部署不当，那是不可能的，因为主要问题来自于打开句柄数，当部署到ECS2那里，一切正常。docker容器的bug，那也不可能的，每个都是我亲自写脚本，亲自编译，亲自构建的，关键是我关掉了docker容器和引擎都没有很大改善。网络攻击也排除，因为网络连接数没几个，流量也不变。那就只剩下病毒入侵也不是，没有异常进程。考虑到ECS的稳定性问题了。这方面就协助阿里云工程师去排查。

8）阿里云工程师用的排查手段和我差不多，最终也是没能看到什么。也只是给了我一些治标不治本的建议。后来上升到专家排查，专家直接在阿里云后端抓取了coremp文件分析打开的文件是图片，程序是nfsd。

好像印证了我刚才后面的猜想，应该就是ECS1使用了nfs共享其他服务器打开了然后算在ECS1头上。那问题又来了，我们的业务已经到达了可以影响服务器的程度吗？

9）既然问题解决到这一步，先不管程序有没有关闭打开的文件和nfs的配置。我们架构上面的图片应该是归nginx读取，难道是linux的内存机制让它缓存了。带着缓存的问题，首先去ECS3上释放内存echo 3 > /proc/sys/vm/drop_caches，释放之后，发现没什么改善，有点失落。总是觉得还有一台后端是PHP主导，但是逻辑上是写入，没有打开文件之说。后来从程序员中了解到，PHP也有打开图片。我猛然去ECS2释放一下内存，果然，句柄数降下来。（这里大家一定有个疑问，为什么我直接想到内存缓存而不是目前打开的文件呢。其一，这是生产环境，web前端只有一个，不能乱来停服务。其二，第一次遇到问题的时候，重启之后没有问题，过了一天之后积累到一定的程度才爆发，这里已经引导了我的思路是积累的问题，那就是缓存不断积累了）

10）因为ECS2的调用ECS1的nfs共享文件，所以lsof也有读不到那么多句柄数的理由。如果说是nfs的服务本身就有缓存，导致问题的话，我查看了配置文件，还是默认值允许缓存，30S过期，根本不会因为nfs的缓存造成打开文件过多。如果我们的后端程序打开之后没好好处理的话，那倒有可能。然后尝试排除：我改了ECS3的配置，使程序只读ECS1后端，从ECS1上面却看不到有什么异常表现，说明PHP程序已经好好处理了打开的文件。也不是docker挂载了nfs的共享的问题，因为nginx也有挂载。排查到这里也很大程度上解决问题，而且缓存了nfs的全部共享文件，句柄并没有增加，也算合理，所以就增加了打开文件数的限制。

11）现在排查的结果是跟后端和nfs共享有关。就是说，后端挂载了nfs的网络共享，被程序读取。而程序释放之后，在正常背景的硬盘文件是没有缓存的。但是在nfs挂载的环境下，缓存并没有得到释放。

12）总结：很多问题的排查和我们的猜想结果一样，但是有些例外的情况。比如这次我想到的原因都一一排除，但是问题也是在一步步排查中，逐步被发现的。