【真实案例】程序设计的陷阱-警惕大块数据

d_hero
发布于 2022-9-14 10:53
浏览
0收藏

无论是架构还是程序的设计,往大的方面说,逃不过分治、分类的范畴。微服务是一种分治的思想;service mesh是一种分治的思想;G1是一种分治的思想;大数据是一种分类的思想;领域划分是一种分类的思想……

数据大了会遇到问题,比如经典的redis的大key问题。遇到这类问题,主流解决方案是两个。

一个是限制,比如超过多大就不处理了,只提示错误。

【真实案例】程序设计的陷阱-警惕大块数据-鸿蒙开发者社区

另外一个是分治,将数据分片处理。

如果这两个都没做?

【真实案例】程序设计的陷阱-警惕大块数据-鸿蒙开发者社区

案例一:请求超时了

问题

首先回顾《近期做的稳定性建设总结》里的一个案例:收到一个可用内存不足10%的告警,经过了两个小时才自动恢复到87%,所在的机器出现一笔请求超时。

 

现象

1、对业务进行了解发现开始出现问题的时间点,有收到外部MQ发过来的大块数据。虽然大块数据做了分片,但是每个分片还是有几M大并且下发条数多,集中下发。

2、分别在问题机器和其他相同应用的不同机器上执行top命令,观察到问题机器和其他机器上jvm内存占用差不多并且稳定。

3、执行free -h命令观察到机器可用内存7.6G,cache/buffer下降到1G以下。

4、收到外部MQ发过来的大块数据时间段网卡占用情况从平时0.5M以下飙升到20M/S。

5、出现一笔请求超时正在下发大块数据的高峰期,请求方发请求到机器接收到请求时间间隔是几毫秒。收到请求后机器会将请求转发给MQ,用了3秒多。而请求方设置了5秒超时。

6、所有环节cpu使用率都很低。

7、20天前在另外一台机器上也发生了内存升高到90%以上的现象。

总结来说:MQ集中接收10M内的大块数据,JVM内存占用正常,操作系统内存占用升高,网卡流量20M/S。

 

分析

此问题的根本原因是外部短时间内下发大量大块数据(受节假日影响当天的大块数据略高于其他天),从根本上治理需要和外部(大佬级别,我们完全没有主动权)一起进行架构方面的调整,不现实也没有必要用此牛刀。

表现为虚机层面内存资源不足,影响了IO速率。因为高峰IO 20M/S,针对现在的千兆网卡、万兆网卡来说,并不大。问题并不在网络通道上,而在机器本身。

我写网络通信和linux操作系统系列也有一段时间了,大家可以用这个实际问题来小试牛刀。

在《深入浅出操作系统的零拷贝》中,我发起了一个投票:使用零拷贝最少要进行几次拷贝?

36%的人答对了,是2次。

零拷贝如果只是从磁盘发送到网络,最低可以只用2次DMA拷贝,也就是内核空间拷贝。但是实际情况是大多数场景,数据都需要回到用户空间进行数据处理,所以都需要3次以上。加上数据往往进来还要出去。所以10M的大块数据处理过程占用的内存是数倍于10M的。

所以最终我们提申请进行了纵向扩容。纵向扩容说白了就是增加物理内存。有人就要问了是不是扩机器数量也能解决问题。这种处理方式大概是能治病但是不一定对症。意思可以理解为吃广谱抗菌药来治疗感冒,有一定帮助但不是针对性的处理。因为扩机器是减少了请求数从而减少了内存占用量。但是万一有个大请求就是把内存飚高了呢?并且扩内存实施成本更低,不需要程序的发布。就是低峰期暂停程序,插个内存条。

经过半年多的验证,超时再没有发生过,说明我们的处理方式是对症的。

 

案例二:内存达到95%

问题

生产环境有个不太核心的服务,共三台机器,一台机器内存达到95%。这个服务分成定时任务和实时请求处理两部分,其实定时任务流量占比居多,实时请求很少。所以我们将这台机器隔离掉定时任务。也就是说定时任务只走另外两台。目前内存稳定在95%,但是内存达到这么高的原因需要找到。

服务的定时任务部分是调用RPC接口获取数据,之后RPC或者http请求发送到别处。每次处理的数据大小在几K。实时请求部分有个是处理文件上传的,文件的大小不固定,几M,几十M都是有可能的。这种请求一般情况下1天十笔,但是不固定。

 

现象

1、使用pmap -x java程序进程号 命令,发现大量anon块,举例如下:

b7f0a000 8 rwx-- 00000000b7f0a000 000:00000 [ anon ]
b7f20000 8 rwx-- 00000000b7f20000 000:00000 [ anon ]

2、这个服务除了内存使用达到95%的这台机器,另外一台达到了93%,还有一台89%。备用机房的机器(无定时任务,也不接受实时请求)内存占用基本都是86%。

 

分析

用pmap -x 查到的anon,中文叫匿名块。是通过malloc或mmap分配的“大”块。Java直接申请的堆内存之外的块就是堆外内存了。我查了代码,这个服务不涉及到数据库操作,没有使用guava等直接内存的。最有可能产生堆外内存的地方是nio(使用了netty、jetty)。

这个问题本来不是我在查,另外两个同事在做。但是一直没有结论,我就进行了介入。同事一直的思路是要找到内存泄露的地方。我分析可能不是内存泄露,因为最近几个月内存没有再增长。

我任务运行的这半年内,有段时间可能有人批量上传大文件。文件上传到哪台服务器是随机的,占用内存高的机器很有可能是当时处理的文件大或者多。因为过去了快半年了,日志都清理了,我没有办法找到直接的证据。

同事还是想排查内存泄露问题。给出两个理由:第一,把定时任务停掉的机器最近内存稳定不再增长了。第二,他查了最近的日志,文件大小都在几M,而内存高的机器要内存使用高出了几百M。

我的答复:内存不再增长与定时任务停掉未必是因果。也可能是最近再也没有如此大块或大量的文件上传。另外,程序没有做限制,最近只有几M未必几个月前没有更的文件上传。另外,案例一里也说了,如果文件大于十几兆,其使用的内存要多出好几倍。

同事觉得有道理,决定下周进行测试环境模拟验证,结果究竟如何呢?咱们来猜一猜。

 

总结

如果你的服务要处理大数据,但是又不想使用分治引入程序的复杂性,那么在申请机器的时候,要增加足够的内存冗余!

有的朋友会觉得这个处理方式并不高大上。牛逼的处理方式是排查到内核层,调整个linux参数啥的。不推荐!原因如下:

现在也算比较流行的一个词叫做:不可变服务器。“传统”的部署方式中,对系统的改动都会呈现在服务器上,从而增加了风险。采用不可变部署方式,服务器都是公司统一标准化的,那么变更只要考虑应用程序的发布,而应用程序一旦发布也不允许改变,就成了不可变服务。不可变性可以增加系统的稳定性。在一个规模比较大的公司,就算可以通过技术解决资源的问题,从整体角度,还是通用方案更加可取。

另外补充一个小知识:

使用pmap -x 命令查看内存地址的时候要注意起始地址:

64位的linux系统,对于虚拟地址空间的划分,将0x0000,0000,0000,0000 – 0x0000,7fff,ffff,f000这128T地址用于用户空间;而0xffff,8000,0000,0000以上的128T为系统空间地址。

 

 

 

文章转载自公众号:编程一生

分类
标签
已于2022-9-14 11:00:09修改
收藏
回复
举报
回复
    相关推荐