CN112631941B - 定位linux内核slub内存泄漏的方法和系统 - Google Patents

定位linux内核slub内存泄漏的方法和系统 Download PDF

Info

Publication number
CN112631941B
CN112631941B CN202011637900.9A CN202011637900A CN112631941B CN 112631941 B CN112631941 B CN 112631941B CN 202011637900 A CN202011637900 A CN 202011637900A CN 112631941 B CN112631941 B CN 112631941B
Authority
CN
China
Prior art keywords
memory
record
leakage
determining
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202011637900.9A
Other languages
English (en)
Other versions
CN112631941A (zh
Inventor
麻长葆
赵伟
陈小军
黄章良
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangzhou Lubangtong IoT Co Ltd
Original Assignee
Guangzhou Lubangtong IoT Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guangzhou Lubangtong IoT Co Ltd filed Critical Guangzhou Lubangtong IoT Co Ltd
Priority to CN202011637900.9A priority Critical patent/CN112631941B/zh
Publication of CN112631941A publication Critical patent/CN112631941A/zh
Application granted granted Critical
Publication of CN112631941B publication Critical patent/CN112631941B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/362—Debugging of software
    • G06F11/366—Debugging of software using diagnostics
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3452—Performance evaluation by statistical analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5022—Mechanisms to release resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Probability & Statistics with Applications (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明公开了一种定位linux内核slub内存泄漏的方法和系统，涉及软件开发技术，包括以下步骤：按照第一设定的时间间隔依次获取第一内存统计信息和第二内存统计信息；根据第一内存统计信息和第二内存统计信息确定内存泄漏情况是否属于slub内存泄漏；当内存泄漏情况属于slub内存泄漏时，按照第二设定时间间隔依次通过slabtop指令获取第一slabtop信息和第二slabtop信息；进而确定内存消耗增量满足第一预设条件的目标分配接口；获取所述目标分配接口的内存操作记录，所述内存操作记录包括内存分配记录和内存释放记录；根据内存操作记录，确定内存泄漏源。本发明可以准确定位内核slub内存泄漏的位置。

Description

定位linux内核slub内存泄漏的方法和系统
技术领域
本发明涉及软件开发技术，特别是一种定位linux内核slub内存泄漏的方法和系统。
背景技术
内存管理子系统可能是linux内核中最为复杂的一个子系统，其核心工作就是内存的分配回收管理，即内存分配和内存释放。一般来说已分配的内存都需要在未来某个时间点进行释放，如果只分配内存而不作释放(通常由内核的SUbsystem和driver缺陷bug引起)，势必会造成内存泄漏。当内存泄漏是量足够大时就会引起linux系统发生内存耗尽(内核OOM)而宕机。Linux内核自2.6.22之后内存分配器就已经从Slab改进为Slub了。
现有的Slub内存泄漏监测的方法是Linux内核自带的kmemleak方法，通过开启内核的CONFIG_DEBUG_KMEMLEAK选项，可以报告kmalloc、vmalloc、kmem_cache_alloc等无法被引用的内存块对象。kmemleak有显著的优点，可以在内核全局的一次性检测所有的内存泄漏可疑点，但同时也存在明显的缺点：
可疑点量多，分析工作量大。Kmemleak监测是全局的，作用范围是整个内核子系统和设备驱动，不利于精准定位分析。
误报数量多，为了简化算法，kmemleak扫描指向块地址范围内任何地址的值。这可能导致误报(false negatives)的数量增加。尽管真正的内存泄漏很可能最终会变得可见。另一个误报的来源是存储在非指针值中的数据。进一步增加了分析难度。
发明内容
有鉴于此，本发明的目的在于：提供一种定位linux内核slub内存泄漏的方法和系统，以实现准确定位泄漏位置。
第一方面，本发明实施例提供了：
一种定位linux内核slub内存泄漏的方法，包括以下步骤：
按照第一设定的时间间隔依次获取第一内存统计信息和第二内存统计信息；
根据第一内存统计信息和第二内存统计信息确定内存泄漏情况是否属于slub内存泄漏；
当内存泄漏情况属于slub内存泄漏时，按照第二设定时间间隔依次通过slabtop指令获取第一slabtop信息和第二slabtop信息；
根据第一slabtop信息和第二slabtop信息确定内存消耗增量满足第一预设条件的目标分配接口；
获取所述目标分配接口的内存操作记录，所述内存操作记录包括内存分配记录和内存释放记录；
根据内存操作记录，确定内存泄漏源。
在一些实施例中，在获取所述第一内存统计信息和获取所述第二内存统计信息之前，均执行以下步骤：
执行SReclaimable内存的回收。
在一些实施例中，根据第一内存统计信息和第二内存统计信息确定内存泄漏情况是否属于slub内存泄漏，包括：
根据第一内存统计信息中的可用内存信息和所述第二内存统计信息中的可用内存之差，确定可用内存差值；
根据第一内存统计信息中的SUnreclaim数值和所述第二内存统计信息中的SUnreclaim数值之差，确定SUnreclaim的内存新增值；
当所述SUnreclaim的内存新增值和所述可用内存差值之差满足第二预设条件，则判定内存泄漏情况属于slub内存泄漏。
在一些实施例中，所述根据第一slabtop信息和第二slabtop信息确定内存消耗增量满足第一预设条件的目标分配接口，包括：
根据每个接口在所述第二slabtop信息中SLAB_CACHE_SIZE值和所述第一slabtop信息中SLAB_CACHE_SIZE值之差，确定每个接口的内存消耗增量；
将所述内存消耗增量大于第一阈值的接口确定为目标分配接口。
在一些实施例中，所述内存分配记录包括alloc操作记录和alloc操作对应的调用堆栈记录；所述内存释放记录包括free操作和free操作对应的调用堆栈记录。
在一些实施例中，所述根据内存操作记录，确定内存泄漏源，包括：
通过对比内存分配记录和内存释放记录，确定没有对应的内存释放记录的目标内存分配记录；
根据所述目标内存分配记录中堆栈记录所采用的堆栈，对多个所述目标内存分配记录进行分类统计；
将统计量最大的分类所对应的堆栈确定内存泄漏源。
在一些实施例中，所述通过对比内存分配记录和内存释放记录，确定没有对应的内存释放记录的目标内存分配记录，包括：
遍历所有所述内存释放记录，删除第一个所述内存分配记录中与所述内存释放记录地址一致的内存分配记录；
将剩余的所述内存分配记录作为目标内存分配记录。
在一些实施例中，所述方法通过脚本执行。
第二方面，本发明实施例提供了：
一种定位linux内核slub内存泄漏的系统，包括：
第一获取模块，用于按照第一设定的时间间隔依次获取第一内存统计信息和第二内存统计信息；
判断模块，用于根据第一内存统计信息和第二内存统计信息确定内存泄漏情况是否属于slub内存泄漏；
第二获取模块，用于当内存泄漏情况属于slub内存泄漏时，按照第二设定时间间隔依次通过slabtop指令获取第一slabtop信息和第二slabtop信息；
目标分配接口确定模块，用于根据第一slabtop信息和第二slabtop信息确定内存消耗增量满足第一预设条件的目标分配接口；
第三获取单元，用于获取所述目标分配接口的内存操作记录，所述内存操作记录包括内存分配记录和内存释放记录；
泄漏源确定单元，用于根据内存操作记录，确定内存泄漏源。
第三方面，本发明实施例提供了：
一种定位linux内核slub内存泄漏的系统，包括：
存储器，用于存储程序；
处理器，用于加载所述程序以执行所述的定位linux内核slub内存泄漏的方法。
本发明实施例通过内存统计信息确定内容泄漏的情况是否属于slub内存泄漏，然后根据slabtop指令获取slabtop信息来确定目标分配接口，接着根据目标分配接口的内存操作记录来确定泄漏源，可以准确地实现linux内核slub内存泄漏的定位。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图做一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是根据本发明实施例提供的一种定位linux内核slub内存泄漏的方法流程图；
图2是根据本发明实施例提供的meminfo信息的查询结果示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，以下将参照本发明实施例中的附图，通过实施方式清楚、完整地描述本发明的技术方案，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
名词解释：
slub：是Linux内核2.6.22版本中引入的一种新型分配器，它具有设计简单、代码精简、额外内存占用率小、扩展性高，性能优秀、方便调试等特点。
slabtop指令：用于实时显示内核slab缓冲区信息。
SReclaimable表示可收回slab的大小。
SUnreclaim表示的是对象在活跃,不能被回收的slab的容量。
SLAB_CACHE_SIZE，是slabtop指令的返回的参数，表示接口(函数)的slab缓存大小。
alloc/free内存操作，分别指内存分配操作和内存释放操作。
参照图1，本实施例公开了一种定位linux内核slub内存泄漏的方法，包括以下步骤：
步骤110、按照第一设定的时间间隔依次获取第一内存统计信息和第二内存统计信息。
步骤120、根据第一内存统计信息和第二内存统计信息确定内存泄漏情况是否属于slub内存泄漏。
在上述两个步骤中，可以通过命令cat/proc/meminfo获取内存统计信息，过一段时间后的再次获取内存统计信息。查看两次meminfo(内存信息)统计信息。两次获取内存统计前先运行命令echo2>/proc/sys/vm/drop_caches触发Sreclaimable内存的回收，以避免无用数据的干扰，使得查询的结果更加准确。如果Sunreclaim的数值有较大的增加，且与free数值(表示系统的可用内存)的内存泄漏大小相当，就可以确认是Sunreclaim造成的泄漏。符合这种情况就可以使用本专利方法来精确和快速地定位泄露点。
从图2中可以看出，使用该方法分析实际项目内存泄漏问题时获取的free/meminfo信息。图2的左边是5月13日18时12分获取的信息，图2右边是运行到5月14日14时49分(18.5小时后)抓取的信息。对比发现：
free项(系统剩余内存):由12.34MB变为7.64MB，降低了4.7MB。
SUnreclaim项(SLUB内存占用情况)：由6.2MB变为了9.8MB,升高了3.6MB。
由此，可以可见系统的内存消耗(泄漏嫌疑)主要来源于slub内存占用(SUnreclaim项)。
至于两次获取内存统计信息的时间间隔，主要取决于内存的泄漏的快慢而确定。泄漏快，间隔可以短一些。在该例子中，内存泄漏18.5小时才泄漏了不到3.6MB。也不宜时间间隔太长，时间长记录的文件就大，分析就更耗时。
步骤130、当内存泄漏情况属于slub内存泄漏时，按照第二设定时间间隔依次通过slabtop指令获取第一slabtop信息和第二slabtop信息。
步骤140、根据第一slabtop信息和第二slabtop信息确定内存消耗增量满足第一预设条件的目标分配接口。
使用slabtop命令锁定内存消耗增加主要来自哪个分配接口(函数)。通过两次记录的slabtop信息，找出SLAB_CACHE_SIZE增加明显的内存分配接口名称“某某接口”(如kmalloc-256)，并留意增加的快慢。但绝大部分情况下直接或间接使用“某某接口”来申请内存的内核子系统和驱动程序有很多地方。
下面是使用slabtop命令查询到的slabtop信息；
摘取kmalloc-256项为例
8550，8537，99％，0.22K，475，18，1900K，kmalloc-256；
在半个小时候后为：
8550，8537，99％，0.22K，475，18，2900K，kmalloc-256；
那么就说kmalloc-256在这半小时就增加了1MB内存，内存占用增量最大的就是泄漏嫌疑最大的。
步骤150、获取所述目标分配接口的内存操作记录，所述内存操作记录包括内存分配记录和内存释放记录；
具体地，先抓取“某某接口”分配接口的所有alloc/free内存操作(含调用栈)记录，再进行自动化的分析即可得到精准泄漏源。
在抓取xxx分配接口(函数)的所有alloc/free内存操作记录前，需调整dump_trace及其相关实现函数的信息输出打印等级。将static void trace(struct kmem_cache*s,struct page*page,void*object,int alloc)里的打印等级pr_info改为pr_emerg；将dump_stack相关的void dump_stack_print_info(const char*log_lvl)里的“printk(”改为“printk(KERN_EMERG”；将void dump_backtrace_entry(unsigned longwhere,unsigned long from,unsigned long frame)里的“printk(”改为“printk(KERN_EMERG”；同时还需要调整控制台输出的打印等级，命令echo 1>/proc/sys/kernel/printk，以便于将只将上面的dump_trace的KERN_EMERG输出信息过滤出来。上述操作为了提高打印等级，从而获取更多的有用信息。
接下来就通过slub的诊断接口记录“某某接口”的所有申请和释放操作。通过指令echo1>/sys/kernel/slab/<xxx>/trace获取所有的leaking_mem_alloc_name类型内存的alloc和free的所有alloc/free操作及其调用堆栈，记录为xxx-all.log。需要记录的时间长短取决于步骤140中分析的“某某接口”的SLABS OBJ/SLAB数量增长的快慢。
步骤160、根据内存操作记录，确定内存泄漏源。
具体地，确定过程包括：
alloc/free内存操作分离工作：
通过xxx-all.log的记录项根据格式“TRACE xxx alloc”或者“TRACE xxx free”分类为两部分xxx-alloc.log和xxx-free.log，其中xxx-alloc.log仅包含所有的alloc操作及其调用堆栈，xxx-free.log仅包含所有的free操作及其调用堆栈。其中“xxx”表示“某某接口”。
未释放(free)内存过滤：
遍历xxx-free.log的每条free记录，将xxx-alloc.log里存在与该free条记录地址一致的第一条alloc记录(含调用栈)删除。最后xxx-alloc.log里剩余的为没找到匹配free的alloc记录。
未释放(free)内存归类统计：
根据调用堆栈的不同，将xxx-alloc.log里剩余记录分类并做计数统计。
最后根据计数统计结果，数量最多的项即为存在内存泄漏的alloc项。再结合该项的函数调用堆栈既可以找出slub在内核精确测内存泄漏源。
在一些实施例中，在获取所述第一内存统计信息和获取所述第二内存统计信息之前，均执行以下步骤：
执行SReclaimable内存的回收。可以理解的是，通过执行SReclaimable内存的回收，可以使得内容统计信息的干扰更少，使得辨别是否slub内存泄漏的结果更加准确。
在一些实施例中，根据第一内存统计信息和第二内存统计信息确定内存泄漏情况是否属于slub内存泄漏，包括：
根据第一内存统计信息中的可用内存信息和所述第二内存统计信息中的可用内存之差，确定可用内存差值；
根据第一内存统计信息中的SUnreclaim数值和所述第二内存统计信息中的SUnreclaim数值之差，确定SUnreclaim的内存新增值；
当所述SUnreclaim的内存新增值和所述可用内存差值之差满足第二预设条件，则判定内存泄漏情况属于slub内存泄漏。
在一些实施例中，所述根据第一slabtop信息和第二slabtop信息确定内存消耗增量满足第一预设条件的目标分配接口，包括：
根据每个接口在所述第二slabtop信息中SLAB_CACHE_SIZE值和所述第一slabtop信息中SLAB_CACHE_SIZE值之差，确定每个接口的内存消耗增量；
将所述内存消耗增量大于第一阈值的接口确定为目标分配接口。
从图2中的例子可以看出，通过统计两次内存统计信息中，系统的可用内存之差，以及SUnreclaim的内存新增值，可以大致判断，主要泄漏来源是否SUnreclaim。其中，在本实施例中，可以通过slabtop信息中SLAB_CACHE_SIZE值前后的变化来确定出目标分配接口。
在一些实施例中，所述内存分配记录包括alloc操作记录和alloc操作对应的调用堆栈记录；所述内存释放记录包括free操作和free操作对应的调用堆栈记录。
在一些实施例中，所述根据内存操作记录，确定内存泄漏源，包括：
通过对比内存分配记录和内存释放记录，确定没有对应的内存释放记录的目标内存分配记录；
根据所述目标内存分配记录中堆栈记录所采用的堆栈，对多个所述目标内存分配记录进行分类统计；
将统计量最大的分类所对应的堆栈确定内存泄漏源。
其中，根据调用的堆栈的不同，可以对目标内存分配记录进行分类，然后在基于堆栈确定内存泄漏的位置，本方案可靠且简单，可以通过脚本实现。
在一些实施例中，所述通过对比内存分配记录和内存释放记录，确定没有对应的内存释放记录的目标内存分配记录，包括：
遍历所有所述内存释放记录，删除第一个所述内存分配记录中与所述内存释放记录地址一致的内存分配记录；
将剩余的所述内存分配记录作为目标内存分配记录。
需要理解的是，内存分配记录和内存释放记录均有内存地址，通过匹配内存地址可以确定分配的内存的位置，这样就可以将内存分配记录和内存释放记录关联在一起，从而筛选出未被释放的内存。
在一些实施例中，所述方法通过脚本执行。通过脚本实施这些方案，可以适用于大多数基于linux的系统，而且开发难度比较低。
本实施例公开了一种定位linux内核slub内存泄漏的系统，包括：
第一获取模块，用于按照第一设定的时间间隔依次获取第一内存统计信息和第二内存统计信息；
判断模块，用于根据第一内存统计信息和第二内存统计信息确定内存泄漏情况是否属于slub内存泄漏；
第二获取模块，用于当内存泄漏情况属于slub内存泄漏时，按照第二设定时间间隔依次通过slabtop指令获取第一slabtop信息和第二slabtop信息；
目标分配接口确定模块，用于根据第一slabtop信息和第二slabtop信息确定内存消耗增量满足第一预设条件的目标分配接口；
第三获取单元，用于获取所述目标分配接口的内存操作记录，所述内存操作记录包括内存分配记录和内存释放记录；
泄漏源确定单元，用于根据内存操作记录，确定内存泄漏源。
本实施例公开了一种定位linux内核slub内存泄漏的系统，包括：
存储器，用于存储程序；
处理器，用于加载所述程序以执行所述的定位linux内核slub内存泄漏的方法。
通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (6)

1.一种定位linux内核slub内存泄漏的方法，其特征在于，包括以下步骤：
按照第一设定的时间间隔依次获取第一内存统计信息和第二内存统计信息；
根据第一内存统计信息和第二内存统计信息确定内存泄漏情况是否属于slub内存泄漏；
当内存泄漏情况属于slub内存泄漏时，按照第二设定时间间隔依次通过slabtop指令获取第一slabtop信息和第二slabtop信息；
根据第一slabtop信息和第二slabtop信息确定内存消耗增量满足第一预设条件的目标分配接口；
获取所述目标分配接口的内存操作记录，所述内存操作记录包括内存分配记录和内存释放记录；
根据内存操作记录，确定内存泄漏源；
在获取所述第一内存统计信息和获取所述第二内存统计信息之前，均执行以下步骤：
执行SReclaimable内存的回收；
根据第一内存统计信息和第二内存统计信息确定内存泄漏情况是否属于slub内存泄漏，包括：
根据第一内存统计信息中的可用内存信息和所述第二内存统计信息中的可用内存之差，确定可用内存差值；
根据第一内存统计信息中的SUnreclaim数值和所述第二内存统计信息中的SUnreclaim数值之差，确定SUnreclaim的内存新增值；
当所述SUnreclaim的内存新增值和所述可用内存差值之差满足第二预设条件，则判定内存泄漏情况属于slub内存泄漏；
所述内存分配记录包括alloc操作记录和alloc操作对应的调用堆栈记录；所述内存释放记录包括free操作和free操作对应的调用堆栈记录；
所述根据内存操作记录，确定内存泄漏源，包括：
通过对比内存分配记录和内存释放记录，确定没有对应的内存释放记录的目标内存分配记录；
根据所述目标内存分配记录中堆栈记录所采用的堆栈，对多个所述目标内存分配记录进行分类统计；
将统计量最大的分类所对应的堆栈确定内存泄漏源。
2.根据权利要求1所述的定位linux内核slub内存泄漏的方法，其特征在于，所述根据第一slabtop信息和第二slabtop信息确定内存消耗增量满足第一预设条件的目标分配接口，包括：
根据每个接口在所述第二slabtop信息中SLAB_CACHE_SIZE值和所述第一slabtop信息中SLAB_CACHE_SIZE值之差，确定每个接口的内存消耗增量；
将所述内存消耗增量大于第一阈值的接口确定为目标分配接口。
3.根据权利要求1所述的定位linux内核slub内存泄漏的方法，其特征在于，所述通过对比内存分配记录和内存释放记录，确定没有对应的内存释放记录的目标内存分配记录，包括：
遍历所有所述内存释放记录，删除第一个所述内存分配记录中与所述内存释放记录地址一致的内存分配记录；
将剩余的所述内存分配记录作为目标内存分配记录。
4.根据权利要求1所述的定位linux内核slub内存泄漏的方法，其特征在于，所述方法通过脚本执行。
5.一种定位linux内核slub内存泄漏的系统，其特征在于，包括：
第一获取模块，用于按照第一设定的时间间隔依次获取第一内存统计信息和第二内存统计信息；
判断模块，用于根据第一内存统计信息和第二内存统计信息确定内存泄漏情况是否属于slub内存泄漏；
根据第一内存统计信息和第二内存统计信息确定内存泄漏情况是否属于slub内存泄漏，包括：
根据第一内存统计信息中的可用内存信息和所述第二内存统计信息中的可用内存之差，确定可用内存差值；
根据第一内存统计信息中的SUnreclaim数值和所述第二内存统计信息中的SUnreclaim数值之差，确定SUnreclaim的内存新增值；
当所述SUnreclaim的内存新增值和所述可用内存差值之差满足第二预设条件，则判定内存泄漏情况属于slub内存泄漏；
第二获取模块，用于当内存泄漏情况属于slub内存泄漏时，按照第二设定时间间隔依次通过slabtop指令获取第一slabtop信息和第二slabtop信息；
目标分配接口确定模块，用于根据第一slabtop信息和第二slabtop信息确定内存消耗增量满足第一预设条件的目标分配接口；
第三获取单元，用于获取所述目标分配接口的内存操作记录，所述内存操作记录包括内存分配记录和内存释放记录；
所述内存分配记录包括alloc操作记录和alloc操作对应的调用堆栈记录；所述内存释放记录包括free操作和free操作对应的调用堆栈记录；
泄漏源确定单元，用于根据内存操作记录，确定内存泄漏源；
所述根据内存操作记录，确定内存泄漏源，包括：
通过对比内存分配记录和内存释放记录，确定没有对应的内存释放记录的目标内存分配记录；
根据所述目标内存分配记录中堆栈记录所采用的堆栈，对多个所述目标内存分配记录进行分类统计；
将统计量最大的分类所对应的堆栈确定内存泄漏源。
6.一种定位linux内核slub内存泄漏的系统，其特征在于，包括：
存储器，用于存储程序；
处理器，用于加载所述程序以执行如权利要求1-4任一项所述的定位linux内核slub内存泄漏的方法。
CN202011637900.9A 2020-12-31 2020-12-31 定位linux内核slub内存泄漏的方法和系统 Active CN112631941B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011637900.9A CN112631941B (zh) 2020-12-31 2020-12-31 定位linux内核slub内存泄漏的方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011637900.9A CN112631941B (zh) 2020-12-31 2020-12-31 定位linux内核slub内存泄漏的方法和系统

Publications (2)

Publication Number Publication Date
CN112631941A CN112631941A (zh) 2021-04-09
CN112631941B true CN112631941B (zh) 2022-04-19

Family

ID=75290116

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011637900.9A Active CN112631941B (zh) 2020-12-31 2020-12-31 定位linux内核slub内存泄漏的方法和系统

Country Status (1)

Country Link
CN (1) CN112631941B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113672417A (zh) * 2021-07-28 2021-11-19 杭州迪普科技股份有限公司 内存泄漏告警方法及装置
CN114356583A (zh) * 2022-01-13 2022-04-15 浪潮商用机器有限公司 一种基于linux操作系统的slub内存申请监测方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105446871A (zh) * 2014-08-26 2016-03-30 华为技术有限公司 一种资源泄漏检测方法、装置及系统
CN107783908A (zh) * 2017-11-07 2018-03-09 晶晨半导体(上海)股份有限公司 一种基于Linux内核内存泄露的检测方法
CN110727585A (zh) * 2019-09-11 2020-01-24 锐捷网络股份有限公司 内存泄漏检测方法、装置、电子设备及可读存储介质
CN110908865A (zh) * 2019-11-15 2020-03-24 珠海豹趣科技有限公司 内存泄漏监控方法、装置及电子设备

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2774575A1 (en) * 2011-04-19 2012-10-19 Monoidics Ltd. System and method for display of software quality
US20160077956A1 (en) * 2014-09-11 2016-03-17 Wipro Limited System and method for automating testing of software
CN105260314B (zh) * 2015-11-03 2018-06-29 上海斐讯数据通信技术有限公司 内存泄漏的监测方法
US10664377B2 (en) * 2016-07-15 2020-05-26 Blackberry Limited Automation of software verification
CN109491897A (zh) * 2018-10-26 2019-03-19 成都安恒信息技术有限公司 一种基于趋势分析的系统资源泄漏测试方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105446871A (zh) * 2014-08-26 2016-03-30 华为技术有限公司 一种资源泄漏检测方法、装置及系统
CN107783908A (zh) * 2017-11-07 2018-03-09 晶晨半导体(上海)股份有限公司 一种基于Linux内核内存泄露的检测方法
CN110727585A (zh) * 2019-09-11 2020-01-24 锐捷网络股份有限公司 内存泄漏检测方法、装置、电子设备及可读存储介质
CN110908865A (zh) * 2019-11-15 2020-03-24 珠海豹趣科技有限公司 内存泄漏监控方法、装置及电子设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
嵌入式Linux下内存泄漏的检查和解决;何恺;《现代计算机》;20200430(第11期);全文 *

Also Published As

Publication number Publication date
CN112631941A (zh) 2021-04-09

Similar Documents

Publication Publication Date Title
CN106610892B (zh) 内存泄漏检测方法和装置
CN109656779A (zh) 内存监控方法、装置、终端和存储介质
CN105122212A (zh) 自动化跟踪系统中的周期性优化
CN112631941B (zh) 定位linux内核slub内存泄漏的方法和系统
CN105283848A (zh) 用分布式目标来进行应用跟踪
CN110515808B (zh) 数据库监控方法、装置、计算机设备及存储介质
CN106997316B (zh) 内存异常增长的检测系统及方法
CN112035314A (zh) 内存泄漏的监控方法、装置及电子设备
CN111625833A (zh) 一种高效的软件程序释放后重用漏洞判定方法和装置
CN111966603B (zh) 内存泄露的检测方法及装置、可读存储介质及电子设备
CN116755891A (zh) 基于多线程的事件队列处理方法和系统
US7962692B2 (en) Method and system for managing performance data
CN109542341B (zh) 一种读写io监测方法、装置、终端及计算机可读存储介质
CN110674145B (zh) 数据一致性的检测方法、装置、计算机设备和存储介质
CN108667740A (zh) 流量控制的方法、装置及系统
CN111274060A (zh) 一种确定内存异常的方法、装置、设备和存储介质
CN114785616A (zh) 数据风险检测方法、装置、计算机设备及存储介质
CN116414722B (zh) 模糊测试处理方法、装置、模糊测试系统及存储介质
CN111523609A (zh) 车辆数据处理方法、装置、计算机设备和存储介质
CN117033099A (zh) 一种系统硬盘的压力测试方法、系统、装置及存储介质
CN107122247B (zh) 一种静态占用图片的检测方法和装置
US20210397508A1 (en) Localization of potential issues to objects
CN112346894B (zh) 内存泄露检测方法、装置、系统及计算机设备
CN109800581B (zh) 软件行为的安全防护方法及装置、存储介质、计算机设备
CN115168124A (zh) 硬盘并发执行多个文件的稳定性测试方法、装置、计算机设备及介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information

Address after: 511356 Room 501, building 2, No. 63, Yong'an Avenue, Huangpu District, Guangzhou, Guangdong

Applicant after: Guangzhou lubangtong Internet of things Technology Co.,Ltd.

Address before: 510653 room F315, 95 daguanzhong Road, Tianhe District, Guangzhou City, Guangdong Province

Applicant before: GUANGZHOU ROBUSTEL TECHNOLOGIES Co.,Ltd.

CB02 Change of applicant information
GR01 Patent grant
GR01 Patent grant