Nginx c30k问题 Nginx的c30k问题解决办法

最近我们的下载服务遭遇了c30k，导致nginx的下载服务近乎停滞。原因嘛，很简单，服务器部署在国外，众所周知的原因，SL机房的线路不稳，加上不同地区出口速率抖动很厉害，为了加速下载，我们放开了限制，允许用户使用多线程的下载工具。这样一来，自然产生了c10k问题。下载文件都不小，每个用户至少使用4线程，同时下载若干个素材。。。很自然并发链接数30k以上。

更受限于手头money，无法扩容（实际上要有钱也不会跑国外)。因此，必须提高单机并发能力和吞吐量。

我们的下载服务是使用Perl写的一个Plack应用，典型的PSGI，实现下载验证，实时防火墙，用户下载跟踪等等，无法直接使用静态文件分发（实际上Perl的性能还是很高效的，部署于Starman，对比PHP的实现，是后者（PHP-FPM)的10倍左右）。

Starman是一个很不错的PSGI Server，它使用传统的Prefork模式。即便高效，但Prefork确实无法有效应对c10k，我无法把Starman的worker增大到几百上千个。在以前的文章曾经提到Evented IO是能够应付c10k的一个方案。因此，我使用Twiggy换下了Starman。Twiggy是基于AE(AnyEvent)的一个PSGI Server，单进程。在低并发下，单进程的Twiggy的qps是弱于Starman，不过到了高并发，Twiggy的优势就显现出来了。在实际部署中，我启动了多个Twiggy进程，分别监听独立的端口，nginx则使用upstream进行负载均衡。 10个Twiggy的吞吐量已经远远超过了50个Starman worker。 Twiggy的开销也不大，因此可以很放心的增加Twiggy的进程。

感谢PSGI的接口规范，从Starman切换到Twiggy，应用程序无需做任何改动。（前提是程序内不能有阻塞io的操作）。

另一个问题是服务器的IO-Wait比较高，毕竟下载这个是IO-Bound的任务。

Nginx支持Linux Native AIO，因此我考虑是否使用AIO能够大大降低IO-Wait? 性能应该有比较明显的提升？

网上有一些资料，吹嘘的Nginx AIO性能提升，神奇云云。我有点将信将疑，因为都没有任何的测试数据比较，均是人云亦云。另外，多数配置都是或多或少有问题的。

我使用的CentOS, Nginx AIO要使用，必须是CentOS 5.5以上。因为只有5.5的kernel才有AIO的backport，nginx并没有使用libaio。

此外，Nginx的AIO本来是为FreeBSD开发，Linux固然可以使用，不过受到了Linux AIO的很多限制。

1. 必须使用Direct IO. 这样一来，导致无法使用vm的disk cache.
2. 文件只有大小和directio_alignment定义block size整数倍的数据才可以使用AIO，当文件整数据块之前和之后，那些不能取整的部分则是blocking方式读取的，这也是为什么需要output-buffer。directio_alignment大小取决于你使用的文件系统，默认是512,而对于XFS，注意，如果你没有修改XFS bsize, 需要调整为XFS默认的4k.

我使用的配置如下：

当启用AIO后，可以看到vmstat中,cache的内存消耗迅速降低，这是因为使用AIO必须使用directio,这就绕过了vm的diskcache。

实际性能如何，AIO一定很快么？ 这点即便是Igor也不确定。

从我们自己的实际效果看，AIO并没有明显的性能提升，相反，偶尔会轻微增加了IO-Wait，这是因为无法利用diskcache，而如果文件多数又和directio_alignment有偏差（尤其是断点续传的时候，多数文件读取位置在directio_alignment数据边界外），这部分的数据必须使用blocking io读取，又没有disk cache，增加IO－Wait也可以理解。

最终，结论是，与其使用不那么靠谱的Nginx AIO, 不如多开一些Nginx的worker，重复利用vm disk cache， 当内存100%利用率的时候，nginx的静态文件分发效率是高于AIO模式的。

BTW，这个实际用例也重新印证了我的一个观点，不要轻信网上那些毫无测试数据的忽悠，多数都是copy & paste的传说, 各个说好，其实多数都没实际印证过。