V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Distributions
Ubuntu
Fedora
CentOS
中文资源站
网易开源镜像站
15015613
V2EX  ›  Linux

ping 的 cpu 使用率奇高

  •  
  •   15015613 ·
    yingziwu · 2017-03-20 10:31:11 +08:00 · 2476 次点击
    这是一个创建于 2790 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近发现笔记本风扇狂转, top 看了一下,发现 ping 的 cpu 使用率奇高。
    ping 关了之后一切恢复正常。
    有人知道这是什么原因吗?

    日志如下:

      PID USER      PR  NI    VIRT    RES  %CPU %MEM     TIME+ S COMMAND
    10080 arch      20   0   36.5m   3.9m  97.4  0.1   1:18.44 R ping
     8111 arch      20   0 3810.0m 1.427g   3.3 18.7 505:03.19 S telegram-deskto
    10441 root      20   0    0.0m   0.0m   0.7  0.0   0:06.31 S kworker/6:2
    11739 arch      20   0   48.7m   4.0m   0.7  0.1   0:00.09 R top
    15026 arch      20   0 1618.3m  82.8m   0.7  1.1  26:00.00 S konsole
        1 root      20   0  196.4m   5.5m   0.0  0.1   0:04.48 S systemd
        2 root      20   0    0.0m   0.0m   0.0  0.0   0:00.18 S kthreadd
        4 root       0 -20    0.0m   0.0m   0.0  0.0   0:00.00 S kworker/0:0H
        6 root      20   0    0.0m   0.0m   0.0  0.0   0:48.72 S ksoftirqd/0
        7 root      20   0    0.0m   0.0m   0.0  0.0   4:48.71 S rcu_preempt
    
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3289 ttl=55 time=84.5 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3290 ttl=55 time=179 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3291 ttl=55 time=4.30 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3292 ttl=55 time=30.1 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3293 ttl=55 time=8.40 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3294 ttl=55 time=61.9 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3295 ttl=55 time=98.8 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3296 ttl=55 time=9.58 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3297 ttl=55 time=7.74 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3298 ttl=55 time=7.22 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3299 ttl=55 time=6.84 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3301 ttl=55 time=5.90 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3302 ttl=55 time=26.1 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3303 ttl=55 time=8.37 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3304 ttl=55 time=6.57 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3305 ttl=55 time=8.36 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3306 ttl=55 time=9.38 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3307 ttl=55 time=11.0 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3308 ttl=55 time=3.66 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3309 ttl=55 time=52.8 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3310 ttl=55 time=4.51 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3311 ttl=55 time=4.62 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3312 ttl=55 time=3.69 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3313 ttl=55 time=4.28 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3314 ttl=55 time=18.3 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3315 ttl=55 time=6.83 ms
    64 bytes from 119.75.218.70 (119.75.218.70): icmp_seq=3316 ttl=55 time=13.3 ms
    
    11 条回复    2017-03-22 19:28:40 +08:00
    Systemd
        1
    Systemd  
       2017-03-20 10:38:17 +08:00 via Android
    会不会是二进制文件被人调包了?
    simpx
        2
    simpx  
       2017-03-20 10:39:44 +08:00
    strace -p pid ,看下有哪些系统调动
    15015613
        3
    15015613  
    OP
       2017-03-20 10:55:35 +08:00
    @Systemd 应该不会吧,我重装一下试试。
    15015613
        4
    15015613  
    OP
       2017-03-21 07:44:10 +08:00
    @simpx
    等了半天问题终于再次出现, strace 结果如下:

    正常情况下
    https://gist.github.com/yingziwu/b0abe335f0594d488c0ee636e7cf86ac

    cpu 占用高时
    https://gist.github.com/yingziwu/7682fd07c19f35e09c0ffd71f9de08dc
    贴上去的仅为屏幕输出的一小部分

    google 了一下,好像也没有说明什么解决办法
    simpx
        5
    simpx  
       2017-03-21 10:11:00 +08:00   ❤️ 1
    @15015613 #4
    你好像贴了两次 strace_ping_normal
    另一次 cpu 高时的 strace 结果是什么?
    simpx
        7
    simpx  
       2017-03-21 10:36:47 +08:00   ❤️ 1
    @15015613 #6

    从我本地测试来看,"poll([{fd=3, events=POLLIN|POLLERR}], 1, 995)"是用来做超时的,应该是必返回 0. 但在你出问题时候的 poll 调用返回了 1 ,并且是 POLLERR 错误

    1. 出错的时候,你 ping 是不是指定了间隔时间?因为你的 poll 第三个参数是 747

    2. 能不能在出错的时候"lsof -p pid"看下 fd 3 是不是已经不是原来的 socket 了
    simpx
        8
    simpx  
       2017-03-21 11:01:27 +08:00   ❤️ 1
    @15015613 #6
    简单看了 ping 的代码,看起来你的 recvmsg 不支持 SO_RCVTIMEO ,才会用 poll 来做超时。
    你可以自己编译一个 ping , gdb 调试下

    代码: http://www.skbuff.net/iputils/
    15015613
        9
    15015613  
    OP
       2017-03-22 17:09:37 +08:00
    @simpx
    发现只有在 ping 的时间足够长,包号特别大的情况下才出现 cpu 使用特别高的情况,时间短的话一切都是正常的。
    一般要包号 50000+好像才会出现。

    lsof -p 的日志, cpu 使用高时
    https://gist.github.com/yingziwu/19845a94e7210eedd8aa6770b682f8f2

    正常时
    https://gist.github.com/yingziwu/6e5c4023b89b89daae30414f4f01b8f0
    15015613
        10
    15015613  
    OP
       2017-03-22 17:11:56 +08:00
    @15015613
    咦,我明明贴了两个不同的 gist 地址,怎么变成一样了

    正常的时候的 lsof -p 的记录
    https://gist.github.com/yingziwu/6e5c4023b89b89daae30414f4f01b8f0
    simpx
        11
    simpx  
       2017-03-22 19:28:40 +08:00
    @15015613 #10

    从你的现象来看,似乎是一旦出错就无法恢复。可能包号大,发包多,出错概率高,一旦出现就不会恢复了。

    lsof 上看没什么区别

    看来只能自己编译一份试试了,看下 poll 出来的 POLLERR 是什么

    实际上这里 poll 改成 sleep 应该也行吧,不知道为什么要用 poll
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5418 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 06:51 · PVG 14:51 · LAX 22:51 · JFK 01:51
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.