Xen出现nf_conntrack: table full, dropping packet.的一些解决调整参数 我们的Centos6 x64_64系统的Xen宿主内核出现了一些日志，相应状况有网络丢包的现象发生。nf_conntrack: table full, dropping packet. nf_conntrack: table full, dropping packet. nf_conntrack: table full, dropping packet. nf_conntrack: table full, dropping packet. nf_conntrack: table full, dropping packet. nf_conntrack: table full, dropping packet. nf_conntrack: table full, dropping packet. nf_conntrack: table full, dropping packet. nf_conntrack: table full, dropping packet. nf_conntrack: table full, dropping packet.根据网络搜索得到的方法，将内核的一些默认参数适当调整可以解决这个问题 [root@node61 ~]#cat /proc/sys/net/netfilter/nf_conntrack_max 24528 由于nf_conntrack_max的默认参数设置比较小，所以适当的调整一下它. 运行下面的代码cat >>/etc/sysctl.conf<<EOF net.nf_conntrack_max = 2097152 net.netfilter.nf_conntrack_tcp_timeout_established = 300 net.netfilter.nf_conntrack_max = 1048576 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 net.ipv4.conf.default.forwarding = 1 EOF sysctl -p以上代码中的参数仅供参考，请根据实际情况进行设置.然后持续监控您的内核日志看情况.

Xen出现Too many frags以及fatal error; disabling device日志，子系统断网解决办法 Xen有些时候一些GUEST OS系统正常运行中但是网络断了，直接重启后网络又恢复了。 从dmesg里面查看相应的信息发现出现了Too many fragsvif vif-162-0: vifXEN_NAME.0: Too many frags vif vif-162-0: vifXEN_NAME.0: fatal error; disabling devicegoogle了一下从一些mail list里面找到了解决办法，就是关闭tx和tso以及gso.先查看网卡ethtool -k 网卡运行命令会得到以下返回数据(一些机器返回的结果可能会有出入)[root@node75 ~]# ethtool -k eth0 Features for eth0: rx-checksumming: on tx-checksumming: on tx-checksum-ipv4: off [fixed] tx-checksum-ip-generic: on tx-checksum-ipv6: off [fixed] tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: on tx-tcp-segmentation: on tx-tcp-ecn-segmentation: off [fixed] tx-tcp6-segmentation: on udp-fragmentation-offload: off [fixed] generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off [fixed] rx-vlan-offload: on tx-vlan-offload: on ntuple-filters: off [fixed] receive-hashing: on highdma: on [fixed] rx-vlan-filter: off [fixed] vlan-challenged: off [fixed] tx-lockless: off [fixed] netns-local: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: off [fixed] fcoe-mtu: off [fixed] tx-nocache-copy: on loopback: off [fixed] rx-fcs: off rx-all: off执行以下命令关闭tx tso gsoethtool -K eth0 tx off tso off gso off关闭后再用ethtool查看网卡会看到下面三个都为off关闭 tx-checksumming: off tcp-segmentation-offload: off generic-segmentation-offload: offtso的全称是tcp-segmentation-offload， gso的全称是generic-segmentation-offload 关于更多相关信息可以查阅http://en.wikipedia.org/wiki/Large_segment_offload以上内容是在基于Centos6 X64，kernel 3的环境撰写。  

[kipmi0]进程CPU 100%高占用率解决办法 服务器top进程上进程看到kipmi0经常占用很高的CPU甚至是100%看看专业的说法： kipmi is supposed to run with low priority. When you say it consumes 70-90% of the CPUs, is that constant (does it still consume the processor when they are other tasks in the process queue that should have a larger slice of the CPU time) or the 70%/90% comes when the machine is idle? A second issue to investigate is whether you have pending controller issues (alarms of varying nature that are not resolved) and/or older versions of controller firmware. 查看服务chkconfig 发现只有近似 ipmievd  服务，估计就是这个，跟网上资料说的ipmi有出入！Fix：不需要修复 No fix required. You should ignore increased CPU utilization as it has no impact on actual system performance.虽然这是一个利用空余的CPU资源进行一些接口自动调节的任务，但看着占那么多的资源还是怕出意外。找到：可以临时降低echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_usIn our system,after set this parameter,the cpu of kipmi0 decreased to 15%.确实执行上面命令后，所占CPU单核资源从100%降低到10%You can try this.永久性降低 To make the changes persistent you can configure the options for the ipmi_si kernel module. Create a file in /etc/modprobe.d/, i.e./etc/modprobe.d/ipmi.conf, and add the following content: # Prevent kipmi0 from consuming 100% CPUecho "options ipmi_si kipmid_max_busy_us=100">/etc/modprobe.d/ipmi.conf系统下次重启会自动调整