ip_conntrack: falling back to vmalloc解决办法
falling back to vmalloc
原因是，ip_conntrack的hashsize设置过大，导致内存分配错误引起。
经过反复尝试，哈希表大小设置为 262144，是比较合理的值，一方面能避免因ip_conntrack哈希表过小（RHEL 默认为8192）导致防火墙丢包( ip_conntrack: table full, dropping packet. )，另一方面也会消除掉 falling back to vmalloc错误。
我之前写过一篇文章，描述如何修改ip_conntrack模块的hashsiz以避免iptables丢包，修改hashsize有两种方法：
1. 一是向/etc/modprobe.conf中增加
options ip_conntrack hashsize=262144
再执行service iptables restart即可生效，可使用sysctl -a|grep ip_conntrack_buckets即可检查是否确实修改成功
2. 二是修改/boot/grub/grub.conf文件，向kernel行末尾增加ip_conntrack.hashsize=262144，再重启机器即可。
以上方法只可用其中之一（不能两者同时使用，否则会导致启动时报内核异常错误），强烈建议使用第一种方法，因为它不用重启机器。
由于我知识面的局限，之前使用第二种方式。实在对大家是一个误导。
将hash表大小设置为262144，不幸的是，又有新的问题产生：重启iptables时，系统日志中出现ip_conntrack: falling back to vmalloc。
冥思苦想而不得解，后尝试着将hashsize减少一半，即262144,这个问题竟然得以解决。那我的理解就是hash表设置过大，导致内存分配有误造成。总结一个，完整解决方案如下：
向/etc/modprobe.conf中增加
options ip_conntrack hashsize=262144
再执行
service iptables restart
验证
sysctl -a|grep ip_conntrack_buckets
再查看iptables跟踪条目数：
sysctl -a|grep conntrack_max
输出：
net.ipv4.ip_conntrack_max = 4194304
net.ipv4.netfilter.ip_conntrack_max = 4194304
设置跟踪连接数目，自动调整为哈希表大小的8倍， 所以不要在/etc/sysctl.conf中设置以下两项的值：
net.ipv4.netfilter.ip_conntrack_max net.ipv4.ip_conntrack_max