无论是语言层面实现的内存管理还是应用程序自行实现的内存管理,大都将内存按照大小分为几种,每种采用不同的管理模式。常见的分类是按照2的整数次幂分,将不同种类的内存通过链表链接, 查询时,从相应大小的链表中寻找,如果找不到,则可以考虑从更大块内存中,拿取一块,将其分为多个小点的内存。当然,对于特别大的内存,语言层面的内存管理可以直接调用内存管理相关的系统调用,应用层面的内存管理则可以直接使用语言层面的内存管理。
nginx内存管理整体可以分为2个部分,
说明
使用流程
nginx内存池的使用较为简单,可以分为3步
//size代表ngx_pool_t一块的大小
ngx_pool_t* ngx_create_pool(size_t size, ngx_log_t *log)
//从pool中申请size大小的内存
void* ngx_palloc(ngx_pool_t *pool, size_t size)
//释放从pool中申请的大块内存
ngx_int_t ngx_pfree(ngx_pool_t *pool, void *p)
//释放整个内存池
void ngx_destroy_pool(ngx_pool_t *pool)
具体实现
如下图所示,nginx将内存分为2种,一种是小内存,一种是大内存,当申请的空间大于pool->max时,我们认为是大内存空间,否则是小内存空间。
//创建内存池的参数size减去头部管理结构ngx_pool_t的大小
pool->max = size - sizeof(ngx_pool_t);
1.对于小块内存空间, nginx首先查看当前内存块待分配的空间中,是否能够满足用户需求,如果可以,则直接将这部分内存返回。如果不能满足用户需求,则需要重新申请一个内存块,申请的内存块与当前块空间大小相同,将新申请的内存块通过链表链接到上一个内存块,从新的内存块中分配用户所需的内存。
小块内存并不释放,用户申请后直接使用,即使后期不再使用也不需要释放该内存。由于用户有时并不知道自己使用的内存块是大是小,此时也可以调用ngx_pfree函数释放该空间,该函数会从大空间链表中查找内存,找到则释放内存。对于小内存而言,并未做任何处理。
2.对于大块内存, nginx会将这些内存放到链表中存储,通过pool->large进行管理。值得注意的是,用户管理大内存的ngx_pool_large_t结构是从本内存池的小块内存中申请而来,也就意味着无法释放这些内存,nginx则是直接复用ngx_pool_large_t结构体。当用户需要申请大内存空间时,利用c函数库malloc申请空间,然后将其挂载某个ngx_pool_large_t结构体上。nginx在需要一个新的ngx_pool_large_t结构时,会首先pool->large链表的前3个元素中,查看是否有可用的,如果有则直接使用,否则新建ngx_pool_large_t结构。
Syntax: | connection_pool_size |
---|---|
Default: | |
Context: | http , server |
Allows accurate tuning of per-connection memory allocations. This directive has minimal impact on performance and should not generally be used. By default, the size is equal to 256 bytes on 32-bit platforms and 512 bytes on 64-bit platforms.
Prior to version 1.9.8, the default value was 256 on all platforms.
Syntax: | request_pool_size |
---|---|
Default: | |
Context: | http , server |
Allows accurate tuning of per-request memory allocations. This directive has minimal impact on performance and should not generally be used.
说明
为什么需要内存池呢?Nginx产生的碎片是非常小的。内存池会提前分配好内存,当使用小内存的时候使用next指针连接在一起
Nginx是一个多进程程序,不同的worker进程要共享数据只能通过共享内存。
Nginx进程间通讯主要有两种方式,一种是通过信号,比如quite reload等。如果需要数据的同步那么就需要共享内存了,比如打开了10M的共享内存,那么多个worker进程可以同时访问它,包括读取和写入,为了使用好该共享内存会再次引入两个问题,一个是锁。因为多个worker进程同时操作一块内存一定会出现竞争关系,所以一定要加锁,还是上面的共享内存被1号worker进程使用,那么2号worker进程需要去获取锁的时候只要1号进程没有释放锁,那么2号进程会一直去请求这把锁。
如果是基于信号量的早期的Nginx锁,那么假设这把锁锁住了一扇门,如果worker进程1已经拿到这把锁进到屋里,那么worker进程2试图去拿锁敲门发现里面有人了,那么worker进程2就会就地休息,等待worker进程1从门里出来以后通知它。
而使用自旋锁不一样,worker进程2发现门里面有人了,它就一直持续的敲门。使用自旋锁要求所有的Nginx模块必须快速的使用共享内存,也就是快速取到锁以后快速的释放锁,一旦第三方模块不遵守这样的规则,就可能导致死锁,性能下降的问题。
共享内存是给所有对象使用的,如果在模块当中手动编写分配内存给这些对象那么将是非常繁琐的。所以这个时候使用了slab内存管理器
Nginx那些模块使用了共享内存呢?
使用共享内存主要使用了两种数据结构,一个是红黑树,比如做限速和流量控制场景时候,这个时候是不能容忍在内存当中做的,一个worker进程对某个用户触发了流量控制而其他worker进程还不知道,所以要在共享内存当中做。红黑树的特点是便利,插入,删除非常的快。所以这些模块都有一个特点需要做快速的插入删除。
其次是单链表,也就是将这些共享元素串联起来就行了。
nginx不同的worker之间需要共享信息的时候只能通过共享内存,共享内存上面可以使用链表或者红黑树的数据结构,但是每一个红黑树上有很多节点,每个节点都需要分配内存去存放,如何将整块内存切割为小块供红黑树的节点使用呢,这时候需要slab来管理了?
Slab会将整块共享内存分为许多页面,每个页面比如4K会切分为很多slot,比如32字节是一个slot,64字节是一种slot,128字节也是一种slot,如果有51字节的内存会怎么分配呢,会放在64字节的slot,这样浪费了13字节。所以slot指向了不同大小的块,同时也会对内存造成浪费,
Slab内存分配使用了bestfit分配思想,是linux系统经常使用内存的分配方式,通常使用共享内存要使用slab去分配相应的内存给对象,再使用上层的数据结构来维持这些对象。
基础
nginx互斥锁的实现
下图为原子操作实现互斥锁的示意图。
问题
- reload时,新启动的master向老的master发送信号后直接退出,旧的master,重新加载配置(ngx_init_cycle函数), 新创建工作进程, 新的工作进程与旧的工作进程使用的锁是相同的。
- 平滑升级时, 旧的master会创建新的master, 新的master会继承旧的master监听的端口(通过环境变量传递监听套接字对应的fd),新的进程并没有重新绑定监听端口。可能存在新老worker同时监听某个端口的情况,此时操作系统会保证只会有一个进程处理该事件(虽然epoll_wait都会被唤醒)。
- 将内存按照页进行分配,每页的大小相同, 此处设为page_size。
- 将内存块按照2的整数次幂进行划分, 最小为8bit, 最大为page_size/2。例如,假设每页大小为4Kb, 则将内存分为8, 16, 32, 64, 128, 256, 512, 1024, 2048共9种,每种对应一个slot, 此时slots数组的大小n即为9。申请小块内存(申请内存大小size <= page_size/2)时,直接给用户这9种中的一种,例如,需要30bit时,找大小为32的内存块提供给用户。
- 每个页只会划分一种类型的内存块。例如,某次申请内存时,现有内存无法满足要求,此时会使用一个新的页,则这个新页此后只会分配这种大小的内存。
- 通过双向链表将所有空闲的页连接。图中ngx_slab_pool_t中的free变量即使用来链接空闲页的。
- 通过slots数组将所有小块内存所使用的页链接起来。
- 对于大于等于页面大小的空间请求,计算所需页数,找到连续的空闲页,将空闲页的首页地址返回给客户使用,通过每页的管理结构ngx_slab_page_t进行标识。
- 所有页面只会有3中状态,空闲、未满、已满。空闲,未满都是通过双向链表进行整合,已满页面则不存在与任何页面,当空间被释放时,会将其加入到某个链表。
nginx共享内存的基本结构图如下: