Linux Performance monitoring: Network

Network monitoring is the most complex of all Linux subsystems, there are too many factors in the inside, such as: delay, blocking, conflict, packet loss, and worse, the router connected to the Linux host, switch, wireless signal will affect the overall network and it is difficult to determine because the Linux The problem of network subsystem is also the problem of other equipments, which increases the complexity of monitoring and judging. Now all of the NICs we use are called adaptive NICs, which means they can be adjusted automatically based on different network speeds and operating modes caused by different network devices on the network. We can use the Ethtool tool to view the configuration and operating mode of the NIC:

#/sbin/ethtool Eth0settings for eth0:supported ports: [TP]supported link modes:   10baset/half 10baset/full                         100b Aset/half 100baset/full                         1000baset/half 1000baset/full Supports auto-negotiation:yesadvertised link modes:  10baset/half 10baset/full                         100baset/half 100baset/full                         1000baset/half 1000baset/full Advertised auto-negotiation:yesspeed:100mb/sduplex:fullport:twisted pairphyad:1transceiver:internalauto-negotiation: Onsupports wake-on:gwake-on:gcurrent message level:0x000000ff (255) Link Detected:yes

The example above shows that the NIC has 10baset,100baset and 1000baseT three options and is currently adaptive to 100baseT (SPEED:100MB/S). You can force the NIC to work under 1000baseT with the Ethtool tool:

#/sbin/ethtool-s eth0 speed, duplex full Autoneg off

Iptraf

Between the two hosts have network cable (or wireless), routers, switches and other devices, testing the network performance between the two hosts one way is to send data between the two systems and statistical results to see how the throughput, latency, rate. Iptraf is a good tool to view the native network throughput, support text graphics interface, very intuitive. The following picture shows that the transmission rate of this Linux system is a bit slow at a network of up to Mbps rates, outgoing rates is only one Mbps.

# iptraf-d Eth0

Netperf

The Netperf runs in client/server mode, which is more versatile than the Iptraf to test the throughput of the terminal. Start NetServer on the server side first:

# NetServer Starting NetServer at Port 12865Starting netserver at hostname 0.0.0.0 Port 12865 and family Af_unspec

Then, on the client test server, perform a TCP test that lasts for 10 seconds:

# netperf-h 172.16.38.36-l 10TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 af_inet to 172.16.38.36 (172.16.38.36) port 0 AF_INETRECV   send    send                          socket socket  Message  Elapsed              size     size Size time     throughput  bytes  bytes   bytes    secs.    10^6bits/sec   87380  16384  16384    10.32      93.68

From the above output can be seen, the network throughput of about 94mbps, for 100mbps network, this performance calculation is very good. The above test is on the server and the client is located in the same LAN, and LAN is the case of wired network, you can also try different structures, different rates of network, such as: between the network between several routers, the client in the Wi-Fi, VPN and so on.

Netperf can also test the number of TCP requests and responses per second by establishing a TCP connection and sending packets sequentially. The output below shows that the TCP requests uses a 2K size and the processing rate is 243 per second using 32K responses:

# netperf-t Tcp_rr-h 172.16.38.36-l---R 2048,32768tcp request/response TEST from 0.0.0.0 (0.0.0.0) port 0 af_inet To 172.16.38.36 (172.16.38.36) port 0 af_inetlocal/remotesocket Size   Request  Resp.   Elapsed  trans.send   Recv   size     size time rate         bytes  bytes  bytes    bytes   secs.    Per sec   16384  87380  2048     32768   10.00     243.03   16384  

Iperf

Iperf and Netperf run in a similar manner and are server/client mode, starting at the server-side iperf:

# iperf-s-D------------------------------------------------------------Server listening on TCP port 5001TCP window size:85.3 KByte (default)------------------------------------------------------------Running Iperf Server as a Daemonthe Iperf Daemon Process id:5695

The server is then tested on the client, the client connects to the server side (172.16.38.36), and a bandwidth test and sampling of the network between the server and the client is performed every 5 seconds within 30 seconds:

# iperf-c 172.16.38.36-t 30-i 5------------------------------------------------------------Client connecting to 172.16.38.36, TCP Port 5001TCP window size:16.0 KByte (default)------------------------------------------------------ ------[3] Local 172.16.39.100 port 49515 connected with 172.16.38.36 Port 5001[ID] Interval Transfer Bandwidt H[3] 0.0-5.0 sec 58.8 MBytes 98.6 mbits/sec[ID] Interval Transfer bandwidth[3] 5.0-10.0 sec 55.0 mbyt ES 92.3 mbits/sec[id] Interval Transfer bandwidth[3] 10.0-15.0 sec 55.1 MBytes 92.4 mbits/sec[ID] Interva   L Transfer bandwidth[3] 15.0-20.0 sec 55.9 MBytes 93.8 mbits/sec[ID] Interval Transfer bandwidth[   3] 20.0-25.0 sec 55.4 MBytes 92.9 mbits/sec[ID] Interval Transfer bandwidth[3] 25.0-30.0 sec 55.3 MBytes 92.8 mbits/sec[ID] Interval Transfer bandwidth[3] 0.0-30.0 sec 335 MBytes 93.7 Mbits/sec

Tcpdump and Tcptrace

Tcmdump and Tcptrace provide a more granular method of profiling by first capturing a packet with tcpdump on demand, outputting the result to a file, and then parsing its file format with Tcptrace. This combination of tools provides some information that is difficult to discover with other tools:

#/usr/sbin/tcpdump-w network.dmptcpdump:listening on eth0, Link-type EN10MB (Ethernet), capture size bytes511942 PAC Kets captured511942 packets received by FILTER0 packets dropped by kernel# Tcptrace network.dmp 1 arg remaining, starting With ' network.dmp ' Ostermann ' s tcptrace--version 6.6.7--Thu Nov 4, 2004511677 packets seen, 511487 TCP packets Tracede Lapsed Wallclock time:0:00:00.510291, 1002714 pkts/sec analyzedtrace file elapsed time:0:02:35.836372tcp Connection info                   : 1:zaber:54581-boulder:111 (A2B) 6> 5< (complete) 2:zaber:833-boulder:32774 (C2D) 6> 5< (complete) 3:zaber:pcanywherestat-172.16.39.5:53086 (e2f) 2> 3< 4:zaber:7 16-boulder:2049 (g2h) 347> 257< 5:172.16.39.100:58029-zaber:12865 (i2j) 7> 5 < (complete) 6:172.16.39.100:47592-zaber:36814 (K2L) 255380> 255378< (reset) 7:breakpoint:45510-        zaber:7012 (M2N)       9> 5< (complete) 8:zaber:35813-boulder:111 (o2p) 6> 5< (complete) 9:zab               er:837-boulder:32774 (Q2R) 6> 5< (complete) 10:breakpoint:45511-zaber:7012 (S2T) 9> 5< (complete) 11:zaber:59362-boulder:111 (u2v) 6> 5< (complete) 12:zabe               r:841-boulder:32774 (w2x) 6> 5< (complete) 13:breakpoint:45512-zaber:7012 (y2z) 9> 5< (complete)

Tcptrace is powerful and can be filtered and Boolean expressions to identify problematic connections, for example, to find a connection that is larger than segments:

# tcptrace-f ' rexmit_segs>100 ' network.dmp

If you find a problem with the connection # #, you can view additional information about the connection:

# Tcptrace-o10 Network.dmp

The following command uses Tcptrace's slice mode, and the program automatically creates a Slice.dat file in the current directory that contains the retransmission information every 15 seconds:

# Tcptrace-xslice network.dmp# cat slice.dat date segs bytes Rexsegs rexbytes new Active-------         --------------------------------------------------------16:58:50.244708 85055 4513418 0 0 6        616:59:05.244708 110921 5882896 0 0 0 216:59:20.244708 126107 6697827 0 0 1 316:59:35.244708 151719 8043597 0 0 0 216:59:50.244708 37296 19 80557 0 0 0 317:00:05.244708 67 8828 0 0 2 317:00:20.244        708 149 22053 0 0 1 217:00:35.244708 30 4080 0 0 0        117:00:50.244708 39 5688 0 0 0 117:01:05.244708 67 8828 0 0 2 317:01:11.081080 37 4121 0 0 1 3

Linux Performance monitoring: Network