精华内容
下载资源
问答
  • 通过dropwatch定位系统内核丢包 Finding out if/why a server is dropping packets github source coed: pavel-odintsov/drop_watch How to drop a packet in Linux in more ways than one 试试Linux下的ip命令...

    引用


    一. 如何查看自己的网卡丢包情况

    1. proc文件系统

    1.1 dev: 查看各net device的统计信息

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# cat /proc/net/dev
    Inter-|   Receive                                                |  Transmit
     face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
        lo:   29142     323    0    0    0     0          0         0    29142     323    0    0    0     0       0          0
    wlp3s0: 35148233   39485    0 1226    0     0          0         0  4937381   36609    0    0    0     0       0          0
    enp4s0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
    

    1.2 softnet_stat: 查看各CPU下的backlog统计信息

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# cat /proc/net/softnet_stat
    000001b0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00000094 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00009a0f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00000089 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    
    注:
    seq_printf(seq,
           "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n",
           sd->processed, sd->dropped, sd->time_squeeze, 0,
           0, 0, 0, 0, /* was fastroute */
           sd->cpu_collision, sd->received_rps, flow_limit_count);
    
    Each line of /proc/net/softnet_stat corresponds to a struct softnet_data structure, of which there is 1 per CPU.
     
    The values are separated by a single space and are displayed in hexadecimal
    
    The first value, sd->processed, is the number of network frames processed. This can be more than the total
     number of network frames received if you are using ethernet bonding. There are cases where the ethernet
     bonding driver will trigger network data to be re-processed, which would increment the sd->processed count
     more than once for the same packet.
     
    The second value, sd->dropped, is the number of network frames dropped because there was no room on the
     processing queue. More on this later.
     
    The third value, sd->time_squeeze, is (as we saw) the number of times the net_rx_action loop terminated
     because the budget was consumed or the time limit was reached, but more work could have been. Increasing
     the budget as explained earlier can help reduce this.
     
    The next 5 values are always 0.
    
    The ninth value, sd->cpu_collision, is a count of the number of times a collision occurred when trying to
     obtain a device lock when transmitting packets. This article is about receive, so this statistic will not be seen below.
     
    The tenth value, sd->received_rps, is a count of the number of times this CPU has been woken up to process
     packets via an Inter-processor Interrupt
     
    The last value, flow_limit_count, is a count of the number of times the flow limit has been reached.
     Flow limiting is an optional Receive Packet Steering feature that will be examined shortly.
    

    ------
    默认每个cpu的backlog是1000。
    当netdev driver使用的非NAPI或开启了RPS时,就会用到backlog。
    当进行高tput测试时,可以查看是否有在backlog这里丢包。

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# sysctl net.core.netdev_max_backlog
    net.core.netdev_max_backlog = 1000

    ------

    1.3 snmp: 查看各层协议的收发信息

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# cat /proc/net/snmp
    Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates
    Ip: 2 64 42966 0 2 0 0 0 40770 50253 20 0 0 0 0 0 0 0 0
    Icmp: InMsgs InErrors InCsumErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchos OutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps
    Icmp: 40 0 0 40 0 0 0 0 0 0 0 0 0 0 40 0 40 0 0 0 0 0 0 0 0 0 0
    IcmpMsg: InType3 OutType3
    IcmpMsg: 40 40
    Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts InCsumErrors
    Tcp: 1 200 120000 -1 38 11 2 0 3 39093 49237 386 0 22 0
    Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors InCsumErrors IgnoredMulti
    Udp: 1196 40 0 594 0 0 0 576
    UdpLite: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors InCsumErrors IgnoredMulti
    UdpLite: 0 0 0 0 0 0 0 0
    

    2. ifconfig

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# ifconfig
    enp4s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether 30:85:a9:2a:48:06  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
    
    ----
    注:
    /net/core/dev.c
    
    struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
    					struct rtnl_link_stats64 *storage)
    {
    	const struct net_device_ops *ops = dev->netdev_ops;
    
    	/* 网卡有注册  ndo_get_stats64该函数*/
    	if (ops->ndo_get_stats64) {
    		memset(storage, 0, sizeof(*storage));
    		ops->ndo_get_stats64(dev, storage);
    
    	/* 网卡有注册 ndo_get_stats 该函数*/
    	} else if (ops->ndo_get_stats) {
    		netdev_stats_to_stats64(storage, ops->ndo_get_stats(dev));
    
    	/* 直接通过 dev->stats 获取, 该结构正在被遗弃。*/
    	} else {
    		netdev_stats_to_stats64(storage, &dev->stats);
    	}
    
    	/* 即 这里还要加上 kernel drop的packet - /net/core/dev.c 。 
           1. enqueue_to_backlog(): 当backlog不够时。atomic_long_inc(&skb->dev->rx_dropped)
    (同时也会更新 sd->dropped++)
           2. __netif_receive_skb_core() -- 不认识的packet。atomic_long_inc(&skb->dev->rx_dropped);
        */
    	storage->rx_dropped += (unsigned long)atomic_long_read(&dev->rx_dropped);
    	storage->tx_dropped += (unsigned long)atomic_long_read(&dev->tx_dropped);
    	storage->rx_nohandler += (unsigned long)atomic_long_read(&dev->rx_nohandler);
    	return storage;
    }

    3. ip

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# ip -s -s link ls enp4s0
    2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
        link/ether 30:85:a9:2a:48:06 brd ff:ff:ff:ff:ff:ff
        RX: bytes  packets  errors  dropped overrun mcast
        0          0        0       0       0       0
        RX errors: length   crc     frame   fifo    missed
                   0        0       0       0       0
        TX: bytes  packets  errors  dropped carrier collsns
        0          0        0       0       0       0
        TX errors: aborted  fifo   window heartbeat transns
                   0        0       0       0       1
    

    4.netstat

    4.1 查看各网卡的netdev统计信息

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# netstat -i
    Kernel Interface table
    Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
    enp4s0    1500        0      0      0 0             0      0      0      0 BMU
    lo       65536      327      0      0 0           327      0      0      0 LRU
    wlp3s0    1500    41520      0   1434 0         40349      0      0      0 BMRU
    

    4.2 查看特定协议(例如.UDP)的统计信息

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# netstat -su
    IcmpMsg:
        InType3: 40
        OutType3: 40
    Udp:
        1159 packets received
        40 packets to unknown port received
        0 packet receive errors
        576 packets sent
        0 receive buffer errors
        0 send buffer errors
        IgnoredMulti: 468
    UdpLite:
    IpExt:
        InMcastPkts: 370
        OutMcastPkts: 83
        InBcastPkts: 728
        OutBcastPkts: 77
        InOctets: 34596737
        OutOctets: 3791474
        InMcastOctets: 147789
        OutMcastOctets: 9349
        InBcastOctets: 311773
        OutBcastOctets: 13116
        InNoECTPkts: 39035
    

    5.ethtool

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# ethtool -S enp4s0
    NIC statistics:
         tx_packets: 0
         rx_packets: 0
         tx_errors: 0
         rx_errors: 0
         rx_missed: 0
         align_errors: 0
         tx_single_collisions: 0
         tx_multi_collisions: 0
         unicast: 0
         broadcast: 0
         multicast: 0
         tx_aborted: 0
         tx_underrun: 0
    

    二. 如何分析和解决丢包问题

    1. 扩大协议栈相关buffer

    ### KERNEL TUNING ###
    
    # Increase size of file handles and inode cache
    fs.file-max = 2097152
    
    # Do less swapping
    vm.swappiness = 10
    vm.dirty_ratio = 60
    vm.dirty_background_ratio = 2
    
    # Sets the time before the kernel considers migrating a proccess to another core
    kernel.sched_migration_cost_ns = 5000000
    
    # Group tasks by TTY
    #kernel.sched_autogroup_enabled = 0
    
    ### GENERAL NETWORK SECURITY OPTIONS ###
    
    # Number of times SYNACKs for passive TCP connection.
    net.ipv4.tcp_synack_retries = 2
    
    # Allowed local port range
    net.ipv4.ip_local_port_range = 2000 65535
    
    # Protect Against TCP Time-Wait
    net.ipv4.tcp_rfc1337 = 1
    
    # Control Syncookies
    net.ipv4.tcp_syncookies = 1
    
    # Decrease the time default value for tcp_fin_timeout connection
    net.ipv4.tcp_fin_timeout = 15
    
    # Decrease the time default value for connections to keep alive
    net.ipv4.tcp_keepalive_time = 300
    net.ipv4.tcp_keepalive_probes = 5
    net.ipv4.tcp_keepalive_intvl = 15
    
    ### TUNING NETWORK PERFORMANCE ###
    
    # Default Socket Receive Buffer
    net.core.rmem_default = 31457280
    
    # Maximum Socket Receive Buffer
    net.core.rmem_max = 33554432
    
    # Default Socket Send Buffer
    net.core.wmem_default = 31457280
    
    # Maximum Socket Send Buffer
    net.core.wmem_max = 33554432
    
    # Increase number of incoming connections
    net.core.somaxconn = 65535
    
    # Increase number of incoming connections backlog
    net.core.netdev_max_backlog = 65536
    
    # Increase the maximum amount of option memory buffers
    net.core.optmem_max = 25165824
    
    # Increase the maximum total buffer-space allocatable
    # This is measured in units of pages (4096 bytes)
    net.ipv4.tcp_mem = 786432 1048576 26777216
    net.ipv4.udp_mem = 65536 131072 262144
    
    # Increase the read-buffer space allocatable
    net.ipv4.tcp_rmem = 8192 87380 33554432
    net.ipv4.udp_rmem_min = 16384
    
    # Increase the write-buffer-space allocatable
    net.ipv4.tcp_wmem = 8192 65536 33554432
    net.ipv4.udp_wmem_min = 16384
    
    # Increase the tcp-time-wait buckets pool size to prevent simple DOS attacks
    net.ipv4.tcp_max_tw_buckets = 1440000
    net.ipv4.tcp_tw_recycle = 1
    net.ipv4.tcp_tw_reuse = 1

    2. 可能性

    2.1 防火墙拦截

    root@spc:~# iptables -L -n
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination
    
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination
    

    2.2 连接跟踪表溢

    root@spc:/# conntrack -S
    cpu=0           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=1           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=2           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=3           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=4           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=5           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=6           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=7           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=8           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=9           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=10          found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=11          found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=12          found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=13          found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=14          found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=15          found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    
    注:
    除了防火墙本身配置DROP规则外,与防火墙有关的还有连接跟踪表nf_conntrack,Linux为每个经过内核网络
    栈的数据包,生成一个新的连接记录项,当服务器处理的连接过多时,连接跟踪表被打满,服务器会丢弃新建连
    接的数据包。
    
    如何确认:
    通过dmesg可以确认是否有该情况发生:如果输出值中有“nf_conntrack: table full, dropping 
    packet”,说明服务器nf_conntrack表已经被打满。
    
    通过conntrack工具或/proc文件系统查看nf_conntrack表实时状态:在本案例中,当前连接数远没有达到跟
    踪表最大值,因此排除这个因素。
    
    如何解决:
    如果确认服务器因连接跟踪表溢出而开始丢包,首先需要查看具体连接判断是否正遭受DOS攻击,如果是正常的
    业务流量造成,则可以考虑调整nf_conntrack的参数:
    
    nf_conntrack_max决定连接跟踪表的大小,默认值是65535,可以根据系统内存大小计算一个合理值:
    CONNTRACK_MAX = RAMSIZE(in bytes)/16384/(ARCH/32),如32G内存可以设置1048576
    
    nf_conntrack_buckets决定存储conntrack条目的哈希表大小,默认值是nf_conntrack_max的1/4,延续这
    种计算方式:BUCKETS = CONNTRACK_MAX/4,如32G内存可以设置262144
    
    nf_conntrack_tcp_timeout_established决定ESTABLISHED状态连接的超时时间,默认值是5天,可以缩短
    到1小时,即3600
    

    2.3 网卡设备的ring buffer溢出(网卡driver的统计)

    如何确认:
    通过 ifconfig/ifconfig/ip/ethtool, /proc/net/dev等可以查看drop包的数量。
    
    如何解决:
    通过调整网卡driver中的相关buffer
    

    2.4 netdev_max_backlog溢出

    通过 /proc/net/softnet_stat 可查看溢出信息。
    
    netdev_max_backlog是内核从NIC收到包后,交由协议栈(如IP、TCP)处理之前的缓冲队列。每个CPU核都有一
    个backlog队列,与Ring Buffer同理,当接收包的速率大于内核协议栈处理的速率时,CPU的backlog队列不断
    增长,当达到设定的netdev_max_backlog值时,数据包将被丢弃。
    
    如何确认:
    通过查看/proc/net/softnet_stat可以确定是否发生了netdev backlog队列溢出。其中:
    每一行代表每个CPU核的状态统计,从CPU0依次往下
    每一列代表一个CPU核的各项统计:第一列代表中断处理程序收到的包总数;第二列即代表由于
    netdev_max_backlog队列溢出而被丢弃的包总数
    
    如何解决:
    netdev_max_backlog的默认值是1000,在高速链路上,可能会出现上述第二列统计不为0的情况,可以适当调大
    内核参数net.core.netdev_max_backlog到2000来解决。

    2.5 反向路由过滤

    root@spc:/# sysctl -a | grep rp_filter
    net.ipv4.conf.all.arp_filter = 0
    net.ipv4.conf.all.rp_filter = 2
    net.ipv4.conf.default.arp_filter = 0
    net.ipv4.conf.default.rp_filter = 2
    net.ipv4.conf.enp4s0.arp_filter = 0
    net.ipv4.conf.enp4s0.rp_filter = 2
    net.ipv4.conf.lo.arp_filter = 0
    net.ipv4.conf.lo.rp_filter = 0
    net.ipv4.conf.wlp3s0.arp_filter = 0
    net.ipv4.conf.wlp3s0.rp_filter = 2
    
    
    注:
    反向路由过滤机制是Linux通过反向路由查询,检查收到的数据包源IP是否可路由(Loose mode)、是否最佳
    路由(Strict mode),如果没有通过验证,则丢弃数据包,设计的目的是防范IP地址欺骗攻击。rp_filter提供了三种模式供配置:
    
    0 - 不验证
    1 - RFC3704定义的严格模式:对每个收到的数据包,查询反向路由,如果数据包入口和反向路由出口不一致,则不通过
    2 - RFC3704定义的松散模式:对每个收到的数据包,查询反向路由,如果任何接口都不可达,则不通过
    
    查看和配置:sysctl -a | grep rp_filter 
    关于rp_filter :https://www.cnblogs.com/lipengxiang2009/p/7446388.html
    
    如何确认:
    查看当前rp_filter策略配置,如果设置为1,就需要查看主机的网络环境和路由策略是否可能会导致客户端的入包无法通过反向路由验证。
    
    从原理来看这个机制工作在网络层,因此,如果客户端能够Ping通服务器,就能够排除这个因素了。
    
    解决办法:
    1.修改路由表,使响应数据包从eth1出,即保证请求数据包进的网卡和响应数据包出的网卡为同一个网卡。
    2.关闭rp_filter参数。(注意all和default的参数都要改)
    1)修改/etc/sysctl.conf文件,然后sysctl -p刷新到内存。
    2)使用sysctl -w直接写入内存:sysctl -w net.ipv4.conf.all.rp_filter=0
    3)修改/proc文件系统: echo "0">/proc/sys/net/ipv4/conf/all/rp_filter

    2.6 半连接队列溢出

    半连接队列指的是TCP传输中服务器收到SYN包但还未完成三次握手的连接队列,队列大小由内核参数tcp_max_syn_backlog定义。
    当服务器保持的半连接数量达到tcp_max_syn_backlog后,内核将会丢弃新来的SYN包。
    
    如何确认:
    通过dmesg可以确认是否有该情况发生:如果输出值中有“TCP: drop open request from”,说明半连接队列已
    被打满。
    半连接队列的连接数量可以通过netstat统计SYN_RECV状态的连接得知。大多数情况下这个值应该是0或很小,因
    为半连接状态从第一次握手完成时进入,第三次握手完成后退出,正常的网络环境中这个过程发生很快,如果这个
    值较大,服务器极有可能受到了SYN Flood攻击。
    
    如何解决:
    tcp_max_syn_backlog的默认值是256,通常推荐内存大于128MB的服务器可以将该值调高至1024,内存小于32MB
    的服务器调低到128,同样,该参数通过sysctl修改。
    另外,上述行为受到内核参数tcp_syncookies的影响,若启用syncookie机制,当半连接队列溢出时,并不会直
    接丢弃SYN包,而是回复带有syncookie的SYC+ACK包,设计的目的是防范SYN Flood造成正常请求服务不可用。
    

    2.7 PAWS :内核参数/proc/sys/net/ipv4/tcp_tw_recycle 控制

    PAWS全名Protect Againest Wrapped Sequence numbers,目的是解决在高带宽下,TCP序列号在一次会话中可能被重复使用而带来的问题

    3. dropwatch

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# sudo ./dropwatch -l kas
    Initalizing kallsyms db
    dropwatch> start
    Enabling monitoring...
    Kernel monitoring activated.
    Issue Ctrl-C to stop monitoring
    9 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    1 drops at __netif_receive_skb_core+14f (0xffffffffac73612f)
    4 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    9 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    4 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    2 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    1 drops at __netif_receive_skb_core+14f (0xffffffffac73612f)
    4 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    4 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    5 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    4 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    1 drops at __netif_receive_skb_core+14f (0xffffffffac73612f)
    1 drops at ip_rcv_finish_core.isra.0+1b2 (0xffffffffac7affa2)
    ^CGot a stop message
    dropwatch>
    

    4. perf

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

    展开全文
  • ActiveMQ之Mqtt的TCP丢包

    千次阅读 2018-09-13 14:26:21
    现象 Mqtt Consumer应该收到的消息少于预期,登录ActiveMQ...怀疑是TCP丢包,通过netstat -s命令观察发送消息前后Tcp信息的输出 对比两次Tcp信息的输出,发现packets pruned from receive queue because of socke...

    现象

    Mqtt Consumer应该收到的消息少于预期,登录ActiveMQ的管理页面里的Topics,查看Messages Enqueued发现同样少于理应接收的数量。

    定位问题

    1. 怀疑是TCP丢包,通过netstat -s命令观察发送消息前后Tcp信息的输出
    2. 对比两次Tcp信息的输出,发现packets pruned from receive queue because of socket buffer overrunpackets collapsed in receive queue due to low socket buffer等含有prunedcollapsed字样的数值在增多。

    解决方案

    • 首先调整系统级tcp的缓冲区,修改/etc/sysctl.conf如下
    net.core.rmem_max = 8388608
    net.core.wmem_max = 8388608
    net.core.rmem_default = 655360
    net.core.wmem_default = 655360
    net.ipv4.tcp_rmem = 4096 655360 8388608 # Tcp接收缓冲区,分别是最小、默认、最大
    net.ipv4.tcp_wmem = 4096 655360 8388608 # Tcp发送缓冲区,分别是最小、默认、最大
    net.ipv4.tcp_mem = 8388608 8388608 8388608
    <transportConnector name="mqtt"
    uri="mqtt+nio://0.0.0.0:1883?maximumConnections=1000&amp;
    wireFormat.maxFrameSize=104857600&amp;transport.ioBufferSize=1048576&amp;
    transport.socketBufferSize=4194304"/>
    - 其中**+nio**表示启用**nio**方式的socket通信。Java里**nio**方式的socket比**bio**方式的更高效。mqtt默认采用**bio**。
    - **socketBufferSize**调整缓冲区大小为4m,默认为64k,防止socket接收缓冲过小引发系统扔包
    - **ioBufferSize**调整程序内部使用的缓冲区大小为1m,默认为8k,提高缓冲可以增加处理性能

    代码分析

    • MQTTTransportFactory继承自TcpTransportFactory
      • org.apache.activemq.transport.tcp.TcpTransportFactory#doBind时解析URI带入的参数
    • org.apache.activemq.transport.mqtt.MQTTNIOTransportFactory#createTcpTransportServer创建TcpTransportServer
    • org.apache.activemq.transport.tcp.TcpTransportServer#doRunWithServerSocketChannel创建与客户端通信的Transport
      • 默认的socketBufferSize = 65536
      • 默认的ioBufferSize = 8192
    • Transportorg.apache.activemq.transport.TransportAcceptListener#onAccept处理
      • Transport被扔给org.apache.activemq.thread.TaskRunnerFactory线程池
      • 在线程池中创建org.apache.activemq.broker.Connection
    • Connection中的org.apache.activemq.broker.TransportConnection#start启动整个TCP的链路

    Windows下定位问题的要点

    展开全文
  • 项目开了个P2P服务器,但是运行一段时间就会出现丢包问题,具体表现为:1、udp丢包严重(一分钟收发分别1.5W) 2、ssh(用于运维指令)连接不上该服务器(超时) 3、服务器运行好像没什么异常,udp假连接数比tcp...

    项目开了个P2P服务器,但是运行一段时间就会出现丢包问题,具体表现为:
    1、udp丢包严重(一分钟收发分别1.5W)

    2、ssh(用于运维指令)连接不上该服务器(超时)

    3、服务器运行好像没什么异常,udp假连接数比tcp连接数少(正常应该相近)

     


     

    首先开始怀疑是不是客户端有bug,查log发现某段时间有个别客户端发大量心跳包,开始怀疑这个原因导致服务异常。在多次关服开服后没出现这个问题,但是服务器运行一段时间依旧出现上述异常,排除这个原因。

     


     

    既然不是客户端导致的。。

    就开始在自身找原因,接着怀疑是不是最大连接数、最大文件打开数,查了一下服务器设置:

     ulimit -n  //可以打开最大文件描述符的数量

    65536

     

    ulimit -a  //显示当前所有的 limit 信息

    time(seconds) unlimited
    file(blocks) unlimited
    data(kbytes) unlimited
    stack(kbytes) 8192
    coredump(blocks) unlimited
    memory(kbytes) unlimited
    locked memory(kbytes) 64
    process 516037
    nofiles 65536
    vmemory(kbytes) unlimited
    locks unlimited

     

    cat /proc/sys/fs/nr_open  //单进程最大文件限制

    1048576

     

    cat /proc/sys/fs/file-max  //系统最大文件限制

    6605234

     

    再看下服务器现在相关信息:

    lsof -n  //查看服务器文件打开数信息

     

    ps -aef  //进程信息

     

    发现无论是文件描述符打开数还是文件打开数都没超标---陷入僵局。


     

    觉得应该是系统某个设置不当导致的,但是又无从查起,查 /car/log/messages 里面的信息应该能查到点端倪,可是没权限。(dmesg  命令好像可以查看)

    后来咨询其他小组,发现他们也遇到过一样的问题,问题来自于跟踪连接表的限制----nf_conntrack/ip_conntrack。

     

     理解nf_conntrack和调整nf_conntrack_max :nf_conntrack 工作在 层,支持 IPv4 和 IPv6,而 ip_conntrack 只支持 IPv4

     

    目前,大多的 ip_conntrack_* 已被 nf_conntrack_* 取代,很多 ip_conntrack_* 仅仅是个 alias,原先的 ip_conntrack 的 /proc/sys/net/ipv4/netfilter/ 依然存在,但是新的 nf_conntrack 在 /proc/sys/net/netfilter/ 中,这个应该是做个向下的兼容。

     

    nf_conntrack/ip_conntrack 跟 nat 有关,用来跟踪连接条目,它会使用一个哈希表来记录 established 的记录。nf_conntrack 在 2.6.15 被引入,而 ip_conntrack 在 2.6.22被移除,如果该哈希表满了,就会出现问题来。

     

    查看系统默认跟踪连接表限制:

    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max  //最大
    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established   //保存时间

     

    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count  //当前

     

    查看了以后,发现运行一段时间后 跟踪连接表的确是满了,导致文章开始所述的情况出现,而 ip_conntrack_max 有个建议值:

    CONNTRACK_MAX = RAMSIZE(in bytes)/16384/(ARCH/32),如32G内存可以设置1048576

     

    临时修改该值:

    echo 1048576> /proc/sys/net/ipv4/netfilter/ip_conntrack_max

     

    p2p服务器重启后运行恢复正常。


     

     

    参考引用:

    http://itoedr.blog.163.com/blog/static/120284297201451013130868/

    http://www.cnblogs.com/276815076/p/5736272.html

    http://www.sdnlab.com/17530.html

    转载于:https://www.cnblogs.com/GO-NO-1/p/7324502.html

    展开全文
  • linux 出现丢包解决方法

    千次阅读 2013-08-28 11:56:02
    linux 出现丢包解决方法 故障排查: 早上突然收到nagios服务器check_icmp的报警,报警显示一台网站服务器的内网网络有问题。因为那台服务器挂载了内网的NFS,因此内网的网络就采用nagios的check_icmp来做监控。 ...

    转自:http://www.10.cn/WebYW/TechSupport.aspx?rid=28

    linux 出现丢包解决方法

    故障排查:

    早上突然收到nagios服务器check_icmp的报警,报警显示一台网站服务器的内网网络有问题。因为那台服务器挂载了内网的NFS,因此内网的网络就采用nagios的check_icmp来做监控。

    赶紧登录服务器进行排查。首先使用ping 内网IP的方式查看内网的连通性,ping的过程中出现丢包现象,信息如下:

    64 bytes from 10.1.1.1: icmp_seq=34 ttl=255 time=0.928 ms

    64 bytes from 10.1.1.1: icmp_seq=35 ttl=255 time=1.01 ms

    ping: sendmsg: Operation not permitted

    ping: sendmsg: Operation not permitted

    显示ping不被允许,奇怪,防火墙上明明开通了icmp的协议。有问题先看日志,日志文件一般会有所记录,tail –f /var/log/messages,发现大量的如下内容:

    Sep 13 09:11:21 dowload_server1 kernel: printk: 261 messagessuppressed.

    Sep 13 09:11:21 dowload_server1 kernel: ip_conntrack: table full,dropping packet

    发现是当前会话数已经满了,因此出现丢包现象。这里对ip_conntrack做一下简单的介绍:IP_conntrack表示连接跟踪数据库(conntrack database),代表NAT机器跟踪连接的数目,连接跟踪表能容纳多少记录是被一个变量控制的,它可由内核中的ip-sysctl函数设置。每一个跟踪连接表会占用350字节的内核存储空间,时间一长就会把默认的空间填满,那么默认空间是多少?在内存为64MB的机器上是4096,内存为128MB是8192,内存为256MB是16384

    通过如下命令查看当前的会话数:

    cat /proc/net/ip_conntrack | wc –l    不要用,占CPU

    或者使用:

    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count

    使用如下命令查看设置的最大会话数

    cat /proc/sys/net/ipv4/ip_conntrack_max

    解决办法:

    发现确实已经达到了最大会话数,通过google发现,可以直接调大用户的最大会话数,命令为:

    echo "102400" > /proc/sys/net/ipv4/ip_conntrack_max

    执行此命令后,不在丢包了,ping也正常了。但是这样设置不会永久保存,当系统重启后设置会丢失,因此需要保存到/etc/sysctl.conf,在/etc/sysctl.conf中加入:net.ipv4.ip_conntract_max =102400,然后执行/sbin/sysctl –p刷新内核参数即可,如果出现error:"net.ipv4.ip_conntract_max" is an unknown key报错的话,需要加载ip_conntract模块,使用modprobe  ip_conntrack加载,使用lsmod | grepip_conntrack查看模块是否加载。

    终极解决:

    为了使彻底解决此问题,还需要再设置一个东西,那就是会话连接超时变量,这个参数设置太长的话就会导致会话连接数不断增加,默认是设置为432000秒,很显然这个值太大了,通过如下命令设置小一点:

    echo 21600>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

    设置成21600也就是6小时,这样会自动清除6小时候后的无效链接。记得将这句话加到自动启动文件/etc/rc.local文件中去。


    展开全文
  •   tcp协议中,序号(seq,ack)的作用是保证连接的可靠和数据包的有序,但现实中往往会出现丢包,或者某些包迷路。例如序列号为s1的包A 因为网络问题没有到达,客户端重发s1包B,但因为带宽足够,在一次回话中,...
  • 使用ifconfig命令,ifconfig是最常用的配置和查看网络接口信息的命令,服务器上执行此命令会得到类下文的内容,一下内容可看到多个设备和设备状态、信息。 # 不包括down状态的网卡 ifconfig #查看所有网卡的...
  • Linux UDP严重丢包问题的解决

    千次阅读 2016-09-20 11:19:35
    测试系统在Linux上的性能发现丢包率极为严重,发210000条数据,丢包达110000之巨,丢包率超过50%。同等情形下Windows上测试,仅丢几条数据。形势严峻,必须解决。考虑可能是因为协议栈Buffer太低所致,于是先看看...
  • linux 系统 UDP 丢包问题分析思路

    千次阅读 2018-01-18 10:54:18
    https://www.tuicool.com/articles/7ni2yyr最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,总结出来这篇文章,供更多人参考。在开始之前,我们先用一张图解释 linux 系统接收网络报文的...
  • linux 丢包问题

    千次阅读 2012-11-27 17:31:22
    测试系统在Linux上的性能发现丢包率极为严重,发210000条数据,丢包达110000之巨,丢包率超过50%。同等情形下Windows上测试,仅丢几条数据。形势严峻,必须解决。考虑可能是因为协议栈Buffer太低所致,于是先看看...
  • linux 系统 UDP 丢包

    2018-10-20 17:28:02
    1、 linux 系统接收网络报文的过程介绍 ● 首先网络报文通过物理网线发送到网卡● 网络驱动程序会把网络中的报文读出来放到 ring buffer 中,这个过程使用 DMA(Direct Memory Access),不需要 CPU 参与● 内核从 ...
  • 本文讨论的udp丢包是指网卡接收到数据包后,Linux内核的tcp/ip协议栈在udp数据包处理过程中的丢包,主要原因有两个:1) udp数据包格式错误或校验和检查失败2) 应用程序来不及处理udp数据包对于原因1),udp数据包本身...
  • 查看网络丢包命令

    千次阅读 2019-10-12 10:55:28
    常见的测试丢包命令 :ping 、mtr 、traceroute 、fping、ipconfig、nbtstat、route、arp iperf检测命令 UDP丢包和延迟测试 iperf3 -c 172.21.76.108 -u -b 100M -f M -i 3 iperf在单线程模式下的传输时间和...
  • 高流量大并发Linux TCP 性能调优

    千次阅读 2016-08-31 18:58:15
     高延迟高丢包(典型的美国服务器) 值得注意的是,因为openvz的VPS权限比较低,能够修改的地方比较少,所以使用openvz的VPS作VPN服务器是非常不推荐的。 我们通过修改 /etc/sysctl.conf 来
  • linux 模拟延时和丢包

    2015-04-24 10:31:00
    我们做的应用软件,还有测试 TCP/UDP 对比,测试 BDP 对 TCP/IP 的影响时,我们都需要一些网络中的延时和丢包模拟,很多商业的软件可以做这个事,其实完美的 Linux 本身就可以使用 TC 来实现这个功能. TC 中的 Netem 可以...
  • Linux tcp拥塞控制

    2020-11-27 22:20:18
    1、滑动窗口 滑动窗口是发送方根据接收方的接收窗口来控制发送速率的手段,接收发的滑动窗口可分成以下四个部分,最左边...紫色区域最右边的值对应tcp的snd_una,蓝色最左侧对应tcp的snd_next;在数据包传输过程中,sn
  • 最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,总结出来这篇文章,供更多人参考。 在开始之前,我们先用一张图解释 linux 系统接收网络报文的过程。 首先网络报文通过物理网线发送到...
  • 目录 TC案例 TC常用命令 TC安装 TC原理介绍 ...如何使用tc模拟网络延迟和丢包 修改网络延时:sudotcqdiscadddeveth0rootnetemdelay1000ms 查看流量管理:tc qdisc show 删除策略:sudotcqdi...
  • 其实主要是手里面的跑openvpn服务器。因为并没有明文禁p2p(哎……想想那么多流量好像不跑点p2p也跑不完),所以造成有的时候如果有比较多人跑BT的话,会造成... 高延迟高丢包(典型的美国服务器)  值得注意的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 13,510
精华内容 5,404
关键字:

linuxtcp丢包命令

linux 订阅