GLIBC内存分配机制引发的“内存泄露”

简介:

我们正在开发的类数据库系统有一个内存模块,出现了一个疑似”内存泄露”问题,现象如下:内存模块的内存释放以后没有归还操作系统,比如内存模块占用的内存为10GB,释放内存以后,通过TOP命令或者/proc/pid/status查看占用的内存有时仍然为10G,有时为5G,有时为3G, etc,内存释放的行为不确定。

首先说一下内存模块的内存管理机制。我们的内存管理很简单,使用全局的定长内存池,每一个内存块为64KB,如果申请的内存小于等于64KB时,直接从内存池的空闲链表中获取一个内存块,内存释放时归还空闲链表;如果申请的内存大于64KB,直接通过操作系统的malloc和free获取。某些数据结构涉及到很多小对象的管理,比如Hash表,B-Tree,这些数据结构从全局内存池获取内存后再根据数据结构的特点进行组织。为了提高内存申请/释放的效率,减少锁冲突,为每一个线程单独保留一个8MB的内存块,每个线程优先从线程专属的8MB内存块获取内存,专属内存不足时才从全局的内存池获取。

由于我们的所有内存申请/释放操作都需要通过全局的内存池进行,我们在全局的内存池中加入对每个子模块的内存统计功能:每个子模块申请内存时都将子模块编号传给全局的内存池,全局的内存池进行统计。复现问题后发现全局的内存池的统计结果符合预期,因此怀疑是操作系统或者glibc的行为。

Linux下Glibc的内存管理机制大致如下:

从操作系统的角度看,进程的内存分配由两个系统调用完成:brk和mmap。brk是将数据段(.data)的最高地址指针_edata往高地址推,mmap是在进程的虚拟地址空间中找一块空闲的。其中,mmap分配的内存由munmap释放,内存释放时将立即归还操作系统;而brk分配的内存需要等到高地址内存释放以后才能释放。也就是说,如果先后通过brk申请了A和B两块内存,在B释放之前,A是不可能释放的,仍然被进程占用,通过TOP查看疑似”内存泄露”。默认情况下,大于等于128KB的内存分配会调用mmap/mummap,小于128KB的内存请求调用sbrk(可以通过设置M_MMAP_THRESHOLD来调整)。详细的内存管理机制可以参考百度分享的文章

我们的内存模块申请/释放内存都是以2MB为单位的,按理说应该是使用mmap和munmap进行内存分配和释放的,不会出现内存释放以后仍然被进程占用的情况。在内核同学的协助下,经过长时间的分析定位,发现了Glibc的新特性:M_MMAP_THRESHOLD可以动态调整。M_MMAP_THRESHOLD的值在128KB到32MB(32位机)或者64MB(64位机)之间动态调整,每次申请并释放一个大小为2MB的内存后,M_MMAP_THRESHOLD的值被调整为2M到2M + 4K之间的一个值(具体可以参考Glibc的patch说明)。例如:

char* no_used = new char[2 * 1024 * 1024];

memset(no_used, 0xfe, 2 * 1024 * 1024);

delete[] no_used;

// M_MMAP_THRESHOLD的值调整为2M到2M + 4K之间的一个值,后续申请 <= 2 * 1024 * 1024的内存块都会走sbrk而不是mmap

了解到这种现象后,我们找到了”内存泄露”的原因:M_MMAP_THRESHOLD的值动态调整,后续的2MB的内存申请通过sbrk实现,而sbrk需要等到高地址内存释放以后低地址内存才能释放。可以通过显式设置M_MMAP_THRESHOLD或者M_MMAP_MAX来关闭M_MMAP_THRESHOLD动态调整的特性,从而避免上述问题。

当然,mmap调用是会导致进程产生缺页中断的,为了提高性能,常见的做法如下:

1, 将动态内存改为静态,比如采用内存池技术或者启动的时候给每个线程分配一定大小,比如8MB的内存,以后直接使用;

2, 禁止mmap内存调用,禁止Glibc内存缩紧将内存归还系统,Glibc相当于实现了一个内存池功能。只需要在进程启动的时候加入两行代码:

mallopt(M_MMAP_MAX, 0); // 禁止malloc调用mmap分配内存

mallopt(M_TRIM_THRESHOLD, 0); // 禁止内存缩进,sbrk申请的内存释放后不会归还给操作系统

花絮:

追查”内存泄露”问题的过程中,尝试使用Glibc的钩子函数(Malloc Hook) 统计malloc和free的内存量:具体做法为malloc的时候多申请8个字节,其中4个字节记录长度,4个字节记录magic_num,malloc和free的时候统计进程申请和释放的内存量。实践表明无论自定义钩子函数是否加锁,malloc和free钩子函数在多线程的情况下运行都不正常,其它同学也发现了相同的问题(Malloc Hook多线程问题)。

目录
相关文章
|
5天前
|
算法
深入理解操作系统的内存管理机制
【5月更文挑战第31天】 在现代计算机系统中,操作系统扮演着资源管理者的角色,其中内存管理是其核心职能之一。本文将探讨操作系统内存管理的关键技术和原理,包括虚拟内存、分页机制、内存分配策略等,旨在为读者提供一个清晰的框架来理解和评估不同操作系统如何高效、安全地管理有限的物理内存资源。通过对这些概念的深入分析,我们不仅能够更好地理解系统性能和稳定性背后的因素,还能对日常编程实践中遇到的相关问题有更深刻的洞察。
|
5天前
|
存储 缓存 算法
深入理解操作系统的内存管理机制
【5月更文挑战第31天】 在现代计算机系统中,操作系统扮演着核心角色,它负责管理硬件资源并为应用程序提供服务。内存管理是操作系统中一个至关重要的功能,它确保了系统能够高效、安全地分配和回收内存资源。本文将详细探讨操作系统内存管理的关键技术,包括虚拟内存的概念、分页与分段机制、物理与逻辑地址转换,以及内存分配策略等。通过对这些技术的深入分析,读者将获得对操作系统如何优化内存使用和管理过程的深刻理解。
|
6天前
|
缓存 算法 Java
深入理解操作系统的内存管理机制
【5月更文挑战第30天】 在现代计算机系统中,操作系统扮演着至关重要的角色,它负责协调和管理硬件资源,为应用程序提供必要的服务。其中,内存管理是操作系统的核心功能之一,它不仅关系到系统的稳定性和效率,而且直接影响到应用程序的性能。本文将深入探讨操作系统中的内存管理机制,包括物理内存与虚拟内存的概念、分页系统、内存分配策略以及内存保护等方面。通过对这些技术的细致剖析,旨在帮助读者建立起对操作系统内存管理深层次的认识。
|
6天前
|
存储 监控 算法
深入理解操作系统的内存管理机制
【5月更文挑战第30天】 本文旨在探讨操作系统中的核心功能之一——内存管理。通过深入分析内存管理的关键技术和原理,我们将揭示操作系统如何高效地分配、监控和回收内存资源。文章将详细阐述内存管理的几个关键方面:分页系统、虚拟内存、物理内存分配以及内存交换机制。这些概念是现代操作系统设计的基础,对于软件开发者来说,了解其背后的原理有助于编写出更加稳定高效的程序。
|
6天前
|
存储
深入理解操作系统的内存管理机制
【5月更文挑战第30天】 在现代计算机系统中,操作系统扮演着至关重要的角色,其负责协调和管理硬件资源,为上层应用提供必要的服务。其中,内存管理是操作系统核心功能之一,它不仅关系到系统性能的优化,还直接影响到系统的稳定性与安全性。本文将深入探讨操作系统中的内存管理机制,包括物理内存与虚拟内存的映射关系、分页与分段技术的应用,以及内存分配策略等方面,旨在为读者提供一个全面而详细的内存管理视角。
|
7天前
|
安全 虚拟化 云计算
探索现代操作系统的虚拟内存管理机制
【5月更文挑战第29天】 在计算机科学领域,虚拟内存是允许程序在比物理内存更大的地址空间中运行的一种技术。本文将深入探讨现代操作系统中虚拟内存管理的基本原理、关键技术以及它对系统性能的影响。我们将从分页机制、段式管理到最新的虚拟化技术,分析其设计哲学与实现方法,并讨论它们如何提升系统的灵活性与稳定性。
|
8天前
|
存储 算法 安全
探索操作系统的虚拟内存管理机制
【5月更文挑战第28天】在现代操作系统中,虚拟内存管理是一项关键技术,它允许系统使用有限的物理内存资源来模拟更大范围的地址空间。本文将深入剖析虚拟内存的工作原理,包括分页机制、地址转换、页面置换算法以及虚拟内存对系统性能的影响。通过理解这些概念,读者可以更好地掌握操作系统如何有效地管理和分配内存资源。
|
11天前
|
存储 算法 C语言
C库函数详解 - 内存操作函数:memcpy()、memmove()、memset()、memcmp() (一)
`memcpy()` 和 `memmove()` 是C语言中的两个内存操作函数。 `memcpy()` 函数用于从源内存区域复制指定数量的字节到目标内存区域。它不处理内存重叠的情况,如果源和目标区域有重叠,结果是未定义的。函数原型如下: ```c void *memcpy(void *dest, const void *src, size_t num); ```
28 6
TU^
|
13天前
|
C语言
C语言内存函数和字符串函数模拟实现
C语言内存函数和字符串函数模拟实现
TU^
26 0
|
2天前
|
安全 编译器 C语言
【再识C进阶3(下)】详细地认识字符分类函数,字符转换函数和内存函数
【再识C进阶3(下)】详细地认识字符分类函数,字符转换函数和内存函数