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

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

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