高并发服务器的设计--内存池的设计
Posted Golang语言社区
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了高并发服务器的设计--内存池的设计相关的知识,希望对你有一定的参考价值。
不同的业务,设计也不尽相同,但至少都一些共同的追求,比如性能。
做服务器开发很多年了,有时候被人问到,服务器性能是什么呢?各种服务器间拼得是什么呢?
简单的回答就是QPS,并发数,但有时候想想也许也不对。
QPS与并发数是针对同样的业务而言的,业务不同,相同的服务器能承受的压力也会不同。
性能,也许可以打个俗点的比方:
服务器就是一艘船,性能就是船的容量,开的速度,行得是否稳当。
该用的用,该省的省。能用内存就别用IO,CPU则能少用就少用,相同的QPS,CPU和内存用的少点的性能就要比用的多点好,同样,QPS跑得多点的就比
跑得小点的性能要好,哪怕多用了点CPU和内存。
什么是性能的保障呢?
高效的事件模型,简单明了的业务架构,统一稳定的资源管理,外加纯熟的人员。
咱就从资源说起吧。
资源多半与IO有关,如果你看过我前面的文章,一定不会对连接池陌生,没错,连接是系统的一种IO资源,下面看看另一种IO资源:内存。
如果你看过apache, nginx之类服务器的代码,或者想入手,那么多半应该从内存管理开始。
与服务器性能息息相关,内存池的设计也追求快速与稳定,生命周期一般有下面三种:
global: 全局的内存,存放整个进程的全局信息。
conn: 每个连接的信息,从连接产生到关闭。
busi:业务相关的信息,伴随每个业务的产生到结束
下面定义一个简单的内存池:
[cpp]
typedef struct yumei_mem_buf_s yumei_mem_buf_t;
typedef struct yumei_mem_pool_s yumei_mem_pool_t;
struct yumei_mem_buf_s
{
int size;
char *pos;
char *data;
yumei_mem_pool_t *pool;
};
struct yumei_mem_pool_s
{
int size;
char *data;
char *last;
yumei_mem_pool_t *next;
yumei_mem_pool_t *current;
};
yumei_mem_pool_t* yumei_mem_pool_create( int block_size, int block_num );
int yumei_mem_pool_free( yumei_mem_pool_t *pool );
yumei_mem_buf_t* yumei_mem_malloc( yumei_mem_pool_t *pool, int size );
int yumei_mem_buf_free( yumei_mem_buf_t *buf );
在每个连接开始的时候,创建连接唯一的内存池,存放IO数据,当要创建新业务时,创建业务内存池,业务处理完毕时释放内存池:
[cpp]
typedef struct yumei_busi_s yumei_busi_t;
struct yumei_busi_s
{
yumei_mem_pool_t *pool;
...
...
}
#define yumei_BUSI_MEM_BLOCL_SIZE 512
#define yumei_BUSI_MEM_BLOCK_NUM 32
yumei_busi_t* yumei_busi_create()
{
yumei_busi_t* busi;
yumei_pool_t* pool;
yumei_mem_buf_t* buf;
int size;
pool = yumei_mem_pool_create( yumei_BUSI_MEM_BLOCL_SIZE, yumei_BUSI_MEM_BLOCK_NUM );
if( !pool ){
return 0;
}
size = sizeof( yumei_busi_t );
buf = yumei_mem_buf_malloc( pool, size );
if( !buf ){
yumei_mem_pool_free( pool );
return 0;
}
busi = buf->data;
return busi;
}
#define YUMEI_BUSI_ERROR -1
#define YUMEI_BUSI_OK 0
int yumei_busi_free( yumei_busi_t* busi )
{
if( !busi ){
return YUMEI_BUSI_ERROR;
}
yumei_mem_pool_free( busi->pool );
return YUMEI_BUSI_OK;
}
有些时候业务比较简单,一个连接仅对应一个业务或多个业务不是并行执行,这样的情况下,就不再需要业务内存池了,可以直接用连接内存池:
[cpp]
yumei_busi_t* yumei_busi_create( yumei_conn_t* conn )
{
yumei_busi_t* busi;
yumei_pool_t* pool;
yumei_mem_buf_t* buf;
int size;
pool = conn->pool;
if( !pool ){
retur 0;
}
size = sizeof( yumei_busi_t );
buf = yumei_mem_buf_malloc( pool, size );
if( !buf ){
yumei_mem_pool_free( pool );
return 0;
}
busi = buf->data;
return busi;
}
#define YUMEI_CONN_ERROR -1
#define YUMEI_CONN_OK 0
int yumei_conn_close( yumei_conn_t* conn )
{
if( !conn ){
return YUMEI_CONN_ERROR;
}
yumei_mem_pool_free( conn->pool );
return YUMEI_CONN_OK;
}
在一些通用的服务器上还会看到另一个元素:large。 这个是争对一些大内存的分配,当不清楚业务到底需要多大内存的时候,large往往是必须的,这样内存池结构就变成这样:
[cpp]
typedef struct yumei_mem_large_s yumei_mem_large_t;
struct yumei_mem_large_s
{
char *data;
int size;
yumei_mem_large_t *next;
}
struct yumei_mem_pool_s
{
int size;
char *data;
char *last;
yumei_mem_pool_t *next;
yumei_mem_pool_t *current;
yumei_mem_large_t *large;
};
对于一些特殊的业务,比如业务使用的内存大小都固定,且相近的时候,内存池就缩化成了固定大小的内存管理,其实是很简单了,这样的内存池可以绑定在连接上,且用完不用释放,留待下条连接复用,进一步节省开销。
以上是关于高并发服务器的设计--内存池的设计的主要内容,如果未能解决你的问题,请参考以下文章