May10

【转自新浪】Memcached深度分析

Author: 奶瓶  Click: 7025   Comments: 0 Category: 网络  Tag: memcached

Memcached是danga.com(运营LiveJournal的技术团队)开发的一套分布式内存对象缓存系统,用于在动态系统中减少数据库负载,提升性能。关于这个东西,相信很多人都用过,本文意在通过对memcached的实现及代码分析,获得对这个出色的开源软件更深入的了解,并可以根据我们的需要对其进行更进一步的优化。末了将通过对BSM_Memcache扩展的分析,加深对memcached的使用方式理解。

本文的部分内容可能需要比较好的数学基础作为辅助。

◎Memcached是什么

在阐述这个问题之前,我们首先要清楚它“不是什么”。很多人把它当作和SharedMemory那种形式的存储载体来使用,虽然memcached使用了同样的“Key=>Value”方式组织数据,但是它和共享内存、APC等本地缓存有非常大的区别。Memcached是分布式的,也就是说它不是本地的。它基于网络连接(当然它也可以使用localhost)方式完成服务,本身它是一个独立于应用的程序或守护进程(Daemon方式)。

Memcached使用libevent库实现网络连接服务,理论上可以处理无限多的连接,但是它和Apache不同,它更多的时候是面向稳定的持续连接的,所以它实际的并发能力是有限制的。在保守情况下memcached的最大同时连接数为200,这和Linux线程能力有关系,这个数值是可以调整的。关于libevent可以参考相关文档。 Memcached内存使用方式也和APC不同。APC是基于共享内存和MMAP的,memcachd有自己的内存分配算法和管理方式,它和共享内存没有关系,也没有共享内存的限制,通常情况下,每个memcached进程可以管理2GB的内存空间,如果需要更多的空间,可以增加进程数。 

◎Memcached适合什么场合

在很多时候,memcached都被滥用了,这当然少不了对它的抱怨。我经常在论坛上看见有人发贴,类似于“如何提高效率”,回复是“用memcached”,至于怎么用,用在哪里,用来干什么一句没有。memcached不是万能的,它也不是适用在所有场合。

Memcached是“分布式”的内存对象缓存系统,那么就是说,那些不需要“分布”的,不需要共享的,或者干脆规模小到只有一台服务器的应用,memcached不会带来任何好处,相反还会拖慢系统效率,因为网络连接同样需要资源,即使是UNIX本地连接也一样。 在我之前的测试数据中显示,memcached本地读写速度要比直接PHP内存数组慢几十倍,而APC、共享内存方式都和直接数组差不多。可见,如果只是本地级缓存,使用memcached是非常不划算的。

Memcached在很多时候都是作为数据库前端cache使用的。因为它比数据库少了很多SQL解析、磁盘操作等开销,而且它是使用内存来管理数据的,所以它可以提供比直接读取数据库更好的性能,在大型系统中,访问同样的数据是很频繁的,memcached可以大大降低数据库压力,使系统执行效率提升。另外,memcached也经常作为服务器之间数据共享的存储媒介,例如在SSO系统中保存系统单点登陆状态的数据就可以保存在memcached中,被多个应用共享。

需要注意的是,memcached使用内存管理数据,所以它是易失的,当服务器重启,或者memcached进程中止,数据便会丢失,所以memcached不能用来持久保存数据。很多人的错误理解,memcached的性能非常好,好到了内存和硬盘的对比程度,其实memcached使用内存并不会得到成百上千的读写速度提高,它的实际瓶颈在于网络连接,它和使用磁盘的数据库系统相比,好处在于它本身非常“轻”,因为没有过多的开销和直接的读写方式,它可以轻松应付非常大的数据交换量,所以经常会出现两条千兆网络带宽都满负荷了,memcached进程本身并不占用多少CPU资源的情况。

◎Memcached的工作方式

以下的部分中,读者最好能准备一份memcached的源代码。

Memcached是传统的网络服务程序,如果启动的时候使用了-d参数,它会以守护进程的方式执行。创建守护进程由daemon.c完成,这个程序只有一个daemon函数,这个函数很简单(如无特殊说明,代码以1.2.1为准):

CODE:
#include
#include
#include

int
daemon(nochdir, noclose)
    int nochdir, noclose;
{
    int fd; 

    switch (fork()) {
    case -1:
        return (-1);
    case 0: 
        break;  
    default:
        _exit(0);
    }

    if (setsid() == -1)
        return (-1);

    if (!nochdir)
        (void)chdir(”/”);

    if (!noclose && (fd = open(”/dev/null”, O_RDWR, 0)) != -1) {
        (void)dup2(fd, STDIN_FILENO);
        (void)dup2(fd, STDOUT_FILENO);
        (void)dup2(fd, STDERR_FILENO);
        if (fd > STDERR_FILENO)
            (void)close(fd);
    }
    return (0);
}

这个函数 fork 了整个进程之后,父进程就退出,接着重新定位 STDIN 、 STDOUT 、 STDERR 到空设备, daemon 就建立成功了。 

Memcached 本身的启动过程,在 memcached.c 的 main 函数中顺序如下: 

1 、调用 settings_init() 设定初始化参数
2 、从启动命令中读取参数来设置 setting 值
3 、设定 LIMIT 参数
4 、开始网络 socket 监听(如果非 socketpath 存在)( 1.2 之后支持 UDP 方式)
5 、检查用户身份( Memcached 不允许 root 身份启动)
6 、如果有 socketpath 存在,开启 UNIX 本地连接(Sock 管道)
7 、如果以 -d 方式启动,创建守护进程(如上调用 daemon 函数)
8 、初始化 item 、 event 、状态信息、 hash 、连接、 slab
9 、如设置中 managed 生效,创建 bucket 数组
10 、检查是否需要锁定内存页
11 、初始化信号、连接、删除队列
12 、如果 daemon 方式,处理进程 ID
13 、event 开始,启动过程结束, main 函数进入循环。 

在 daemon 方式中,因为 stderr 已经被定向到黑洞,所以不会反馈执行中的可见错误信息。 

memcached.c 的主循环函数是 drive_machine ,传入参数是指向当前的连接的结构指针,根据 state 成员的状态来决定动作。 

Memcached 使用一套自定义的协议完成数据交换,它的 protocol 文档可以参考: http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt

在API中,换行符号统一为\r\n

◎Memcached的内存管理方式

Memcached有一个很有特色的内存管理方式,为了提高效率,它使用预申请和分组的方式管理内存空间,而并不是每次需要写入数据的时候去malloc,删除数据的时候free一个指针。Memcached使用slab->chunk的组织方式管理内存。

1.1和1.2的slabs.c中的slab空间划分算法有一些不同,后面会分别介绍。

Slab可以理解为一个内存块,一个slab是memcached一次申请内存的最小单位,在memcached中,一个slab的大小默认为1048576字节(1MB),所以memcached都是整MB的使用内存。每一个slab被划分为若干个chunk,每个chunk里保存一个item,每个item同时包含了item结构体、key和value(注意在memcached中的value是只有字符串的)。slab按照自己的id分别组成链表,这些链表又按id挂在一个slabclass数组上,整个结构看起来有点像二维数组。slabclass的长度在1.1中是21,在1.2中是200。

slab有一个初始chunk大小,1.1中是1字节,1.2中是80字节,1.2中有一个factor值,默认为1.25

在1.1中,chunk大小表示为初始大小*2^n,n为classid,即:id为0的slab,每chunk大小1字节,id为1的slab,每chunk大小2字节,id为2的slab,每chunk大小4字节……id为20的slab,每chunk大小为1MB,就是说id为20的slab里只有一个chunk:

CODE:
void slabs_init(size_t limit) {
    int i;
    int size=1;

    mem_limit = limit;
    for(i=0; i<=POWER_LARGEST; i++, size*=2) {
        slabclass[i].size = size;
        slabclass[i].perslab = POWER_BLOCK / size;
        slabclass[i].slots = 0;
        slabclass[i].sl_curr = slabclass[i].sl_total = slabclass[i].slabs = 0;
        slabclass[i].end_page_ptr = 0;
        slabclass[i].end_page_free = 0;
        slabclass[i].slab_list = 0;
        slabclass[i].list_size = 0;
        slabclass[i].killing = 0;
    }

    /* for the test suite:  faking of how much we’ve already malloc’d */
    {
        char *t_initial_malloc = getenv(”T_MEMD_INITIAL_MALLOC”);
        if (t_initial_malloc) {
            mem_malloced = atol(getenv(”T_MEMD_INITIAL_MALLOC”));
        }
    }

    /* pre-allocate slabs by default, unless the environment variable
       for testing is set to something non-zero */
    {
        char *pre_alloc = getenv(”T_MEMD_SLABS_ALLOC”);
        if (!pre_alloc || atoi(pre_alloc)) {
            slabs_preallocate(limit / POWER_BLOCK);
        }
    }
}

在1.2中,chunk大小表示为初始大小*f^n,f为factor,在memcached.c中定义,n为classid,同时,201个头不是全部都要初始化的,因为factor可变,初始化只循环到计算出的大小达到slab大小的一半为止,而且它是从id1开始的,即:id为1的slab,每chunk大小80字节,id为2的slab,每chunk大小80*f,id为3的slab,每chunk大小80*f^2,初始化大小有一个修正值CHUNK_ALIGN_BYTES,用来保证n-byte排列 (保证结果是CHUNK_ALIGN_BYTES的整倍数)。这样,在标准情况下,memcached1.2会初始化到id40,这个slab中每个chunk大小为504692,每个slab中有两个chunk。最后,slab_init函数会在最后补足一个id41,它是整块的,也就是这个slab中只有一个1MB大的chunk:

CODE:
void slabs_init(size_t limit, double factor) {
    int i = POWER_SMALLEST – 1;
    unsigned int size = sizeof(item) + settings.chunk_size;

    /* Factor of 2.0 means use the default memcached behavior */
    if (factor == 2.0 && size < 128)
        size = 128;

    mem_limit = limit;
    memset(slabclass, 0, sizeof(slabclass));

    while (++i < POWER_LARGEST && size <= POWER_BLOCK / 2) {
        /* Make sure items are always n-byte aligned */
        if (size % CHUNK_ALIGN_BYTES)
            size += CHUNK_ALIGN_BYTES – (size % CHUNK_ALIGN_BYTES);

        slabclass[i].size = size; 
        slabclass[i].perslab = POWER_BLOCK / slabclass[i].size;
        size *= factor; 
        if (settings.verbose > 1) {
            fprintf(stderr, “slab class %3d: chunk size %6d perslab %5d\n”,
                    i, slabclass[i].size, slabclass[i].perslab);
        }       
    }

    power_largest = i;
    slabclass[power_largest].size = POWER_BLOCK;
    slabclass[power_largest].perslab = 1;

    /* for the test suite:  faking of how much we’ve already malloc’d */
    {
        char *t_initial_malloc = getenv(”T_MEMD_INITIAL_MALLOC”);
        if (t_initial_malloc) {
            mem_malloced = atol(getenv(”T_MEMD_INITIAL_MALLOC”));
        }       

    }

#ifndef DONT_PREALLOC_SLABS
    {
        char *pre_alloc = getenv(”T_MEMD_SLABS_ALLOC”);
        if (!pre_alloc || atoi(pre_alloc)) {
            slabs_preallocate(limit / POWER_BLOCK);
        }
    }
#endif
}

由上可以看出,memcached的内存分配是有冗余的,当一个slab不能被它所拥有的chunk大小整除时,slab尾部剩余的空间就被丢弃了,如id40中,两个chunk占用了1009384字节,这个slab一共有1MB,那么就有39192字节被浪费了。

Memcached使用这种方式来分配内存,是为了可以快速的通过item长度定位出slab的classid,有一点类似hash,因为item的长度是可以计算的,比如一个item的长度是300字节,在1.2中就可以得到它应该保存在id7的slab中,因为按照上面的计算方法,id6的chunk大小是252字节,id7的chunk大小是316字节,id8的chunk大小是396字节,表示所有252到316字节的item都应该保存在id7中。同理,在1.1中,也可以计算得到它出于256和512之间,应该放在chunk_size为512的id9中(32位系统)。

Memcached初始化的时候,会初始化slab(前面可以看到,在main函数中调用了slabs_init())。它会在slabs_init()中检查一个常量DONT_PREALLOC_SLABS,如果这个没有被定义,说明使用预分配内存方式初始化slab,这样在所有已经定义过的slabclass中,每一个id创建一个slab。这样就表示,1.2在默认的环境中启动进程后要分配41MB的slab空间,在这个过程里,memcached的第二个内存冗余发生了,因为有可能一个id根本没有被使用过,但是它也默认申请了一个slab,每个slab会用掉1MB内存

当一个slab用光后,又有新的item要插入这个id,那么它就会重新申请新的slab,申请新的slab时,对应id的slab链表就要增长,这个链表是成倍增长的,在函数grow_slab_list函数中,这个链的长度从1变成2,从2变成4,从4变成8……:

CODE:
static int grow_slab_list (unsigned int id) {
    slabclass_t *p = &slabclass[id];
    if (p->slabs == p->list_size) {
        size_t new_size =  p->list_size ? p->list_size * 2 : 16; 
        void *new_list = realloc(p->slab_list, new_size*sizeof(void*));
        if (new_list == 0) return 0;
        p->list_size = new_size;
        p->slab_list = new_list;
    }
    return 1;
}

在定位item时,都是使用slabs_clsid函数,传入参数为item大小,返回值为classid,由这个过程可以看出,memcached的第三个内存冗余发生在保存item的过程中,item总是小于或等于chunk大小的,当item小于chunk大小时,就又发生了空间浪费。

◎Memcached的NewHash算法

Memcached的item保存基于一个大的hash表,它的实际地址就是slab中的chunk偏移,但是它的定位是依靠对key做hash的结果,在primary_hashtable中找到的。在assoc.c和items.c中定义了所有的hash和item操作。

Memcached使用了一个叫做NewHash的算法,它的效果很好,效率也很高。1.1和1.2的NewHash有一些不同,主要的实现方式还是一样的,1.2的hash函数是经过整理优化的,适应性更好一些。

NewHash的原型参考:http://burtleburtle.net/bob/hash/evahash.html。数学家总是有点奇怪,呵呵~

为了变换方便,定义了u4和u1两种数据类型,u4就是无符号的长整形,u1就是无符号char(0-255)。

具体代码可以参考1.1和1.2源码包。

注意这里的hashtable长度,1.1和1.2也是有区别的,1.1中定义了HASHPOWER常量为20,hashtable表长为hashsize(HASHPOWER),就是4MB(hashsize是一个宏,表示1右移n位),1.2中是变量16,即hashtable表长65536:

CODE:
typedef  unsigned long  int  ub4;   /* unsigned 4-byte quantities */
typedef  unsigned       char ub1;   /* unsigned 1-byte quantities */

#define hashsize(n) ((ub4)1<<(n))
#define hashmask(n) (hashsize(n)-1)

在assoc_init()中,会对primary_hashtable做初始化,对应的hash操作包括:assoc_find()、assoc_expand()、assoc_move_next_bucket()、assoc_insert()、assoc_delete(),对应于item的读写操作。其中assoc_find()是根据key和key长寻找对应的item地址的函数(注意在C中,很多时候都是同时直接传入字符串和字符串长度,而不是在函数内部做strlen),返回的是item结构指针,它的数据地址在slab中的某个chunk上。

items.c是数据项的操作程序,每一个完整的item包括几个部分,在item_make_header()中定义为:

key:键
nkey:键长
flags:用户定义的flag(其实这个flag在memcached中没有启用)
nbytes:值长(包括换行符号\r\n)
suffix:后缀Buffer
nsuffix:后缀长

一个完整的item长度是键长+值长+后缀长+item结构大小(32字节),item操作就是根据这个长度来计算slab的classid的。

hashtable中的每一个桶上挂着一个双链表,item_init()的时候已经初始化了heads、tails、sizes三个数组为0,这三个数组的大小都为常量LARGEST_ID(默认为255,这个值需要配合factor来修改),在每次item_assoc()的时候,它会首先尝试从slab中获取一块空闲的chunk,如果没有可用的chunk,会在链表中扫描50次,以得到一个被LRU踢掉的item,将它unlink,然后将需要插入的item插入链表中。

注意item的refcount成员。item被unlink之后只是从链表上摘掉,不是立刻就被free的,只是将它放到删除队列中(item_unlink_q()函数)。

item对应一些读写操作,包括remove、update、replace,当然最重要的就是alloc操作。

item还有一个特性就是它有过期时间,这是memcached的一个很有用的特性,很多应用都是依赖于memcached的item过期,比如session存储、操作锁等。item_flush_expired()函数就是扫描表中的item,对过期的item执行unlink操作,当然这只是一个回收动作,实际上在get的时候还要进行时间判断:

CODE:
/* expires items that are more recent than the oldest_live setting. */
void item_flush_expired() {
    int i;  
    item *iter, *next;
    if (! settings.oldest_live)
        return; 
    for (i = 0; i < LARGEST_ID; i++) {
        /* The LRU is sorted in decreasing time order, and an item’s timestamp
         * is never newer than its last access time, so we only need to walk
         * back until we hit an item older than the oldest_live time.
         * The oldest_live checking will auto-expire the remaining items.
         */
        for (iter = heads[i]; iter != NULL; iter = next) { 
            if (iter->time >= settings.oldest_live) {
                next = iter->next;
                if ((iter->it_flags & ITEM_SLABBED) == 0) { 
                    item_unlink(iter);
                }       
            } else {
                /* We’ve hit the first old item. Continue to the next queue. */
                break;  
            }       
        }       
    }
}

 

CODE:
/* wrapper around assoc_find which does the lazy expiration/deletion logic */
item *get_item_notedeleted(char *key, size_t nkey, int *delete_locked) {
    item *it = assoc_find(key, nkey);
    if (delete_locked) *delete_locked = 0;
    if (it && (it->it_flags & ITEM_DELETED)) {
        /* it’s flagged as delete-locked.  let’s see if that condition
           is past due, and the 5-second delete_timer just hasn’t
           gotten to it yet… */
        if (! item_delete_lock_over(it)) {
            if (delete_locked) *delete_locked = 1;
            it = 0; 
        }       
    }
    if (it && settings.oldest_live && settings.oldest_live <= current_time &&
        it->time <= settings.oldest_live) {
        item_unlink(it);
        it = 0; 
    }
    if (it && it->exptime && it->exptime <= current_time) {
        item_unlink(it);
        it = 0; 
    }
    return it;
}

Memcached的内存管理方式是非常精巧和高效的,它很大程度上减少了直接alloc系统内存的次数,降低函数开销和内存碎片产生几率,虽然这种方式会造成一些冗余浪费,但是这种浪费在大型系统应用中是微不足道的。

◎Memcached的理论参数计算方式

影响 memcached 工作的几个参数有: 

常量REALTIME_MAXDELTA 60*60*24*30
最大30天的过期时间

conn_init()中的freetotal(=200)
最大同时连接数

常量KEY_MAX_LENGTH 250
最大键长

settings.factor(=1.25)
factor将影响chunk的步进大小

settings.maxconns(=1024)
最大软连接

settings.chunk_size(=48)
一个保守估计的key+value长度,用来生成id1中的chunk长度(1.2)。id1的chunk长度等于这个数值加上item结构体的长度(32),即默认的80字节。

常量POWER_SMALLEST 1
最小classid(1.2)

常量POWER_LARGEST 200
最大classid(1.2)

常量POWER_BLOCK 1048576
默认slab大小

常量CHUNK_ALIGN_BYTES (sizeof(void *))
保证chunk大小是这个数值的整数倍,防止越界(void *的长度在不同系统上不一样,在标准32位系统上是4)

常量ITEM_UPDATE_INTERVAL 60
队列刷新间隔

常量LARGEST_ID 255
最大item链表数(这个值不能比最大的classid小)

变量hashpower(在1.1中是常量HASHPOWER)
决定hashtable的大小

根据上面介绍的内容及参数设定,可以计算出的一些结果:

1、在memcached中可以保存的item个数是没有软件上限的,之前我的100万的说法是错误的。
2、假设NewHash算法碰撞均匀,查找item的循环次数是item总数除以hashtable大小(由hashpower决定),是线性的。
3、Memcached限制了可以接受的最大item是1MB,大于1MB的数据不予理会。
4、Memcached的空间利用率和数据特性有很大的关系,又与DONT_PREALLOC_SLABS常量有关。 在最差情况下,有198个slab会被浪费(所有item都集中在一个slab中,199个id全部分配满)。 

◎Memcached的定长优化

根据上面几节的描述,多少对memcached有了一个比较深入的认识。在深入认识的基础上才好对它进行优化。

Memcached本身是为变长数据设计的,根据数据特性,可以说它是“面向大众”的设计,但是很多时候,我们的数据并不是这样的“普遍”,典型的情况中,一种是非均匀分布,即数据长度集中在几个区域内(如保存用户 Session);另一种更极端的状态是等长数据(如定长键值,定长数据,多见于访问、在线统计或执行锁)。

这里主要研究一下定长数据的优化方案(1.2),集中分布的变长数据仅供参考,实现起来也很容易。

解决定长数据,首先需要解决的是slab的分配问题,第一个需要确认的是我们不需要那么多不同chunk长度的slab,为了最大限度地利用资源,最好chunk和item等长,所以首先要计算item长度。

在之前已经有了计算item长度的算法,需要注意的是,除了字符串长度外,还要加上item结构的长度32字节。

假设我们已经计算出需要保存200字节的等长数据。

接下来是要修改slab的classid和chunk长度的关系。在原始版本中,chunk长度和classid是有对应关系的,现在如果把所有的chunk都定为200个字节,那么这个关系就不存在了,我们需要重新确定这二者的关系。一种方法是,整个存储结构只使用一个固定的id,即只使用199个槽中的1个,在这种条件下,就一定要定义DONT_PREALLOC_SLABS来避免另外的预分配浪费。另一种方法是建立一个hash关系,来从item确定classid,不能使用长度来做键,可以使用key的NewHash结果等不定数据,或者直接根据key来做hash(定长数据的key也一定等长)。这里简单起见,选择第一种方法,这种方法的不足之处在于只使用一个id,在数据量非常大的情况下,slab链会很长(因为所有数据都挤在一条链上了),遍历起来的代价比较高。

前面介绍了三种空间冗余,设置chunk长度等于item长度,解决了第一种空间浪费问题,不预申请空间解决了第二种空间浪费问题,那么对于第一种问题(slab内剩余)如何解决呢,这就需要修改POWER_BLOCK常量,使得每一个slab大小正好等于chunk长度的整数倍,这样一个slab就可以正好划分成n个chunk。这个数值应该比较接近1MB,过大的话同样会造成冗余,过小的话会造成次数过多的alloc,根据chunk长度为200,选择1000000作为POWER_BLOCK的值,这样一个slab就是100万字节,不是1048576。三个冗余问题都解决了,空间利用率会大大提升。

修改 slabs_clsid 函数,让它直接返回一个定值(比如 1 ):

CODE:
unsigned int slabs_clsid(size_t size) {
        return 1;
}

修改slabs_init函数,去掉循环创建所有classid属性的部分,直接添加slabclass[1]:

CODE:
slabclass[1].size = 200;                //每chunk200字节
slabclass[1].perslab = 5000;        //1000000/200

◎Memcached客户端

Memcached是一个服务程序,使用的时候可以根据它的协议,连接到memcached服务器上,发送命令给服务进程,就可以操作上面的数据。为了方便使用,memcached有很多个客户端程序可以使用,对应于各种语言,有各种语言的客户端。基于C语言的有libmemcache、APR_Memcache;基于Perl的有Cache::Memcached;另外还有Python、Ruby、Java、C#等语言的支持。PHP的客户端是最多的,不光有mcache和PECL memcache两个扩展,还有大把的由PHP编写的封装类,下面介绍一下在PHP中使用memcached的方法:

mcache扩展是基于libmemcache再封装的。libmemcache一直没有发布stable版本,目前版本是1.4.0-rc2,可以在这里找到。libmemcache有一个很不好的特性,就是会向stderr写很多错误信息,一般的,作为lib使用的时候,stderr一般都会被定向到其它地方,比如Apache的错误日志,而且libmemcache会自杀,可能会导致异常,不过它的性能还是很好的。

mcache扩展最后更新到1.2.0-beta10,作者大概是离职了,不光停止更新,连网站也打不开了(~_~),只能到其它地方去获取这个不负责的扩展了。解压后安装方法如常:phpize & configure & make & make install,一定要先安装libmemcache。使用这个扩展很简单:

CODE:
$mc memcache();    // 创建一个memcache连接对象,注意这里不是用new!
$mc->add_server(‘localhost’11211);    // 添加一个服务进程
$mc->add_server(‘localhost’11212);    // 添加第二个服务进程
$mc->set(‘key1′‘Hello’);    // 写入key1 => Hello
$mc->set(‘key2′‘World’10);    // 写入key2 => World,10秒过期
$mc->set(‘arr1′, array(‘Hello’‘World’));    // 写入一个数组
$key1 $mc->get(‘key1′);    // 获取’key1′的值,赋给$key1
$key2 $mc->get(‘key2′);    // 获取’key2′的值,赋给$key2,如果超过10秒,就取不到了
$arr1 $mc->get(‘arr1′);    // 获取’arr1′数组
$mc->delete(‘arr1′);    // 删除’arr1′
$mc->flush_all();    // 删掉所有数据
$stats $mc->stats();    // 获取服务器信息
var_dump($stats);    // 服务器信息是一个数组
?>

这个扩展的好处是可以很方便地实现分布式存储和负载均衡,因为它可以添加多个服务地址,数据在保存的时候是会根据hash结果定位到某台服务器上的,这也是libmemcache的特性。libmemcache支持集中hash方式,包括CRC32、ELF和Perl hash。

PECL memcache是PECL发布的扩展,目前最新版本是2.1.0,可以在pecl网站得到。memcache扩展的使用方法可以在新一些的PHP手册中找到,它和mcache很像,真的很像:

CODE:

$memcache = new Memcache;
$memcache->connect(‘localhost’11211) or die (“Could not connect”);

$version $memcache->getVersion();
echo 
“Server’s version: ”.$version.“n”;

$tmp_object = new stdClass;
$tmp_object->str_attr ‘test’;
$tmp_object->int_attr 123;

$memcache->set(‘key’$tmp_objectfalse10) or die (“Failed to save data at the server”);
echo 
“Store data in the cache (data will expire in 10 seconds)n”;

$get_result $memcache->get(‘key’);
echo 
“Data from the cache:n”;

var_dump($get_result);

?>

这个扩展是使用php的stream直接连接memcached服务器并通过socket发送命令的。它不像libmemcache那样完善,也不支持add_server这种分布操作,但是因为它不依赖其它的外界程序,兼容性要好一些,也比较稳定。至于效率,差别不是很大。

另外,有很多的PHP class可以使用,比如MemcacheClient.inc.php,phpclasses.org上可以找到很多,一般都是对perl client API的再封装,使用方式很像。

◎BSM_Memcache

从C client来说,APR_Memcache是一个很成熟很稳定的client程序,支持线程锁和原子级操作,保证运行的稳定性。不过它是基于APR的(APR将在最后一节介绍),没有libmemcache的应用范围广,目前也没有很多基于它开发的程序,现有的多是一些Apache Module,因为它不能脱离APR环境运行。但是APR倒是可以脱离Apache单独安装的,在APR网站上可以下载APR和APR-util,不需要有Apache,可以直接安装,而且它是跨平台的。

BSM_Memcache是我在BS.Magic项目中开发的一个基于APR_Memcache的PHP扩展,说起来有点拗口,至少它把APR扯进了PHP扩展中。这个程序很简单,也没做太多的功能,只是一种形式的尝试,它支持服务器分组。

和mcache扩展支持多服务器分布存储不同,BSM_Memcache支持多组服务器,每一组内的服务器还是按照hash方式来分布保存数据,但是两个组中保存的数据是一样的,也就是实现了热备,它不会因为一台服务器发生单点故障导致数据无法获取,除非所有的服务器组都损坏(例如机房停电)。当然实现这个功能的代价就是性能上的牺牲,在每次添加删除数据的时候都要扫描所有的组,在get数据的时候会随机选择一组服务器开始轮询,一直到找到数据为止,正常情况下一次就可以获取得到。

BSM_Memcache只支持这几个函数:

CODE:
zend_function_entry bsm_memcache_functions[] =
{
    PHP_FE(mc_get,          NULL)
    PHP_FE(mc_set,          NULL)
    PHP_FE(mc_del,          NULL)
    PHP_FE(mc_add_group,    NULL)
    PHP_FE(mc_add_server,   NULL)
    PHP_FE(mc_shutdown,     NULL)
    {NULL, NULL, NULL}
};

mc_add_group函数返回一个整形(其实应该是一个object,我偷懒了~_~)作为组ID,mc_add_server的时候要提供两个参数,一个是组ID,一个是服务器地址(ADDRORT)。

CODE:
/**
* Add a server group
*/
PHP_FUNCTION(mc_add_group)
{
    apr_int32_t group_id;
    apr_status_t rv;

    if (0 != ZEND_NUM_ARGS())
    {
        WRONG_PARAM_COUNT;
        RETURN_NULL();
    }

    group_id = free_group_id();
    if (-1 == group_id)
    {
        RETURN_FALSE;
    }

    apr_memcache_t *mc;
    rv = apr_memcache_create(p, MAX_G_SERVER, 0, &mc);

    add_group(group_id, mc);

    RETURN_DOUBLE(group_id);
}

 

CODE:
/**
* Add a server into group
*/
PHP_FUNCTION(mc_add_server)
{
    apr_status_t rv;
    apr_int32_t group_id;
    double g;
    char *srv_str;
    int srv_str_l;

    if (2 != ZEND_NUM_ARGS())
    {
        WRONG_PARAM_COUNT;
    }

    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, “ds”, &g, &srv_str, &srv_str_l) == FAILURE)
    {
        RETURN_FALSE;
    }

    group_id = (apr_int32_t) g;

    if (-1 == is_validate_group(group_id))
    {
        RETURN_FALSE;
    }

    char *host, *scope;
    apr_port_t port;

    rv = apr_parse_addr_port(&host, &scope, &port, srv_str, p);
    if (APR_SUCCESS == rv)
    {
        // Create this server object
        apr_memcache_server_t *st;
        rv = apr_memcache_server_create(p, host, port, 0, 64, 1024, 600, &st);
        if (APR_SUCCESS == rv)
        {
            if (NULL == mc_groups[group_id])
            {
                RETURN_FALSE;
            }

            // Add server
            rv = apr_memcache_add_server(mc_groups[group_id], st);

            if (APR_SUCCESS == rv)
            {
                RETURN_TRUE;
            }
        }
    }

    RETURN_FALSE;
}

在set和del数据的时候,要循环所有的组:

CODE:
/**
* Store item into all groups
*/
PHP_FUNCTION(mc_set)
{
    char *key, *value;
    int key_l, value_l;
    double ttl = 0;
    double set_ct = 0;

    if (2 != ZEND_NUM_ARGS())
    {
        WRONG_PARAM_COUNT;
    }

    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, “ss|d”, &key, &key_l, &value, &value_l, ttl) == FAILURE)
    {
        RETURN_FALSE;
    }

    // Write data into every object
    apr_int32_t i = 0;
    if (ttl < 0)
    {
        ttl = 0;
    }

    apr_status_t rv;

    for (i = 0; i < MAX_GROUP; i++)
    {
        if (0 == is_validate_group(i))
        {
            // Write it!
            rv = apr_memcache_add(mc_groups[i], key, value, value_l, (apr_uint32_t) ttl, 0);
            if (APR_SUCCESS == rv)
            {
                set_ct++;
            }
        }
    }

    RETURN_DOUBLE(set_ct);
}

在mc_get中,首先要随机选择一个组,然后从这个组开始轮询:

CODE:
/**
* Fetch a item from a random group
*/
PHP_FUNCTION(mc_get)
{               
    char *key, *value = NULL;
    int key_l;
    apr_size_t value_l;

    if (1 != ZEND_NUM_ARGS())
    {
        WRONG_PARAM_COUNT;
    }

    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, “s”, &key, &key_l) == FAILURE)
    {
        RETURN_MULL();
    }
    
    // I will try …
    // Random read
    apr_int32_t curr_group_id = random_group();
    apr_int32_t i = 0;
    apr_int32_t try = 0;
    apr_uint32_t flag;
    apr_memcache_t *oper;
    apr_status_t rv;

    for (i = 0; i < MAX_GROUP; i++)
    {
        try = i + curr_group_id;
        try = try % MAX_GROUP;
        if (0 == is_validate_group(try))
        {
            // Get a value
            oper = mc_groups[try];
            rv = apr_memcache_getp(mc_groups[try], p, (const char *) key, &value, &value_l, 0);
            if (APR_SUCCESS == rv)
            {
                RETURN_STRING(value, 1);
            }
        }
    }

    RETURN_FALSE;
}

 

CODE:
/**
* Random group id
* For mc_get()
*/
apr_int32_t random_group()
{
    struct timeval tv;
    struct timezone tz;
    int usec;

    gettimeofday(&tv, &tz);

    usec = tv.tv_usec;

    int curr = usec % count_group();

    return (apr_int32_t) curr;
}

BSM_Memcache的使用方式和其它的client类似:

CODE:
$g1 mc_add_group();    // 添加第一个组
$g2 mc_add_group();    // 添加第二个组
mc_add_server($g1‘localhost:11211′);    // 在第一个组中添加第一台服务器
mc_add_server($g1‘localhost:11212′);    // 在第一个组中添加第二台服务器
mc_add_server($g2‘10.0.0.16:11211′);    // 在第二个组中添加第一台服务器
mc_add_server($g2‘10.0.0.17:11211′);    // 在第二个组中添加第二台服务器

mc_set(‘key’‘Hello’);    // 写入数据
$key mc_get(‘key’);    // 读出数据
mc_del(‘key’);    // 删除数据
mc_shutdown();    // 关闭所有组
?>

APR_Memcache的相关资料可以在这里找到,BSM_Memcache可以在本站下载。

◎APR环境介绍

APR的全称:Apache Portable Runtime。它是Apache软件基金会创建并维持的一套跨平台的C语言库。它从Apache httpd1.x中抽取出来并独立于httpd之外,Apache httpd2.x就是建立在APR上。APR提供了很多方便的API接口可供使用,包括如内存池、字符串操作、网络、数组、hash表等实用的功能。开发Apache2 Module要接触很多APR函数,当然APR可以独立安装独立使用,可以用来写自己的应用程序,不一定是Apache httpd的相关开发。

◎后记

这是我在农历丙戌年(我的本命年)的最后一篇文章,由于Memcached的内涵很多,仓促整理一定有很多遗漏和错误。感谢新浪网提供的研究机会,感谢部门同事的帮助。

NP博士 02-13-2007 

原文发表于:http://www.54np.com/
转载请注明

May9

The C10K Problem学习笔记

Author: leeon  Click: 8263   Comments: 0 Category: 架构  Tag: c10k
什么叫做C10K?
答:网络服务在处理数以万计的客户端连接时,往往出现效率低下甚至完全瘫痪,这被称为 C10K问题。随着互联网的迅速发展,越来越多的网络服务开始面临C10K问题,作为大型网站的开发人员有必要对C10K问题有一定的了解。

HTTP请求中的连结策略:
主要有两方面的策略:
1.应用软件以何种方式和操作系统合作,获取I/O事件并调度多个socket上的I/O操作。包括: 阻塞I/O、非阻塞I/O、异步I/O。
2. 应用软件以何种方式处理任务和线程/进程的关系。包括: 每任务1进程、每任务1线 程、单线程、多任务共享线程池以及一些更复杂的变种方案。

什么叫做边缘触发(edge trigger)?
答:边缘触发是指每当状态变化时发生一个io事件。

什么叫做条件触发level trigger)?
答:条件触发是只要满足条件就发生一个io事件。

select操作属于条件触发

I/O框架

以下所列的为几个包装好的库,它们概要了几中常见的技巧,并且可以使你的代码与具体操作 系统隔离,从而具有更好的移植性。

  • ACE, 一个重量级的C++ I/O框架,用面向对象实现了一些I/O策略和其它有用的东西,特别的, 它的Reactor是用OO方式处理非阻塞I/O,而Proactor是用OO方式处理异步I/O的( In particular, his Reactor is an OO way of doing nonblocking I/O, and Proactor is an OO way of doing asynchronous I/O).
  • ASIO 一个C++的I/O框架,逐渐成为Boost库的一部分。it's like ACE updated for the STL era。
  • libevent 由Niels Provos用C编写的一个轻量级的I/O框架。它支持kqueue和select,并且很 快就可以支持poll和epoll(翻译此文时已经支持)。我想它应该是只采用了水平触发机制,该机制 有好处当然也有不好的地方。Niels给出了一张图 来说明时间和连接数目在处理一个事件上的功能,从图上可以看出kqueue和sys_epoll明显胜出。
  • 我本人也尝试过轻量级的框架(很可惜没有维持至今):
    • Poller 是一个轻量级的C++ I/O框架,它使用任何一种准备就绪API(poll, select, /dev/poll, kqueue, sigio)实现水平触发准备就绪API。以其它不同的API为基准 ,Poller的性能 好得多。该链接文档的下面一部分说明了如何使用这些准备就绪API。
    • rn 是一个轻量级的C I/O框架,也是我继Poller后的第二个框架。该框架可以很容易的被用 于商业应用中,也容易的适用于非C++应用中。它如今已经在几个商业产品中使用。
  • Matt Welsh在2000年四月关于在构建服务器方面如何平衡工作线程和事件驱动技术的使用写了 一篇论文,在该论文中描述了他自己的Sandstorm I/O框架。
  • Cory Nelson's Scale! library - 一个Windows下的异步套接字,文件和管道的库。

I/O Strategies

网络软件设计者往往有很多种选择,以下列出一些:

  • 是否处理多个I/O?如何处理在单一线程中的多个I/O调用?
    • 不处理,从头到尾使用阻塞和同步I/O调用,可以使用多线程或多进程来达到并发效果。
    • 使用非阻塞调用(如在一个设置O_NONBLOCK选项的socket上使用write)读取I/O,当I/O完 成时发出通知(如poll,/dev/poll)从而开始下一个I/O。这种主要使用在网络I/O上,而不是磁盘的I/O上。
    • 使用异步调用(如aio_write())读取I/O,当I/O完成时会发出通知(如信号或者完成端口),可以同时使用在网络I/O和磁盘I/O上。
  • 如何控制对每个客户的服务?
    • 对每个客户使用一个进程(经典的Unix方法,自从1980年一直使用)
    • 一个系统级的线程处理多个客户,每个客户是如下一种:
      • a user-level thread (e.g. GNU state threads, classic Java with green threads)
      • a state machine (a bit esoteric, but popular in some circles; my favorite)
      • a continuation (a bit esoteric, but popular in some circles)
    • o一个系统级的线程对应一个客户端(e.g. classic Java with native threads)
    • 一个系统级的线程对应每一个活动的客户端(e.g. Tomcat with apache front end; NT完成端口; 线程池)
  • 是否使用标准的操作系统服务,还是把一些代码放入内核中(如自定义驱动,内核模块,VxD)。

下面的五种方式应该是最常用的了。

  1. 一个线程服务多个客户端,使用非阻塞I/O和水平触发的就绪通知
  2. 一个线程服务多个客户端,使用非阻塞I/O和就绪改变时通知
  3. 一个服务线程服务多个客户端,使用异步I/O
  4. 一个服务线程服务一个客户端,使用阻塞I/O
  5. 把服务代码编译进内核

1. 一个线程服务多个客户端,使用非阻塞I/O和水平触发的就绪通知

...把网络句柄设置为非阻塞模型,然后使用select()或poll()来告知哪个句柄已有数据在等待 处理。此模型是最传统的,在此模型下,由内核告知你某个文件描述符是否准备好,是否已经完 成你的任务自从上次内核告知已准备好以来(“水平触发”这个名字来源计算机硬件设计,与其 相对的是“边缘触发”,Jonathon Lemon在它的关于kqueue() 的论文中介绍了这两个术语)。

注意:牢记内核的就绪通知仅仅只是个提示,当你试图从一个文件描述符读取数据时,该文件 描述符可能并没有准备好。这就是为什么需要在使用就绪通知的时候使用非阻塞模型的原因。

一个重要的瓶颈是read()或sendfile()从磁盘块读取时,如果该页当前并不在内存中。设置磁 盘文件描述符为非阻塞没有任何影响。同样的问题也发生在内存映射磁盘文件中。首先一个服务 需要磁盘I/O时,进程块和所有的客户端都必须等待,因此最初的非线程的性能就被消耗了。
这也是异步I/O的目的,当然仅限于没有AIO的系统。处理磁盘I/O的工作线程或工作进程也可能遭遇此 瓶颈。一条途径就是使用内存映射文件,如果mincore()指明I/O必需的话,那么要求一个工作线 程来完成此I/O,然后继续处理网络事件。Jef Poskanzer提到Pai,Druschel和Zwaenepoel的 Flash web服务器使用了这个方法,并且他们就此在 Usenix'99上做了一个演讲,看上去就好像 FreeBSD和Solaris 中提供了mincore()一样,但是它并不是Single Unix Specification的一部分,在Linux的2.3.51 的内核中提供了该方法,感谢Chuck Lever。

在2003.11的 freebsd-hackers list中,Vivek Pei上报了一个不错的成果,他们利用系统剖析 工具剖析它们的Flash Web服务器,然后再攻击其瓶颈。其中找到的一个瓶颈就是mincore(猜测 毕竟不是好办法),另外一个就是sendfile在磁盘块访问时。他们修改了sendfile(),当需要读 取的页不在内存中时则返回类似EWOULDBLOCK的值,从而提高了性能。The end result of their optimizations is a SpecWeb99 score of about 800 on a 1GHZ/1GB FreeBSD box, which is better than anything on file at spec.org.

在非阻塞套接字的集合中,关于单一线程是如何告知哪个套接字是准备就绪的,以下列出了几 种方法:

  • 传统的select()
    遗憾的是,select()受限于FD_SETSIZE个句柄。该限制被编译进了标准库和用户程序(有些 版本的C library允许你在用户程序编译时放宽该限制)。

    See Poller_select (cc, h) for an example of how to use select() interchangeably with other readiness notification schemes.

  • 传统的poll()
    poll()虽然没有文件描述符个数的硬编码限制,但是当有数千个时速度就会变得很慢,因为 大多数的文件描述符在某个时间是空闲的,彻底扫描数千个描述符是需要花费一定时间的。

    有些操作系统(如Solaris 8)通过使用了poll hinting技术改进了poll(),该技术由Niels Provos在1999年实现并利用基准测试程序测试过。

    See Poller_poll (cc, h, benchmarks) for an example of how to use poll() interchangeably with other readiness notification schemes.

  • /dev/poll
    这是在Solaris中被推荐的代替poll的方法。

    /dev/poll的背后思想就是利用poll()在大部分的调用时使用相同的参数。使用/dev/poll时 ,首先打开/dev/poll得到文件描述符,然后把你关心的文件描述符写入到/dev/poll的描述符, 然后你就可以从/dev/poll的描述符中读取到已就绪的文件描述符。

    /dev/poll 在Solaris 7(see patchid 106541) 中就已经存在,不过在Solaris 8 中才公开现身。在750个客户端的情况下,this has 10% of the overhead of poll()。

    关于/dev/poll在Linux上有多种不同的尝试实现,但是没有一种可以和epoll相比,不推荐在 Linux上使用/dev/poll。

    See Poller_devpoll (cc, h benchmarks ) for an example of how to use /dev/poll interchangeably with many other readiness notification schemes. (Caution - the example is for Linux /dev/poll, might not work right on Solaris.)

  • kqueue()
    这是在FreeBSD系统上推荐使用的代替poll的方法(and, soon, NetBSD).

    kqueue()即可以水平触发,也可以边缘触发,具体请看下面.

2. 一个线程服务多个客户端,使用非阻塞I/O和就绪改变时通知

Readiness change notification(或边缘触发就绪通知)的意思就是当你给内核一个文件描述 符,一段时间后,如果该文件描述符从没有就绪到已经准备就绪,那么内核就会发出通知,告知 该文件描述符已经就绪,并且不会再对该描述符发出类似的就绪通知直到你在描述符上进行一些 操作使得该描述符不再就绪(如直到在send,recv或者accept等调用上遇到EWOULDBLOCK错误,或 者发送/接收了少于需要的字节数)。

当使用Readiness change notification时,必须准备好处理乱真事件,因为最常见的实现是只 要接收到任何数据包都发出就绪信号,而不管文件描述符是否准备就绪。

这是水平触发的就绪通知的相对应的机制。It's a bit less forgiving of programming mistakes, since if you miss just one event, the connection that event was for gets stuck forever. 然而,我发现edge-triggered readiness notification可以使编写带OpenSSL的 非阻塞客户端更简单,可以试下。

[Banga, Mogul, Drusha '99]详细描述了这种模型.

有几种APIs可以使得应用程序获得“文件描述符已就绪”的通知:

  • kqueue() 这是在FreeBSD系统上推荐使用边缘触发的方法 (and, soon, NetBSD).

    FreeBSD 4.3及以后版本,NetBSD(2002.10)都支持 kqueue()/kevent(), 支持边沿触发和水平触发(请查看Jonathan Lemon 的网页和他的BSDCon 2000关于kqueue的论文)。

    就像/dev/poll一样,你分配一个监听对象,不过不是打开文件/dev/poll,而是调用kqueue ()来获得。需要改变你所监听的事件或者获得当前事件的列表,可以在kqueue()返回的描述符上 调用kevent()来达到目的。它不仅可以监听套接字,还可以监听普通的文件的就绪,信号和I/O完 成的事件也可以.

    Note: 在2000.10,FreeBSD的线程库和kqueue()并不能一起工作得很好,当kqueue()阻塞时, 那么整个进程都将会阻塞,而不仅仅是调用kqueue()的线程。

    See Poller_kqueue (cc, h, benchmarks) for an example of how to use kqueue() interchangeably with many other readiness notification schemes.

    使用kqueue()的例程和库:

    • PyKQueue -- 一个Python的kqueue()库.
    • Ronald F.Guilmette的echo的服务器例程; 另外可以查看他在 2000.9.28在freebsd 上发表的帖子。

  • epoll
    这是Linux 2.6的内核中推荐使用的边沿触发poll.

    2001.7.11, Davide Libenzi提议了一个实时信号的可选方法,他称之为/dev/epoll< /a>, 该方法类似与实时信号就绪通知机制,但是结合了其它更多的事件,从而在大多数的事件获取上拥有更高的效率。

    epoll在将它的接口从一个/dev下的指定文件改变为系统调用sys_epoll后就合并到2.5版本的 Linux内核开发树中,另外也提供了一个为2.4老版本的内核可以使用epoll的补丁。

    unifying epoll, aio, 2002 年万圣节前夕的Linux内核邮件列表就统一epoll,aio和其它的event sources 展开了很久的争论,it may yet happen,but Davide is concentrating on firming up epoll in general first.

  • Polyakov's kevent (Linux 2.6+) 的最后新闻:2006.2.9和2006.7.9,Evgeniy Polyakov发表了融合epoll和 aio的补丁,他的目标是支持网络AIO. See:
    • the LWN article about kevent
    • his July announcement
    • his kevent page
    • his naio page
    • some recent discussion

  • Drepper的最新网络接口 (proposal for Linux 2.6+)
    在2006 OLS上,Ulrich Drepper提议了一种最新的高速异步网络API. See:
    • his paper, "The Need for Asynchronous, Zero-Copy Network I/O"
    • his slides
    • LWN article from July 22

  • Realtime Signals实时信号
    Linux2.4内核中推荐使用的边沿触发poll.

    2.4的linux内核可以通过实时信号来分派套接字事件,示例如下:

    /* Mask off SIGIO and the signal you want to use. */ sigemptyset(&sigset); sigaddset(&sigset, signum); sigaddset(&sigset, SIGIO); sigprocmask(SIG_BLOCK, &m_sigset, NULL); /* For each file descriptor, invoke F_SETOWN, F_SETSIG, and set O_ASYNC. */ fcntl(fd, F_SETOWN, (int) getpid()); fcntl(fd, F_SETSIG, signum); flags = fcntl(fd, F_GETFL); flags |= O_NONBLOCK|O_ASYNC; fcntl(fd, F_SETFL, flags); 
    当正常的I/O函数如read()或write()完成时,发送信号。要使用该段的话,在外层循环中编写 一个普通的poll(),在循环里面,当poll()处理完所有的描述符后,进入 sigwaitinfo()循环。 如果sigwaitinfo()或sigtimedwait()返回了实时信号,那么siginfo.si_fd和 siginfo_si_band给出的信息和调用poll()后pollfd.fd和pollfd.revents的几乎一样。如果你处 理该I/O,那么就继续调用sigwaitinfo()。
    如果sigwaitinfo()返回了传统的SIGIO,那么信号队列溢出了,你必须通过临时 改变信号处理 程序为SIG_DFL来刷新信号队列,然后返回到外层的poll()循环。

    See Poller_sigio (cc, h) for an example of how to use rtsignals interchangeably with many other readiness notification schemes.

    See Zach Brown's phhttpd 示例代码来如何直接使用这些特点. (Or don't; phhttpd is a bit hard to figure out...)

    [Provos, Lever, and Tweedie 2000] 描述了最新的phhttp的基准测试,使用了不同的sigtimewait()和sigtimedwait4(),这些调用可以使你只用一次调用便获得多个信号。 有趣的是,sigtimedwait4()的主要好处是它允许应用程序测量系统负载(so it could behave appropriately)(poll()也提供了同样的系统负载 测量)。

  • Signal-per-fd
    Signal-per-fd是由Chandra和Mosberger提出的对实时信号的一种改进,它可以减少甚至削除实 时信号的溢出通过oalescing redundant events。然而是它的性能并没有epoll好. 论文(www.hpl.hp.com/techreports/2000/HPL-2000-174.html) 比较了它和select(),/dev/poll的性能.

    Vitaly Luban在2001.5.18公布了一个实现Signal-per-fd的补丁; 授权见www.luban.org/GPL/gpl.html. (到2001.9,在很重的负载情况下仍然存在稳定性问题,利用dkftpbench测试在4500个用户时将引发问题.

    See Poller_sigfd (cc, h) for an example of how to use signal-per-fd interchangeably with many other readiness notification schemes.

3. 一个服务线程服务多个客户端,使用异步I/O

该方法目前还没有在Unix上普遍的使用,可能因为很少的操作系统支持异步I/O,或者因为它需 要重新修改应用程序(rethinking your applications)。 在标准Unix下,异步I/O是由"aio_"接口 提供的,它把一个信号和值与每一个I/O操作关联起来。信号和其值的队列被有效地分配到用户的 进程上。异步I/O是POSIX 1003.1b实时标准的扩展,也属于Single Unix Specification,version 2.

AIO使用的是边缘触发的完成时通知,例如,当一个操作完成时信号就被加入队列(也可以使用 水平触发的完成时通知,通过调用aio_suspend()即可, 不过我想很少人会这么做).

glibc 2.1和后续版本提供了一个普通的实现,仅仅是为了兼容标准,而不是为了获得性能上的提高。

Ben LaHaise编写的Linux AIO实现合并到了2.5.32的内核中,它并没有采用内核线程,而是使 用了一个高效的underlying api,但是目前它还不支持套接字(2.4内核也有了AIO的补丁,不过 2.5/2.6的实现有一定程序上的不同)。更多信息如下:

  • The page "Kernel Asynchronous I/O (AIO) Support for Linux" which tries to tie together all info about the 2.6 kernel's implementation of AIO (posted 16 Sept 2003)
  • Round 3: aio vs /dev/epoll by Benjamin C.R. LaHaise (presented at 2002 OLS)
  • Asynchronous I/O Suport in Linux 2.5, by Bhattacharya, Pratt, Pulaverty, and Morgan, IBM; presented at OLS '2003
  • Design Notes on Asynchronous I/O (aio) for Linux by Suparna Bhattacharya -- compares Ben's AIO with SGI's KAIO and a few other AIO projects
  • Linux AIO home page - Ben's preliminary patches, mailing list, etc.
  • linux-aio mailing list archives
  • libaio-oracle - library implementing standard Posix AIO on top of libaio. First mentioned by Joel Becker on 18 Apr 2003.

Suparma建议先看看AIO的API.

RedHat AS和Suse SLES都在2.4的内核中提供了高性能的实现,与2.6的内核实现相似,但并不完全一样。

2006.2,在网络AIO有了一个新的尝试,具体请看Evgeniy Polyakov的基于kevent的AIO.

1999, SGI为Linux实现了一个高速的AIO,在到1.1版本时,据说可以很好的工作于磁盘I/O和网 络套接字,且使用了内核线程。目前该实现依然对那些不能等待Ben的AIO套接字支持的人来说是 很有用的。

O'Reilly 的"POSIX.4: Programming for the Real World"一书对aio做了很好的介绍.

这里 有一个指南介绍了早期的非标准的aio实现,可以看看,但是请记住你得把"aioread"转换为"aio_read"。

注意AIO并没有提供无阻塞的为磁盘I/O打开文件的方法,如果你在意因打开磁盘文件而引起 sleep的话,Linus建议 你在另外一个线程中调用open()而不是把希望寄托在对aio_open()系统调用上。

在Windows下,异步I/O与术语"重叠I/O"和"IOCP"(I/O Completion Port,I/O完成端口)有一定联系。Microsoft的IOCP结合了 先前的如异步I/O(如aio_write)的技术,把事件完成的通知进行排队(就像使用了aio_sigevent字段的aio_write),并且它 为了保持单一IOCP线程的数量从而阻止了一部分请求。(Microsoft's IOCP combines techniques from the prior art like asynchronous I/O (like aio_write) and queued completion notification (like when using the aio_sigevent field with aio_write) with a new idea of holding back some requests to try to keep the number of running threads associated with a single IOCP constant.) 更多信息请看 Mark russinovich在sysinternals.com上的文章 Inside I/O Completion Ports, Jeffrey Richter的书"Programming Server-Side Applications for Microsoft Windows 2000" (Amazon, MSPress), U.S. patent #06223207, or MSDN.

4. 一个服务线程服务一个客户端,使用阻塞I/O

... 让read()和write()阻塞. 这样不好的地方在于需要为每个客户端使用一个完整的栈,从而比较浪费内存。 许多操作系统仍在处理数百个线程时存在一定的问题。如果每个线程使用2MB的栈,那么当你在32位的机器上运行 512(2^30 / 2^21=512)个线程时,你就会用光所有的1GB的用户可访问虚拟内存(Linux也是一样运行在x86上的)。 你可以减小每个线程所拥有的栈内存大小,但是由于大部分线程库在一旦线程创建后就不能增大线程栈大小,所以这样做 就意味着你必须使你的程序最小程度地使用内存。当然你也可以把你的程序运行在64位的处理器上去。

Linux,FreeBSD和Solaris系统的线程库一直在更新,64位的处理器也已经开始在大部分的用户中所使用。 也许在不远的将来,这些喜欢使用一个线程来服务一个客户端的人也有能力服务于10000个客户了。 但是在目前,如果你想支持更多的客户,你最好还是使用其它的方法。

For an unabashedly pro-thread viewpoint, see Why Events Are A Bad Idea (for High-concurrency Servers) by von Behren, Condit, and Brewer, UCB, presented at HotOS IX. Anyone from the anti-thread camp care to point out a paper that rebuts this one? :-)

LinuxThreads

LinuxTheads 是标准Linux线程库的命名。 它从glibc2.0开始已经集成在glibc库中,并且高度兼容Posix标准,不过在性能和信号的支持度上稍逊一筹。

NGPT: Next Generation Posix Threads for Linux下一代LinuxPosix线程

NGPT是一个由IBM发起的项目,其目的是提供更好的Posix兼容的Linux线程支持。 现在已到2.2稳定版,并且运行良好...但是NGPT team 公布 他们正在把NGPT的代码基改为support-only模式,因为他们觉得这才是支持社区长久运行的最好的方式。 NGPT小组将继续改进Linux的线程支持,但主要关注NPTL方面。 (Kudos to the NGPT team for their good work and the graceful way they conceded to NPTL.)

NPTL: Native Posix Thread Library for Linux(Linux本地Posix线程库)

NPTL是由 Ulrich Drepper ( glibc的主要维护人员)和 Ingo Molnar发起的项目,目的是提供world-class的Posix Linux线程支持。

2003.10.5,NPTL作为一个add-on目录(就像linuxthreads一样)被合并到glibc的cvs树中,所以很有可能随glibc的下一次release而 一起发布。

Red Hat 9是最早的包含NPTL的发行版本(对一些用户来说有点不太方便,但是必须有人来打破这沉默[break the ice]...)

NPTL links:

  • NPTL讨论的邮件列表
  • NPTL源码
  • NPTL的最初发表
  • 最初的描述NPTL目标的白皮书
  • 修改的NPTL的最后设计的白皮书
  • Ingo Molnar最初的基准测试表明可以处理10^6个线程
  • Ulrich的基准测试 比较了LinuxThreads,NPTL和IBM的NGPT的各自性能,结果看来NPTL比NGPT快的多。

这是我尝试写的描述NPTL历史的文章(也可以参考Jerry Cooperstein的文章):

2002.3,NGPT小组的Bill Abt,glibc的维护者Ulrich Drepper 和其它人召开了个会议来探讨LinuxThreads的发展,会议的一个idea就是要改进mutex的性能。 Rusty Russell 等人 随后实现了 fast userspace mutexes (futexes), (如今已在NGPT和NPTL中应用了)。 与会的大部分人都认为NGPT应该合并到glibc中。

然而Ulrich Drepper并不怎么喜欢NGPT,他认为他可以做得更好。 (对那些曾经想提供补丁给glibc的人来说,这应该不会令他们感到惊讶:-) 于是在接下来的几个月里,Ulrich Drepper, Ingo Molnar和其它人致力于glibc和内核的改变,然后就弄出了 Native Posix Threads Library (NPTL). NPTL使用了NGPT设计的所有内核改进(kernel enhancement),并且采用了几个最新的改进。 Ingo Molnar描述了 一下的几个内核改进:

NPTL使用了三个由NGPT引入的内核特征: getpid()返回PID,CLONE_THREAD和futexes; NPTL还使用了(并依赖)也是该项目的一部分的一个更为wider的内核特征集。

一些由NGPT引入内核的items也被修改,清除和扩展,例如线程组的处理(CLONE_THREAD). [the CLONE_THREAD changes which impacted NGPT's compatibility got synced with the NGPT folks, to make sure NGPT does not break in any unacceptable way.]

这些为NPTL开发的并且后来在NPTL中使用的内核特征都描述在设计白皮书中, http://people.redhat.com/drepper/nptl-design.pdf ...

A short list: TLS support, various clone extensions (CLONE_SETTLS, CLONE_SETTID, CLONE_CLEARTID), POSIX thread-signal handling, sys_exit() extension (release TID futex upon VM-release), the sys_exit_group() system-call, sys_execve() enhancements and support for detached threads.

There was also work put into extending the PID space - eg. procfs crashed due to 64K PID assumptions, max_pid, and pid allocation scalability work. Plus a number of performance-only improvements were done as well.

In essence the new features are a no-compromises approach to 1:1 threading - the kernel now helps in everything where it can improve threading, and we precisely do the minimally necessary set of context switches and kernel calls for every basic threading primitive.

NGPT和NPTL的一个最大的不同就是NPTL是1:1的线程模型,而NGPT是M:N的编程模型(具体请看下面). 尽管这样, Ulrich的最初的基准测试 还是表明NPTL比NGPT快很多。(NGPT小组期待查看Ulrich的测试程序来核实他的结果.)

FreeBSD线程支持

FreeBSD支持LinuxThreads和用户空间的线程库。同样,M:N的模型实现KSE在FreeBSD 5.0中引入。 具体请查看www.unobvious.com/bsd/freebsd-threads.html.

2003.3.25, Jeff Roberson 发表于freebsd-arch:

... 感谢Julian, David Xu, Mini, Dan Eischen,和其它的每一位参加了KSE和libpthread开发的成员所提供的基础, Mini和我已经开发出了一个1:1模型的线程实现,它可以和KSE并行工作而不会带来任何影响。It actually helps bring M:N threading closer by testing out shared bits. ...

And 2006.7, Robert Watson提议1:1的线程模型应该为FreeBSD 7.x的默认实现:

我知道曾经讨论过这个问题,但是我认为随着7.x的向前推进,这个问题应该重新考虑。 在很多普通的应用程序和特定的基准测试中,libthr明显的比libpthread在性能上要好得多。 libthr是在我们大量的平台上实现的,而libpthread却只有在几个平台上。 最主要的是因为我们使得Mysql和其它的大量线程的使用者转换到"libthr",which is suggestive, also! ... 所以strawman提议:让libthr成为7.x上的默认线程库。

NetBSD线程支持

根据Noriyuki Soda的描述:

内核支持M:N线程库是基于调度程序激活模型,合并于2003.1.18当时的NetBSD版本中。

详情请看Nathan J. Williams, Wasabi Systems, Inc.在2002年的FREENIX上的演示 An Implementation of Scheduler Activations on the NetBSD Operating System。

Solaris线程支持

Solaris的线程支持还在进一步提高evolving... 从Solaris 2到Solaris 8,默认的线程库使用的都是M:N模型, 但是Solaris 9却默认使用了1:1线程模型. 查看Sun多线程编程指南 和Sun的关于Java和Solaris线程的note.

Java在JDK 1.3.x及更早的线程支持

大家都知道,Java一直到JDK1.3.x都没有支持任何处理网络连接的方法,除了一个线程服务一个客户端的模型之外。 Volanomark是一个不错的微型测试程序,可以用来测量在 某个时候不同数目的网络连接时每秒钟的信息吞吐量。在2003.5, JDK 1.3的实现实际上可以同时处理10000个连接,但是性能却严重下降了。 从Table 4 可以看出JVMs可以处理10000个连接,但是随着连接数目的增长性能也逐步下降。

Note: 1:1 threading vs. M:N threading

在实现线程库的时候有一个选择就是你可以把所有的线程支持都放到内核中(也就是所谓的1:1的模型),也可以 把一些线程移到用户空间上去(也就是所谓的M:N模型)。从某个角度来说, M:N被认为拥有更好的性能,但是由于很难被正确的编写, 所以大部分人都远离了该方法。

  • 为什么Ingo Molnar相对于M:N更喜欢1:1
  • Sun改为1:1的模型
  • NGPT是Linux下的M:N线程库.
  • Although Ulrich Drepper计划在新的glibc线程库中使用M:N的模型, 但是还是选用了1:1的模型.
  • MacOSX 也将使用1:1的线程.
  • FreeBSD和 NetBSD 仍然将使用M:N线程,FreeBSD 7.0也倾向于使用1:1的线程(见上面描述),可能M:N线程的拥护者最后证明它是错误的。

5. 把服务代码编译进内核

Novell和Microsoft都宣称已经在不同时期完成了该工作,至少NFS的实现完成了该工作。 khttpd在Linux下为静态web页面完成了该工作, Ingo Molnar完成了"TUX" (Threaded linUX webserver) ,这是一个Linux下的快速的可扩展的内核空间的HTTP服务器。 Ingo在2000.9.1宣布 alpha版本的TUX可以在 ftp://ftp.redhat.com/pub/redhat/tux下载, 并且介绍了如何加入其邮件列表来获取更多信息。
在Linux内核的邮件列表上讨论了该方法的好处和缺点,多数人认为不应该把web服务器放进内核中, 相反内核加入最小的钩子hooks来提高web服务器的性能,这样对其它形式的服务器就有益。 具体请看 Zach Brown的讨论 对比用户级别和内核的http服务器。 在2.4的linux内核中为用户程序提供了足够的权力(power),就像X15 服务器运行的速度和TUX几乎一样,但是它没有对内核做任何改变。

Comments

Richard Gooch曾经写了一篇讨论I/O选项的论文。

在2001, Tim Brecht和MMichal Ostrowski为使用简单的select的服务器 做了各种策略的测度 测试的数据值得看一看。

在2003, Tim Brecht发表了 userver的源码, 该服务器是整合了Abhishek Chandra, David Mosberger, David Pariag和Michal Ostrowski所写的几个服务器而成的, 可以使用select(), poll(), epoll()和sigio.

回到1999.3, Dean Gaudet发表:

我一直在问“为什么你们不使用基于select/event的模型,它明显是最快的。”...

他们的理由是“太难理解了,并且其中关键部分(payoff)不清晰”,但是几个月后,当该模型变得易懂时人们就开始愿意使用它了。

Mark Russinovich写了 一篇评论和 文章讨论了在2.2的linux内核只能够I/O策略问题。 尽管某些地方似乎有点错误,不过还是值得去看。特别是他认为Linux2.2的异步I/O (请看上面的F_SETSIG) 并没有在数据准备好时通知用户进程,而只有在新的连接到达时才有。 这看起来是一个奇怪的误解。 还可以看看 早期的一些comments, Ingo Molnar在1999.4.30所举的反例, Russinovich在1999.5.2的comments, Alan Cox的 反例,和各种 linux内核邮件. 我怀疑他想说的是Linux不支持异步磁盘I/O,这在过去是正确的,但是现在SGI已经实现了KAIO,它已不再正确了。

查看页面 sysinternals.com和 MSDN了解一下“完成端口”, 据说它是NT中独特的技术, 简单说,win32的"重叠I/O"被认为是太低水平而不方面使用,“完成端口”是提供了完成事件队列的封装,再加上魔法般的调度, 通过允许更多的线程来获得完成事件如果该端口上的其它已获得完成事件的线程处于睡眠中时(可能正在处理阻塞I/O),从而可以保持运行线程数目恒定(scheduling magic that tries to keep the number of running threads constant by allowing more threads to pick up completion events if other threads that had picked up completion events from this port are sleeping (perhaps doing blocking I/O).

查看OS/400的I/O完成端口支持.

在1999.9,在linux内核邮件列表上曾有一次非常有趣的讨论,讨论题目为 "15,000 Simultaneous Connections" (并且延续到第二周). Highlights:

  • Ed Hall 发表了一些他自己的经验:他已经在运行Solaris的UP P2/333上完成>1000个连接每秒。 他的代码使用了一个很小的线程池(每个cpu 1或者2个线程池),每个线程池使用事件模型来管理大量的客户端连接。
  • Mike Jagdisposted an analysis of poll/select overhead, and said "The current select/poll implementation can be improved significantly, especially in the blocking case, but the overhead will still increase with the number of descriptors because select/poll does not, and cannot, remember what descriptors are interesting. This would be easy to fix with a new API. Suggestions are welcome..."
  • Mike posted about his work on improving select() and poll().
  • Mike posted a bit about a possible API to replace poll()/select(): "How about a 'device like' API where you write 'pollfd like' structs, the 'device' listens for events and delivers 'pollfd like' structs representing them when you read it? ... "
  • Rogier Wolff suggested using "the API that the digital guys suggested", http://www.cs.rice.edu/~gaurav/papers/usenix99.ps
  • Joerg Pommnitz pointed out that any new API along these lines should be able to wait for not just file descriptor events, but also signals and maybe SYSV-IPC. Our synchronization primitives should certainly be able to do what Win32's WaitForMultipleObjects can, at least.
  • Stephen Tweedie asserted that the combination of F_SETSIG, queued realtime signals, and sigwaitinfo() was a superset of the API proposed in http://www.cs.rice.edu/~gaurav/papers/usenix99.ps. He also mentions that you keep the signal blocked at all times if you're interested in performance; instead of the signal being delivered asynchronously, the process grabs the next one from the queue with sigwaitinfo().
  • Jayson Nordwick compared completion ports with the F_SETSIG synchronous event model, and concluded they're pretty similar.
  • Alan Cox noted that an older rev of SCT's SIGIO patch is included in 2.3.18ac.
  • Jordan Mendelson posted some example code showing how to use F_SETSIG.
  • Stephen C. Tweedie continued the comparison of completion ports and F_SETSIG, and noted: "With a signal dequeuing mechanism, your application is going to get signals destined for various library components if libraries are using the same mechanism," but the library can set up its own signal handler, so this shouldn't affect the program (much).
  • Doug Royer noted that he'd gotten 100,000 connections on Solaris 2.6 while he was working on the Sun calendar server. Others chimed in with estimates of how much RAM that would require on Linux, and what bottlenecks would be hit.
May5

给你的iPhone,iPod Touch 装上GCC

Author: leeon  Click: 9500   Comments: 0 Category: 生活  Tag: iphone,ipod,touch,libgcc,gcc

安装GCC之前提示要有依赖性文件libgcc,但是cydia上我反正是没有找到可以下载的链接,索性在weiphone上找到了答案,转载过来分享给大家:
在终端中输入以下命令:
[code="bash"]
wget http://apt.saurik.com/debs/libgcc_4.2-20080410-1-6_iphoneos-arm.deb
dpkg -i libgcc_4.2-20080410-1-6_iphoneos-arm.deb
apt-get install iphone-gcc
[/code]
安装完libgcc,其它工作就很好搞定了~

May5

Linux知识点备忘录

Author: leeon  Click: 7428   Comments: 0 Category: linux  Tag: linux

此文章不定期更新。记录一些Linux的零散知识点。
学了忘,忘了学,温故而知新~
                      Mark!!


   
NFS权限:
      no_root_squash:登入 NFS 主机使用分享目录的使用者,如果是 root 的话,那么对于这个分享的目录来说,他就具有 root 的权限!这个项目『极不安全』,不建议使用!
     root_squash:在登入 NFS 主机使用分享之目录的使用者如果是 root 时,那么这个使用者的权限将被压缩成为匿名使用者,通常他的 UID 与 GID 都会变成 nobody 那个系统账号的身份。

 

linux系统root用户可强制踢制其它登录用户,

首先以root登录以便查看全部的在线用户信息,可用w命令查看登录用户信息

强制踢人命令格式:pkill -kill -t tty

解释:

pkill -kill -t  踢人命令

tty 所踢用户的TTY

如上踢出liu用户的命令为: pkill -kill -t pts/1

分类

标签

归档

最新评论

Abyss在00:04:28评论了
Linux中ramdisk,tmpfs,ramfs的介绍与性能测试
shallwe99在10:21:17评论了
【原创】如何在微信小程序开发中正确的使用vant ui组件
默一在09:04:53评论了
Berkeley DB 由浅入深【转自架构师杨建】
Memory在14:09:22评论了
【原创】最佳PHP框架选择(phalcon,yaf,laravel,thinkphp,yii)
leo在17:57:04评论了
shell中使用while循环ssh的注意事项

我看过的书

链接

其他

访问本站种子 本站平均热度:9360 c° 本站链接数:1 个 本站标签数:464 个 本站被评论次数:94 次