nginx【23】内存池对性能的影响
  IdAbMGfNl7YD 2023年11月02日 102 0

如果你开发过nginx的第三方模块,虽然我们在写C语言代码,但是不需要关心内存的释放,如果你现在在配置一些罕见场景的nginx的时候,你可能会需要去修改nginx在请求和连接上初始分配的内存池大小,但是nginx官方上推荐通常不需要修改这样的配置,那么我们究竟要不要修改这些内存池的大小尼?

下面我们来看下 内存池 究竟是怎么运转的?

在上讲中我们看到一个结构体​​ngx_connection_s​​​也就是每一个连接需要这么一个结构体;而这个结构体中,有一个成员变量​​pool​​;

它对应着这个连接所使用的内存池
nginx【23】内存池对性能的影响_nginx
这个内存池可以通过一个变量​​​connection_pool_size​​配置来定义;

那么我们为什么需要内存池尼?
nginx【23】内存池对性能的影响_运维_02
如果有一些工具的话,我们会发现,nginx它所产生的内存碎片是非常小的;这就是内存池的一个功劳,那么内存池尼它会把内存提前分配好一批,而且当我们使用小块内存的时候,每次我们使用的小块内存的时候,它会使用last,end,next,failed一个个连接在一起,每次我们使用的东西比较小的时候尼,在第二次再分配小块内存,它还会再进行连接一起,这样就大大减少了我们的内存碎片,当然当我们分配大块内存的时候尼,会走操作系统的 ​​​alloc​​模块;

那么对于nginx有什么好处尼?

因为它主要在处理WEB请求,WEB请求特别是对http请求;它有两个非常明显的特点就是每当我们有个tcp连接的时候,这个tcp连接上面可能会有很多http请求;也就是所谓的http keepalive请求,连接没有关闭;执行完一条请求以后 还负责执行另外一条请求;那么有一些内存尼 我为连接分配一次就够了;比如说我去读取每一个请求的前1k字节;在连接内存池上我分配一次;只要这个连接不关闭,那么这个1k的内存我永远不要释放;什么时候需要释放尼?连接关闭的时候我再释放,没有任何问题;

请求内存池尼?每一个http请求我开始分配的时候尼,我不知道分配多大,但是http请求特别是​​http1.1​​​而言,通常我们会分配​​4k大小​​的内存;因为我们的url或者header需要分配这么多;如果没有内存池尼,我们可能需要频繁的分配(小块的分配);而分配内存池尼,我们是有代价的;如果我们一次性的分配较多的内存尼,就没有这样的问题;而请求执行完毕以后,哪怕连接我们还可以复用;我们也可以把请求内存池给销毁;而这样所有的nginx第三方模块开发者就不需要去关注你村什么时候去释放;它只需要关注它是从请求内存池里面申请分配的内存;还是从连接内存池里申请分配的内存;只要这个逻辑讲的通;比如说请求结束以后,连接人想继续使用,你可以在连接内存池里分配;

我们看下具体的例子;​​ngx_http_core_module​​​ 这个模块中
nginx【23】内存池对性能的影响_第三方模块_03
nginx【23】内存池对性能的影响_运维_04
这跟我们的操作系统的位数是有关的;

内存池配置​​512​​并不是代表在这里我只能分配512的字节;

当我们分配的内存超过预分配的大小的时候,还是可以继续分配的;这里只是说因为我提前预分配了足够大小的空间可以减少我分配内存的次数;

那么我们再看另外一个配置叫​​request_pool_size​​​nginx【23】内存池对性能的影响_nginx_05
nginx【23】内存池对性能的影响_第三方模块_06
也就是每一个请求的内存池的大小;这里我们可以看到它的默认大小是4k;为什么会差距那么大?

之所以会差距8倍,那是因为对连接而言,它需要保存的上下文信息非常的少;它只需要帮助后面的请求,读取最初一部分字节就行了,而对于请求而言,我们需要保存大量的上下文信息,比如说所有读取到的url或者header我需要保存下来,url通常还比较长,所以我们需要4k的大小;当然官方文档中说 它对性能的影响比较小,如果我们在极端场景下,如果你的url特别大,可以考虑把这个值分配的更大,通常来说你是很小内存的,url特别小,header也非常少,可以考虑将这个值降低一些,这样nginx消耗的内存会小一些;也意味着可以做更大并发量的请求;

总结:以上我们介绍了内存池的原理,以及请求内存池和连接内存池,它们的配置代表了怎么样的意义,内存池对减少我们内存碎片,对第三方模块的快速开发,是有很大意义的;可能有些第三方模块不当使用了内存池,比如本该在请求内存池里分配内存,却在连接内存池里连接内存;可能会导致内存的延期释放,导致nginx的内存无谓的增加;这需要我们注意;


【版权声明】本文内容来自摩杜云社区用户原创、第三方投稿、转载,内容版权归原作者所有。本网站的目的在于传递更多信息,不拥有版权,亦不承担相应法律责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@moduyun.com

  1. 分享:
最后一次编辑于 2023年11月08日 0

暂无评论

推荐阅读
  ehrZuhofWJiC   2024年05月17日   36   0   0 linuxsvn
  ehrZuhofWJiC   2024年05月17日   40   0   0 KVMlinux
  ehrZuhofWJiC   2024年05月17日   44   0   0 服务器linux
IdAbMGfNl7YD