今天發(fā)現(xiàn)有一個數(shù)據(jù)延遲的很厲害，通過日志查看，日志2G的日志傳輸了半個小時的時間，導致最后分析延遲。是什么原因呢？
分析原因
通過日志可以查看到rsync日志同步的速度比平時慢了9倍。通過zabbix監(jiān)控看到網(wǎng)絡雖然比較繁忙，但是還沒有達到瓶頸。所以猜測：丟包了！！！
ifconfig可以查看到一些網(wǎng)卡信息的匯總：
# ifconfig em2
em2 Link encap:Ethernet HWaddr AC:85:3D:A9:03:0D
inet addr:1.1.1.33 Bcast:1.1.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:17141208886 errors:164254181 dropped:0 overruns:0 frame:0
TX packets:14685534428 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2619578349554 (2.3 TiB) TX bytes:1479317006067 (1.3 TiB)
Memory:94b00000-94b20000
RX errors: 表示總的收包的錯誤數(shù)量，這包括 too-long-frames 錯誤，Ring Buffer 溢出錯誤，crc 校驗錯誤，幀同步錯誤，fifo overruns 以及 missed pkg 等等。
500514388_banner
RX dropped: 表示數(shù)據(jù)包已經(jīng)進入了 Ring Buffer，但是由于內(nèi)存不夠等系統(tǒng)原因，導致在拷貝到內(nèi)存的過程中被丟棄。
RX overruns: 表示了 fifo 的 overruns，這是由于 Ring Buffer(aka Driver Queue) 傳輸?shù)?IO 大于 kernel 能夠處理的 IO 導致的，而 Ring Buffer 則是指在發(fā)起 IRQ 請求之前的那塊 buffer。很明顯，overruns 的增大意味著數(shù)據(jù)包沒到 Ring Buffer 就被網(wǎng)卡物理層給丟棄了，而 CPU 無法即
的處理中斷是造成 Ring Buffer 滿的原因之一，上面那臺有問題的機器就是因為 interruprs 分布的不均勻(都壓在 core0)，沒有做 affinity 而造成的丟包。
RX frame: 表示 misaligned 的 frames。
對于 TX 的來說，出現(xiàn)上述 counter 增大的原因主要包括 aborted transmission, errors due to carrirer, fifo error, heartbeat erros 以及 windown error，而 collisions 則表示由于 CSMA/CD 造成的傳輸中斷。
在梳理這些 error/drop/discard 的時候，由于涉及到不同的 NIC 型號，ethtool/netstat 或者是直接從 proc 里面獲取到的數(shù)據(jù)所代表的意思還不完全一樣，比如上面通過 ethtool 得到的「丟包」是通過 rx_queue_NUM_drops 這個字段表示的，而通過 netstat 看到的卻是 RX-OVR 表示的，一個是 overruns 一個是 dropped，字面意思完全不同
# netstat -i | column -t
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
em2 1500 0 17159519100 0 0 164254181 14701510290 0 0 0 BMR
信息來源
不管是使用何種工具，最終的數(shù)據(jù)無外乎是從下面這兩個文件獲取到的:
/sys/class/net/em2/statistics/
/proc/net/dev
# cat /proc/net/dev | column -t
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
em2:2621515020998 17153788154 0 0 164254181 0 0 0 1480433225509 14696703883 0 0 0 0 0 0
對于上面出現(xiàn)的若干種問題，一方面是做好監(jiān)控，另外一方面是出現(xiàn)問題的時候及時的想到各種的可能，無外乎那么幾種。
暫時處理
更新了網(wǎng)卡的驅(qū)動，對網(wǎng)絡丟包進行了監(jiān)控。當時出現(xiàn)丟包的具體原因還是不清楚，你是否有遇到過呢？
上一篇：
香港機房的能源將會發(fā)生什么樣的變化
下一篇：
CDN+P2P結(jié)合：巨大技術紅利正在涌現(xiàn)
