“cat / proc / net / dev”와“ip -s link”는 다른 통계를 보여줍니다. 어느 거짓말입니까?

8

나는 /proc/net/deveth3에 1753 이 있다고 말합니다 drop. ip -s link0을 표시 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

— 검은 모자
소스

여기도 마찬가지입니다. 그것은 (사용자 공간 프로그램에서 32 비트 정수 롤오버처럼 보이는 ifconfig여기에 같은 일을)하지만,에 따라 bc, 1258629839430%(2^32)이다 204421702난, 그래서 244,248,462하지하지 확인하십시오 (당신이 실행하지 않는 한의 그것 ip~ 40메가바이트 이상)

— DerfK

@DerfK 예, 약 40MB의 소리가납니다. 몇 초 밖에 걸리지 않았지만 바쁜 서버입니다.

— ablackhat

11

스퀴즈 머신에서 신뢰하십시오 /proc/net/dev. 동일한 데이터를보다 간단하고 안정적으로 보는 방법입니다.

삭제 된 카운트의 특정 경우에 대해서는 정확한 문제를 설명 할 수 없지만 다른 스퀴즈 상자에서이를 확인할 수 있습니다. 내가 돌보 았다면, 데비안에 버그로보고 할 것이다.

둘 다의 tx_dropped필드 에서 숫자를 가져옵니다 net_device_stats. 에서 /proc/net/dev의 라인에 의해 생성 된 dev_seq_printf_stats발 net/core/dev.c.

ip평소와 같이 netlink를 통해,보다 정확하게는 네트워크 장치 통계 인 rtnetlink를 통해 이동합니다. 구조가 사용자 공간으로 전달되었습니다 rtnl_link_stats.

기본 구조는 unsigned longs, rtnetlinkuses을 사용 __u32하며 다소 암시적인 변환이 수행됩니다 copy_rtnl_link_stats.

또한, 32 비트 버전은 구조의 시작 부분에서 사용되는 잡으려고 아주 쉽게 rx_packets입니다 : 동안 /proc/net/dev쇼 1258629839430, ip쇼 244,248,462, 마지막 32 비트 (플러스 몇 명령어 사이 바이트)에 대략 대응; 패킷 수와 같은 것.

이 두 가지 첫 번째 필드의 숫자는 다음과 같습니다.

% 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 는 하드웨어 카운터에서 읽습니다. 다른 통계는 장치 구조의 네트워크 스택에서 업데이트됩니다.

드롭은 하드웨어에 의해 이루어질 수 있기 때문에 일치하지 않을 가능성이 더 높습니다. 패킷 맥 대상은 장치 나 멀티 캐스트가 아니며 장치가 무차별 적이 지 않습니다. 하드웨어가 패킷을 직접 삭제하면 스택은 해당 패킷이 존재한다는 것을 절대 알 수 없습니다.

마지막으로 왜 동기화하지 않거나 항상 하드웨어 통계를 사용하는지 궁금 할 것입니다. 어떤 이유로 스택이 패킷을 삭제하면 하드웨어 카운터를 업데이트 할 수 없으며 디버깅을 위해 패킷이 삭제 된 위치를 추적 할 수 있다는 것을 아는 것이 유용합니다.

도움이 되었기를 바랍니다

— 맹인
소스