博客园_MrDB's 技术随笔

乱谈服务器编程

2012-01-11T06:39:00Z

乱谈服务器编程

第一部分 编程模型

1、服务器编程模型

关于server编程模型，大师stevens在他的《UNP》一书中已经做了详细论述，这里不再重复，这里主要讲一下我的一些理解。

从线程的角度，可以分为两类，一是单线程，一是多线程。先来看单线程模型。

1.1、单线程模型

整个进程只有一个线程，由于只有一个线程，所以要实现高性能，必须与“non-blocking IO + IO multiplexing”相结合。程序基本模型如下：

struct epoll_event ev, events[MAX_EVENTS];

int listen_sock, nfds, epollfd;

/* Set up listening socket, 'listen_sock' (socket(),bind(), listen()) */

/* 1. 创建一个epoll描述符 */

epollfd = epoll_create(10);

ev.events = EPOLLIN;

ev.data.fd = listen_sock;

/* 2. 注册监听事件 */

epoll_ctl(epollfd, EPOLL_CTL_ADD, listen_sock, &ev);

for (;;) {

/* 3. 监听事件 */

nfds = epoll_wait(epollfd, events, MAX_EVENTS, -1);

/* 4. 处理事件 */

for (n = 0; n < nfds; ++n) {

if (events[i].data.fd == listener_fd) {

HandleAccept(events[i].data.fd);

continue;

}

if (events[i].events & EPOLLIN) {

HandleRead(events[i].data.fd);

}

if (events[i].events & EPOLLOUT) {

HandleWrite(events[i].data.fd);

}

该模型的代表主要有haproxy、nginx等，另外libevent本身也是单线程的。相对于多线程，单线程server没有线程切换以及加锁的开销，劣势是不能充分利用CPU的多核优势，不过，这可以通过多个进程来解决。

另外，这种模型编程也很简单，因为简单，所以是编写高性能server的首选。公司内部的网络框架Srvframework、GNP都属于这类范畴。 Alan Cox曾说：“线程是为不懂状态机的人准备的”[9]。的确，单线程+状态机可以做很多事情。

1.2、多线程模型

进程有多个线程，一般来说，可以将server的线程分成两类：I/O线程和工作线程。由此又可以将多线程模型大体分成两类：单一I/O线程+多个工作线程、多个I/O线程(工作线程)。另外，不论是单线程，还是多线程，non-blocking IO + IO multiplexing都是必选的。

(1)单一I/O线程+多个工作线程

这种模型下，I/O线程负责event loop、I/O操作，工作线程负责实际的业务逻辑处理，I/O线程与工作线程可以通过阻塞队列/共享内存等方式进行数据交换，队列/共享内存的访问需要加锁。实际上，这种模型本质上与1.2中单线程是类似的，只不过这里的业务逻辑交由单独的工作处理，它有大家都很熟悉的名字——半同步/半异步模型(HS/HA)。Taf属于这类。

(2)多个I/O线程(工作线程)

这种模型下，每个I/O线程都有一个event loop，另外，这里的工作线程可有可无，而且通常是没有，即I/O线程既处理I/O，又进行业务逻辑计算。大家熟悉的leader/follower(L/F)以及muti-reactor(M-R)模型都属于这类，这方面的资料很多，见参考文献，不再讨论。Memcached使用的M-R，ICE使用的L/F。

1.3、小结

个人认为：(1)单线程模型实现简单，如果业务逻辑不复杂，是实现高性能server的首选，比如proxy之类的server。(2)HS/HA很清晰，如果业务逻辑很复杂，比如database，可以考虑这种模型。(3)如果你想充分利用多CPU，当然可以考虑L/F或者M-R。但是值得一提的是，L/F中会有锁的开销，而M-R中没有锁的开销，但M-R的线程切换的开销要高于L/F。根据同事的一些测试，对于短连接L/F的结果好于M-R，而对于长连接，M-R要好于L/F。

第二部分 理解epoll

2、epoll的实现

2.1、核心数据结构

2.1.1、epoll实例

当用系统调用函数epoll_create创建一个epoll环境时，用户态得到epoll fd，内核态创建一个eventpoll：

//fs/eventpoll.c

struct eventpoll {

/* Protect the access to this structure */

spinlock_t lock;

* This mutex is used to ensure that files are not removed

* while epoll is using them. This is held during the event

* collection loop, the file cleanup path, the epoll file exit

* code and the ctl operations.

struct mutex mtx; ///主要用于epoll_ctl的并发

/* Wait queue used by sys_epoll_wait() */

wait_queue_head_t wq; ///sys_epoll_wait()使用的等待队列, process list

/* Wait queue used by file->poll() */

wait_queue_head_t poll_wait; ///file->poll()使用的等待队列

/* List of ready file descriptors */

struct list_head rdllist; ///ready list

/* RB tree root used to store monitored fd structs */

struct rb_root rbr;

* This is a single linked list that chains all the "struct epitem" that

* happened while transferring ready events to userspace w/out

* holding ->lock.

struct epitem *ovflist;

/* The user that created the eventpoll descriptor */

struct user_struct *user;

}

理解这个结构是理解epoll的开始，所以这里有必要解释一下。

我们知道在Unix/Linux中，一切都是文件，对于epoll实例的fd，eventpoll通常保存在file. private_data字段中。

lock：自旋锁，用于保护该数据结构。

mtx：互斥量，主要用于多个epoll_ctl之间的并发，epoll以红黑树组织关注的fd，epoll_ctl会修改红黑树，参见epoll_ctl的实现。

为什么有了一个自旋锁，还要搞一个互斥量？见最后一小结。

wq：epoll_wait使用的等待队列，在多线程程序中，我们可以在多个线程中对同一个epoll实例调用epoll_wait。

poll_wait：这个域是比较让人费解的。这里说说我的理解：对于socket fd，会将fd对应的epitem加入到sock的等待队列，但是，对于epfd，没有sock对象，用poll_wait做等待队列，参见ep_eventpoll_poll。

ovflist: 主要是解决当内核在传输数据给用户空间(ep_send_events_proc)时的锁(eventpoll->mtx)，此时epoll就是将这个时候传递上来的事件保存到ovflist中。

2.1.2、epitem

在epoll内部，每个关注的fd都对应一个epitem：

struct epitem {

/* RB tree node used to link this structure to the eventpoll RB tree */

struct rb_node rbn; ///RB tree

/* List header used to link this structure to the eventpoll ready list */

struct list_head rdllink; ///ready list

* Works together "struct eventpoll"->ovflist in keeping the

* single linked chain of items.

struct epitem *next;

/* The file descriptor information this item refers to */

struct epoll_filefd ffd; ///文件描述符信息

/* Number of active wait queue attached to poll operations */

int nwait;

/* List containing poll wait queues */

struct list_head pwqlist;

/* The "container" of this item */

struct eventpoll *ep;

/* List header used to link this item to the "struct file" items list */

struct list_head fllink;

/* The structure that describe the interested events and the source fd */

struct epoll_event event; ///关注的事件

};

这个结构比较简单，没什么好说的。

2.2、核心函数

2.2.1、epoll_ctl

当我们调用epoll_create创建一个epoll实例后，就可以调用epoll_ctl向epoll添加关注的fd了。

SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd,

struct epoll_event __user *, event)

{

…

ep = file->private_data;

//对互斥量加锁

mutex_lock(&ep->mtx);

* Try to lookup the file inside our RB tree, Since we grabbed "mtx"

* above, we can be sure to be able to use the item looked up by

* ep_find() till we release the mutex.

epi = ep_find(ep, tfile, fd);

error = -EINVAL;

switch (op) {

case EPOLL_CTL_ADD:

if (!epi) {

epds.events |= POLLERR | POLLHUP;

error = ep_insert(ep, &epds, tfile, fd);

} else

error = -EEXIST;

break;

case EPOLL_CTL_DEL:

if (epi)

error = ep_remove(ep, epi);

else

error = -ENOENT;

break;

case EPOLL_CTL_MOD:

if (epi) {

epds.events |= POLLERR | POLLHUP;

error = ep_modify(ep, epi, &epds);

} else

error = -ENOENT;

break;

}

mutex_unlock(&ep->mtx);

…

}

ep_insert：

/* @tfile :target file，即fd对应的file */

static int ep_insert(struct eventpoll *ep, struct epoll_event *event,

struct file *tfile, int fd)

{

…

/* Initialize the poll table using the queue callback */

epq.epi = epi;

//设置poll中调用的回调函数ep_ptable_queue_proc

init_poll_funcptr(&epq.pt, ep_ptable_queue_proc);

/* 调用底层文件系统的poll，对于tcp socket，为sock_poll，后者调用具体协议(protocol-specific)的poll，如tcp_poll( ) */

revents = tfile->f_op->poll(tfile, &epq.pt); ///参见sock_poll

//加入红黑树

ep_rbtree_insert(ep, epi);

/* We have to drop the new item inside our item list to keep track of it */

spin_lock_irqsave(&ep->lock, flags);

/* 如果文件已经ready，则加入到ready list */

if ((revents & event->events) && !ep_is_linked(&epi->rdllink)) {

list_add_tail(&epi->rdllink, &ep->rdllist);

/* Notify waiting tasks that events are available */

if (waitqueue_active(&ep->wq))

wake_up_locked(&ep->wq); ///唤醒等待进程,调用epoll_wait的进程

if (waitqueue_active(&ep->poll_wait))

pwake++;

}

spin_unlock_irqrestore(&ep->lock, flags);

…

}

ep_insert主要将fd添加到红黑树，然后在具体协议的poll，比如tcp_poll中，调用回调函数ep_ptable_queue_proc，最后检查fd是否ready，如果ready，则将fd加入到就绪队列，并唤醒等待进程。另外，值得一提的是在epoll_ctl和epoll_wait中，对epoll的就绪队列的访问都是由自旋锁lock保护。

/* @file : target file

** @whead: fd对应的sock的等待队列

static void ep_ptable_queue_proc(struct file *file, wait_queue_head_t *whead,

poll_table *pt)

{

struct epitem *epi = ep_item_from_epqueue(pt);

struct eppoll_entry *pwq;

if (epi->nwait >= 0 && (pwq = kmem_cache_alloc(pwq_cache, GFP_KERNEL))) {

init_waitqueue_func_entry(&pwq->wait, ep_poll_callback); ///注册唤醒回调函数

pwq->whead = whead;

pwq->base = epi;

add_wait_queue(whead, &pwq->wait); ///将epitem加到sock的等待队列

list_add_tail(&pwq->llink, &epi->pwqlist);

epi->nwait++;

} else {

/* We have to signal that an error occurred */

epi->nwait = -1;

}

ep_ptable_queue_proc主要将epoll_ctl传进来的fd封装成的epitem添加到target file对应的sock的等待队列。

当socket收到数据时，内核协议栈会将其放到sock的接收队列sk_receive_queue，并调用sk_data_ready回调函数(如果用标准函数sock_init_data来初始化sock实例，通常是sock_def_readable)，唤醒等待队列，内核唤醒原语最终会调用这里注册的回调函数ep_poll_callback。

//net/core/sock.c

static void sock_def_readable(struct sock *sk, int len)

{

struct socket_wq *wq;

rcu_read_lock();

wq = rcu_dereference(sk->sk_wq);

if (wq_has_sleeper(wq)) ///检查sock的等待队列

wake_up_interruptible_sync_poll(&wq->wait, POLLIN | POLLPRI |

POLLRDNORM | POLLRDBAND); ///唤醒

sk_wake_async(sk, SOCK_WAKE_WAITD, POLL_IN);

rcu_read_unlock();

}

下面来看看ep_poll_callback：

static int ep_poll_callback(wait_queue_t *wait, unsigned mode, int sync, void *key)

{

…

struct epitem *epi = ep_item_from_wait(wait);

struct eventpoll *ep = epi->ep;

spin_lock_irqsave(&ep->lock, flags);

//如果只有ET/ONESHOT位设置,则不加入ready list

if (!(epi->event.events & ~EP_PRIVATE_BITS))

goto out_unlock;

///check event

if (key && !((unsigned long) key & epi->event.events))

goto out_unlock;

/* If this file is already in the ready list we exit soon */

if (!ep_is_linked(&epi->rdllink)) ///加入ready链表

list_add_tail(&epi->rdllink, &ep->rdllist);

* Wake up ( if active ) both the eventpoll wait list and the ->poll()

* wait list.

if (waitqueue_active(&ep->wq))

wake_up_locked(&ep->wq); ///唤醒等待进程

if (waitqueue_active(&ep->poll_wait))

pwake++;

out_unlock:

spin_unlock_irqrestore(&ep->lock, flags);

…

}

该函数将fd加到epoll实例的ready list，然后唤醒epoll实例的等待进程队列。注意红色部分，后面讨论epoll线程安全性的时候会再提到。

2.2.2、epoll_wait

当我们把关注的fd添加到epoll环境后，就可以调用epoll_wait等待fd上的事件发生了。

SYSCALL_DEFINE4(epoll_wait, int, epfd, struct epoll_event __user *, events,

int, maxevents, int, timeout)

{

struct file *file; ///epfd file

struct eventpoll *ep;

file = fget(epfd);

ep = file->private_data; ///epoll环境

/* Time to fish for events ... */

error = ep_poll(ep, events, maxevents, timeout);

…

}

很简单，主要逻辑由ep_poll完成：

static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events,

int maxevents, long timeout)

{

…

fetch_events:

spin_lock_irqsave(&ep->lock, flags);

if (!ep_events_available(ep)) { ///没有ready event, sleep current process

* We don't have any available event to return to the caller.

* We need to sleep here, and we will be wake up by

* ep_poll_callback() when events will become available.

init_waitqueue_entry(&wait, current);

///将进程加入到epoll环境的等待队列

__add_wait_queue_exclusive(&ep->wq, &wait);

for (;;) {

* We don't want to sleep if the ep_poll_callback() sends us

* a wakeup in between. That's why we set the task state

* to TASK_INTERRUPTIBLE before doing the checks.

set_current_state(TASK_INTERRUPTIBLE);

if (ep_events_available(ep) || timed_out) ///timeout==0, timed_out==1,则break

break;

if (signal_pending(current)) {

res = -EINTR;

break;

}

spin_unlock_irqrestore(&ep->lock, flags);

if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS)) ///schedule

timed_out = 1;

spin_lock_irqsave(&ep->lock, flags);

}

__remove_wait_queue(&ep->wq, &wait);

set_current_state(TASK_RUNNING);

}

check_events:

/* Is it worth to try to dig for events ? */

eavail = ep_events_available(ep);

spin_unlock_irqrestore(&ep->lock, flags);

* Try to transfer events to user space. In case we get 0 events and

* there's still timeout left over, we go trying again in search of

* more luck.

if (!res && eavail && ///将事件拷贝到用户空间

!(res = ep_send_events(ep, events, maxevents)) && !timed_out)

goto fetch_events;

…

}

ep_poll的逻辑也非常简单，就是不断检查epoll的ready list，如果有ready fd，则将其拷贝到用户空间。

注意ep_poll是调用__add_wait_queue_exclusive将当前进程加入到epoll的等待队列的，所以，即使多个线程对同一个epoll调用epoll_wait，也不会出现thundering herd问题。

最后来看一下ep_send_events函数，因为它与epoll的几种模式：LT、ET和ONESHOT相关，理解了其实现，也就理解了LT、ET与ONESHOT。

2.2.3、ep_send_events

static int ep_send_events(struct eventpoll *ep,

struct epoll_event __user *events, int maxevents)

{

struct ep_send_events_data esed;

esed.maxevents = maxevents;

esed.events = events;

///处理ready list

return ep_scan_ready_list(ep, ep_send_events_proc, &esed);

}

主要逻辑是在回调函数ep_send_events_proc中完成的。

static int ep_send_events_proc(struct eventpoll *ep, struct list_head *head,

void *priv)

{

struct ep_send_events_data *esed = priv;

int eventcnt;

unsigned int revents;

struct epitem *epi;

struct epoll_event __user *uevent;

* We can loop without lock because we are passed a task private list.

* Items cannot vanish during the loop because ep_scan_ready_list() is

* holding "mtx" during this call.

for (eventcnt = 0, uevent = esed->events;

!list_empty(head) && eventcnt < esed->maxevents;) {

epi = list_first_entry(head, struct epitem, rdllink);

list_del_init(&epi->rdllink); ///删除一个epitem

///检查事件

revents = epi->ffd.file->f_op->poll(epi->ffd.file, NULL) &

epi->event.events;

* If the event mask intersect the caller-requested one,

* deliver the event to userspace. Again, ep_scan_ready_list()

* is holding "mtx", so no operations coming from userspace

* can change the item.

if (revents) {

if (__put_user(revents, &uevent->events) ||

__put_user(epi->event.data, &uevent->data)) {

list_add(&epi->rdllink, head); ///加入到输出队列

return eventcnt ? eventcnt : -EFAULT;

}

eventcnt++;

uevent++;

if (epi->event.events & EPOLLONESHOT)

///take care,只设置EPOLLET/EPOLLONESHOT,参见ep_poll_callback

epi->event.events &= EP_PRIVATE_BITS;

else if (!(epi->event.events & EPOLLET)) { //LT模式

* If this file has been added with Level

* Trigger mode, we need to insert back inside

* the ready list, so that the next call to

* epoll_wait() will check again the events

* availability. At this point, no one can insert

* into ep->rdllist besides us. The epoll_ctl()

* callers are locked out by

* ep_scan_ready_list() holding "mtx" and the

* poll callback will queue them in ep->ovflist.

list_add_tail(&epi->rdllink, &ep->rdllist); //LT模式,重新加入到ready list

}

return eventcnt;

}

LT：Level Triggered，水平触发是epoll的默认工作模式，当fd上有事件发生，内核除了把事件上报给用户，还把fd重新加到就绪队列中，所以直到收集事件时没有事件发生，该fd才从epoll的就绪队列中移除。

例如：socket fd可读，如果数据并没有读完，则接下来每次epoll_wait都会返回该fd可读，直到有一次收集事件失败，即socket不可读。

ET: Edge Triggered，边缘触发，相比LT，ET收集完事件后不会把fd重新加入就绪队列。

如果fd可读，epoll上报有事件发生，该fd也从就绪队列中移除了，无论数据有没有读完。该fd只有在下次事件发生并在回调函数ep_poll_callback中被加入就绪队列。

ONESHOT: 顾名思义，如果fd有事件发生，只会触发一次。从ep_send_events_pro的实现可以看到，对于EPOLLONESHOT，会将其它事件位全部清掉。这样，以后ep_poll_callback(参见其实现)将不会将该fd加入ready list，即使有事件发生，直到用户再一次通过EPOLL_CTL_MOD重新设置fd。所以，对于ONESHOT的fd，如果有事件发生，每次EPOLL_CTL_MOD只会上报一次。

第三部分 问题

3、epoll为什么比poll高效

先看看poll的实现：

//fs/select.c

SYSCALL_DEFINE3(poll, struct pollfd __user *, ufds, unsigned int, nfds,

long, timeout_msecs)

{

…

ret = do_sys_poll(ufds, nfds, to);

…

}

主要逻辑在do_sys_poll完成：

int do_sys_poll(struct pollfd __user *ufds, unsigned int nfds,

struct timespec *end_time)

{

struct poll_wqueues table;

int err = -EFAULT, fdcount, len, size;

/* Allocate small arguments on the stack to save memory and be

faster - use long to make sure the buffer is aligned properly

on 64 bit archs to avoid unaligned access */

long stack_pps[POLL_STACK_ALLOC/sizeof(long)];

struct poll_list *const head = (struct poll_list *)stack_pps; ///先使用栈上的空间

struct poll_list *walk = head;

unsigned long todo = nfds;

if (nfds > rlimit(RLIMIT_NOFILE))

return -EINVAL;

len = min_t(unsigned int, nfds, N_STACK_PPS);

for (;;) {

walk->next = NULL;

walk->len = len;

if (!len)

break;

///1.将用户空间的描述符拷贝到内核

if (copy_from_user(walk->entries, ufds + nfds-todo,

sizeof(struct pollfd) * walk->len))

goto out_fds;

todo -= walk->len;

if (!todo)

break;

///如果栈上空间不够,则调用kmalloc分配空间存储描述符信息

len = min(todo, POLLFD_PER_PAGE);

size = sizeof(struct poll_list) + sizeof(struct pollfd) * len;

walk = walk->next = kmalloc(size, GFP_KERNEL);

if (!walk) {

err = -ENOMEM;

goto out_fds;

}

///设置poll的回调函数,与epoll类似

poll_initwait(&table);

///2.poll所有描述符,是否有事件发生

fdcount = do_poll(nfds, head, &table, end_time);

poll_freewait(&table);

for (walk = head; walk; walk = walk->next) {

struct pollfd *fds = walk->entries;

int j;

///3.设置相应文件描述发生的事件

for (j = 0; j < walk->len; j++, ufds++)

if (__put_user(fds[j].revents, &ufds->revents))

goto out_fds;

}

…

}

从上面的代码可以看出，poll至少有三个原因导致它比epoll效率低：

(1)每次调用都要将用户空间的所有描述符信息拷贝到内核；

(2)与epoll不同，poll内部没一个ready list，所以，每次都需要检查所有的描述符；

(3)遍历所有的描述符，设置发生的事件。

当fd数量较多时，比如支持上万连接的高并发的server，这些遍历操作会成为性能的致命杀手。

4、epoll线程安全性

考虑两种情况：一是两个线程对同一个epoll调用epoll_ctl；二是A线程对epoll调用epoll_wait，同时线程B调用epoll_ctl。

(1) 从第2节的epoll实现可以看到，epoll_ctl会修改内部红黑树，而且同时涉及到内存分配，所以它们之间通过互斥量保证线程性安全性。

(2) 另外，epoll_wait与epoll_wait，或者epoll_wait与epoll_ctl之间，涉及到对epoll内部ready list的访问，而且时间很短，没有其它复杂逻辑。所以用自旋锁保护。

综上，epoll是线程安全的。

在Memcached中，每个线程都有一个epoll loop，主线程(处理accept)收到一个连接，会丢到工作线程的epoll loop中，它先将连接对象CQ_ITEM加入工作线程的队列，然后通过管道来通知工作线程。但是，由于两个线程需要访问连接对象队列，所以，使用了锁来保护。实际上，如果在主线程中直接对工作线程调用epoll_ctl，是没有问题的，这样，我们就可以做一些工作(比如利用epoll_event数据结构)，从而做到多个线程间无锁编程(这里的无锁是指用户态无锁，但内核仍然会有锁)。注意，这里只针对epoll，不适用于其它模型。

主要参考

1. Kernel 3.0 sourcode

2. Libevent 1.4.13 sourcecode

3. Memcached 1.4.5 sourcecode

4. Haproxy 1.4.8 sourcecode

5. Nginx 0.8.28 sourcecode

6. 《Half Sync/Half Async》

7. 《Leader/Followers:A Design Pattern for Efﬁcient Multi-threaded I/O Demultiplexing and Dispatching》

8. 《Understanding Linux Network Internals》

9. http://lkml.indiana.edu/hypermail/linux/kernel/0106.2/0405.html

作者：MrDB
出处：http://www.cnblogs.com/hustcat/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

本文链接

一个由string使用不当产生的问题

2011-12-29T11:37:00Z

今天因不正确的使用std::string，产生一个很难发觉的问题，搞了许久，mark一下。原代码大概如下：

void func(char *buf, int len){

string s;

s.reserve(len);

memcpy((char *)&s[0], buf, len));

string t(s, 0, len);

}

发现t中的数据始终为空。最后才明白，reserve函数没有更改string的size，也就是说s.size()==0，后面其它字符串通过string的方法从s获取数据，由于size为零，都不能真正拷贝数据。解决方法很简单，将reserve换成resize即可。可参考resize的源码：

610 template<typename _CharT, typename _Traits, typename _Alloc>
611 void
612 basic_string<_CharT, _Traits, _Alloc>::
613 resize(size_type __n, _CharT __c)
614 {
615 const size_type __size = this->size();
616 _M_check_length(__size, __n, "basic_string::resize");
617 if (__size < __n)
618 this->append(__n - __size, __c);
619 else if (__n < __size)
620 this->erase(__n);
621 // else nothing (in particular, avoid calling _M_mutate() unnecessarily.)
622 } // /usr/include/c++/4.1.0/bits/basic_string.tcc

本文链接

从free到page cache

2011-10-27T12:32:00Z

Free
我们经常用free查看服务器的内存使用情况，而free中的输出却有些让人困惑，如下：

图1-1
先看看各个数字的意义以及如何计算得到：
free命令输出的第二行(Mem)：这行分别显示了物理内存的总量(total)、已使用的 (used)、空闲的(free)、共享的(shared)、buffer(buffer大小)、 cache(cache的大小)的内存。我们知道Total、free、buffers、cached这几个字段是从/proc/meminfo中获取的，而used = total – free。Share列已经过时，忽略(见参考)。
free命令输出的第三行(-/+ buffers/cache)：
它显示的第一个值(used)：548840，这个值表示系统本身使用的内存总量，即除去buffer/cache，等于Mem行used列 - Mem行buffers列 - Mem行cached列。
它显示的第二个值(free)：1417380，这个值表示系统当前可用内存，它等于Mem行total列—used，也等于Mem行free列 + Mem行buffers列 + Mem行cached列。
free命令输出的第四行(Swap) 这行显示交换内存的总量、已使用量、空闲量。

我们都知道free是从/proc/meminfo中读取相关的数据的。

图1-2
来看看/proc/meminfo的相关实现：
// proc_misc.c
static int meminfo_read_proc(char *page, char **start, off_t off,
                                     int count, int eof, void data)
{
…
struct sysinfo i;
         si_meminfo(&i); //统计memory的使用情况
         si_swapinfo(&i); //统计swap的使用情况
…
         len = sprintf(page,
                   "MemTotal:     %8lu kB\n"
                   "MemFree:      %8lu kB\n"
                   "Buffers:      %8lu kB\n"
                   "Cached:       %8lu kB\n"
                   "SwapCached:   %8lu kB\n"
…
                   K(i.totalram),
                  K(i.freeram),
                   K(i.bufferram),
                   K(get_page_cache_size()-total_swapcache_pages-i.bufferram),
                   K(total_swapcache_pages),
…
}

struct sysinfo {
         long uptime;                      /* Seconds since boot /
         unsigned long loads[3];          / 1, 5, and 15 minute load averages /
         unsigned long totalram;                  /总的页框数,Total usable main memory size /
         unsigned long freeram;                   / Available memory size /
         unsigned long sharedram;    / Amount of shared memory /
         unsigned long bufferram;     / Memory used by buffers /
         unsigned long totalswap;       / Total swap space size /
         unsigned long freeswap;                 / swap space still available /
         unsigned short procs;            / Number of current processes /
         unsigned short pad;                / explicit padding for m68k /
         unsigned long totalhigh;        / Total high memory size /
         unsigned long freehigh;                  / Available high memory size /
         unsigned int mem_unit;                  / Memory unit size in bytes /
         char _f[20-2sizeof(long)-sizeof(int)]; /* Padding: libc5 uses this.. /
};
图中，Buffers对应sysinfo.bufferram，内核中以页框为单位，通过宏K转化成以KB为单位输出。
void si_meminfo(struct sysinfo val)
{
         val->totalram = totalram_pages;//总的页框数
         val->sharedram = 0;
         val->freeram = nr_free_pages();//计算空闲页框数
         val->bufferram = nr_blockdev_pages();//block device使用的面框数
#ifdef CONFIG_HIGHMEM
         val->totalhigh = totalhigh_pages;
         val->freehigh = nr_free_highpages();
#else
         val->totalhigh = 0;
         val->freehigh = 0;
#endif
         val->mem_unit = PAGE_SIZE;
}
//遍历所有的块设备，累加相应的页面数量
long nr_blockdev_pages(void)
{
         struct list_head p;
         long ret = 0;
         spin_lock(&bdev_lock);
         list_for_each(p, &all_bdevs) {
                   struct block_device bdev;
                   bdev = list_entry(p, struct block_device, bd_list);
                   ret += bdev->bd_inode->i_mapping->nrpages;
         }
         spin_unlock(&bdev_lock);
         return ret;
}
nr_blockdev_pages计算块设备使用的页框数，遍历所有块设备，将使用的页框数相加。而不包含普通文件使用的页框数。

Cached = get_page_cache_size()-total_swapcache_pages-i.bufferram。
static inline unsigned long get_page_cache_size(void)
{
         int ret = atomic_read(&nr_pagecache);
         if (unlikely(ret < 0))
                   ret = 0;
         return ret;
}
Cache的大小为内核总的page cache减去swap cache和块设备占用的页框数量，实际上cache即为普通文件的占用的page cache。实际上，在函数add_to_page_cache和__add_to_swap_cache 中，都会通过调用pagecache_acct实现对内核变量nr_pagecache进行累加。前者对应page cache，内核读块设备和普通文件使用；后者对应swap cache，内核读交换分区使用。

Page cache(页面缓存)
在linux系统中，为了加快文件的读写，内核中提供了page cache作为缓存，称为页面缓存(page cache)。为了加快对块设备的读写，内核中还提供了buffer cache作为缓存。在2.4内核中，这两者是分开的。这样就造成了双缓冲，因为文件读写最后还是转化为对块设备的读写。在2.6中，buffer cache合并到page cache中，对应的页面叫作buffer page。当进行文件读写时，如果文件在磁盘上的存储块是连续的，那么文件在page cache中对应的页是普通的page，如果文件在磁盘上的数据块是不连续的，或者是设备文件，那么文件在page cache中对应的页是buffer page。buffer page与普通的page相比，每个页多了几个buffer_head结构体(个数视块的大小而定)。此外，如果对单独的块（如超级块）直接进行读写，对应的page cache中的页也是buffer page。这两种页面虽然形式略有不同，但是最终他们的数据都会被封装成bio结构体，提交到通用块设备驱动层，统一进行I/O调度。

// include/buffer_head.h
struct buffer_head {
         /* First cache line: /
         unsigned long b_state;            / buffer state bitmap (see above) /
         struct buffer_head b_this_page;/* circular list of page's buffers /
         struct page b_page;               /* the page this bh is mapped to,页框 /
         atomic_t b_count;            / users using this block /
         u32 b_size;                        / block size /

         sector_t b_blocknr;                   / block number,块设备中的逻辑块号 /
         char b_data;                     /* pointer to data block /

         struct block_device b_bdev;//块设备
         bh_end_io_t b_end_io;           / I/O completion /
        void b_private;               /* reserved for b_end_io /
         struct list_head b_assoc_buffers; / associated with another mapping /
};
在kernel2.6之后，buffer_head没有别的作用，主要用来保持页框与块设备中数据块的映射关系。

Buffer page(缓冲页)
如果内核需要单独访问一个块，就会涉及到buffer page，并会检查对应的buffer head。
内核创建buffer page的两种常见情况：
(1)当读或者写一个文件页的数据块不相邻时。发生这种情况是因为文件系统为文件分配了非连续的块，或者文件有洞。具体请参见block_read_full_page(fs/buffer.c)函数:
///对于块设备文件和数据块不相邻的普通文件,都会调用该方法
int block_read_full_page(struct page page, get_block_t get_block)
{
…
         if (!page_has_buffers(page))///page没有分配buffer head,见buffer_head.h
                   create_empty_buffers(page, blocksize, 0);//为page创建buffer_head
         head = page_buffers(page);
}
这里使用buffer head主要是通过buffer head建立页框与数据块的映射关系。因为页面中的数据不是连接的，而页框描述符struct page的字段又不足以表达这种信息。
(2)访问一个单独的磁盘块(比如，读超级块或者索引节点块时)。参见ext2_fill_super(fs/ext2/super.c)，该函数在安装ext2文件系统时调用。

Buffer page和buffer head的关系：

小结：对于普通文件，如果页面中的块是连续的，则页面没有对应buffer head；如果不连续，则页面有对应的buffer head，参见do_mpage_readpage函数。对于块设备，无论是读取单独的数据块，还是作为设备文件来进行读取，页面始终有对应的buffer head，参见block_read_full_page/__bread函数。

Swap cache(交换缓存)
在图1-2中，有一行swapcached，它表示交换缓存的大小。Page cache是磁盘数据在内存中的缓存，而swap cache则是交换分区在内存中的临时缓存。Swap cache对交换分区具有十分重要的意义，这里不再赘述，详细讨论请见参考文献。

Swap用来为非映射页在磁盘上提供备份。有三类页必须由交换子系统进行处理：(1)进程匿名线性区(anonymous memory region)的页，比如用户态的堆栈和堆，匿名内存映射也是。(2) 进程私有内存映射的脏页。(3)IPC共享内存区的页。1和3都比较好理解，因为它们都没有对应的磁盘文件，所以必须通过swap来临时存储数据。下面讨论一下第2点。

Memory mapping(内存映射)
内核有两种类型的内存映射：共享型(shared)和私有型(private)。私有型是当进程为了只读文件，而不写文件时使用，这时，私有映射更加高效。但是，任何对私有映射页的写操作都会导致内核停止映射该文件中的页。所以，写操作既不会改变磁盘上的文件，对访问该文件的其它进程也是不可见的。
共享内存中的页通常都位于page cache，私有内存映射只要没有修改，也位于page cache。当进程试图修改一个私有映射内存页时，内核就把该页进行复制，并在页表中用复制的页替换原来的页。由于修改了页表，尽管原来的页仍然在page cache，但是已经不再属于该内存映射。而新复制的页也不会插入page cache，而是添加到匿名页反向映射数据结构。参见do_no_page(mm/memory.c)。
static int
do_no_page(struct mm_struct mm, struct vm_area_struct vma,
         unsigned long address, int write_access, pte_t page_table, pmd_t pmd)
{
…
         //写私有内存映射,则复制页面
         if (write_access && !(vma->vm_flags & VM_SHARED)) {
                   struct page page;

                   if (unlikely(anon_vma_prepare(vma)))
                            goto oom;
                   page = alloc_page_vma(GFP_HIGHUSER, vma, address);
                   if (!page)
                            goto oom;
                  copy_user_highpage(page, new_page, address);///copy page
                   page_cache_release(new_page);
                   new_page = page;
                   anon = 1;
         }
…
                   if (anon) {
                            lru_cache_add_active(new_page);//将页插入LRU的活动链表
                            page_add_anon_rmap(new_page, vma, address);//将匿名页插入到反向映射数据结构
                   }
…
}

释放cache
Free命令输出的第一行是对应的实实在在的内存，不管是buffer，还是cache。Swap对应磁盘上的交换分区。Kernel会尽量使用RAM做cache，所以一般cache都比较大：
8G的内存，而空闲(free)的内存只有约50M，比较惊人。其实，cached占了3G+。另外，我们看到第三行used列约为4G，是比较大的，确实，该机器上跑了好几个接入服务。

Kernel2.6.16之后的版本提供了一种释放cache的机制，通过修改内核参数/proc/sys/vm/drop_caches让内核释放干净的cache。
To free pagecache:
         echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:
         echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
         echo 3 > /proc/sys/vm/drop_caches

# free
             total       used       free     shared    buffers     cached
Mem:       1966220    1676428     289792          0     418900     705216
-/+ buffers/cache:     552312    1413908
Swap:      2104504     131084    1973420
# echo 1 > /proc/sys/vm/drop_caches
# free
            total       used       free     shared    buffers     cached
Mem:       1966220     597840    1368380          0        324      65852
-/+ buffers/cache:     531664    1434556
Swap:      2104504     131084    1973420
设置内核参数drop_caches后，cached的值迅速下降。通常来说，Linux会尽量使用可用的RAM，cache过高，是正常的。而手动释放cache会增加I/O开销，导致系统性能下降。

最后，水平有限，欢迎指正和探讨。

主要参考：
《ULK》
http://linux.die.net/man/1/free
http://www.kernel.org/doc/Documentation/sysctl/vm.txt
http://linux-mm.org/Drop_Caches

作者：MrDB
出处：http://www.cnblogs.com/hustcat/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
本文链接

数据库牛人榜(随时更新)

2011-03-30T15:21:00Z

Edgar F. Codd：1981年图灵奖，以他命名的SIGMOD Innovations Award。http://en.wikipedia.org/wiki/Edgar_F._Codd

Jim Gray: 事务处理的权威，1998年图灵奖。http://en.wikipedia.org/wiki/Jim_Gray_(computer_scientist)

Michael Stonebraker：Professor of Computer Science at University of California, Berkeley，参与开发Ingres和Postgres（这两项足以傲视群雄）。http://en.wikipedia.org/wiki/Michael_Stonebraker

本文链接

ACID、Data Replication、CAP与BASE

2010-09-07T13:40:00Z

ACID

在传数据库系统中，事务具有ACID 4个属性(Jim Gray在《事务处理：概念与技术》中对事务进行了详尽的讨论)。

(1)原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。

(2)一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。

(3)隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。

(4)持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。

对于单个节点的事务，数据库都是通过并发控制（两阶段封锁，two phase locking或者多版本，multiversioning）和恢复机制（日志技术）保证事务的ACID特性。对于跨多个节点的分布式事务，通过两阶段提交协议（two phase commiting）来保证事务的ACID。

可以说，数据库系统是伴随着金融业的需求而快速发展起来。对于金融业，可用性和性能都不是最重要的，而一致性是最重要的，用户可以容忍系统故障而停止服务，但绝不能容忍帐户上的钱无故减少(当然，无故增加是可以的)。而强一致性的事务是这一切的根本保证。

Data Replication

数据复制(data replication)属于分布式计算的范畴，它并不仅仅局限于数据库，但这里主要是指分布式数据库的复制。

在多副本构成的分布式数据库系统中，其事务特性与单个数据库系统的差别主要表现在原子性和一致性两个方面。在原子性方面，要求同一分布式事务的所有操作在所有相关副本上要么提交，要么回滚，即除了保证原有的局部事务的原子性，还需要控制全局事务的原子性；在一致性方面，多副本之间需要保证单一副本一致性。

针对分布式事务的原子性和一致性这两个复制协议中的核心问题，经过近20年的研究，人们提出了各种各样的复制协议。这些协议在外在功能和内部实现两方面都有较大的差别。据此，我们可以从这两个大的方面进行分类说明。

从外在功能的角度看，依据文献[1]，可以从事务执行的地点和时间两个方面进行分类。从事务执行的地点，可以分为两类：主从( Priamry / Copy)方式和更新所有( Update-Anywhere ) 方式。

前者的处理过程一般是系统中仅仅指定一个Primary节点接受更新请求，在事务操作执行完毕后，在事务提交前或后将操作广播到其他Copy节点。

后者的处理过程稍微复杂，系统中的任何副本具有相同的地位，都可以接收Update请求，在检测事务冲突、事务提交前或后将各个节点的Update传播到其他副本节点。

Primary / Copy方式并发控制较为简单，由Primary本地的事务控制即可实现，事务的原子性的实现也较为简单，一般由Primary节点作为协调节点来实现。但是，其缺陷也显而易见：仅仅单个节点提供Update请求处理能力，对于Update密集类型的应用，如OLTP，容易形成单点性能瓶颈。Update-Anywhere方式则与其相辅相成，可以通过多点提高事务吞吐率，但随之而来的是多个分布式事务之间复杂的并发控制和原子性问题。

从事务提交的时间点看，可以分为积极 (Eager)和消极(Lazy) 两类。其区别在于，前者是在事务提交前传播更新，后者则是在提交之后才将事务操作传播到其他副本。实际上，前者即通常无谓的同步复制(synchronous replication)，后者即无谓的异步复制(asynchronous replication)。

异步复制的优点是可以提高响应速度，但牺牲了一致性，一般实现该类协议的算法需要增加额外的补偿机制。同步复制的优点是可以保证一致性(一般通过两阶段提交协议)，但是开销较大，可用性不好(参见CAP部分)，带来了更多的冲突和死锁等问题。值得一提的是Lazy+Primary/Copy的复制协议在实际生产环境中是非常实用的，MySQL的复制实际上就属于这种。

CAP

在2000的PODC（Principles of Distributed Computing）会议上，Brewer提出了著名的CAP理论。2002年，Seth Gilbert和Nancy Lynch证明了这一理论。CAP指的是：Consistency、Availability和Partition Tolerance。

（1）Consistency（一致性）：一致性是说数据的原子性，这种原子性在经典的数据库中是通过事务来保证的，当事务完成时，无论其是成功还是回滚，数据都会处于一致的状态。在分布式环境中，一致性是说多个节点的数据是否一致。

（2）Availability（可用性）：可用性是说服务能一直保证是可用的状态，当用户发出一个请求，服务能在有限时间内返回结果。

（3）Partition Tolerance（分区容错性）：Partition是指网络的分区。可以这样理解，一般来说，关键的数据和服务都会位于不同的IDC。

CAP理论告诉我们，一个分布式系统不可能同时满足一致性，可用性和分区容错性这三个需求，三个要素中最多只能同时满足两点。三者不可兼顾，此所谓鱼与熊掌不可兼得也！而对于分布式数据系统而言，分区容错性是基本要求，否则就不称其为分布式系统了。因此架构设计师不要把精力浪费在设计如何能同时满足三者的完美分布式系统上，而是应该进行权衡取舍。这也意味着分布式系统的设计过程，也就是根据业务特点在C（一致性）和A（可用性）之间寻求平衡的过程，要求架构师真正理解系统需求，把握业务特点。

BASE

BASE来自于互联网的电子商务领域的实践，它是基于CAP理论逐步演化而来，核心思想是即便不能达到强一致性(Strong consistency)，但可以根据应用特点采用适当的方式来达到最终一致性(Eventual consistency)的效果。BASE是Basically Available、Soft state、Eventually consistent三个词组的简写，是对CAP中C & A的延伸。BASE的含义：

（1）Basically Available：基本可用；

（2）Soft-state：软状态/柔性事务，即状态可以有一段时间的不同步；

（3）Eventual consistency：最终一致性；

BASE是反ACID的，它完全不同于ACID模型，牺牲强一致性，获得基本可用性和柔性可靠性并要求达到最终一致性。

CAP、BASE理论是当前在互联网领域非常流行的NoSQL的理论基础。

主要参考

[1]J.N.Gray, P.Helland,and a.D.S.P.O’Neil. The dangers of replication and a solution. In Proceedings of the 1996 ACM SIGMOD International Conference on Management of Data, pages 173–182,Montreal, Canada, June 1996.SIGMOD.

[2]Gilbert , S., Lynch, N. 2002. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant Web services. ACM SIGACT News 33(2).

[3]http://www.allthingsdistributed.com/2008/12/eventually_consistent.html

[4]http://queue.acm.org/detail.cfm?id=1394128

[5]http://en.wikipedia.org/wiki/ACID

作者：arrowcat
出处：http://www.cnblogs.com/hustcat/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

本文链接

libevent源码分析

2010-08-31T12:49:00Z

这两天没事，看了一下Memcached和libevent的源码，做个小总结。

1、入门

1.1、概述
Libevent是一个用于开发可扩展性网络服务器的基于事件驱动(event-driven)模型的网络库。Libevent有几个显著的亮点：
(1)事件驱动（event-driven），高性能；
(2)轻量级，专注于网络，不如 ACE 那么臃肿庞大；
(3)源代码相当精炼、易读；
(4)跨平台，支持 Windows、Linux、*BSD和 Mac Os；
(5)支持多种 I/O多路复用技术， epoll、poll、dev/poll、select 和kqueue 等；
(6)支持 I/O，定时器和信号等事件；
(7)注册事件优先级；
Libevent 已经被广泛的应用，作为底层的网络库；比如 memcached、 Vomi t、 Nylon、 Netchat等等。

1.2、一个简单示例

1 int lasttime;
2
3 static void
4 timeout_cb(int fd, short event, void *arg)
5 {
6 struct timeval tv;
7 struct event *timeout = arg;
8 int newtime = time(NULL);
9
10 //printf("%s: called at %d: %d\n", __func__, newtime,
11 printf("%s: called at %d: %d\n", "timeout_cb", newtime,
12         newtime - lasttime);
13 lasttime = newtime;
14
15 evutil_timerclear(&tv);
16 tv.tv_sec = 2;
17 //重新注册event
18 event_add(timeout, &tv);
19 }
20
21 int
22 main (int argc, char **argv)
23 {
24 struct event timeout;
25 struct timeval tv;
26
27 /* Initalize the event library */
28 //初始化event环境
29 event_init();
30
31 /* Initalize one event */
32 //设置事件
33 evtimer_set(&timeout, timeout_cb, &timeout);
34
35 evutil_timerclear(&tv);
36 tv.tv_sec = 2;
37 //注册事件
38 event_add(&timeout, &tv);
39
40 lasttime = time(NULL);
41
42 //等待,分发,处理事件
43 event_dispatch();
44
45 return (0);
46 }

这是一个简单的基于libevent的定时器程序，运行结果：

用libevent编程非常简单，只需要调用event_init初始化环境，然后调用event_add注册相应的事件，接着调用event_dispatch等待并处理相应的事件即可。
调用event_add注册事件时，设置其回调函数。Libevent检测到事件发生时，便会调用事件对应的回调用函数，执行相关的业务逻辑。

1.3、源代码结构
Libevent 的源代码虽然都在一层文件夹下面，但是其代码分类还是相当清晰的，主要可分为头文件、内部使用的头文件、辅助功能函数、日志、libevent 框架、对系统 I/O 多路复用机制的封装、信号管理、定时事件管理、缓冲区管理、基本数据结构和基于 libevent的两个实用库等几个部分，有些部分可能就是一个源文件。
（1）头文件
主要就是 event.h：事件宏定义、接口函数声明，主要结构体 event 的声明；
（2）内部头文件
xxx-internal.h：内部数据结构和函数，对外不可见，以达到信息隐藏的目的；
（3）libevent框架
event.c：event 整体框架的代码实现；
（4）对系统 I/O多路复用机制的封装
epoll.c：对 epoll 的封装；
select.c：对 select 的封装；
devpoll.c：对 dev/poll 的封装;
kqueue.c：对kqueue 的封装；
（5）定时事件管理
min-heap.h：其实就是一个以时间作为 key的小根堆结构；
（6）信号管理
signal.c：对信号事件的处理；
（7）辅助功能函数
evutil.h 和 evutil.c：一些辅助功能函数，包括创建 socket pair和一些时间操作函数：加、减和比较等。
（8）日志
log.h和 log.c：log 日志函数
（9）缓冲区管理
evbuffer.c 和buffer.c：libevent 对缓冲区的封装；
（10）基本数据结构
compat\sys 下的两个源文件： queue.h是 libevent 基本数据结构的实现，包括链表，双向链表，队列等；_libevent_time.h：一些用于时间操作的结构体定义、函数和宏定义；
（11）实用网络库
http 和evdns：是基于 libevent 实现的http 服务器和异步 dns 查询库；

2、核心对象
结构体event和event_base是libevent的两个核心数据结构，前者代表一个事件对象，后者代表整个事件处理框架。
2.1、event（事件）

1 //event.h
2 struct event {
3 TAILQ_ENTRY (event) ev_next;          //已注册事件链表
4 TAILQ_ENTRY (event) ev_active_next;//就绪事件链表
5 TAILQ_ENTRY (event) ev_signal_next; //signal链表
6 unsigned int min_heap_idx;    /* for managing timeouts,事件在堆中的下标 */
7
8 struct event_base *ev_base;
9
10 int ev_fd;      //对于I/O事件,是绑定的文件描述符;对于signal事件,是绑定的信号
11 short ev_events; //event关注的事件类型
12 short ev_ncalls; //事件就绪执行时，调用 ev_callback 的次数
13 short *ev_pncalls;    /* Allows deletes in callback */
14
15 struct timeval ev_timeout;  //timout事件的超时值
16
17 int ev_pri;   /* smaller numbers are higher priority,优先级 */
18
19 void (*ev_callback)(int, short, void *arg); //回调函数
20 void *ev_arg; //回调函数的参数
21
22 int ev_res;        /* result passed to event callback */
23 int ev_flags; //event的状态
24 };
25

Libevent通过event对象将I/O事件、信号事件和定时器事件封装，从而统一处理，这也是libevent的精妙所有。
各个字段的具体含义：
(1) ev_events：event关注的事件类型，它可以是以下3种类型：
I/O事件： EV_WRITE和EV_READ
定时事件：EV_TIMEOUT
信号：    EV_SIGNAL
辅助选项：EV_PERSIST，表明是一个永久事件
libevent中的定义为：
#define EV_TIMEOUT   0x01
#define EV_READ   0x02
#define EV_WRITE   0x04
#define EV_SIGNAL   0x08
#define EV_PERSIST   0x10   /* Persistant event */
（2）ev_next，ev_active_next 和 ev_signal_next 都是双向链表节点指针；它们是 libevent 对不同事件类型和在不同的时期，对事件的管理时使用到的字段。
libevent 使用双向链表保存所有注册的 I/O和 Signal 事件，ev_next 就是该I/O事件在链表中的位置；此链表可以称为“已注册事件链表”；
同样 ev_signal_next 就是 signal 事件在 signal 事件链表中的位置；
ev_active_next：libevent 将所有的激活事件放入到链表 active list 中，然后遍历 active list 执
行调度，ev_active_next就指明了 event 在active list 中的位置；
（3）min_heap_idx 和 ev_timeout，如果是 timeout 事件，它们是 event 在小根堆中的索引和超时值，libevent 使用小根堆来管理定时事件。
（4）ev_base指向事件框架实例。
（5）ev_fd，对于 I/O事件，是绑定的文件描述符；对于 signal 事件，是事件对应的信号；
（6）eb_flags：libevent 用于标记 event信息的字段，表明事件当前的状态，可能的值有：
#define EVLIST_TIMEOUT   0x01 // event在time堆中
#define EVLIST_INSERTED 0x02 // event在已注册事件链表中
#define EVLIST_SIGNAL    0x04 // 未见使用
#define EVLIST_ACTIVE    0x08 // event在激活链表中
#define EVLIST_INTERNAL 0x10 // 内部使用标记
#define EVLIST_INIT      0x80 // event 已被初始化

2.2、event_base(事件处理框架)

1 //evenet_internal.h
2 struct event_base {
3 const struct eventop *evsel; //底层具体I/O demultiplex操作函数集
4 void *evbase;
5 int event_count;        /* counts number of total events,总的事件数量 */
6 int event_count_active;    /* counts number of active events,就绪事件数量 */
7
8 int event_gotterm;        /* Set to terminate loop */
9 int event_break;        /* Set to terminate loop immediately */
10
11 /* active event management */
12 //就绪事件链表数组
13 struct event_list **activequeues;
14 int nactivequeues;//就绪事件队列个数
15
16 /* signal handling info */
17 struct evsignal_info sig; //用于管理信号
18
19 struct event_list eventqueue; //注册事件队列
20 struct timeval event_tv;
21
22 struct min_heap timeheap; //管理定时器的小根堆
23 struct timeval tv_cache; //记录时间缓存
24 };

（1）evsel：libevent支持Linux、Windows等多种平台，也支持epoll、poll、select、kqueue等多种I/O多路复用模型。如果把event_init、event_add看成高层抽象的统一事件操作接口，则evsel为这些函数在底层具体的I/O demultiplex的对应的操作函数集。eventop为函数指针的集合：

1 struct eventop {
2 const char *name;
3 void *(*init)(struct event_base *);
4 int (*add)(void *, struct event *);
5 int (*del)(void *, struct event *);
6 int (*dispatch)(struct event_base *, void *, struct timeval *);
7 void (*dealloc)(struct event_base *, void *);
8 /* set if we need to reinitialize the event base */
9 int need_reinit;
10 };
11

在初始化函数event_base_new中，libevent将evsel指向全局数组eventops的具体元素：

1 //I/O multiplex机制实例数组
2 static const struct eventop *eventops[] = {
3 #ifdef HAVE_EVENT_PORTS
4 &evportops,
5 #endif
6 #ifdef HAVE_WORKING_KQUEUE
7 &kqops,
8 #endif
9 #ifdef HAVE_EPOLL
10 &epollops,
11 #endif
12 #ifdef HAVE_DEVPOLL
13 &devpollops,
14 #endif
15 #ifdef HAVE_POLL
16 &pollops,
17 #endif
18 #ifdef HAVE_SELECT
19 &selectops,
20 #endif
21 #ifdef WIN32
22 &win32ops,
23 #endif
24 NULL
25 };
26

2.3、主要函数
2.3.1、event_int（初始化libevent实例）
struct event_base *
event_init(void)
初始化事件处理框架实例，内部调用event_base_new。

event_base_new的主要逻辑：

1 struct event_base *
2 event_base_new(void)
3 {
4
5 //初始化小根堆
6 min_heap_ctor(&base->timeheap);
7
8 //初始化注册事件队列
9 TAILQ_INIT(&base->eventqueue);
10
11 for (i = 0; eventops[i] && !base->evbase; i++) {
12 //I/O demultiplex机制实例
13 base->evsel = eventops[i];
14
15 //初始化I/O demultiplex实例(参见win32_init)
16 base->evbase = base->evsel->init(base);
17 }
18
19 //分配1个就绪事件队列
20 event_base_priority_init(base, 1);
21
22 }

2.3.2、event_add（注册事件）
//注册事件
int
event_add(struct event *ev, const struct timeval *tv)
该函数主要将事件ev加入到事件框架event_base的注册事件链表base->eventqueue。

2.3.3、event_del（删除事件）
//删除事件
int
event_del(struct event *ev)
该函数主要将事件ev从相应的链表上删除。

2.3.4、event_set（设置事件）

/*设置event对象
**ev:事件对象
**fd:事件对应的文件描述符或信号,对于定时器设为-1
**events:事件类型，比如 EV_READ,EV_PERSIST, EV_WRITE, EV_SIGNAL
**callback:事件的回调函数
**arg:回调函数参数
*/
void
event_set(struct event *ev, int fd, short events,
void (*callback)(int, short, void *), void *arg)

在将事件注册事件处理框架之前，应该先调用event_set对事件进行相关设置。

2.4、libevent对event的管理
event结构有3个链表结点域和一个小根堆索引，libevent通过3个链表和一个小根堆对I/O事件、signal事件和timer事件进行管理。
对于I/O事件，通过event_add将其加入event_base的注册事件链表eventqueue ；就绪时会加入event_base的就绪链表activequeues[]；
对于timer事件，event_add将其加入到event_base的小根堆timeheap；
Signale事件的管理相对复杂些，event_add将其加入到注册事件链表，同时，event_add内部会调用I/O demultiplex的add函数（对于I/O事件也一样），比如epoll_add。而add函数又会调用evsignal_add将其加入到evsignal_info的evsigevents[signo]链表(关于signal，后面会详细介绍)。

3、事件处理框架主循环
Libevent将I/O事件、signal事件和timer事件用统一的模型进行处理，这是非常精妙的。libevent主循环函数不断检测注册事件，如果有事件发生，则将其放入就绪链表，并调用事件的回调函数，完成业务逻辑处理。
3.1、event_dispatch
//事件处理主循环
int
event_dispatch(void)
这是呈现给外部的接口，它的实现很简单，即调用event_loop，而event_loop调用event_base_loop，event_base_loop完成实际的主循环逻辑。

3.2、event_base_loop
主要算法：

1 done = 0;
2 while (!done) {
3
4 /*如果没有就绪事件,根据timer heap中事件的最小超时时间,计算I/O demultiplex的
5 **最大等待时间. 相反,如果有就绪事件,则清除tv,即I/O demultiplex不应该等待.
6 */
7 if (!base->event_count_active && !(flags & EVLOOP_NONBLOCK)) {
8     timeout_next(base, &tv_p);
9 } else {
10     /*
11      * if we have active events, we just poll new events
12      * without waiting.
13      */
14     evutil_timerclear(&tv);
15 }
16
17 /* If we have no events, we just exit */
18 //没有事件处理,则退出循环
19 if (!event_haveevents(base)) {
20     event_debug(("%s: no events registered.", __func__));
21     return (1);
22 }
23
24 //tv_p为I/O demultiplex的超时时间
25 //处理signal事件和I/O事件
26 res = evsel->dispatch(base, evbase, tv_p);
27
28 //处理timeout事件,对于超时的事件,将其放到就绪事件链表
29 timeout_process(base);
30
31 if (base->event_count_active) {
32     //处理就绪事件
33     event_process_active(base);
34     if (!base->event_count_active && (flags & EVLOOP_ONCE))
35         done = 1;
36 } else if (flags & EVLOOP_NONBLOCK)
37     done = 1;
38
39 }//end while
40

3.3、timeout_next

1 /*根据timer heap中事件的最小超时时间,计算I/O demultiplex的最大等待时间.
2 **为了及时处理timer事件,I/O demultiplex的最大等待时间不应该超过timer事件中最小的超时时间,
3 **否则,timer事件就不能得到及时处理
4 */
5 static int
6 timeout_next(struct event_base *base, struct timeval **tv_p)
7 {
8     struct timeval now;
9     struct event *ev;
10     struct timeval *tv = *tv_p;
11
12     //如果没有timer事件,则直接返回
13     if ((ev = min_heap_top(&base->timeheap)) == NULL) {
14         /* if no time-based events are active wait for I/O */
15         *tv_p = NULL;
16         return (0);
17     }
18
19     if (gettime(base, &now) == -1)
20         return (-1);
21
22     //如果最小的timer事件已经超时,则清除tv,即I/O demultiplex不应该等待.
23     if (evutil_timercmp(&ev->ev_timeout, &now, <=)) {
24         evutil_timerclear(tv);
25         return (0);
26     }
27
28     //更新I/O demultiplex可以等待的最大时间:ev->ev_timeout - now
29     evutil_timersub(&ev->ev_timeout, &now, tv);
30     return (0);
31 }
32

3.4、dispatch函数
调用底层I/O multiplex的dispatch函数，具体的实现可以参见epoll的实现epoll_dispatch。

3.5、event_process_active

1 /*处理就绪事件.
2 **就绪事件位于优先级队列中,低优先级通常比高优先级队列先处理,所以,
3 **高优先级队列可能饿死.
4 */
5 static void
6 event_process_active(struct event_base *base)
7 {
8     struct event *ev;
9     struct event_list *activeq = NULL;
10     int i;
11     short ncalls;
12
13     for (i = 0; i < base->nactivequeues; ++i) {
14         if (TAILQ_FIRST(base->activequeues[i]) != NULL) {
15             //一次只处理一个就绪事件链表
16             activeq = base->activequeues[i];
17             break;
18         }
19     }
20
21     assert(activeq != NULL);
22
23     //处理就绪事件链表上的所有事件
24     for (ev = TAILQ_FIRST(activeq); ev; ev = TAILQ_FIRST(activeq)) {
25
26         //先将事件从链表上删除
27         if (ev->ev_events & EV_PERSIST)
28             event_queue_remove(base, ev, EVLIST_ACTIVE);
29         else
30             event_del(ev); //删除事件
31
32         /* Allows deletes to work */
33         ncalls = ev->ev_ncalls;
34         ev->ev_pncalls = &ncalls;
35         while (ncalls) {
36             ncalls--; //调用次数减1
37             ev->ev_ncalls = ncalls;
38             //调用事件的回调函数
39             (*ev->ev_callback)((int)ev->ev_fd, ev->ev_res, ev->ev_arg);
40             if (base->event_break)
41                 return;
42         }
43     }
44 }
45

4、Timer事件
Timer事件的处理本身比较简单，不再赘述。

5、signal事件
5.1、socket pair
Libevent通过socketpair，将signal事件与I/O事件完美的统一起来。Socketpair，简单的说就一对socket，一端用于写，一端用于读。工作方式如下：

为了与I/O事件统一起来，libevent内部使用了一个针对read socket的读事件。

5.1.1、Socketpair的创建
与信号事件的初始化工作都是在evsignal_init中完成的，而evsignal_init通过调用evutil_socketpair创建socketpair。对于Unix平台，有socketpair系统调用；对于Windows，则相对复杂一些，具体见evutil_socketpair函数的实现。

5.2、evsignal_info
在event_base内部有一个evsignal_info类型的字段sig，它是用于管理signal事件的核心数据结构：

1 //evsignal.h
2 struct evsignal_info {
3 struct event ev_signal;    //内部socket读事件
4 int ev_signal_pair[2];  //对应socket pair的两个socket描述符
5 int ev_signal_added;  //内部socket读事件是否已经加入注册链表
6 volatile sig_atomic_t evsignal_caught; //是否有信号发生
7 //信号事件链表数组,evsigevents[signo]表示注册信号signo的事件
8 struct event_list evsigevents[NSIG];
9 //具体记录每个信号触发的次数，evsigcaught[signo]是记录信号 signo被触发的次数
10 sig_atomic_t evsigcaught[NSIG];
11
12 //sh_old记录了原来的 signal 处理函数指针，当信号 signo 注册的 event 被清空时，需要重新设置其处理函数
13 #ifdef HAVE_SIGACTION
14 struct sigaction **sh_old;
15 #else
16 ev_sighandler_t **sh_old;
17 #endif
18 int sh_old_max;
19 };
20

5.3、主要函数
5.3.1、evsignal_init
主要完成evsignal_info的初始化，主要算法：

1 int
2 evsignal_init(struct event_base *base)
3 {
4 evutil_socketpair(AF_UNIX, SOCK_STREAM, 0, base->sig.ev_signal_pair);
5 base->sig.sh_old = NULL;
6 base->sig.sh_old_max = 0;
7
8 //事件发生次数设为0
9 base->sig.evsignal_caught = 0;
10 memset(&base->sig.evsigcaught, 0, sizeof(sig_atomic_t)*NSIG);
11 /* initialize the queues for all events */
12 for (i = 0; i < NSIG; ++i)
13 TAILQ_INIT(&base->sig.evsigevents[i]);
14
15 evutil_make_socket_nonblocking(base->sig.ev_signal_pair[0]); //写端
16
17 //设置内部读事件
18 event_set(&base->sig.ev_signal, base->sig.ev_signal_pair[1],
19 EV_READ | EV_PERSIST, evsignal_cb, &base->sig.ev_signal); //读端
20 base->sig.ev_signal.ev_base = base;
21
22 //sig.ev_signal == EV_READ | EV_PERSIST | EVLIST_INTERNAL
23 base->sig.ev_signal.ev_flags |= EVLIST_INTERNAL;
24 }

该函数的关键在于这里会设置libevent用于管理信号事件的内部读事件evsignal_info的ev_signal，并将该事件对应的文件描述符设为socket pair的读端。该函数由I/O multiplex的init函数调用。注：这里只是设置，而并没有注册socket pair的读事件(见下一节)。

5.3.2、evsignal_add
当调用event_add注册信号事件时，内部会先调用I/O multiplex的add函数，add函数又会调用evsignal_add，将事件加到evsignal_info内部的信号事件链表。然后再event_queue_insert将其添加到event_base的注册事件链表。

1 int
2 evsignal_add(struct event *ev)
3 {
4     int evsignal;
5     struct event_base *base = ev->ev_base;
6     struct evsignal_info *sig = &ev->ev_base->sig;
7
8     //信号事件与I/O事件是不相容的
9     if (ev->ev_events & (EV_READ|EV_WRITE))
10         event_errx(1, "%s: EV_SIGNAL incompatible use", __func__);
11     //事件的信号
12     evsignal = EVENT_SIGNAL(ev);
13     assert(evsignal >= 0 && evsignal < NSIG);
14     if (TAILQ_EMPTY(&sig->evsigevents[evsignal])) {
15         event_debug(("%s: %p: changing signal handler", __func__, ev));
16
17         //注册信号处理函数evsignal_handler
18         //向socket pair的写端写入一个字节的数据
19         if (_evsignal_set_handler(
20                 base, evsignal, evsignal_handler) == -1)
21             return (-1);
22
23         /* catch signals if they happen quickly */
24         evsignal_base = base;
25
26         //添加内部socket读事件sig->ev_signal
27         if (!sig->ev_signal_added) {
28             if (event_add(&sig->ev_signal, NULL))
29                 return (-1);
30             sig->ev_signal_added = 1;
31         }
32     }
33
34     /* multiple events may listen to the same signal */
35     //添加信号事件链表
36     TAILQ_INSERT_TAIL(&sig->evsigevents[evsignal], ev, ev_signal_next);
37
38     return (0);
39 }
40

这里有两个地方需要注意，一是调用_evsignal_set_handler设置外部注册信号事件对应的信号的信号处理函数evsignal_handler：

1 static void
2 evsignal_handler(int sig)
3 {
4     int save_errno = errno;
5
6     //设置信号事件的发生次数
7     evsignal_base->sig.evsigcaught[sig]++;
8     evsignal_base->sig.evsignal_caught = 1;
9
10 #ifndef HAVE_SIGACTION
11     signal(sig, evsignal_handler);
12 #endif
13
14     /* Wake up our notification mechanism */
15     //向socket pair的写端写数据
16     send(evsignal_base->sig.ev_signal_pair[0], "a", 1, 0);
17     errno = save_errno;
18 }

当用户注册信号事件对应的信号发生时，OS转到evsignal_handler函数，从而设置sig.evsignal_caught，并向socket pair的写端发送数据。
二是通过调用event_add完成内部socket pair的读事件sig->ev_signal的注册。最后，将（外部）事件添加到信号事件链表。
5.3.2、与主循环结合
信号事件完成了注册，libevent就会在主循环中，等待事件发生，并处理事件。为了理解，来看看具体I/O demultiplex的dispatch函数：

1 static int
2 epoll_dispatch(struct event_base *base, void *arg, struct timeval *tv)
3 {
4     struct epollop *epollop = arg;
5     struct epoll_event *events = epollop->events;
6     struct evepoll *evep;
7     int i, res, timeout = -1;
8
9     if (tv != NULL)
10         timeout = tv->tv_sec * 1000 + (tv->tv_usec + 999) / 1000;
11
12     if (timeout > MAX_EPOLL_TIMEOUT_MSEC) {
13         /* Linux kernels can wait forever if the timeout is too big;
14          * see comment on MAX_EPOLL_TIMEOUT_MSEC. */
15         timeout = MAX_EPOLL_TIMEOUT_MSEC;
16     }
17
18     //等待I/O事件
19     res = epoll_wait(epollop->epfd, events, epollop->nevents, timeout);
20
21     if (res == -1) {
22         if (errno != EINTR) {
23             event_warn("epoll_wait");
24             return (-1);
25         }
26         //epoll_wait被信号中断
27         evsignal_process(base);
28         return (0);
29     } else if (base->sig.evsignal_caught) {//发生了信号事件
30         //处理信号事件
31         evsignal_process(base);
32     }
33 //…
34 }

epoll_dispatch函数调用epoll_wait函数等待I/O发生。然后，如果有信号事件发生，则调用evsignal_process处理信号事件，evsignal_process的逻辑比较简单，它只是将事件从注册事件链表转移到就绪事件链表。

还记得evsignal_handler函数吗？它是所有（外部）信号事件对应的信号的信号处理函数，将实际的信号发生时，OS会转而执行evsignal_handler函数，而它便向socket pair的写端写数据，而读端收到数据。而此时，libevent的内部socket pair读事件已经完成注册。libevent正阻塞在epoll_wait处，当socketp pair读端收到数据时，libevent便从epoll_wait处返回。总之，signal事件通过socket pair，与I/O事件实现完美的统一。

Libevent从epoll_wait返回后，它调用evsignal_process处理信号事件，然后调用event_active将I/O事件（包括内部的socket pair读事件）转移到就绪事件链表。

Socket pair的读事件回调函数：

1 static void
2 evsignal_cb(int fd, short what, void *arg)
3 {
4 static char signals[1];
5 #ifdef WIN32
6 SSIZE_T n;
7 #else
8 ssize_t n;
9 #endif
10 //接收数据
11 n = recv(fd, signals, sizeof(signals), 0);
12 if (n == -1)
13 event_err(1, "%s: read", __func__);
14 }

6、libevent的应用
Libevent是一个非常优秀的开源网络库，它被许多其它开源程序使用。Memcache使用libevent作为底层的网络处理组件，并采用主线程(main thread，单一)+工作线程(work thread，多个)的多线程模型（这将在Memcached的分析中详细介绍）。

本文链接

vim7.2中文乱码解决方法

2010-07-29T11:42:00Z

这个问题困扰我几天了。网上查了许久，由于说得不到位，一直没解决，今天又折腾了一下，终于搞定。

1、下载

可到http://www.vim.org/下载最新的7.2。

2、安装

编译之前，先要configure --help查看一下配置选项，
--enable-multibyte Include multibyte editing support.

支持多字节编码，这一步很重要。否则，后面如何配置也是枉然。

然后，
[root@localhost wbl]# vim --version | grep multi
-mouse_jsbterm -mouse_netterm -mouse_sysmouse +mouse_xterm +multi_byte
+multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra -perl +postscript
查看配置是否起作用。

3、配置

编辑~/.vimrc文件，加上如下几行：

set fileencodings=gb2312,gb18030,utf-8
set termencoding=utf-8
set encoding=prc

即可搞定。

附(Vim编码详细介绍)：

Vim和所有的流行文本编辑器一样，Vim 可以很好的编辑各种字符编码的文件，这当然包括 UCS-2、UTF-8 等流行的 Unicode 编码方式。

Vim 有四个跟字符编码方式有关的选项，encoding、fileencoding、fileencodings、termencoding (这些选项可能的取值请参考 Vim 在线帮助 :help encoding-names)，它们的意义如下:
(1)encoding: Vim 内部使用的字符编码方式，包括 Vim 的 buffer (缓冲区)、菜单文本、消息文本等。用户手册上建议只在 .vimrc 中改变它的值，事实上似乎也只有在 .vimrc 中改变它的值才有意义。
(2)fileencoding: Vim 中当前编辑的文件的字符编码方式，Vim 保存文件时也会将文件保存为这种字符编码方式 (不管是否新文件都如此)。
(3)fileencodings: Vim 启动时会按照它所列出的字符编码方式逐一探测即将打开的文件的字符编码方式，并且将 fileencoding 设置为最终探测到的字符编码方式。因此最好将 Unicode 编码方式放到这个列表的最前面，将拉丁语系编码方式 latin1 放到最后面。
(4)ermencoding: Vim 所工作的终端 (或者 Windows 的 Console 窗口) 的字符编码方式。这个选项在 Windows 下对我们常用的 GUI 模式的 gVim 无效，而对 Console 模式的 Vim 而言就是 Windows 控制台的代码页，并且通常我们不需要改变它。

来看看 Vim 的多字符编码方式支持是如何工作的。
(1)Vim 启动，根据 .vimrc 中设置的 encoding 的值来设置 buffer、菜单文本、消息文的字符编码方式。
(2)读取需要编辑的文件，根据 fileencodings 中列出的字符编码方式逐一探测该文件编码方式。并设置 fileencoding 为探测到的，看起来是正确的 (注1) 字符编码方式。
(3)对比 fileencoding 和 encoding 的值，若不同则调用 iconv 将文件内容转换为 encoding 所描述的字符编码方式，并且把转换后的内容放到为此文件开辟的 buffer 里，此时我们就可以开始编辑这个文件了。注意，完成这一步动作需要调用外部的 iconv.dll (注2)，你需要保证这个文件存在于 $VIMRUNTIME 或者其他列在 PATH 环境变量中的目录里。
(4)编辑完成后保存文件时，再次对比 fileencoding 和 encoding 的值。若不同，再次调用 iconv 将即将保存的 buffer 中的文本转换为 fileencoding 所描述的字符编码方式，并保存到指定的文件中。同样，这需要调用 iconv.dll

由于 Unicode 能够包含几乎所有的语言的字符，而且 Unicode 的 UTF-8 编码方式又是非常具有性价比的编码方式 (空间消耗比 UCS-2 小)，因此建议 encoding 的值设置为 utf-8。这么做的另一个理由是 encoding 设置为 utf-8 时，Vim 自动探测文件的编码方式会更准确 (或许这个理由才是主要的 ;) 。我们在中文 Windows 里编辑的文件，为了兼顾与其他软件的兼容性，文件编码还是设置为 GB2312/GBK 比较合适，因此 fileencoding 建议设置为 chinese (chinese 是个别名，在 Unix 里表示 gb2312，在 Windows 里表示 cp936，也就是 GBK 的代码页)。

本文链接

SlickEdit的破解

2010-07-22T04:55:00Z

SlickEdit是一个非常不错的编辑器，相对于SI，更有开发环境的味道。不过，相对于Vim，它们都是收费的。在公司购买的正版软件列表上没有找到，

只好下载一个，破解之。

下载：

http://www.slickedit.com/trial/slickedit

安装后，需要授权文件。

先不管它，下面用hiew——强大的反汇编工具，来破解win/vs.exe。

>hiew32 vs.exe

按两次<Enter>，进入汇编模式。

按<F5>，输入F750，转到0040F750处；

按<F3>，切换在编辑模式，

将 mov eax, ebp 改成 xor eax,eax ；

回车，按<F9>保存，两分钟搞定。

再运行SlickEdit，不再出现授权界面。

本文链接

Hbase初体验

2010-07-01T07:38:00Z

1、配置

(1)编辑$HBASE_HOME/conf/ hbase-env.sh配置环境变量JAVA_HOME;

(2)编辑$HBASE_HOME/conf/hbase-site.xml, 增加如下配置(与Hadoop保持一致)：

<property>
    <name>hbase.rootdir</name>
    <value>hdfs://localhost:9000/hbase</value>
    <description>The directory shared by region servers.
    </description>
</property>

2、使用

#启动HBase
[root@yy1 hbase-0.20.5]# bin/start-hbase.sh
localhost: starting zookeeper, logging to /root/hadoop/hbase-0.20.5/bin/../logs/hbase-root-zookeeper-yy1.out
starting master, logging to /root/hadoop/hbase-0.20.5/bin/../logs/hbase-root-master-yy1.out
localhost: starting regionserver, logging to /root/hadoop/hbase-0.20.5/bin/../logs/hbase-root-regionserver-yy1.out

[root@yy1 hbase-0.20.5]# bin/hbase shell
HBase Shell; enter 'help<RETURN>' for list of supported commands.
Version: 0.20.5, r956266, Sat Jun 19 12:25:12 PDT 2010
hbase(main):001:0>

#创建表test
hbase(main):003:0> create "test","data"
0 row(s) in 1.3560 seconds
hbase(main):004:0> describe "test"
DESCRIPTION ENABLED
{NAME => 'test', FAMILIES => [{NAME => 'data', COMPRESSION => 'NONE', true
VERSIONS => '3', TTL => '2147483647', BLOCKSIZE => '65536', IN_MEMORY
=> 'false', BLOCKCACHE => 'true'}]}
1 row(s) in 0.0610 seconds

#插入数据
hbase(main):005:0> put "test","row1","data:1","value1"
0 row(s) in 0.0060 seconds
hbase(main):006:0> put "test","row2","data:2","value2"
0 row(s) in 0.0100 seconds
hbase(main):007:0> scan "test"
ROW                          COLUMN+CELL
row1                        column=data:1, timestamp=1277968472718, value=value1
row2                        column=data:2, timestamp=1277968487913, value=value2
2 row(s) in 0.0350 seconds

hbase(main):009:0> get "test", "row1"
COLUMN CELL
data:1 timestamp=1277968472718, value=value1
1 row(s) in 0.0100 seconds

#停止HBase
[root@yy1 hbase-0.20.5]# bin/stop-hbase.sh
stopping master..............................
localhost: stopping zookeeper.

#HBase创建的文件
[root@yy1 hadoop-0.20.2]# bin/hadoop fs -ls /hbase
Found 5 items
drwxr-xr-x   - root supergroup          0 2010-07-01 14:51 /hbase/-ROOT-
drwxr-xr-x   - root supergroup          0 2010-07-01 14:51 /hbase/.META.
drwxr-xr-x   - root supergroup          0 2010-07-01 15:18 /hbase/.logs
-rw-r--r--   3 root supergroup          3 2010-07-01 14:51 /hbase/hbase.version
drwxr-xr-x   - root supergroup          0 2010-07-01 15:12 /hbase/test
[root@yy1 hadoop-0.20.2]# bin/hadoop fs -ls /hbase/test
Found 1 items
drwxr-xr-x   - root supergroup          0 2010-07-01 15:18 /hbase/test/1886847087

本文链接

Hadoop初体验——问题总结

2010-06-30T09:22:00Z

第一次使用Hadoop，整个过程真是让我折腾。

先是在cygwin下，出现如下问题：

cygwin :1.7.5-1
openssh :5.5p1-2
openssl :0.9.8o-2

ssh已经配置，且在cygwin下输入：
net start sshd
显示成功启动

然后输入，
ssh localhost
此时，没有任何输出，一直挂着。

事件查看器输出如下错误：
sshd: PID 632: error: setsockopt IPV6_V6ONLY: Protocol not available.
似乎是sshd内部调用setsockopt设置IPV6_V6ONLY出错。

搞了很久，也没搞好。只好做罢，在vmware中又遇到各种问题：

1、safemode

bin/hadoop fs -put ./input input
put: org.apache.hadoop.hdfs.server.namenode.SafeModeException: Cannot create directory /user/root/input. Name node is in safe mode.

解决方法：

NameNode在启动的时候首先进入安全模式，如果datanode丢失的block达到一定的比例（1-dfs.safemode.threshold.pct），则系统会一直处于安全模式状态即只读状态。

dfs.safemode.threshold.pct（缺省值0.999f）表示HDFS启动的时候，如果DataNode上报的block个数达到了元数据记录的block个数的0.999倍才可以离开安全模式，否则一直是这种只读模式。如果设为1则HDFS永远是处于SafeMode。

下面这行摘录自NameNode启动时的日志（block上报比例1达到了阀值0.9990）

The ratio of reported blocks 1.0000 has reached the threshold 0.9990. Safe mode will be turned off automatically in 18 seconds.
hadoop dfsadmin -safemode leave

有两个方法离开这种安全模式
（1）修改dfs.safemode.threshold.pct为一个比较小的值，缺省是0.999。
（2）hadoop dfsadmin -safemode leave命令强制离开

用户可以通过dfsadmin -safemode value 来操作安全模式，参数value的说明如下：

enter - 进入安全模式
leave - 强制NameNode离开安全模式
get - 返回安全模式是否开启的信息
wait - 等待，一直到安全模式结束。

2、could only be replicated to 0 nodes, instead of 1

#执行 fs -put时，出现如下问题

hdfs.DFSClient: DataStreamer Exception: org.apache.hadoop
.ipc.RemoteException: java.io.IOException: ... could only be replicated to 0 nodes, instead of 1 ...

解决方法：
（1）防火墙原因
（2）磁盘空间原因
df –ah #查看磁盘空间
如果是磁盘空间不够，则调整磁盘空间(我就是该原因，折腾了很久)，推荐一个强大的分区工具GParted 。

3、DataNode error

2010-06-25 11:40:12,473 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode:
java.io.IOException: Incompatible namespaceIDs in /tmp/hadoop-root/dfs/data:
namenode namespaceID = 647870650; datanode namespaceID = 466015089

解决方法：

删除 /tmp/hadoop-root/dfs目录下的所有目录，
执行hadoop namenode -format

很久没有用过Java了，原以为以后不会再有机会使用。但是，有Hadoop这样优秀的开源项目，不得不又重新拾起Java。

本文链接