和Lighttpd搏斗的一天

原贴:http://blog.scaner.i.thu.cn/index.php/2006/11/17/live-with-lighttpd-2006-11-16/

和Lighttpd搏斗的一天 November 17, 2006

Posted by scaner in : Coding, Linux, Web , trackback

昨天的事情。随便记录一下

具体情况是这样的,完全静态内容,1.4M左右的小文件,每个文件3k-8k(基本上是小图片文件)。每秒完成请求在1000个左右。这个时候,由于disk io的压力,会直接导致Lighttpd整个被block住,包括网络部分。

首先的救急解决方案,别的不废话,Lighttpd同时开上四个,前面堆一个Haproxy,暂时先抗着。虽然还是不怎么样,至少不会全死了,说得过去,继续折腾。

这两天Lighty的作者非常的积极,1.5-pre2发布出来了,还专门在Blog上 讨论了Linux AIO这个现代科技。不管怎么说,光是看着统一的mod_cache核结构,也很值得期待的试一下。弄回来build一run,虽然使用了linux- aio-sendfile做network backend,一样的死菜。察看了一下代码……,可能是考虑效率方面的问题吧,所有小于一个标准page size(x86上就是4K啦)的内容,都是直接sendfile了,没有经过aio这步。咬咬牙,改了程序,拼死aio,不管多大的内容,都用aio的 过程操作。初步的测试表现,都挺好,不过一上压力,又挂了……问题出在Lighttpd 1.5缺省只有64个aio控制块,也就是说最多积压64个io任务,在多就又变成directly sendfile了。这64个对于每秒上百的请求根本没啥作用。继续修改程序,把64修改成128,256,512,都还是会有任务队列冲满的情况。拼死 加到2048个,确实冲满是不发生了,不过io block情况照旧的恶劣,唯一的好处,就是connection还是能正常地accept,请求的处理,该堵的堵,该慢的慢,没有在多变化了。基本上结 论就是,lighttpd aio,对于非常多的非常小文件服务,基本上是没有什么帮助了,除了能保证不因为disk io导致network io的block。不过这个保证也是没有什么用的,如果没有强劲的disk io支持,没有数据往外吐,network io还是要停下来的。而且aio需要以O_DIRECT方式打开文件,貌似会导致系统的buffer不缓存文件,进一步加重disk负载,反而是负面影响 了。情况就这样了,一天搏斗就是得出这个不算结论的结论。

Comments»

1. snailfly yin - December 26, 2006

lighttpd是web server,如果io吞吐量不足,无论怎么调整也没法超越IO这个瓶颈吧.如果在前端放置mod_mem_cache或用squid cache_dir null 做全内存cache不知道能不能解决?

 

你可能感兴趣的:(linux,IO,cache,lighttpd,NetWork,disk)