NGINX原理分析 之 SLAB分配机制

1 引言

众所周知,操作系统使用伙伴系统管理内存,不仅会造成大量的内存碎片,同时处理效率也较低下。SLAB是一种内存管理机制,其拥有较高的处理效率,同时也
有效的避免内存碎片的产生,其核心思想是预分配。其按照SIZE对内存进行分类管理的,当申请一块大小为SIZE的内存时,分配器就从SIZE集合中分配
一个内存块(BLOCK)出去,当释放一个大小为SIZE的内存时,则将该内存块放回到原有集合,而不是释放给操作系统。当又要申请相同大小的内存时,可
以复用之前被回收的内存块(BLOCK),从而避免了内存碎片的产生。[注:因SLAB处理过程的细节较多,在此只是做一个原理上的讲解]

2 总体结构

图1 SLAB内存结构

3 处理流程

如图1中所示:SLAB管理机制将内存大体上分为SLAB头、SLOT数组、PAGES数组、可分配空间、被浪费空间等模块进行分别管理,其中各模块的功能和作用:

SLAB
头:包含SLAB管理的汇总信息,如最小分配单元(min_size)、最小分配单元对应的位移(min_shift)、页数组地址(pages)、空闲
页链表(free)、可分配空间的起始地址(start)、内存块结束地址(end)等等信息(如代码1所示),在内存的管理过程中,内存的分配、回收、
定位等等操作都依赖于这些数据。

SLOT数组:SLOT数组各成员分别负责固定大小的内存块(BLOCK)的分配和回收。在nginx中
SLOT[0]~SLOT[7]分别负责区间在[1~8]、[9~16]、[17~32]、[33~64]、[65~128]、[129~256]、
[257~512]、[513~1024]字节大小内存的分配,但为方便内存块(BLOCK)的分配和回收,每个内存块(BLOCK)的大小为各区间的上
限(8、16、32、64、128、256、512、1024)。比如说:假如应用进程请求申请5个字节的空间,因5处在[1~8]的区间内,因此由
SLOT[0]负责该内存的分配,但区间[1~8]的上限为8,因此即使申请5个字节,却依然分配8字节给应用进程。以此类推:假如申请12字节,12处
于区间[9~16]之间,取上限16,因此由SLOT[1]分配16个字节给应用进程;假如申请50字节,50处于区间[33~64]之间,取上限64,
因此由SLOT[2]分配64个字节给应用进程;假如申请84字节,84处于区间[65~128]之间,取上限128,因此由SLOT[3]分配128个
字节;...;假如申请722字节,722处于区间[513~1024]之间,取上限1024,因此由SLOT[7]分配1024字节。

PAGES数组:PAGES数组各成员分别负责可分配空间中各页的查询、分配和回收,其处理流程可参考3.2节的说明。

可分配空间:SLAB在逻辑上将可分配空间划分成M个内存页,每页大小为4K。每页内存与PAGES数组成员一一对应,由PAGES数组各成员负责各内存页的分配和回收。

被浪费空间:按照每页4K的大小对空间进行划分时,满足4K的空间,将作为可分配空间被PAGES数组进行管理,而最后剩余的不足4K的内存将会被舍弃,也就是被浪费了!

3.1 初始化流程

初始化阶段主要完成对SLOT头、SLOT数组、PAGES数组、可分配空间和被浪费空间的区域分化,各区域的划分可参考图1和各模块功能的说明。nginx中slab结构体如下所示:

[html] view plaincopyprint?

typedef struct {

size_t min_size; /* 最小分配单元 */

size_t min_shift; /* 最小分配单元对应的位移 */

ngx_slab_page_t *pages; /* 页数组 */

ngx_slab_page_t free; /* 空闲页链表 */

u_char *start; /* 可分配空间的起始地址 */

u_char *end; /* 内存块的结束地址 */

... /* 其他变量成员(省略) */

}ngx_slab_pool_t

typedef struct {
    size_t            min_size;     /* 最小分配单元 */
    size_t            min_shift;    /* 最小分配单元对应的位移 */

    ngx_slab_page_t  *pages;        /* 页数组 */
    ngx_slab_page_t   free;         /* 空闲页链表 */

    u_char           *start;        /* 可分配空间的起始地址 */
    u_char           *end;          /* 内存块的结束地址 */

    ...                             /* 其他变量成员(省略) */
}ngx_slab_pool_t

代码1 SLAB头部结构体

3.2 页的管理

3.2.1 页的分配

1)分配之前

在SLAB初始化之后,所有页可以看成是一个连续的整体,其内存结构如下图所示:

图2 页的结构(分配之前)

2)申请一页

当申请一页时,则将pages[0]从free链表中分离出去,如下图所示:

图3 页的结构(申请一页)

3)申请二页

当再申请二页时,则将page[3]和pages[4]作为一个整体从free链表中分离出去,如下图所示:

图4 页的结构(申请二页)

3.2.2 页的回收

1)回收一页

当页被回收时,被回收的页并不会和未被分配的页进行合并,而是通过链表串联起来,如下图所示:

图5 页的结构(回收一页)

2)回收二页

当页被回收时,被回收的页并不会和未被分配的页进行合并,而是通过链表串联起来,如下图所示:

图6 页的结构(回收二页)

3.4 SLOT的管理

SLOT数组的作用可以参考第三章开头的阐述。SLOT数组各成员相当于链表头,在SLOT的分配和回收过程中,通过链表来组织用于分配各SIZE(1~1024)的PAGE。如,在某时刻,可能存在如下状态:

图7 SLOT和PAGES的关系

3.4.1 页的管理

1)初始状态

在SLAB初始化后,slot链表头的下一个节点都为NULL,如下图所示:

图8 SLOT初始状态

2)添加一页

SLOT[2]负责32(17~32)字节空间的分配和回收,假设现申请分配24字节(17~32之间)的空间,因此将从slot[2]中分配。但在初始
状态下slot[2]的下一页为NULL,因此需要向页管理模块申请一页pages[x]内存,再将该页加入到slot[2]的链表中,添加之后的内存结
构如下图所示:

图9 slot[2]增加一页

3)暂离链表

SLOT[2]中的每一页有128(4K/32=128)个单元,当一页分配了128次时,表示该页可分配单元分配完毕,此时该页将会暂时从链表中剔除出去,以防止下次申请时,做无效的遍历。如下图所示:

图10 slot[2]第一页被使用完

4)再添一页

当再次申请17~32字节时,此时slot[2]的后续链表为空,因此需要再次向页管理申请一页pages[y]内存,再将该页加入到slot[2]的链表中,如下图所示。如果该页又被分配完,则进行3)的处理。

图11 slot[2]再添一页

5)重入链表

当所有单元被用完的页pages[x]中的一个单元被回收时,页pages[x]中将有1个单元可以再次被分配使用,此时应该将pages[x]重新加入
到slot[2]的链表中,以便下次分配时可以从页pages[x]中进行查找。此时内存组织形式如下图所示:

图12 页pages[x]重入链表

6)回收整页

当页pages[x]所有单元被释放后,则该页将会被全部回收:该页将从slot[2]的链表中被剔除,并将页pages[x]重新加入到free链表。此时的内存结构图如下图所示:

图13 回收页pages[x]

3.4.2 SLOT的分配

1)页内结构

被加入到SLOT数组链表的页在逻辑上划分为很多的内存单元,每一小内存单元的使用情况是通过位图进行标记的,1表示被占用,0表示未被占用。如:第20
位bit的值为1时,表示第20个内存单元被占用。假如此SLOT链表的PAGE正好可以划分为32块,则其逻辑组织结构如下图所示:

图14 PAGE内结构

2)分配单元

假如此时在SLOT[s]链表的页中连续申请4个内存单元,则其前4个内存单元将首先被占用,则此时的位图结构如下图所示:

图15 分配单元

3)释放单元

假如此时释放SLOT[s]链表页中第3个内存单元,则此时的位图结构如下图所示:

图16 释放单元

上文来自:http://blog.163.com/zhangjie_0303/blog/static/99082706201442134648918/

时间: 2024-10-16 03:37:42

NGINX原理分析 之 SLAB分配机制的相关文章

[转载]NGINX原理分析 之 SLAB分配机制

作者:邹祁峰 邮箱:[email protected] 博客:http://blog.csdn.net/qifengzou 日期:2013.09.15 23:19 转载请注明来自"祁峰"的CSDN博客 1 引言 众所周知,操作系统使用伙伴系统管理内存,不仅会造成大量的内存碎片,同时处理效率也较低下.SLAB是一种内存管理机制,其拥有较高的处理效率,同时也有效的避免内存碎片的产生,其核心思想是预分配.其按照SIZE对内存进行分类管理的,当申请一块大小为SIZE的内存时,分配器就从SIZE

Handler系列之原理分析

上一节我们讲解了Handler的基本使用方法,也是平时大家用到的最多的使用方式.那么本节让我们来学习一下Handler的工作原理吧!!! 我们知道Android中我们只能在ui线程(主线程)更新ui信息,那么你们知道为什么只能通过Handler机制更新ui吗?其实最根本的目的就是解决多线程并发的问题. 假设在一个Activity中有多个线程去更新ui,并且都没有加锁,那么会是什么样子? 导致的结果就是更新界面错乱. 如果对更新ui的操作都进行加锁处理的话又产生什么问题哪? 性能下降. 处于对以上

memcached学习——memcached的内存分配机制Slab Allocation、内存使用机制LRU、常用监控记录(四)

内存分配机制Slab Allocation 本文参考博客:https://my.oschina.net/bieber/blog/505458 Memcached的内存分配是以slabs为单位的,会根据初始chunk大小.增长因子.存储数据的大小实际划分出多个不同的slabs class,slab class中包含若干个等大小的trunk和一个固定48byte的item信息.trunk是按页存储的,每一页成为一个page(默认1M). 1.slabs.slab class.page三者关系: sl

Linux内存分配机制——伙伴系统和SLAB

内核内存管理的一项重要工作就是如何在频繁申请释放内存的情况下,避免碎片的产生.这就要求内核采取灵活而恰当的内存分配策略.通常,内存分配一般有两种情况:大对象(大的连续空间分配).小对象(小的空间分配).针对不同的需求,Linux分别采取了伙伴系统算法和SLAB进行内存分配. 伙伴系统:把所有的空闲页框分为11个块链表,每个块链表中的结点分别是大小为1,2,4,8,16,32,64,128,256,512和1024个连续页框的页框块.最大的页框块包含1024个连续页框,对应4MB大小的连续内存.假

Redis数据持久化机制AOF原理分析二

Redis数据持久化机制AOF原理分析二 分类: Redis 2014-01-12 15:36  737人阅读  评论(0)  收藏  举报 redis AOF rewrite 目录(?)[+] 本文所引用的源码全部来自Redis2.8.2版本. Redis AOF数据持久化机制的实现相关代码是redis.c, redis.h, aof.c, bio.c, rio.c, config.c 在阅读本文之前请先阅读Redis数据持久化机制AOF原理分析之配置详解文章,了解AOF相关参数的解析,文章链

list的内存分配机制分析

该程序演示了list在内存分配时候的问题.里面的备注信息是我的想法. /* 功能说明: list的内存分配机制分析. 代码说明: list所管理的内存地址可以是不连续的.程序在不断的push_back的过程中,程序仅会将操作的元素进行复制一份,保存到list中.通过复制构造函数和析构函数,可以看到这些操作. 实现方式: 限制条件或者存在的问题: 无 */ #include <iostream> #include <string> #include <list> #inc

vector的内存分配机制分析

该程序初步演示了我对vector在分配内存的时候的理解.可能有误差,随着理解的改变,改代码可以被修改. 1 /* 2 功能说明: 3 vector的内存分配机制分析. 4 代码说明: 5 vector所管理的内存地址是连续的.程序在不断的push_back的过程中,如果当前所管理的内存不能装下新的元素的时候,程序会创建更大的地址连续的空间来保存更多的元素. 6 这种机制会引起大量的无用的复制和删除操作.如果vector的元素为类结构的时候,他就会有很多临时变量产生.通过复制构造函数和析构函数,可

map的内存分配机制分析

该程序演示了map在形成的时候对内存的操作和分配. 因为自己对平衡二叉树的创建细节理解不够,还不太明白程序所显示的日志.等我明白了,再来修改这个文档. /* 功能说明: map的内存分配机制分析. 代码说明: map所管理的内存地址可以是不连续的.如果key是可以通过<排序的,那么,map最后的结果是有序的.它是通过一个平衡二叉树来保存数据.所以,其查找效率极高. 实现方式: 限制条件或者存在的问题: 无 */ #include <iostream> #include <strin

ngxin源码学习(二):nginx内存池分配机制

main -> ngx_save_argv创造一个包含argc个地址空间的数组ngx_argv,然后为ngx_argv每个地址空间分配argv[i]大小的空间,并将argv[i]拷贝入ngx_argv[i]指向的地址空间 main -> ngx_process_options调用ngx_pnalloc,在内存池中找到一块ngx_prefix大小的空间 onginx内存池分配机制:内存池pool的数据结构中包含两个链表,一个是ngx_pool_t链表(存放一般block),一个是ngx_larg