最近在一台服务器上处理包过滤的程序，服务器上集成了6块 Intel 82574L 的千兆网卡，这块网卡出来的比较早，性能也比较均衡，很多服务器设备上也有集成。包过滤程序使用了pf_ring作为抓包的模块，操作系统使用的是CentOS 6.9，内核是2.6.32版本。在测试的时候发现几次很异常的情况，抓包一段时间以后（时长不定），被抓包的网卡上就再也没有流量上来了。使用ifconfig -a 查看

eth1  Link encap:Ethernet  HWaddr 00:0C:29:F6:7F:E1  
      inet addr:192.168.2.192  Bcast:192.168.2.255  Mask:255.255.255.0
      inet6 addr: fe80::20c:29ff:fef6:7fe1/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:1738132 errors:0 dropped:6356865 overruns:0 frame:0
      TX packets:1328354 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:840530707 (801.5 MiB)  TX bytes:1706701844 (1.5 GiB)

发现RX dropped 非常的高，自没有流量上来以后，所有的包都被丢弃了。

再查看一下ethtool -S eth1

 NIC statistics:
     rx_packets: 1740086
     tx_packets: 327205
     rx_bytes: 847640005
     tx_bytes: 1652632934
     rx_broadcast: 0
     tx_broadcast: 0
     rx_multicast: 0
     tx_multicast: 0
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 0
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 6356865 
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     tx_restart_queue: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 91453
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 847640005
     rx_csum_offload_good: 822676
     rx_csum_offload_errors: 0
     alloc_rx_buff_failed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0

里面的rx_missed_errors很高。

出现问题的时候，查询了其它网卡，数据都是正常的。只有抓包的那个网卡出现问题。原以为是pf_ring的驱动模块出现了问题，把pfring.ko卸载以后，还是老样子。暂时没有头绪，就放狗去搜。找到几篇讨论的文章：

Problem with Intel 82579V and 82574L NIC.
Intel 82574L Gigabit network card - issues and resolution

82574 adapters are known to have a hardware problem that requires a special fix in the driver. I am unsure if the fix for this has made it into CentOS 6.1 or 6.2 but the kmod-e1000e from ELrepo does have the fix and can be installed from there.

这里讲到，在旧内核里面82574L的驱动是有问题的，是需要用一个特殊的驱动去修复的。后来查了一些其它相关资料。内核版本在2.6.35以后才修复了这个驱动，但是CentOS 6 的内核是2.6.32，所以没有办法解决。只有升级成ELrepo 提供的第三方驱动去解决了。

ELrepo 提供的e1000e驱动地址：

升级完成以后，持续测试了两天，都没有再出现断流的问题了。应该是解决了。

最近把小主机升级到了ESXI6.5，debian 9也已经出来了。所以就配了个虚拟机装了最新的debian 9，安装一切无话。安装好以后配了nginx等相关服务。系统装好后测试一切正常，就放着不动了。

等第二天，发现博客首页上不去了，去ping debian 9的IP地址也ping不通了，去ESXI管理界面界面上一看，vCPU占用100%，感觉情况不妙。打开系统终端控制台，发现无论输入什么都没有反映，系统已经挂了的感觉，按crtl+alt+ins也没反应。最后只能强制重启了，当时以为是意外。遂没有管它。当再过了一天，又出现同样的情况了，就说明不是意外。查看了系统的相关日志，看不出有什么异常的地方，想起来装过vmware tools ，当即把它卸载了再观察。可是再过了一天，情况还是老样子，又死了。所以，应该和vmware tools没什么关系。

没有头绪，只能放狗去搜，找到一篇老外的讨论：
VM becomes unresponsive, some vCPUs are 100% utilized

里面有讲到应该和网卡类型和 vmxnet3 有关

All of the VMs use the vmxnet3 vNIC. On one occasion, after resetting the VM, I looked at the kernel log and it displayed some vmxnet3 messages which led me to believe the problem may be caused by http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2005717. I moved some VMs to the host running ESXi v5.0 and the problem still occurred, so that theory was debunked. Also, this problem has happened quite a few times but those vmxnet3 kernel messages only showed up on one occasion.

然后，我就把网卡类型改成了：e1000e，就没有再出过这个问题了，在这里记录一下备查。使用vmxnet3时，在系统里看到的网卡速率是10000M，使用e1000e类型就只有1000M。ESXI 6.5用debian 9 时，网卡已经没有e1000的类型选择了。

centos5/redhat5 自带的GCC已经很低了，一般是4.1左右，但如果安装一些软件需求高版本的gcc就比较麻烦了。

除了下源码编译安装外，这里介绍通过YUM源来直接安装

wget http://people.centos.org/tru/devtools-2/devtools-2.repo -O /etc/yum.repos.d/devtools-2.repo
yum install devtoolset-2-gcc devtoolset-2-binutils devtoolset-2-gcc-c++
ln -s /opt/rh/devtoolset-2/root/usr/bin/* /usr/local/bin/

hash -r
gcc --version

大功告成！