Linux内存使用调整

不念不忘少年蓝@ 2022-03-27 04:38 223阅读 0赞

前段时间在做播放器的时候，遇到个问题，花了很长时间，做个记录，希望对有需要的人有所帮助：

播放器的播视频的时候，无论是手动切换视频还是到视频播放完成，自动切换视频，一定次数后均出现黑屏现象，偶尔有声音，问题出现后，不可恢复，Kernel输出如下Log：

DMA free:71672kB min:616kB low:768kB high:924kB active\_anon:0kB inactive\_anon:0kB active\_file:0kB inactive\_file:0kB unevictable:0kB isolateds

lowmem\_reserve\[\]: 0 1244 1593 1593

Normal free:1249804kB min:4212kB low:5264kB high:6316kB active\_anon:0kB inactive\_anon:0kB active\_file:0kB inactive\_file:0kB unevictable:0kB o

lowmem\_reserve\[\]: 0 0 2794 2794

HighMem free:223000kB min:348kB low:640kB high:936kB active\_anon:39248kB inactive\_anon:140kB active\_file:61020kB inactive\_file:34108kB unevio

lowmem\_reserve\[\]: 0 0 0 0

DMA: 22\*4kB 90\*8kB 21\*16kB 82\*32kB 7\*64kB 137\*128kB 69\*256kB 3\*512kB 8\*1024kB 5\*2048kB 3\*4096kB 0\*8192kB 0\*16384kB 0\*32768kB = 71672kB

Normal: 1\*4kB 53\*8kB 16\*16kB 6\*32kB 6\*64kB 4\*128kB 1\*256kB 1\*512kB 2\*1024kB 2\*2048kB 3\*4096kB 2\*8192kB 4\*16384kB 35\*32768kB = 1249772kB

HighMem: 14\*4kB 10\*8kB 437\*16kB 386\*32kB 374\*64kB 27\*128kB 10\*256kB 7\*512kB 8\*1024kB 7\*2048kB 4\*4096kB 2\*8192kB 1\*16384kB 3\*32768kB = 223000B

23829 total pagecache pages

0 pages in swap cache

Swap cache stats: add 0, delete 0, find 0/0

Free swap = 0kB

Total swap = 0kB

524288 pages of RAM

387015 free pages

73287 reserved pages

1169 slab pages

8545 pages shared

0 pages swap cached

Physical memory allocation error!

通过Log，定位到输出的位置是解码驱动中，驱动在DMA请求失败后，输出以上信息。针对这个现象，按以下几个思路进行的调查：

1. 内存泄露

在驱动中增加了一些Log，随着视频切换，分配的地址会一定程度的变大，直到最后分配失败。但仔细研究发现分配与释放是配对的，驱动中记录的内存使用信息完全正确，没有任何迹象表明有内存泄露发生。

2. 内存碎片

官论上有同样的问题登录，但无明确结论，官方应该是没重现。民间有人指出问题在于驱动请求的连续内存块比较大，但系统已无相应的内存可供分配，即内存碎片了。同时有人给出俩个方案：缓存每次的请求的内存，分配后，不再返还给系统，这个方案我测试后，发现会导致其它视频驱动出现同样问题，不可用；另一个方案是认为导致内存碎片的原因在于，文件系统的Cache机制，要解决这个问题，需要清除被Cache占用的内存，方法如下：

echo 3 > /proc/sys/vm/drop\_caches

试验之后，果然有效，测试了手中的测试用例几千次后，发了测试软件，结果悲剧，开发部的测试用例几次就测出同样的问题，该方案水土不服。

3. 调查Linux内存使用

从内存碎片这个思路出发，分析什么导致了驱动的DMA空间碎片化。查了一些资料发现，Linux的内存划分分成3块：DMA，Low Memory和High Memory。一般32位PC的配置是DMA Zone位于0x00010000-0x00ffffff，大约16MB，Low Memory是0x01000000-0x37bfdfff，约800多MB，再往上的空间给High Memory，这部分的访问要通过跳转，性能不如DMA Zone和Low Memory Zone快。而内存分配的策略是从上往下分配，一旦高位的内存空间不足，则向低地址的空间请求内存。在我们的产品上，总的内存大小是512MB，某些驱动预留128MB，DMA Zone的配置是184MB，那么实际剩下的Low Memory Zone只有200MB，而这200MB要运行UI，媒体管理，互联等等一系列进程。一旦Low Memory Zone的内存不够用，系统会向DMA Zone请求内存，从而导致的DMA空间的内存碎片化！而这时，通过free命令是看不到正确的内存信息的，因为看到的空间还有，但一是被Cache占用，二是计算的是总数，而不是真正的连续内存，这时查看内存应该使用系统提供的Buddy Info来看真正剩余的内存块：

$cat /proc/buddyinfo

Node 0, zone DMA 3 1 3 4 1 2 2 0 1 2 0 3 2 2

Node 0, zone Normal 74 36 29 8 6 4 3 2 1 2 3 2 0 2

输出的数据从左侧开始是4K内存块的个数，依次乘2到最右侧的32M；在出问题时，系统基本上只有小块的内存，而问题的原因就是一些文件访问的操作导致DMA Zone的空间被Cache使用了。

4. 控制内存分配算法

找到问题的原因后，调查如何能禁止系统从DMA Zone分配内存。查找到可以设置lowmem\_reserve\_ratio，来告诉系统，DMA Zone的预留空间。其参数有3个（系统默认：256,32,32），与DMA Zone有关的是第一个，其值是除数，用DMA Zone的大小除以256，得到的基本就是预留的大小了。做了几个测试后，发现只有设置为1才能有效保护DMA Zone不被占用，:(!设置为1后，视频不再出现黑屏，但其他问题很快出现，因为系统可用的内存减少，内存的回收算法被频繁执行，性能急剧下降。

5. 最终方案

由于产品的总内存太小，而预留的DMA Zone太大，所以需要调整DMA Zone预留的空间，但lowmem\_reserve\_ratio已无调整空间，所以考虑从调整Kernel上下手。最后，将Kernel中的DMA Zone总大小由184MB调整为原来的3/4，即138MB，得到一个近似合理的配置，保证的DMA和Low Memory都可以申请到足够的空间，长时间测试后，未再现相关问题。