varnish 400 503错误的原因及解决方法

我们在生产环境中尝试使用varnish替代squid的主要原因:


1.  squid不支持多核cpu, 生产环境中大多使用Dell R610系列,这种类型机器配置为2个4核双线程cpu, 操作系统识别为16个,对squid来说,只能利用到一个逻辑cpu, 其它15个逻辑cpu相当于一直浪费!


2.  squid无法批量清除缓存


3.  squid3.0目前还无法支持http 1.1, 这对一些管理调整(如gzip压缩,cache-control)带来不必要的麻烦


4.  目前我还未找到squid的grace模式(指源站不可到达时,继续使用过期缓存为用户提供服务),而varnish是完全支持的。


5.  经过生产环境数个月反复测试,同样访问量情况下,varnish消耗的更少,也没有出现过崩溃情况,而squid因为不支持多核,导致Dell R610机器负载往往超过4,但使用varnish后,机器负载从来没超过1.5


经过反复测试,我们已经开始在日独立IP百万级站点中使用varnish替换squid了。


但这个过程中,充满太多未知情况,目前我们所遇到的关键问题下:


1. 高流量情况下iptables丢包

ip_conntrack: table full, dropping packet.

按网上常规方法,只修改/etc/sysctl.conf是无效的


需要以下两步,方可解决之
/boot/grub/grub.conf kernel行中增加参数
ip_conntrack.hashsize=524288
/etc/sysctl.conf中增加
net.ipv4.netfilter.ip_conntrack_max = 2097152


注意,上面的操作需要重启机器


2. 登录shell ulimit的默认值
/etc/security/limits.conf中加入
* soft nofile 655360
* hard nofile 655360

默认的文件描述符限制为1024, 太小,即使调整成65536,对高负载机器也可能不够,故设置为655360,但也要注意,这个值不能设置过大,否则会导致shell无法登录。


修改/etc/security/limits.conf后,只对登录shell有效。对开机运行的程序,一定要注意这个问题(在启动前设置ulimit)
 
那么,shell级的资源限制来自于/etc/security/limits.conf,那么系统级的资源限制可在哪里修改? 


3. squid换varnish后流量增加的解决方案:
/etc/security/limits.conf中加入

* soft memlock 1048576
* soft memlock 1048576

或执行 ulimit -HSl 1048576

默认的memlock 只有32K,对varnish来说,太小太小。varnish使用内存块保存日志,故这个值需要调大一些。

上面的值将其调整为1G,即可解决varnish流量高于squid的问题


3. varnish运行中频繁出现400,503错误


400错误出现,是因为varnish认为客户端请求header行数及长度过大,其默认最大接受的请求header行数为64,最大长度(所有请求header行长度之和)为2048,解决这个问题比较简单,在varnish启动参数中加入:

-p http_max_hdr=256

-p http_req_hdr_len=8192


再重启varnish, 即可解决其400错误


503错误,这是因为varnish对后端服务器响应header有限制,默认长度是2048,可将其调大一些

-p http_resp_hdr_len=8192


再重启之,即可解决这个问题

你可能感兴趣的:(varnish 400 503错误的原因及解决方法)