nginx的问题(续)

昨天说了nginx的几个问题，

由于我现在支持的主要是通用CDN，也就是小图片和CSS以及JS这些东西，并没有做大文件的cache。而问了我们视频部门他们也根本不用nginx作为cache使用，所以有些问题还是没考虑周到。 一个问题是之前发现的，在做tmpfs的时候，当你设置的cache大小为tmpfs的90%的时候，一旦要缓存的内容大于这个90%的时候，nginx会自己崩溃掉。这个我明天做个测试再重现一下，现在有点忘记原因了，好像是tmpfs会占用到实际的磁盘才导致的。 另外一个其实是upstream的问题，这个是一个新浪的老兄提的，基本现在是无解。问题是：比如平均一个文件10M，你在磁盘上存3000个文件，然后模拟多个客户端去访问，因为shm一开始是空的，所以都会去后端拽文件，我们放慢这个拽的过程，比如说网络不好吧 呵呵，那么第一个请求发现不在lookup失败，就会去upstream取数据，边取边向downsteam发，并且存在一个临时文件中，这时第二个请求来了也请求这个文件，因为第一个请求没有处理完，所以第二个请求找不到目标文件只好继续去后端拽，又生成临时文件，并发量大的时候，一个大文件会对应N多的临时文件，最终这些文件rename到一个目标文件，大大浪费了磁盘IO。这个rename是内核做的，nginx调完之后就返回了。这种问题往往会导致内部网络流量非常大，而实际却没有根本没有大。 当有多个连接来获取同一个文件的时候，squid中却没有跟nginx cache一样的问题。我们看看squid是怎么解决的吧。我们在squid有这样一个参数collapsed_forwarding on（http://wiki.squid-cache.org/Features/CollapsedForwarding），一旦设置了参数了，当发现有连接请求同一个文件的时候，squid会合并多个连接，但是它会以最慢速的那个连接去取，然后同步地传送给客户端。这样就不会重复请求后端了。但是squid也有问题，因为首先它是同步的。当用户请求的是动态的内容的话会导致客户端错误。而且当一个用户连接速度很快，一个用户连接速度很慢，那就会以最慢的速度进行获取和传输。所以在squid3.0以后取消了这个参数。 这个问题的解决办法暂时看起来只能在nginx cache前充一下热点的大文件。还好一般内网都是千兆连接，这个速度往往大于用户的连接速度。只有当文件特别大，并且热点文件特别多的情况下才会发生。而且nginx这种处理方式也有一定的好处。 nginx upstream流程我们可以参考http://bollaxu.javaeye.com/blog/900424和http://bollaxu.javaeye.com/blog/900357这2篇文章。基本是由于nginx upstream为了防止锁所以进程间是不共享的。