«Cat / proc / net / dev» и «ip -s link» показывают разные статистические данные. Кто лжет?

8

Я заметил, /proc/net/devчто у eth3 1753 dropс. ip -s linkпоказывает 0 dropped. Почему есть разница? Откуда поступают разные данные? Какой из них правильный?

Я удалил лишние данные.

# 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
источник

Тоже самое. Это похоже на 32-разрядное целочисленное переключение в программах пользовательского пространства ( ifconfigделает то же самое здесь), но, согласно bc, 1258629839430%(2^32)это 204421702не 244248462, поэтому я не уверен, что это так (если вы не запустили ip~ 40

— МБ

@DerfK Да, около 40 МБ звучит правильно. Прошло всего несколько секунд, но это занятый сервер.

— ablackhat

11

На выжимной машине доверяй /proc/net/dev. Это более простой и надежный способ просмотра одних и тех же данных.

Для конкретного случая отброшенного счета я не могу объяснить точную проблему, но я могу наблюдать это на других полях Сжатия. Если бы я заботился, я бы сообщил об этом как об ошибке в Debian (и предложил бы, чтобы кто-то сделал и сообщил здесь).

Оба берут номер с tx_droppedполя net_device_stats. В /proc/net/dev, строка генерируется dev_seq_printf_statsиз net/core/dev.c.

ipидет, как обычно, через netlink, а точнее для статистики сетевых устройств, rtnetlink. Структура передана в пользовательское пространство rtnl_link_stats.

Нативная структура использует unsigned longs, rtnetlinkиспользует __u32более или менее неявное преобразование copy_rtnl_link_stats.

Довольно легко понять, что 32-битная версия используется с начала структуры, rx_packets: пока /proc/net/devпоказывает 1258629839430, ipпоказывает 244248462, что примерно соответствует последним 32 битам (плюс еще несколько байтов между командами); То же самое с количеством пакетов.

Вот число хруст для этих 2 первых полей:

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

Вещи улучшились вокруг введения IFLA_STATS64:

в ядре (из коммита 10708f37ae729baba9b67bd134c3720709d4ae62, доступно в апстриме v2.6.35 и новее)
в iproute2 (из коммита 8864ac9dc5bd5ce049280337deb21191673a02d0, доступно в восходящем потоке в v2.6.33-36 и более поздних версиях).

— Пьер Кэрриер
источник

Отлично, это именно то, что я искал.

— ablackhat

-2

На большинстве устройств / proc / net / dev читается со счетчиков оборудования. Другие характеристики обновляются из сетевого стека в структурах устройства.

Отбрасывания с большей вероятностью могут не совпадать, поскольку они могут быть сделаны аппаратным обеспечением: назначение Mac пакета не является ни устройством, ни многоадресной рассылкой, и устройство не находится в случайном порядке: аппаратное обеспечение непосредственно отбрасывает пакет, стек никогда не узнает о его существовании.

Наконец, вам может быть интересно, почему бы не синхронизировать их или всегда использовать аппаратную статистику? Когда стек сбрасывает пакет по какой-либо причине, он не может обновить аппаратный счетчик, и для отладки полезно знать, что вы можете найти каждый, чтобы отследить, куда был отброшен пакет.

Надеюсь это поможет

— bleader
источник