aufs 存储机制

aufs存储机制已经发展到超出了改进squid磁盘I/O响应时间的最初尝试。"a"代表着异步I/O。默认的ufs和aufs之间的唯一区别，在于I/O是否被squid主进程执行。数据格式都是一样的，所以你能在两者之间轻松选择，而不用丢失任何cache数据。 

aufs使用大量线程进行磁盘I/O操作。每次squid需要读写，打开关闭，或删除cache文件时，I/O请求被分派到这些线程之一。当线程完成了I/O后，它给squid主进程发送信号，并且返回一个状态码。实际上在squid2.5中，某些文件操作默认不是异步执行的。最明显的，磁盘写总是同步执行。你可以修改src/fs/aufs/store_asyncufs.h文件，将ASYNC_WRITE设为1，并且重编译squid。 

aufs代码需要pthreads库。这是POSIX定义的标准线程接口。尽管许多Unix系统支持pthreads库，但我经常遇到兼容性问题。aufs存储系统看起来仅仅在Linux和Solaris上运行良好。在其他操作系统上，尽管代码能编译，但也许会面临严重的问题。 

为了使用aufs，可以在./configure时增加一个选项： 
% ./configure --enable-storeio=aufs,ufs 

严格讲，你不必在storeio模块列表中指定ufs。然而，假如你以后不喜欢aufs，那么就需要指定ufs，以便能重新使用稳定的ufs存储机制。 
假如愿意，你也能使用—with-aio-threads=N选项。假如你忽略它，squid基于aufs cache_dir的数量，自动计算可使用的线程数量。表8-1显示了1-6个cache目录的默认线程数量。 
Table 8-1. Default number of threads for up to six cache directories 
cache_dirs Threads 
1 16 
2 26 
3 32 
4 36 
5 40 
6 44 

将aufs支持编译进squid后，你能在squid.conf文件里的cache_dir行后指定它： 
cache_dir aufs /cache0 4096 16 256 

在激活了aufs并启动squid后，请确认每件事仍能工作正常。可以运行tail -f store.log一会儿，以确认缓存目标被交换到磁盘。也可以运行tail -f cache.log并且观察任何新的错误或警告。 


8.4.1 aufs如何工作 

Squid通过调用pthread_create来创建大量的线程。所有线程在任何磁盘活动之上创建。这样，即使squid空闲，你也能见到所有的线程。 
无论何时，squid想执行某些磁盘I/O操作（例如打开文件读），它分配一对数据结构，并将I/O请求放进队列中。线程循环读取队列，取得I/O请求并执行它们。因为请求队列共享给所有线程，squid使用独享锁来保证仅仅一个线程能在给定时间内更新队列。 

I/O操作阻塞线程直到它们被完成。然后，将操作状态放进一个完成队列里。作为完整的操作，squid主进程周期性的检查完成队列。请求磁盘I/O的模块被通知操作已完成，并获取结果。 

你可能已猜想到，aufs在多CPU系统上优势更明显。唯一的锁操作发生在请求和结果队列。然而，所有其他的函数执行都是独立的。当主进程在一个CPU上执行时，其他的CPU处理实际的I/O系统调用。 


8.4.2 aufs发行 
线程的有趣特性是所有线程共享相同的资源，包括内存和文件描述符。例如，某个线程打开一个文件，文件描述符为27，所有其他线程能以相同的文件描述符来访问该文件。可能你已知道，在初次管理squid时，文件描述符短缺是较普遍问题。Unix内核典型的有两种文件描述符限制： 
进程级的限制和系统级的限制。你也许认为每个进程拥有256个文件描述符足够了（因为使用线程），然而并非如此。在这样的情况下，所有线程共享少量的文件描述符。请确认增加系统的进程文件描述符限制到4096或更高，特别在使用aufs时。 

调整线程数量有点棘手。在某些情况下，可在cache.log里见到如下警告： 
2003/09/29 13:42:47| squidaio_queue_request: WARNING - Disk I/O overloading 

这意味着squid有大量的I/O操作请求充满队列，等待着可用的线程。你首先会想到增加线程数量，然而我建议，你该减少线程数量。 

增加线程数量也会增加队列的大小。超过一定数量，它不会改进aufs的负载能力。它仅仅意味着更多的操作变成队列。太长的队列导致响应时间变长，这绝不是你想要的。 

减少线程数量和队列大小，意味着squid检测负载条件更快。当某个cache_dir超载，它会从选择算法里移除掉（见7.4章）。然后，squid选择其他的cache_dir或简单的不存储响应到磁盘。这可能是较好的解决方法。尽管命中率下降，响应时间却保持相对较低。 


8.4.3 监视aufs操作 

Cache管理器菜单里的Async IO Counters选项，可以显示涉及到aufs的统计信息。它显示打开，关闭，读写，stat，和删除接受到的请求的数量。例如： 
% squidclient mgr:squidaio_counts 
... 
ASYNC IO Counters: 
Operation       # Requests 
open             15318822 
close            15318813 
cancel           15318813 
write                   0 
read             19237139 
stat                    0 
unlink            2484325 
check_callback  311678364 
queue                   0 

取消(cancel)计数器正常情况下等同于关闭(close)计数器。这是因为close函数总是调用cancel函数，以确认任何未决的I/O操作被忽略。 
写(write)计数器为0，因为该版本的squid执行同步写操作，即使是aufs。 

check_callbak计数器显示squid主进程对完成队列检查了多少次。 

queue值显示当前请求队列的长度。正常情况下，队列长度少于线程数量的5倍。假如你持续观察到队列长度大于这个值，说明squid配得有问题。增加更多的线程也许有帮助，但仅仅在特定范围内。