"Cat / proc / net / dev" und "ip -s link" zeigen unterschiedliche Statistiken. Welches lügt?

8

Ich /proc/net/devstelle fest, dass eth3 1753 drops hat. ip -s linkzeigt 0 dropped. Warum gibt es einen Unterschied? Woher kommen die verschiedenen Daten? Welches ist richtig?

Ich habe die zusätzlichen Daten entfernt.

# 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
quelle

Hier gilt das gleiche. Es sieht aus wie ein 32-Bit - Integer - Überschlag in den User - Space - Programme ( ifconfigtut die gleiche Sache hier) , aber nach bc, 1258629839430%(2^32)ist 204421702nicht 244.248.462, so dass ich nicht sicher bin , dass es sich (es sei denn , Sie liefst ip~ 40MB später)

— DerfK

@DerfK Ja, ungefähr 40 MB klingen richtig. War nur ein paar Sekunden, aber es ist ein ausgelasteter Server.

— Ablackhat

11

Vertrauen Sie auf einer Squeeze-Maschine /proc/net/dev. Es ist eine einfachere und zuverlässigere Art, dieselben Daten zu betrachten.

Für den speziellen Fall der abgelegten Zählung kann ich das genaue Problem nicht erklären, aber ich kann es auf anderen Squeeze-Boxen beobachten. Wenn es mich kümmerte, würde ich es Debian als Fehler melden (und vorschlagen, dass jemand dies tut und hier zurückmeldet).

Beide nehmen die Nummer aus dem tx_droppedFeld von net_device_stats. In /proc/net/devwird die Leitung durch erzeugt dev_seq_printf_statsaus net/core/dev.c.

ipgeht wie üblich über netlink und genauer gesagt über die Netzwerkgerätestatistik rtnetlink. Die an den Benutzerbereich übergebene Struktur rtnl_link_stats.

Die native Struktur verwendet unsigned longs, rtnetlinkverwendet __u32, eine mehr oder weniger implizite Konvertierung erfolgt in copy_rtnl_link_stats.

Es ist ziemlich einfach zu erkennen, dass die 32-Bit-Version vom Anfang der Struktur an verwendet wird: rx_packets: /proc/net/devzeigt 1258629839430, ipzeigt 244248462, was ungefähr den letzten 32 Bit entspricht (plus ein paar weitere Bytes zwischen Befehlen); Gleiches gilt für die Paketanzahl.

Hier ist die Zahl, die für diese beiden ersten Felder berechnet wird:

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

Mit der Einführung von IFLA_STATS64:

im Kernel (ab Commit 10708f37ae729baba9b67bd134c3720709d4ae62, verfügbar in Version 2.6.35 und höher)
in iproute2 (von Commit 8864ac9dc5bd5ce049280337deb21191673a02d0, verfügbar in Version 2.6.33-36 und höher).

— Pierre Carrier
quelle

Großartig, genau das habe ich gesucht.

— Ablackhat

-2

Auf den meisten Geräten wird / proc / net / dev von Hardware-Zählern gelesen. Andere Statistiken werden vom Netzwerkstapel in den Gerätestrukturen aktualisiert.

Drops stimmen mit größerer Wahrscheinlichkeit nicht überein, da sie von der Hardware vorgenommen werden können: Das Paket-Mac-Ziel ist weder ein Gerät noch ein Multicast, und das Gerät ist nicht promiskuitiv: Hardware verwirft das Paket direkt, der Stack wird nie wissen, dass es existiert.

Schließlich fragen Sie sich vielleicht, warum Sie sie nicht synchronisieren oder immer Hardwarestatistiken verwenden sollten. Wenn der Stapel ein Paket aus irgendeinem Grund verwirft, kann er den Hardwarezähler nicht aktualisieren. Zum Debuggen ist es hilfreich zu wissen, dass Sie jedes Paket finden können, um festzustellen, wo das Paket verworfen wurde.

Hoffe das hilft

— Bleader
quelle