unix 网卡丢包_unix 查看网卡 - CSDN
  • 最近收到线上一台DB服务器ping丢包,丢包率一直在30%左右。通过Zabbix监控查看了服务器CPU,内存都很正常,网卡流量也不高,基本在100M左右。 首先确认一下服务器硬件是否正常,由于没有收到硬件报警。登录服务器通过...

      最近收到线上一台DB服务器ping丢包,丢包率一直在30%左右。通过Zabbix监控查看了服务器CPU,内存都很正常,网卡流量也不高,基本在100M左右。
    wKiom1ekGFCBE0nWAAHfgGoPDTk656.jpg-wh_50

      首先确认一下服务器硬件是否正常,由于没有收到硬件报警。登录服务器通过HP管理工具在此确认了硬件信息都正常(硬盘,缓存卡,内存等)。
      第二步在排查一下系统问题,通过top,ps等命令也没有发现什么异常,基本上排除系统问题。
      第三步查看了一下该服务器上联监控机端口流量,也都很正常,由于收到只有这一台服务器报警,也排除了上联交换机故障问题。
      最后向同事咨询了服务器承载业务类型,每2分钟会同步大量的数据文件到该服务器上面,然后用sar命令查看一下网卡流量,发现发送流量瞬间在12万KB/s,换算成b/s基本上在940-950Mb/s,意味着千兆网卡流量基本上爆满,才会引起服务器ping丢包。
    wKioL1ekGHTRDUfnAAGPak_j6LQ842.jpg-wh_50
      由于我的监控是每5分钟抓一次,所以对应服务器瞬间高流量都没有获取到,还得优化一下监控时间间隔。

    下面顺便总结一下sar命令常用的选项,sar命令行的常用格式如下:

    sar 选项 取样时间间隔 输出次数

    1)查看CPU信息,1表示1秒钟取一次值,2表示采集2次数据。

    [root@monitor ~]# sar -u 1 2
    Linux 2.6.32-358.el6.x86_64 (monitor)     08/05/16     _x86_64_    (24 CPU)
     
    10:51:39        CPU     %user     %nice   %system   %iowait    %steal     %idle
    10:51:40        all      0.08      0.00      0.17      0.00      0.00     99.75
    10:51:41        all      0.21      0.00      0.21      0.00      0.00     99.58
    Average:        all      0.15      0.00      0.19      0.00      0.00     99.67

    输出项说明:

    CPU          all 表示统计信息为所有CPU的平均值。
    %user        显示在用户级别(application)运行使用CPU总时间的百分比。
    %nice        显示在用户级别,用于nice操作,所占用CPU总时间的百分比。
    %system      在核心级别(kernel)运行所使用CPU总时间的百分比。
    %iowait      显示用于等待I/O操作占用 CPU 总时间的百分比。
    %steal       管理程序(hypervisor)为另一个虚拟进程提供服务而等待虚拟 CPU 的百分比。
    %idle        显示CPU空闲时间占用CPU总时间的百分比。

    2)查看网络接口信息。    

    [root@monitor ~]# sar -n DEV 1 2
    Linux 2.6.32-358.el6.x86_64 (monitor)     08/05/16     _x86_64_    (24 CPU)
     
    11:04:22        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
    11:04:23           lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
    11:04:23         eth0    140.40    170.71     98.07     84.00      0.00      0.00      2.02
    11:04:23         eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
    11:04:23         eth2      0.00      0.00      0.00      0.00      0.00      0.00      0.00
    11:04:23         eth3      0.00      0.00      0.00      0.00      0.00      0.00      0.00
     
    11:04:23        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
    11:04:24           lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
    11:04:24         eth0     40.59     26.73     41.62      4.17      0.00      0.00      0.99
    11:04:24         eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
    11:04:24         eth2      0.00      0.00      0.00      0.00      0.00      0.00      0.00
    11:04:24         eth3      0.00      0.00      0.00      0.00      0.00      0.00      0.00
     
    Average:        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
    Average:           lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
    Average:         eth0     90.00     98.00     69.56     43.69      0.00      0.00      1.50
    Average:         eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
    Average:         eth2      0.00      0.00      0.00      0.00      0.00      0.00      0.00
    Average:         eth3      0.00      0.00      0.00      0.00      0.00      0.00      0.00

    输出项说明:

    IFACE        网络设备名
    rxpck/s      每秒接收的包总数
    txpck/s      每秒传输的包总数
    rxKB/s       每秒接收的字节(byte)总数
    txKB/s       每秒传输的字节(byte)总数
    rxcmp/s      每秒接收压缩包的总数
    txcmp/s      每秒传输压缩包的总数
    rxmcst/s     每秒接收的多播(multicast)包的总数3)查看磁盘1/0信息。

        

    [root@monitor ~]# sar -b 1 2
    Linux 2.6.32-358.el6.x86_64 (monitor)     08/05/16     _x86_64_    (24 CPU)
     
    11:07:55          tps      rtps      wtps   bread/s   bwrtn/s
    11:07:56        11.11      0.00     11.11      0.00    129.29
    11:07:57         6.93      0.00      6.93      0.00     63.37
    Average:         9.00      0.00      9.00      0.00     96.00

    输出项说明:

    tps       每秒钟物理设备的I/O传输总量
    rtps      每秒钟从物理设备读入的数据总量
    wtps      每秒钟向物理设备写入的数据总量
    bread/s   每秒钟从物理设备读入的数据量,单位为 块/s
    bwrtn/s   每秒钟向物理设备写入的数据量,单位为 块/s

      总结:在系统运维的过程中,一般关注服务器的下面指标。
      CPU使用率:如果服务器CPU使用率超过80-85%,说明服务器CPU处理能力比较繁忙,需要提升CPU性能。
      CPU iowait:如果服务器CPU iowait的值大于5-10%,说明磁盘I/O存在瓶颈,需要提升硬盘的读写速度。
      网卡流量:网卡流量和上联交换机和服务器网卡都有关系。如果系统和网络都正常,服务器出现丢包,应该考虑网卡的吞吐率是否达到上限而出现的丢包。




    展开全文
  • 转自:...utm_medium=toutiao.io&utm_source=toutiao.io linux 系统 UDP 丢包问题分析思路 最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,总结出来这篇文章,供...

    转自:http://cizixs.com/2018/01/13/linux-udp-packet-drop-debug?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

    linux 系统 UDP 丢包问题分析思路

    最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,总结出来这篇文章,供更多人参考。

    在开始之前,我们先用一张图解释 linux 系统接收网络报文的过程。

    1. 首先网络报文通过物理网线发送到网卡
    2. 网络驱动程序会把网络中的报文读出来放到 ring buffer 中,这个过程使用 DMA(Direct Memory Access),不需要 CPU 参与
    3. 内核从 ring buffer 中读取报文进行处理,执行 IP 和 TCP/UDP 层的逻辑,最后把报文放到应用程序的 socket buffer 中
    4. 应用程序从 socket buffer 中读取报文进行处理

    在接收 UDP 报文的过程中,图中任何一个过程都可能会主动或者被动地把报文丢弃,因此丢包可能发生在网卡和驱动,也可能发生在系统和应用。

    之所以没有分析发送数据流程,一是因为发送流程和接收类似,只是方向相反;另外发送流程报文丢失的概率比接收小,只有在应用程序发送的报文速率大于内核和网卡处理速率时才会发生。

    本篇文章假定机器只有一个名字为 eth0 的 interface,如果有多个 interface 或者 interface 的名字不是 eth0,请按照实际情况进行分析。

    NOTE:文中出现的 RX(receive) 表示接收报文,TX(transmit) 表示发送报文。

    确认有 UDP 丢包发生

    要查看网卡是否有丢包,可以使用 ethtool -S eth0 查看,在输出中查找 bad 或者 drop 对应的字段是否有数据,在正常情况下,这些字段对应的数字应该都是 0。如果看到对应的数字在不断增长,就说明网卡有丢包。

    另外一个查看网卡丢包数据的命令是 ifconfig,它的输出中会有 RX(receive 接收报文)和 TX(transmit 发送报文)的统计数据:

    ~# ifconfig eth0
    ...
            RX packets 3553389376  bytes 2599862532475 (2.3 TiB)
            RX errors 0  dropped 1353  overruns 0  frame 0
            TX packets 3479495131  bytes 3205366800850 (2.9 TiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    ...
    

    此外,linux 系统也提供了各个网络协议的丢包信息,可以使用 netstat -s 命令查看,加上 --udp 可以只看 UDP 相关的报文数据:

    [root@holodesk02 GOD]# netstat -s -u
    IcmpMsg:
        InType0: 3
        InType3: 1719356
        InType8: 13
        InType11: 59
        OutType0: 13
        OutType3: 1737641
        OutType8: 10
        OutType11: 263
    Udp:
        517488890 packets received
        2487375 packets to unknown port received.
        47533568 packet receive errors
        147264581 packets sent
        12851135 receive buffer errors
        0 send buffer errors
    UdpLite:
    IpExt:
        OutMcastPkts: 696
        InBcastPkts: 2373968
        InOctets: 4954097451540
        OutOctets: 5538322535160
        OutMcastOctets: 79632
        InBcastOctets: 934783053
        InNoECTPkts: 5584838675
    

    对于上面的输出,关注下面的信息来查看 UDP 丢包的情况:

    • packet receive errors 不为空,并且在一直增长说明系统有 UDP 丢包
    • packets to unknown port received 表示系统接收到的 UDP 报文所在的目标端口没有应用在监听,一般是服务没有启动导致的,并不会造成严重的问题
    • receive buffer errors 表示因为 UDP 的接收缓存太小导致丢包的数量

    NOTE: 并不是丢包数量不为零就有问题,对于 UDP 来说,如果有少量的丢包很可能是预期的行为,比如丢包率(丢包数量/接收报文数量)在万分之一甚至更低。

    网卡或者驱动丢包

    之前讲过,如果 ethtool -S eth0 中有 rx_***_errors 那么很可能是网卡有问题,导致系统丢包,需要联系服务器或者网卡供应商进行处理。

    # ethtool -S eth0 | grep rx_ | grep errors
         rx_crc_errors: 0
         rx_missed_errors: 0
         rx_long_length_errors: 0
         rx_short_length_errors: 0
         rx_align_errors: 0
         rx_errors: 0
         rx_length_errors: 0
         rx_over_errors: 0
         rx_frame_errors: 0
         rx_fifo_errors: 0
    

    netstat -i 也会提供每个网卡的接发报文以及丢包的情况,正常情况下输出中 error 或者 drop 应该为 0。

    如果硬件或者驱动没有问题,一般网卡丢包是因为设置的缓存区(ring buffer)太小,可以使用 ethtool 命令查看和设置网卡的 ring buffer。

    ethtool -g 可以查看某个网卡的 ring buffer,比如下面的例子

    # ethtool -g eth0
    Ring parameters for eth0:
    Pre-set maximums:
    RX:        4096
    RX Mini:    0
    RX Jumbo:    0
    TX:        4096
    Current hardware settings:
    RX:        256
    RX Mini:    0
    RX Jumbo:    0
    TX:        256
    

    Pre-set 表示网卡最大的 ring buffer 值,可以使用 ethtool -G eth0 rx 8192 设置它的值。

    Linux 系统丢包

    linux 系统丢包的原因很多,常见的有:UDP 报文错误、防火墙、UDP buffer size 不足、系统负载过高等,这里对这些丢包原因进行分析。

    UDP 报文错误

    如果在传输过程中UDP 报文被修改,会导致 checksum 错误,或者长度错误,linux 在接收到 UDP 报文时会对此进行校验,一旦发明错误会把报文丢弃。

    如果希望 UDP 报文 checksum 及时有错也要发送给应用程序,可以在通过 socket 参数禁用 UDP checksum 检查:

    int disable = 1;
    setsockopt(sock_fd, SOL_SOCKET, SO_NO_CHECK, (void*)&disable, sizeof(disable)
    

    防火墙

    如果系统防火墙丢包,表现的行为一般是所有的 UDP 报文都无法正常接收,当然不排除防火墙只 drop 一部分报文的可能性。

    如果遇到丢包比率非常大的情况,请先检查防火墙规则,保证防火墙没有主动 drop UDP 报文。

    UDP buffer size 不足

    linux 系统在接收报文之后,会把报文保存到缓存区中。因为缓存区的大小是有限的,如果出现 UDP 报文过大(超过缓存区大小或者 MTU 大小)、接收到报文的速率太快,都可能导致 linux 因为缓存满而直接丢包的情况。

    在系统层面,linux 设置了 receive buffer 可以配置的最大值,可以在下面的文件中查看,一般是 linux 在启动的时候会根据内存大小设置一个初始值。

    • /proc/sys/net/core/rmem_max:允许设置的 receive buffer 最大值
    • /proc/sys/net/core/rmem_default:默认使用的 receive buffer 值
    • /proc/sys/net/core/wmem_max:允许设置的 send buffer 最大值
    • /proc/sys/net/core/wmem_dafault:默认使用的 send buffer 最大值

    但是这些初始值并不是为了应对大流量的 UDP 报文,如果应用程序接收和发送 UDP 报文非常多,需要讲这个值调大。可以使用 sysctl 命令让它立即生效:

    sysctl -w net.core.rmem_max=26214400 # 设置为 25M
    

    也可以修改 /etc/sysctl.conf 中对应的参数在下次启动时让参数保持生效。

    如果报文报文过大,可以在发送方对数据进行分割,保证每个报文的大小在 MTU 内。

    另外一个可以配置的参数是 netdev_max_backlog,它表示 linux 内核从网卡驱动中读取报文后可以缓存的报文数量,默认是 1000,可以调大这个值,比如设置成 2000:

    sudo sysctl -w net.core.netdev_max_backlog=2000
    

    系统负载过高

    系统 CPU、memory、IO 负载过高都有可能导致网络丢包,比如 CPU 如果负载过高,系统没有时间进行报文的 checksum 计算、复制内存等操作,从而导致网卡或者 socket buffer 出丢包;memory 负载过高,会应用程序处理过慢,无法及时处理报文;IO 负载过高,CPU 都用来响应 IO wait,没有时间处理缓存中的 UDP 报文。

    linux 系统本身就是相互关联的系统,任何一个组件出现问题都有可能影响到其他组件的正常运行。对于系统负载过高,要么是应用程序有问题,要么是系统不足。对于前者需要及时发现,debug 和修复;对于后者,也要及时发现并扩容。

    应用丢包

    上面提到系统的 UDP buffer size,调节的 sysctl 参数只是系统允许的最大值,每个应用程序在创建 socket 时需要设置自己 socket buffer size 的值。

    linux 系统会把接受到的报文放到 socket 的 buffer 中,应用程序从 buffer 中不断地读取报文。所以这里有两个和应用有关的因素会影响是否会丢包:socket buffer size 大小以及应用程序读取报文的速度。

    对于第一个问题,可以在应用程序初始化 socket 的时候设置 socket receive buffer 的大小,比如下面的代码把 socket buffer 设置为 20MB:

    uint64_t receive_buf_size = 20*1024*1024;  //20 MB
    setsockopt(socket_fd, SOL_SOCKET, SO_RCVBUF, &receive_buf_size, sizeof(receive_buf_size));
    

    如果不是自己编写和维护的程序,修改应用代码是件不好甚至不太可能的事情。很多应用程序会提供配置参数来调节这个值,请参考对应的官方文档;如果没有可用的配置参数,只能给程序的开发者提 issue 了。

    很明显,增加应用的 receive buffer 会减少丢包的可能性,但同时会导致应用使用更多的内存,所以需要谨慎使用。

    另外一个因素是应用读取 buffer 中报文的速度,对于应用程序来说,处理报文应该采取异步的方式

    包丢在什么地方

    想要详细了解 linux 系统在执行哪个函数时丢包的话,可以使用 dropwatch 工具,它监听系统丢包信息,并打印出丢包发生的函数地址:

    # dropwatch -l kas
    Initalizing kallsyms db
    dropwatch> start
    Enabling monitoring...
    Kernel monitoring activated.
    Issue Ctrl-C to stop monitoring
    
    1 drops at tcp_v4_do_rcv+cd (0xffffffff81799bad)
    10 drops at tcp_v4_rcv+80 (0xffffffff8179a620)
    1 drops at sk_stream_kill_queues+57 (0xffffffff81729ca7)
    4 drops at unix_release_sock+20e (0xffffffff817dc94e)
    1 drops at igmp_rcv+e1 (0xffffffff817b4c41)
    1 drops at igmp_rcv+e1 (0xffffffff817b4c41)
    

    通过这些信息,找到对应的内核代码处,就能知道内核在哪个步骤中把报文丢弃,以及大致的丢包原因。

    此外,还可以使用 linux perf 工具监听 kfree_skb(把网络报文丢弃时会调用该函数) 事件的发生:

    sudo perf record -g -a -e skb:kfree_skb
    sudo perf script
    

    关于 perf 命令的使用和解读,网上有很多文章可以参考。

    总结

    • UDP 本身就是无连接不可靠的协议,适用于报文偶尔丢失也不影响程序状态的场景,比如视频、音频、游戏、监控等。对报文可靠性要求比较高的应用不要使用 UDP,推荐直接使用 TCP。当然,也可以在应用层做重试、去重保证可靠性
    • 如果发现服务器丢包,首先通过监控查看系统负载是否过高,先想办法把负载降低再看丢包问题是否消失
    • 如果系统负载过高,UDP 丢包是没有有效解决方案的。如果是应用异常导致 CPU、memory、IO 过高,请及时定位异常应用并修复;如果是资源不够,监控应该能及时发现并快速扩容
    • 对于系统大量接收或者发送 UDP 报文的,可以通过调节系统和程序的 socket buffer size 来降低丢包的概率
    • 应用程序在处理 UDP 报文时,要采用异步方式,在两次接收报文之间不要有太多的处理逻辑

    参考资料

    展开全文
  • 近产品老是报托管到机房的服务器高峰期合作商的一个IP丢包,自己测试了到目标IP确实丢包(同网段一个丢一个不丢),但是ping别的门户网站正常,合 作伙伴是国内网络设备部大亨难道他们的网络有问题,经过一起调试...
    http://www.myhack58.com/Article/sort099/sort0102/2013/40287.htm


    一、概述

    最 近产品老是报托管到机房的服务器高峰期合作商的一个IP丢包,自己测试了到目标IP确实丢包(同网段一个丢一个不丢),但是ping别的门户网站正常,合 作伙伴是国内网络设备部大亨难道他们的网络有问题,经过一起调试他们死活认为我的网络有问题,我联系IDC机房(国内最牛X的)机房网络检测了几天说机房 网络正常对方问题。
    奇葩了!!!受老板鸭梨必须查出丢包原因和丢包点,没办法只有请SmokePing出来给我监控找答案了。。。。下面进入正题搭建SmokePing实战!
    1、环境
    系统 centos5.8 64bit
    安装环境
    http rrdtool fping smokeping CGI-SpeedyCGI

    二、安装环境
    1、更新yum源

    rpm -Uvh http://apt.sw.be/redhat/el5/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm

    2、yum安装环境

    yum -y install gcc gcc-* make man file vim-enhanced openssh-clients lftp ftp wget curl elinks httpd httpd-devel expect ntp pango system-config-network-tui libxml2-devel libpng-devel pango pango-devel libart_lgpl libart_lgpl-devel freetype freetype-devel fontconfig cairo cairo-devel sendmail
    yum install perl perl-Net-Telnet perl-Net-DNS perl-LDAP perl-libwww-perl perl-RadiusPerl perl-IO-Socket-SSL perl-Socket6 perl-CGI-SpeedyCGI
    yum install fping echoping

    3、安装rrdtool

    wget http://bcs.duapp.com/xiueli/rrdtool.tar.gz
    tar zxvf rrdtool.tar.gz
    mv rrdtool /usr/local/
    ln /usr/local/rrdtool/bin/rrdtool /usr/bin
    #这个包的rrdool是1.4.5的已经编译好的
    /usr/local/rrdtool/bin/rrdtool   #可以查看版本

    4、安装smokeping
    wget http://oss.oetiker.ch/smokeping/pub/smokeping-2.4.2.tar.gz
    tar zxvf smokeping-2.4.2.tar.gz
    mv smokeping-2.4.2 /usr/local/smokeping

    5、配置smokeping (这步是搭建smokeping最难的了)

    cp /usr/local/smokeping/bin/smokeping.dist /usr/local/smokeping/bin/smokeping
    cp /usr/local/smokeping/htdocs/smokeping.cgi.dist /usr/local/smokeping/htdocs/smokeping.cgi
    mkdir -p /usr/local/smokeping/htdocs/img
    mkdir -p /usr/local/smokeping/var
    vim /usr/local/smokeping/bin/smokeping
    内容如下
    #!/usr/bin/perl -w
    # -*-perl-*-
    
    use lib qw(/usr/local/rrdtool/lib/perl/);   #需要更改
    use lib qw(/usr/local/smokeping/lib/);      *需要更改
    use strict;
    use warnings;
    use Smokeping 2.004002;
    
    Smokeping::main("/usr/local/smokeping/etc/config.dist");   #需要更改
    
    vim /usr/local/smokeping/htdocs/smokeping.cgi
    #更改,还是上面那三处
    #!/usr/bin/speedy
    # -*-perl-*-
    
    use strict;
    use warnings;
    
    use lib qw(/usr/local/rrdtool/lib/perl/);  
    use lib qw(/usr/local/smokeping/lib/);  
    
    use CGI::Carp qw(fatalsToBrowser);
    
    use Smokeping 2.004002;
    
    Smokeping::cgi("/usr/local/smokeping/etc/config.dist");

    最重要的config.dist配置
    见http://www.yinxiulei.cn/smokeping配置文件.html

    6、设置登录密码

     htpasswd -c /usr/local/smokeping/htdocs/htpasswd admin

    7、apache配置

    vi /etc/httpd/conf.d/smkeping.conf
    #加入下面内容
    
        ServerAdmin 627526297@qq.com
        DocumentRoot "/usr/local/smokeping/htdocs"
        ServerName localhost
       
        Options FollowSymLinks ExecCGI
        AllowOverride None
        AddHandler cgi-script cgi
        Order allow,deny
        Allow from all
        AuthName "Smokeping"
        AuthType Basic
        AuthUserFile /usr/local/smokeping/htdocs/htpasswd
        Require valid-user
        ErrorLog logs/smokeping-error_log
        CustomLog logs/smokeping-access_log combined

    三、启动服务器

    /etc/init.d/httpd start
    /usr/local/smokeping/bin/smokeping start

    如正常启动打开网站

    http://ip/smokeping/smokeping.cgi

    ps问题解决
    smokeping无图图片叉叉,检查配置文件中的imgcache
    看imgcache目录内是否有数据,目录是否在htdocs内

    <script>window._bd_share_config={"common":{"bdSnsKey":{},"bdText":"","bdMini":"2","bdMiniList":false,"bdPic":"","bdStyle":"0","bdSize":"16"},"share":{}};with(document)0[(getElementsByTagName('head')[0]||body).appendChild(createElement('script')).src='http://bdimg.share.baidu.com/static/api/js/share.js?v=89860593.js?cdnversion='+~(-new Date()/36e5)];</script>
    阅读(774) | 评论(0) | 转发(0) |
    给主人留下些什么吧!~~
    评论热议
    展开全文
  • Linux内核对网卡处理机制大约经历了4个阶段。 1、网卡在同一时刻只能接收一个,当网卡接收到之后,马上向中断控制器发出中断请求,中断控制器向CPU发出中断信号。 2、网卡在同一时刻能接收多个,单...

    Linux内核对网卡收包处理机制大约经历了4个阶段。

    1、网卡在同一时刻只能接收一个包,当网卡接收到包之后,马上向中断控制器发出中断请求,中断控制器向CPU发出中断信号。

    2、网卡在同一时刻能接收多个包,单CPU,网卡接收到多个包的时刻,马上向中断控制器发出中断请求,中断控制器向CPU发出中断信号。

    3、网卡在同一时刻能接收多个包,多CPU,网卡接收到多个包的时刻,马上向中断控制器发出中断请求,中断控制器向CPU发出中断信号,所有CPU都将接收到数据包放入同一个接受队列里。

    4、网卡支持多队列+DMA方式,多CPU,网卡接收到多个包的时刻,主动把数据包通过网卡DMA到rx_ring(多个)里,当DMA完成时,发生网卡硬件中断,在硬中断里调用软中断,软中断把该CPU对应的r_ring里buffer拷贝到链路层(又称为接口层)接收队列里。

    第一个阶段(约1985~1997?):

    tcp/ip协议栈在1985左右开始集成到BSD UNIX内核中。在那个年代,互联网是个稀罕玩意儿,网络流量不大,网卡性能也比较弱。

    网络处理机制从纯硬中断到下半部机制过渡。


    第二个阶段(约1997~2000?):

    网络流量开始增大,传统的Linux下半部机制仍然能应付。


    第三个阶段(2000~2008?):

    Linux内核开始出现NAPI网络处理机制。

    这个阶段最大的问题在于SMP下网卡的优势无法发挥出来。中断落在CPU0上,SMP对网卡处理负载不均衡。流量大的时候,CPU0负载很高,网卡丢包现象严重。

    解决问题的方法是采用APIC中断控制器,但是,此时接收队列仍然只有1个,即便网卡中断均衡到多个CPU, 接收队列只有一个 ,CPU对网卡数据处理仍然有很大瓶颈。这好比5个未成年男淫与一个成年女性轮流发生性关系,没办法5个人一起来,只能轮流来。


    第四个阶段:(约2008?~now):

    多队列网卡出现。同一个网卡具备多个rx_ring和DMA功能。本质上,借用了NUMA架构思想(与SMP同一层级的架构)。


    展开全文
  • 常见的测试丢包的命令 :ping 、mtr 、traceroute 常见的测试丢包的方法是通过使用PING命令进行测试 解析 :ping使用了ICMP回送请求与回送回答报文。ICMP回送请求报文是主机或路由器向一个特定的目的主机发出的...

    常见的测试丢包的命令 :ping 、mtr 、traceroute 、fping、iftop

    在开始之前,我们先用一张图解释 linux 系统接收网络报文的过程。
    1、首先网络报文通过物理网线发送到网卡
    2、网络驱动程序会把网络中的报文读出来放到 ring buffer 中,这个过程使用 DMA(Direct Memory Access),不需要 CPU 参与
    3、内核从 ring buffer 中读取报文进行处理,执行 IP 和 TCP/UDP 层的逻辑,最后把报文放到应用程序的 socket buffer 中
    4、应用程序从 socket buffer 中读取报文进行处理
    在这里插入图片描述
    在接收 UDP 报文的过程中,图中任何一个过程都可能会主动或者被动地把报文丢弃,因此丢包可能发生在网卡和驱动,也可能发生在系统和应用。

    之所以没有分析发送数据流程,一是因为发送流程和接收类似,只是方向相反;另外发送流程报文丢失的概率比接收小,只有在应用程序发送的报文速率大于内核和网卡处理速率时才会发生。

    本篇文章假定机器只有一个名字为 eth0 的 interface,如果有多个 interface 或者 interface 的名字不是 eth0,请按照实际情况进行分析。

    NOTE:文中出现的 RX(receive) 表示接收报文,TX(transmit) 表示发送报文。

    # ifconfig enp1
    enp2s0f1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether 04:b0:e7:fa:75:9d  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device memory 0x92200000-922fffff
    

    在这里插入图片描述
    此外,linux 系统也提供了各个网络协议的丢包信息,可以使用 netstat -s 命令查看,加上 --udp 可以只看 UDP 相关的报文数据:

    # netstat -s -u
    IcmpMsg:
        InType0: 17
        InType3: 75
        InType8: 77
        OutType0: 77
        OutType3: 692
        OutType8: 249
    Udp:
        5728807 packets received
        12 packets to unknown port received.
        0 packet receive errors
        982710 packets sent
        0 receive buffer errors
        0 send buffer errors
    UdpLite:
    IpExt:
        InNoRoutes: 3
        InBcastPkts: 497633
        InOctets: 1044710406807
        OutOctets: 17460621991142
        InBcastOctets: 114600482
        InNoECTPkts: 2886955071
    

    在这里插入图片描述
    对于上面的输出,关注下面的信息来查看 UDP 丢包的情况:

    • packet receive errors 不为空,并且在一直增长说明系统有 UDP 丢包
    • packets to unknown port received 表示系统接收到的 UDP
      报文所在的目标端口没有应用在监听,一般是服务没有启动导致的,并不会造成严重的问题
    • receive buffer errors 表示因为 UDP 的接收缓存太小导致丢包的数量
      注意 :并不是丢包数量不为零就有问题,对于 UDP 来说,如果有少量的丢包很可能是预期的行为,比如丢包率(丢包数量/接收报文数量)在万分之一甚至更低。

    网卡或者驱动丢包

    之前讲过,如果 ethtool -S eth0 中有 rx_***_errors 那么很可能是网卡有问题,导致系统丢包,需要联系服务器或者网卡供应商进行处理。

    # ethtool -S enp1 | grep rx_ | grep errors
         rx_crc_errors: 0
         rx_missed_errors: 0
         rx_long_length_errors: 0
         rx_short_length_errors: 0
         rx_align_errors: 0
         rx_errors: 0
         rx_length_errors: 0
         rx_over_errors: 0
         rx_frame_errors: 0
         rx_fifo_errors: 0
    

    在这里插入图片描述
    netstat -i 也会提供每个网卡的接发报文以及丢包的情况,正常情况下输出中 error 或者 drop 应该为 0。

    如果硬件或者驱动没有问题,一般网卡丢包是因为设置的缓存区(ring buffer)太小,可以使用 ethtool 命令查看和设置网卡的 ring buffer。

    ethtool -g 可以查看某个网卡的 ring buffer,比如下面的例子

    # ethtool -g enp1
    Ring parameters for enp2s0f1:
    Pre-set maximums:
    RX:    4096
    RX Mini:  0
    RX Jumbo:  0
    TX:    4096
    Current hardware settings:
    RX:    256
    RX Mini:  0
    RX Jumbo:  0
    TX:    256
    

    在这里插入图片描述
    Pre-set 表示网卡最大的 ring buffer 值,可以使用 ethtool -G eth0 rx 8192 设置它的值。

    Linux 系统丢包

    linux 系统丢包的原因很多,常见的有:UDP 报文错误、防火墙、UDP buffer size 不足、系统负载过高等,这里对这些丢包原因进行分析。

    UDP 报文错误

    如果在传输过程中UDP 报文被修改,会导致 checksum 错误,或者长度错误,linux 在接收到 UDP 报文时会对此进行校验,一旦发明错误会把报文丢弃。

    如果希望 UDP 报文 checksum 及时有错也要发送给应用程序,可以在通过 socket 参数禁用 UDP checksum 检查。

    防火墙

    如果系统防火墙丢包,表现的行为一般是所有的 UDP 报文都无法正常接收,当然不排除防火墙只 drop 一部分报文的可能性。

    如果遇到丢包比率非常大的情况,请先检查防火墙规则,保证防火墙没有主动 drop UDP 报文。

    UDP buffer size 不足

    linux 系统在接收报文之后,会把报文保存到缓存区中。因为缓存区的大小是有限的,如果出现 UDP 报文过大(超过缓存区大小或者 MTU 大小)、接收到报文的速率太快,都可能导致 linux 因为缓存满而直接丢包的情况。

    在系统层面,linux 设置了 receive buffer 可以配置的最大值,可以在下面的文件中查看,一般是 linux 在启动的时候会根据内存大小设置一个初始值。

    • /proc/sys/net/core/rmem_max:允许设置的 receive buffer 最大值
    • /proc/sys/net/core/rmem_default:默认使用的 receive buffer 值
    • /proc/sys/net/core/wmem_max:允许设置的 send buffer 最大值
    • /proc/sys/net/core/wmem_dafault:默认使用的 send buffer 最大值

    但是这些初始值并不是为了应对大流量的 UDP 报文,如果应用程序接收和发送 UDP 报文非常多,需要讲这个值调大。可以使用 sysctl 命令让它立即生效:

    # sysctl -w net.core.rmem_max=26214400 # 设置为 25M
    net.core.rmem_max = 26214400
    

    也可以修改 /etc/sysctl.conf 中对应的参数在下次启动时让参数保持生效。

    如果报文报文过大,可以在发送方对数据进行分割,保证每个报文的大小在 MTU 内。

    另外一个可以配置的参数是 netdev_max_backlog,它表示 linux 内核从网卡驱动中读取报文后可以缓存的报文数量,默认是 1000,可以调大这个值,比如设置成 2000:

    # sudo sysctl -w net.core.netdev_max_backlog=2000
    net.core.netdev_max_backlog = 2000
    

    系统负载过高

    系统 CPU、memory、IO 负载过高都有可能导致网络丢包,比如 CPU 如果负载过高,系统没有时间进行报文的 checksum 计算、复制内存等操作,从而导致网卡或者 socket buffer 出丢包;memory 负载过高,会应用程序处理过慢,无法及时处理报文;IO 负载过高,CPU 都用来响应 IO wait,没有时间处理缓存中的 UDP 报文。

    linux 系统本身就是相互关联的系统,任何一个组件出现问题都有可能影响到其他组件的正常运行。对于系统负载过高,要么是应用程序有问题,要么是系统不足。对于前者需要及时发现,debug 和修复;对于后者,也要及时发现并扩容。

    应用丢包

    上面提到系统的 UDP buffer size,调节的 sysctl 参数只是系统允许的最大值,每个应用程序在创建 socket 时需要设置自己 socket buffer size 的值。

    linux 系统会把接受到的报文放到 socket 的 buffer 中,应用程序从 buffer 中不断地读取报文。所以这里有两个和应用有关的因素会影响是否会丢包:socket buffer size 大小以及应用程序读取报文的速度。

    对于第一个问题,可以在应用程序初始化 socket 的时候设置 socket receive buffer 的大小,比如下面的代码把 socket buffer 设置为 20MB:

    uint64_t receive_buf_size = 20*1024*1024;  //20 MB
    setsockopt(socket_fd, SOL_SOCKET, SO_RCVBUF, &receive_buf_size, sizeof(receive_buf_size));
    

    如果不是自己编写和维护的程序,修改应用代码是件不好甚至不太可能的事情。很多应用程序会提供配置参数来调节这个值,请参考对应的官方文档;如果没有可用的配置参数,只能给程序的开发者提 issue 了。

    很明显,增加应用的 receive buffer 会减少丢包的可能性,但同时会导致应用使用更多的内存,所以需要谨慎使用。

    另外一个因素是应用读取 buffer 中报文的速度,对于应用程序来说,处理报文应该采取异步的方式

    包丢在什么地方

    想要详细了解 linux 系统在执行哪个函数时丢包的话,可以使用 dropwatch 工具,它监听系统丢包信息,并打印出丢包发生的函数地址:

    # apt install -y xawtv-tools
    
    # dropwatch -l kas
    Initalizing kallsyms db
    dropwatch> start
    Enabling monitoring...
    Kernel monitoring activated.
    Issue Ctrl-C to stop monitoring
    
    1 drops at tcp_v4_do_rcv+cd (0xffffffff81799bad)
    10 drops at tcp_v4_rcv+80 (0xffffffff8179a620)
    1 drops at sk_stream_kill_queues+57 (0xffffffff81729ca7)
    4 drops at unix_release_sock+20e (0xffffffff817dc94e)
    1 drops at igmp_rcv+e1 (0xffffffff817b4c41)
    1 drops at igmp_rcv+e1 (0xffffffff817b4c41)
    

    通过这些信息,找到对应的内核代码处,就能知道内核在哪个步骤中把报文丢弃,以及大致的丢包原因。本人在排查这个问题过程中更倾向于在各个机器抓包,这个方法更适合追踪自身业务出现问题导致丢包,如下所示:

    tcpdump -i 网络接口名称 udp port 2020 -s0 -XX -nn
    

    还可以使用 linux perf 工具监听 kfree_skb(把网络报文丢弃时会调用该函数) 事件的发生:

    sudo perf record -g -a -e skb:kfree_skb
    sudo perf script
    

    总结 :

    1. 单独进行网络连通性测试使用ping即可。

    2. 范围性的检测连通性,比如检测一个办公室内,哪些ip正在使用,可以使用fping。

    3. 在网络排查中单独ping很难把所有中间转发链路和转发接口全部压上的,所以使用fping,利用五元组(源目ip、源目mac、端口号)中的不同的目的ip、目的mac可以尽可能的压上所有链路,进行网络探测工作。

    4. fping还可以用于网络监控、监控设备存活、批量输出延迟信息使用。

    5. traceroute可直接探测源目ip地址中间,转发设备的ip信息和连通性。

    6. MTR可以实时监测每时每刻的转发信息。

    7. 相比traceroute的信息输出,MTR有着更全面输出结果.

    8. MTR的整齐输出格式可用于日常监控使用,可以结合ping或者fping进行连通性探测,当出现某个目的ip不通时激活MTR进程,进行逐条探测,然后以文本形式输出(-r参数),可作为历史故障分析使用。

    常见的测试丢包的方法是通过使用PING命令进行测试

    解析 :ping使用了ICMP回送请求与回送回答报文。ICMP回送请求报文是主机或路由器向一个特定的目的主机发出的询问,收到此报文的机器必须给源主机发送ICMP回送回答报文。

    • Request timed out.表示此刻发生丢包故障
    • Reply from 220.181.6.19: bytes=32
      time=10ms TTL=55 类似显示表示数据传输正常

    丢包故障多数由以下几方面问题引起:网络阻塞、路由器或者交换机超过工作负荷、
    蠕虫病毒、网线连接距离过长(室内理论有效传输距离为100米,但实际应用中一般以不超过50米为宜)、网线故障(包括水晶头金属物氧化及其他故障)、操作系统自身故障、网卡故障(由于网卡工作频率与网络设备工作频率不相符引起的故障,如千兆网卡配合百兆网络设备等;也可能为网卡物理故障,如设备自然老化或遇到雷击等)、网络设备故障(设备工作环境影响引起,如环境过于潮湿、干燥或电磁干扰严重等,也可能由于设备硬件故障造成)、网络运营商线路问题。  
    解决方法对照以上所示故障为:断开网络后安全模式下查杀病毒、适当减短网线长度、检查网线并重新制作水晶头、重装操作系统、调整网卡或网络设备使之工作在同一频率、更换网卡、更换网络设备的使用环境或更换网络设备、联系网络运营商解决。

    Ping丢包故障定位

    1、配置Ping多包。
    2、缩小故障范围。

    在PC上分别Ping SwitchA、SwitchB、SwitchC和SwitchD,通过Ping结果可以判断出哪一段网络出现故障。本例假设PC上Ping SwitchB时也出现丢包,则可以初步判断丢包发生在SwitchA和SwitchB直连网段之间。
    3、配置流量统计。
    在SwitchA和SwitchB上配置流量统计功能,观察丢包情况。
    4、分析统计结果。
    在SwitchA上持续Ping SwitchB。
    如果离开SwitchA的报文数目多余进入SwitchB的报文数目,说明传输链路上存在丢包,请依照后面介绍的物理链路故障引起ping丢包进行处理。
    如果离开SwitchA的报文数目等于进入SwitchB的报文数目,但是离开SwitchB的报文数目少于进入SwitchB报文数目,说明SwitchB上存在丢包。引起SwitchB设备丢包可能原因分为网络环路和ICMP问题。
    5、物理链路故障引起ping丢包分析
    通过Ping丢包故障定位思路可以判断出是否由于物理链路故障引起的丢包。物理链路故障常见以下原因:
    计算机网卡有问题、设备接口不正常、线缆接头接触不良或松脱、网线过长或出现破损、光纤弯曲度过大、光模块收发的光功率过低、电口协商不一致,如一端自协商一端非自协商。
    在实际环境中设备未接地导致静电不能释放、风扇损坏导致设备过热等物理环境问题也会引起Ping丢包。
    物理链路故障可以通过观察发现,如光纤弯曲度过大、物理连接线过长、设备或者电脑网卡指示灯显示不正常等。针对物理链路故障,故障的解决的办法一般是更换物理器件,器件更换后故障即可恢复。
    6、网络环路故障引起ping丢包分析
    以太网交换网络中为了进行链路备份,提高网络可靠性,通常会使用冗余链路。但是使用冗余链路会在交换网络上产生环路,引发广播风暴以及MAC地址表不稳定等故障现象,从而导致用户通信质量较差,甚至通信中断。网络环路会导致设备CPU和端口利用率高,Ping报文被丢弃。
    当设备处于存在环路的网络中,设备的反应速度比较缓慢。环路问题判断方法如下:
    1、通过display interface brief | include up命令,查看所有UP接口下的流量,存在环路的接口上InUti和OutUti两个计数会逐步增加,甚至到接近100%,远远超过业务流量。

    2、判断交换机是否存在MAC地址漂移

    可以执行display trapbuffer命令,查看MAC地址漂移的日志来判断。
    可以执行mac-address flapping detection命令配置MAC地址漂移检测功能,然后通过display mac-address flapping record命令来判断是否出现MAC地址漂移。
    可以多次执行display mac-address来观察,若MAC地址在交换机不同的接口学习到,则存在mac地址漂移。
    3、检查CPU的利用率。
    通过命令display cpu-usage查看CPU的利用率。网络环路会导致CPU利用率一直很高,Ping报文未来得及处理就被丢弃。
    解决此种Ping丢包问题的方法是破除网络环路,可以在设备上部署RRPP、SEP、Smart Link、STP/RSTP/MSTP等协议,对环路进行处理。

    7. ARP问题故障引起ping丢包分析

    8. ICMP问题故障引起ping丢包分析
    ICMP问题常见故障现象:
    Ping设备时,一旦Ping速度比较快就会丢包,速度慢下来就不会丢包。 Ping大包时出现规律性丢包。 Ping设备时,会出现Ping通几个报文后Ping不通,大约两分钟左右又可以Ping通,Ping通几个报文后又Ping不通。

    常见ICMP问题有以下三种:

    丢包分析工具的使用案例
    ping

    ping -c 400 -i 0.01 -s 1024 -f
    

    mtr

    mtr报告各列含义
    Loss%       表示在每一跳的丢包率
    Snt         每个中间设备收到的发送的报的数目(上图为400个包),MTR会同            时对所有中间节点发送ICMP包进行测试。
    Last        最后一个数据包往返时间(ms)
    Avg         数据包往返平均时间(ms)
    Best        数据包往返最小时间(ms)
    Wrst        数据包往返最大时间(ms)
    StDev       标准偏差。如果标准偏差越高,说明数据包在这个节点上的延时越  
    
    [root@host ~]# mtr --report  www.baidu.com
    Start: Mon Jan 14 22:53:11 2019
    HOST: host.localdomain            Loss%   Snt   Last   Avg  Best  Wrst StDev
      1.|-- ???                                  100.0    10    0.0   0.0   0.0   0.0   0.0
      2.|-- lax1-5-1.it7.net                 0.0%    10    0.6   0.8   0.6   1.1   0.0
      3.|-- lax1-fatpipe-1.it7.net        0.0%    10    0.3   0.8   0.3   5.6   1.6
      4.|-- 69.12.69.1                        0.0%    10    0.3   0.4   0.3   1.2   0.0
      5.|-- las-b3-link.telia.net           0.0%    10    0.4   0.7   0.4   2.0   0.3
      6.|-- pccw-ic-319974-las-b3.c.t 0.0%    10    1.0   1.1   0.8   2.4   0.3
      7.|-- tenge0-2-0-22.br04.sjo01.  0.0%    10    8.1  18.2   7.9 109.1  31.9
      8.|-- 63-219-23-98.static.pccwg  0.0%    10    8.6   8.6   8.5   8.7   0.0
      9.|-- 104.193.88.13                     0.0%    10    8.9   9.7   8.8  12.2   0.9
     10.|-- 104.193.88.123                  0.0%    10    7.5   7.5   7.4   8.3   0.0
    

    参数 :
    -n 不用主机解释

    -c 发送多少个数据包

    –report 结果显示,并不动态显示。
    默认配置下,返回结果中各数据列的说明:

    第一列(Host):节点IP地址和域名。如前面所示,按n键可以切换显示。
    第二列(Loss%):节点丢包率。
    第三列(Snt):每秒发送数据包数。默认值是10,可以通过参数 -c 指定。
    第四列(Last):最近一次的探测延迟值。
    第五、六、七列(Avg、Best、Wrst):分别是探测延迟的平均值、最小值和最大值。
    第八列(StDev):标准偏差。越大说明相应节点越不稳定。

    mtr -s 用来指定ping数据包的大小

    mtr -n no-dns不对IP地址做域名解析

    mtr -a 来设置发送数据包的IP地址 这个对一个主机由多个IP地址是有用的

    mtr -i 使用这个参数来设置ICMP返回之间的要求默认是1秒

    mtr -4 IPv4

    mtr -6 IPv6

    mtr -c 400 -i 0.1 -n -r 192.168.1.1
    

    traceroute

    traceroute -n
    

    分析方法
    对于故障现象不明显的我们可以做以下测试:
    1、抓包:从源IP ping 目的IP,然后在源端抓reply包,在目的端抓request包
      a)如果目的端抓到的request包少于400(目的端收到的请求包少于400,源端收到的reply包肯定少于400),则重点关注源端到目的端的mtr和traceroute图
      b)如果目的端收到的request包为400,但是源端收到的reply包少于400,则重点关注从目的端到源端的mtr和traceroute图
      **c) 如果我在对端抓包,抓不到任何数据包,**这种情况一般是数据包在中间路径就丢了。此时对比MTR分析,可以很明显的看到路径是不完整的或者是有回路。
      抓包小技巧:因为我们测试一般是在监控机测试,但是作为监控机,一定会收到大量的ICMP包,对抓包会造成影响。为了避免这种影响,我们可以为发送的数据包指定伊特特殊的长度,比如1016。此时的表达式为:

    tcpdump -i eth1 -n -vv -p icmp and src host IPADD | grep “length 1024”

    这里为什么时1024字节了?因为需要加上8字节的头部,所以是1016+8=1024

    常见的网络问题 :
    1、电脑拼局域网的服务器间歇丢包,上外网没有问题
    答案 :网络不稳定,路由震荡,正常
    目前的解决方法,就是开个cmd窗口 ping -t ,这样能保持路由更新快些。
    同一个交换机内的电脑,ping 很稳定,不同交换机,就会间歇Request timed out, ping 外网正常。

    2、buntu12.04去ping专线ip
    掉包率达到35%

    3、

    4、

    5、

    参考连接:

    Linux 系统 UDP 丢包问题分析思路 ; 作者:CloudDeveloper
    链接:https://cizixs.com/2018/01/13/linux-udp-packet-drop-debug/

    https://blog.csdn.net/weixin_33721427/article/details/92661924

    展开全文
  • 问题描述:两个不同的应用程序,分别运行在linux服务器A,linux服务器B,跨网段进行udp数据传输,中间经过一种网闸设备(一种安防行业的跨网段的网络设备),服务器A发送数据,服务器B接收数据,服务器B抓有数据,...
  • https://www.tuicool.com/articles/7ni2yyr最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,总结出来这篇文章,供更多人参考。在开始之前,我们先用一张图解释 linux 系统接收网络报文的...
  • 最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,总结出来这篇文章,供更多人参考。 在开始之前,我们先用一张图解释 linux 系统接收网络报文的过程。 首先网络报文通过物理网线发送到...
  • 解决系统丢包问题

    2013-12-13 18:50:25
    当系统经常出现丢包问题时(ifconfig可以看到),修改rx_ring可以解决这个问题。 sudo /sbin/ethtool -g eth0 | /bin/grep "RX:" | /bin/sed "1q"|/bin/cut -f 3 |xargs /sbin/ethtool -G eth0 rx [huanglq@hadoop...
  • [root@pa137 ~]# netstat --helpusage: netstat [-veenNcCF] [<Af>] -r netstat {-V|--version|-h|--help} netstat [-vnNcaeol] [<Socket> ...] netstat { [-veenNac]...
  • # lspci | grep Ethernet03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)07:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM570...
  • linux UDP丢包问题分析

    2019-12-05 22:25:17
    linux 系统 UDP 丢包问题分析思路 www.cnblogs.com2018/01/13 转自:http://cizixs.com/2018/01/13/linux-udp-packet-drop-debug?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io 最近工作...
  • Oracle RAC 与 网卡绑定

    2017-12-05 15:01:16
       RAC 对节点之间的内部通信要求比较高,如果内部节点...所以这里就提到了网卡绑定,就是将多个物理网卡绑定到一个虚拟网卡上,由虚拟网卡提供服务。    网卡绑定有几种,常用主备模式和负载
  • 通过ADSL宽带“猫”上网,系统为RedHat 9.0,但在上网时有些网页打不开,而且网速不快。这跟MTU值有关系,将它修改到适当的值即可。在Windows下可以通过修改注册表来修改MTU值,可在Linux下面又该如何做呢?...
  • 续上一篇《性能测试知识问题整理(二)》 二十一、Ramp-up 配置有什么作用?为什么说压力工具中 TPS 和响应时间曲线抖动过大不易于分析? 问题一:Jmeter中Ramp-up 配置有什么样的作用? Ramp-up 配置的时间是指...
  • 最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,总结出来这篇文章,供更多人参考。 在开始之前,我们先用一张图解释 linux 系统接收网络报文的过程。 首先网络报文通过物理网线发送到...
1 2 3 4 5 ... 20
收藏数 4,039
精华内容 1,615
关键字:

unix 网卡丢包