“Cat / proc / net / dev” dan “ip -s link” menunjukkan statistik berbeda. Yang mana yang berbohong?

8

Saya perhatikan bahwa /proc/net/devkata eth3 memiliki 1753 drops. ip -s linkmenunjukkan 0 dropped. Mengapa ada perbedaan? Dari mana datangnya data yang berbeda? Yang mana yang benar?

Saya telah menghapus data ekstra.

# uname -a
Linux example09 2.6.32-5-amd64 #1 SMP Thu Mar 22 17:26:33 UTC 2012 x86_64 GNU/Linux

# lsb_release -a
Distributor ID: Debian
Description:    Debian GNU/Linux 6.0.4 (squeeze)
Release:        6.0.4
Codename:       squeeze

# cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  eth3:1258629839430 12545003042    0 1753    0     0          0  10594858 6666255952912 10026428444    0    0    0     0       0          0

# ip -s link
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:15:17:96:0b:61 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    244248462  3955476484 0       0       0       10595400
    TX: bytes  packets  errors  dropped carrier collsns
    683632524  1436809416 0       0       0       0

— ablackhat
sumber

Sama disini. Sepertinya integer rollover 32-bit dalam program userspace ( ifconfigmelakukan hal yang sama di sini) tetapi menurut bc, 1258629839430%(2^32)adalah 204421702tidak 244.248.462, jadi saya tidak yakin bahwa ini itu (kecuali jika Anda berlari ip~ 40MB kemudian)

— DerfK

@ DerfK Ya, sekitar 40MB terdengar benar. Hanya beberapa detik, tapi ini server yang sibuk.

— ablackhat

11

Pada mesin Squeeze, percayalah /proc/net/dev. Ini cara yang lebih mudah dan dapat diandalkan untuk melihat data yang sama.

Untuk kasus tertentu dari penghitungan yang dijatuhkan, saya tidak bisa menjelaskan masalah yang sebenarnya, tetapi saya bisa mengamatinya di kotak Squeeze lainnya. Jika saya peduli, saya akan melaporkannya sebagai bug ke Debian (dan menyarankan seseorang melakukannya dan melaporkan kembali ke sini).

Keduanya mengambil nomor dari tx_droppedbidang net_device_stats. Di /proc/net/dev, garis dihasilkan oleh dev_seq_printf_statsdari net/core/dev.c.

ipberjalan, seperti biasa, melalui netlink, dan lebih tepatnya untuk statistik perangkat jaringan, rtnetlink. Struktur diteruskan ke userspace rtnl_link_stats,.

Struktur asli menggunakan unsigned longs, rtnetlinkmenggunakan __u32, konversi yang kurang lebih dilakukan di copy_rtnl_link_stats.

Sangat mudah untuk menangkap versi 32-bit yang digunakan dari awal struktur, rx_packets: sementara /proc/net/devmenunjukkan 1258629839430, ipmenunjukkan 244248462, yang sesuai kira-kira dengan 32 bit terakhir (ditambah beberapa byte lebih banyak antara perintah); hal yang sama dengan jumlah paket.

Inilah angka-angka untuk 2 bidang pertama itu:

% echo '1258629839430 % (2^32)'|bc; echo 244248462
204421702
244248462
% echo '12545003042 % (2^32)'|bc; echo 3955476484 
3955068450
3955476484

Banyak hal menjadi lebih baik di sekitar pengenalan IFLA_STATS64:

di kernel (dari commit 10708f37ae729baba9b67bd134c3720709d4ae62, tersedia di hulu di v2.6.35 dan yang lebih baru)
di iproute2 (dari commit 8864ac9dc5bd5ce049280337deb21191673a02d0, tersedia di hulu di v2.6.33-36 dan yang lebih baru).

— Pierre Carrier
sumber

Hebat, ini persis apa yang saya cari.

— ablackhat

-2

Pada sebagian besar perangkat, / proc / net / dev dibaca dari penghitung perangkat keras. Statistik lainnya diperbarui dari tumpukan jaringan dalam struktur perangkat.

Drops lebih cenderung tidak cocok karena mereka dapat dibuat oleh perangkat keras: tujuan paket mac bukan perangkat maupun multicast, dan perangkat tidak dalam promiscuous: perangkat keras langsung menjatuhkan paket, tumpukan tidak akan pernah tahu itu ada.

Akhirnya, Anda mungkin bertanya-tanya mengapa tidak menyinkronkannya atau selalu menggunakan statistik perangkat keras? Ketika tumpukan menjatuhkan paket karena alasan apa pun, itu tidak dapat memperbarui penghitung perangkat keras, dan untuk debugging, perlu diketahui bahwa Anda dapat menemukan masing-masing untuk melacak di mana paket itu dijatuhkan.

Semoga ini membantu

— pemutih
sumber