阿里云日常运维的坑

Posted 2022-11-28 XiaoYNil

呵呵，运维谈不上专业，只是日常需要，记录一些问题。因为是个人玩家，所以使用的实例配置也比较低，更容易因为某项资源不足而触发瓶颈，最终短板给整个系统带来故障，甚至是灾难。

1、HTTP/S请求频繁超时？

2018~2019（今年）都碰到了这个坑，先说下现象和配置，

实例规格是ecs.n4.small  ，即单核、2GB内存，带宽1M。ECS里主要运行了五个应用ABCDE、E开了以后，HTTP/S请求频繁超时，导致前面4个应用也出现类似问题。

查看了下系统监控数据，CPU60上下，内存100，带宽100，可见是带宽触发了上限，并且经过实验（只跑E）发现降低E的线程数并提高sleep时间可以降内存和带宽（这不是废话么）。

于是先尝试升级带宽（因为应用必须保证线程数和sleep啊，不然线程数为1，sleep(Inf)多好）。

问题改善了，于是尝试跑E的升级版（应用需要，规模大概是线程数X2，sleep保持不变）。这个时候CPU不干了，100！！！内存在60上下，且呈锯齿状，看来GC有在起作用，磁盘未见异样，出口带宽也够用，TCP链接异常ESTABLISHED/NON_ESTABLISHED=230/3400，non里面几乎都是TIME_WAIT。。。说明产生了大量的主动关闭连接。

当只运行升级版E时，仍会出现频繁超时的问题。

这里就不追究具体的原因了，因为有更加经济的解决方案。

主要总结一下频繁超时的一般可以采取的一些措施：

1、升级实例带宽，这是最直接的，一般也有效；

2、程序优化，比如使用长连接，即keeplive，大量HTTP/S请求时，当对于同一网络资源，可以避免频繁建立连接；

3、应用隔离，人家阿里云用容器给你划了边界，就要好好利用起来；虽然为了整合，将带宽都并到一起了，但有时合并CPU/内存资源却给管理带来了更多不确定性，一个应用导致其他应用都宕机，产生的维护成本、时间成本可能远比多一份CPU/内存的RMB消耗还大。比如因为E的问题，导致了ABCD几天的运行数据都无效。

去年出现超时问题时，主要采用了带宽升级和长连接进行了优化。而今天这个问题打算采取应用隔离。

2、时钟同步问题

windows系统下，阿里云ECS的时间会比实际时间跑快，大概是10分钟快6秒；

该问题经与客服沟通，换了硬件底层也无解，只能windows time服务随机启动，而且同步间隔要根据实际精度要求设置。比如要控制时间精度在1s内，就需要设置同步间隔为100s以内。但是使用windows time服务注意有时需要延迟启动，否则服务可能自动启动失败，故时间敏感的应用最好也delay run吧。

同时需要注意的是，阿里云官方提供的所谓高精度校时服务器：ntp.cloud.aliyuncs.com，其实未必准，尤其是海外的服务器（大陆的服务器还没试过），统计了下日志数据，有一天居然有至少21%时间的时间差是超过5秒的，而ECS本身造成的误差基本不会达到5秒（设置的5分钟为同步周期，故误差最多3秒）。校时请求失败已经算小事，校时后居然还能有明显的时间差。所以海外的ECS建议用windows等OS系统官方的NTP服务器比较好。