为什么我的Python应用程序因“系统”内核CPU时间而停滞不前

概述首先,我不确定是否应将此作为Ubuntu问题发布或在此处. 但我猜它更像是一个 Python问题,而不是一个OS问题. 我的Python应用程序在64核AMD服务器上运行在Ubuntu之上. 它通过网络从5 GigE摄像机中提取图像,通过ctypes调用.so然后处理它们. 我看到我的应用程序经常暂停,导致相机的帧被外部相机库丢弃. 为了调试这个,我使用了流行的psutil Python包,我在一 首先,我不确定是否应将此作为Ubuntu问题发布或在此处.
但我猜它更像是一个 Python问题,而不是一个OS问题.

我的Python应用程序在64核AMD服务器上运行在Ubuntu之上.
它通过网络从5 GigE摄像机中提取图像,通过ctypes调用.so然后处理它们.
我看到我的应用程序经常暂停,导致相机的帧被外部相机库丢弃.

为了调试这个,我使用了流行的psutil Python包,我在一个单独的线程中每0.2秒注销一次cpu统计数据.
我在该线程中睡眠0.2秒,当睡眠时间长得多时,我也看到相机帧被丢弃.
我看到长达17秒的停顿！
我的大多数处理是在OpenCV或Numpy(两者都发布GIL)或在应用程序的一个部分进行多处理.
有59个进程(这可以绕过Python GIL).

当暂停发生时,我的调试日志记录在我的许多进程’线程上显示非常高的’系统'(即内核)cpu时间.

例如.我看到cpu时间如下(通常每0.2秒)然后突然大幅跳跃
(‘进程’数字在cpu利用率,即1个cpu完全使用将是1,linux顶部显示123％将是1.2)：

Process user | Process system | OS system % | OS IDle %19.9         | 10.5           | 6           | 74 5.6          | 2.3            | 4           | 876.8          | 1.7            | 11          | 754.6          | 5.5            | 43          | 520.5          | 26.4           | 4           | 90

我不知道为什么在匹配高流程系统使用之前报告一行高OS系统使用情况.
两者相比,64核中的26.4 = 41％.那时我的应用程序经历了大约3.5秒的暂停
(由我的cpu信息记录线程使用OpenCV的cv2.getTickCount()以及Python日志记录输出中的时间戳跳转确定)
导致多个相机帧被丢弃.

发生这种情况时,我还记录了我的进程的每个线程的cpu信息.
对于上面的示例,25个线程在“系统”cpu利用率为0.9时运行,并且在0.6处运行更多,这与上面26.4的进程的总数相匹配.
那时大约有183个线程在运行.

在使用多处理池(它用于短脉冲串)之后,这种暂停通常似乎很接近,但每次使用池时都不会发生.
此外,如果我将需要在池外进行的处理量减半,则不会发生相机跳过.

问题：如何确定 *** 作系统’系统’/内核时间突然出现的原因？为什么会在Python应用程序中发生？

更重要的是：任何想法为什么会发生这种情况以及如何避免它？

笔记：

>不幸的是,它以root用户身份运行(不幸的是它必须用于相机库)
>当相机关闭时,应用程序重新启动(使用新手中的respawn)并且这种情况一天发生多次,因此不是因为长时间运行,我也看到这在进程开始后很快就会发生
>这是相同的代码被反复运行,这不是因为运行了我的代码的不同分支
>目前有一个很好的-2,我已经尝试删除没有影响的好
> Ubuntu 12.04.5 LTS
> Python 2.7
>机器有128GB的内存,我不在附近使用

解决方法 好.我有自己的问题的答案.是的,我需要3个多月的时间才能做到这一点.

它似乎是Python中的GIL颠簸,这是大规模“系统”cpu峰值和相关暂停的原因.这是一个good explanation of where the thrashing comes from.那个演讲也指出了我正确的方向.

Python 3.2 introduced a new GIL implementation避免这种颠簸.结果可以通过一个简单的线程示例显示(摘自上面的演示文稿)：

from threading import Threadimport psutildef countdown():    n = 100000000    while n > 0:        n -= 1t1 = Thread(target=countdown)t2 = Thread(target=countdown)t1.start(); t2.start()t1.join(); t2.join()print(psutil.Process().cpu_times())

在我的Macbook Pro with Python 2.7.9中,它使用14.7秒的“用户”cpu和13.2秒的“系统”cpu.

Python 3.4使用15.0的’user'(略多)但只有0.2s的’system’.

因此,GIL仍然存在,它仍然只运行与代码是单线程时一样快,但它避免了Python 2的所有GIL争用,表现为内核(‘系统’)cpu时间.我认为,这种争论正是造成原始问题的原因.

更新

发现cpu问题的另一个原因是OpenCV / TBB.完整记录在SO question中.

总结

以上是内存溢出为你收集整理的为什么我的Python应用程序因“系统”/内核CPU时间而停滞不前全部内容，希望文章能够帮你解决为什么我的Python应用程序因“系统”/内核CPU时间而停滞不前所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。