gpu 内存泄漏测试方法

#############################################################################
内存泄漏解释
#############################################################################
1、内存leak解释
    1、 一个程序处理过程需要达到平衡状态，申请资源->使用->释放，一轮过程中资源的申请和释放需要达到平衡，申请后用完要释放；
        如果只申请不释放，占用内存越来越多，就会产生leak，申请比释放多就会产生leak；
    2、举例：
        推理、视频监控类任务的处理流程：
            拿到数据，申请资源进行处理，使用结束后要释放；
            一轮过程中资源的申请和释放需要平衡；
            从开始到结束需要有始有终，不然就会出现爆发性增长；
        训练的情况会复杂些，处理的事情比较多，但是长时间看一个任务处理完后仍然需要释放
2、内存类型
    系统内存
    设备内存
    
3、重点观察的指标
    vram_used: 
            - 反映的是device hbm的负载情况
            - 如果稳定，则表明hbm没有异常增长，如果有问题是设备device内存泄漏
            - device/hbm的负载情况看vram_used指标，如调用api申请device内存，申请但不释放引起
    xtt_used:  
            - 反映的是gpu向系统申请的DDR内存情况
    VmRSS：
            - 反映的是特定进程申请的系统内存
            - 如果进程一直在申请内存，没有释放会导致vmRss泄漏
            - 比如客户程序、driver用到的程序、pde申请的内存等没有释放，可能会引起vmrss的异常增长
          
4、内存泄漏的类型
    1、hbm 泄漏---》看vram_used
    2、gpu申请的系统内存---》看xtt_used
    3、系统内存泄漏：
            - 用户程序的泄漏---》看vmrss指标
            - kmd泄漏---》也属于系统内存泄漏，看kmd指标

#############################################################################
某客户程序内存leak测试实例
#############################################################################
一、测试背景
    1、问题：客户poc出现了内存泄漏的问题，主要泄漏的是jpeg编码和onnxruntime
    2、目的：规避内存泄漏的问题，确保有测试覆盖到
    3、测试程序要求：
        1、保证运行过程是稳定的，内存大小不应该变化太大
        2、从上层测试的话，不容易构造一直特别稳定的数据来确保占用是稳定的，因此从更底层来进行测试，由开发提供脚本
        3、监控内存变化情况，需保持稳定

二、测试方法
    - 测试程序
            -方式1：使用开发自研的推理、视频工具，长时间执行
                1、ai推理工具：执行某个模型推理，循环长时间执行
                    1、执行./mc_dla_memory_leak_test --gtest_filter=MxDlaTestMemoryLeak.testCaseMemoryLeakAsync --network_path=resnet50_int8_224x224 --network_num=8 --stream_num=8 --batch_size=8
                    
            - 方式2：使用客户的测试程序，即同时处理30路视频，并提前将视频处理为长时间，确保长时间运行时以及功能是否一直正常
                    1、执行./start.sh

            - 【风险不高，应该没有什么问题】方式3：频繁的启动程序、结束程序，查看内存是否能够正常释放
    - 监控程序
        1、执行方式./monitor_mem.sh smengine_demo  #smengine_demo为监控的进程名

三、监控的指标    
    1、hbm vram内存：反映hbm的负载情况，如果稳定，则表明没有异常增长，如果有问题是设备device内存泄漏
        查询方式：xx_smi --show-memory
        指标：vram_used、vram_usage
    2、xtt vram：反映gpu向系统申请的DDR内存
        查询方式：xx_smi --show-memory
        指标：xtt_used、xtt_usage        
        
    3、系统内存-虚拟内存： 根据进程来看的，反映某个进程申请的统内存   
        查询方式： cat /proc/$pid/status
        VmRSS(KB)： 虚拟内存驻留集合大小。这是驻留在物理内存的一部分。它没有交换到硬盘。它包括代码，数据和栈。
        VmSize(KB) ： 虚拟内存大小。整个进程使用虚拟内存大小，是VmLib, VmExe, VmData, 和 VmStk的总和。
                VmLib(KB) ：被映像到任务的虚拟内存空间的库的大小    
                VmExe(KB)： 程序所拥有的可执行虚拟内存的大小，代码段，不包括任务使用的库        
                VmData(KB)：  程序数据段的大小（所占虚拟内存的大小）， 堆使用的虚拟内存。
                VmStk(KB)：  任务在用户态的栈的大小， 栈使用的虚拟内存   
    3、kmd内存           
        查询方式；通过/proc/meminfo查看
        指标：MemTotal,MemFree,MemAvailable,Buffers,Cached,KReclaimable,Slab,SReclaimable,SUnreclaim,KernelStack,PageTables
       【弃用】注意事项：每次查询之前，需要手动释放linux缓存 echo 1 > /proc/sys/vm/drop_caches----》后来开发说不需要了，会自动释放
       
    【关注较少】5、系统内存-物理内存
        查询方式：top命令中查询到的进程的res、mem
        指标：
            1、RES     
                1、进程使用的、未被换出的物理内存大小，单位kb。
                2、表示进程的常驻内存大小，准确表示当前有多少物理内存被这个进程消费，这个和MEM是对应的.
                3、RES=CODE+DATA    
                    CODE  可执行代码占用的物理内存大小，单位kb
                    DATA  可执行代码以外的部分(数据段+栈)占用的物理内存大小，单位kb
            2、MEM  进程使用的物理内存百分比
        
    

四、监控指标数据结果分析
    1、执行过程中：
            一个程序处理过程需要达到平衡状态，申请资源->使用->释放，一轮过程中资源的申请和释放需要达到平衡，申请后用完要释放；
            当进程稳定运行后，各指标的数据应保持稳定，如果数据的曲线出现了数据增长、缓慢增长、跳涨、波动、抖动等不稳定情况，可能存在内存泄漏的问题             
    2、异常处理：
            如果某个指标利用率打满的话，应有错误处理机制，不应出现core dump退出的情况
    3、执行完成后：
            资源应正常释放