Python大量调用Popen导致服务器sy占用很大的处理思路

背景介绍

  • 我的代码是交换机监控系统,大约有27个线程,每个线程都会不断地使用subprocess.Popen去调用snmpwalk命令来收集交换机状态数据。
  • 监控部署在一台树莓派2B上,CPU是4核1GHz。
  • 现在收集数据速度不是很理想,因为交换机数量有700多台,大约6分钟才能刷新一次数据。当我想提高snmpwalk的并发量来提高收集速度的时候,我发现CPU是限制我的监控系统的瓶颈。
  • 系统状态数据如下,我们可以看到,sy一项特别的大。
监控系统状态ussyidloadavgsnmpwalk平均进程数python进程占用CPU
未启动1.20.6981.48不存在不存在
启动后1629493.422650%~70%
  • 今天面试腾讯运维开发的时候,和面试官讨论到这个问题,给了我一些启发,所以面完就马上试验一下我的想法。

分析与排查

  • 我觉得可能的原因有:
    • 线程调度开销
    • Popen开销
    • snmpwalk开销
    • 进程调度开销
  • 下面来逐个排查

线程调度开销

  • 使用如下代码进行测试
import threading
import time
import subprocess

def snmp(a):
    time.sleep(5)
    print(a)

for a in range(1,249):
    threading.Thread(target=snmp,args=(a,), name=a).start()
    print("Thread Start:",a)
  • 测试结果:只有在创建线程的时候,us有明显升高,sy仅升高约2%创建完成后随即下降。
  • 结论:sy升高与线程调度无关。

Popen开销

  • 使用如下代码进行测试
import threading
import time
import subprocess

def snmp(a):
    time.sleep(5)
    subprocess.Popen(["echo",str(a),], bufsize=0, shell=False, stdin=subprocess.PIPE, stdout=subprocess.PIPE,stderr=subprocess.PIPE)

for a in range(1,101):
    threading.Thread(target=snmp,args=(a,), name=a).start()
    print("Thread Start:",a)
  • 测试结果:到subprocess.Popen执行时,sy瞬间飙高,us约16%,sy约65%。
  • 结论:sy升高与同时间大量使用Popen有关。

snmpwalk开销

  • 通过上面的代码,我们发现应该是Popen的开销,所以snmpwalk就不需要测试了。

进程调度开销

  • 系统的平均负载小于CPU核心数,说明运行队列是有空余的,所以应该不是进程调度开销导致的。(对这方面不是很懂,我猜的,不知道对不对)

解决思路

  • 先google一下Linux系统sys高的原因。 google链接
  • 我找到这个: 高sys的CPU排查
  • 我尝试使用strace来统计系统调用。对于上面的Popen开销测试代码,我先运行,然后在sleep(5)的时候迅速地把python的pid记下,运行strace命令,等python代码运行结束后,就会给出结果。这里的结果如下:
strace: Process 28984 attached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    2.033028       16942       120        51 futex
  0.00    0.000000           0         6           close
  0.00    0.000000           0         1           brk
  0.00    0.000000           0         1           rt_sigaction
  0.00    0.000000           0         1           madvise
------ ----------- ----------- --------- --------- ----------------
100.00    2.033028                   129        51 total
  • 我们可以看到,futex这项占了超多。
  • 先不着急,我们再用同样的方法调试一下我的监控程序。运行了6分钟后终止,得到的结果如下:
strace: Process 29205 attached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.92  374.189481       33959     11019      3144 futex
  0.02    0.082074           9      8745           pread64
  0.02    0.072160           7     11008           fcntl64
  0.02    0.058213           6      9592           fstat64
  0.01    0.030947           4      7494      5498 stat64
  0.00    0.012808         512        25           wait4
  0.00    0.009980         322        31           read
  0.00    0.007934          12       665           lstat64
  0.00    0.005470         260        21           _llseek
  0.00    0.001788          81        22           write
  0.00    0.001008           1      1338       666 open
  0.00    0.000507           9        57           mmap2
  0.00    0.000379           1       665           getcwd
  0.00    0.000300           0       666           getpid
  0.00    0.000282           0       729           close
  0.00    0.000000           0         7         7 ioctl
  0.00    0.000000           0         2           munmap
  0.00    0.000000           0         1         1 sigreturn
  0.00    0.000000           0        56           clone
  0.00    0.000000           0        56           mprotect
  0.00    0.000000           0         1           rt_sigaction
------ ----------- ----------- --------- --------- ----------------
100.00  374.473331                 52200      9316 total
  • 很明显,是futex这项造成的,占了99.92%!
  • 那futex是什么?我们用man futex看一下:
       The  futex()  system call provides a method for waiting until a certain
       condition becomes true.  It is typically used as a  blocking  construct
       in  the  context of shared-memory synchronization.  When using futexes,
       the majority of the synchronization operations are  performed  in  user
       space.   A user-space program employs the futex() system call only when
       it is likely that the program has to block for a longer time until  the
       condition  becomes  true.  Other futex() operations can be used to wake
       any processes or threads waiting for a particular condition.
  • 感觉是锁之类的东西,没啥头绪。
  • 那就换个方向。既然是Popen导致的,那我不用Popen或者少用不就行了。今天面试腾讯运维开发的时候,面试官给了一个建议,把net-snmp的代码改了,让它可以一直运行不退出。我觉得ok,然后我下了net-snmp的源码,打算看看从哪下手,突然看到一个叫python的文件夹……!然后我点进去看了下,觉得不错,然后上网找了找资料,发现已经有人做好一个包了,用pip3 install netsnmp-py3进行安装。项目地址:https://github.com/xstaticxgpx/netsnmp-py3
  • 安装完之后我就把调用snmp的代码修改了,现在一个Popen都没有,直接用函数来调用snmp。
  • 我们来对比一下优化前后的结果。感觉不错,sy有明显的下降,同时扫描速度快了很多。
数据ussyidloadavgpython占用CPU扫描一栋楼所需时间
优化前2040323.5150%~90%约6分5秒
优化后149741.0970%约3分23秒

总结

  • 我们的目的是降低sy的占用,现在目标已经达成了。
  • 解决方法是尽量不调用Popen,在我这里,就是用netsnmp-py3提供的函数来代替Popen执行snmp命令。
  • 后面的目标是,既然CPU使用率这么低,就想办法再加快数据的获取速度。