相关疑难解决方法(0)

我今天尝试了linux的perf实用程序,但在解释其结果方面遇到了麻烦.我已经习惯了valgrind的callgrind,这当然是一种完全不同于基于采样的perf方法的方法.

我做了什么:

perf record -g -p $(pidof someapp)
perf report -g -n

现在我看到这样的事情:

+     16.92%  kdevelop  libsqlite3.so.0.8.6               [.] 0x3fe57                                                                                                              ?
+     10.61%  kdevelop  libQtGui.so.4.7.3                 [.] 0x81e344                                                                                                             ?
+      7.09%  kdevelop  libc-2.14.so                      [.] 0x85804                                                                                                              ?
+      4.96%  kdevelop  libQtGui.so.4.7.3                 [.] 0x265b69                                                                                                             ?
+      3.50%  kdevelop  libQtCore.so.4.7.3                [.] 0x18608d                                                                                                             ?
+      2.68%  kdevelop  libc-2.14.so                      [.] memcpy                                                                                                               ?
+      1.15%  kdevelop  [kernel.kallsyms]                 [k] copy_user_generic_string                                                                                             ?
+      0.90%  kdevelop  libQtGui.so.4.7.3                 [.] QTransform::translate(double, double)                                                                                ?
+      0.88%  kdevelop  libc-2.14.so                      [.] __libc_malloc                                                                                                        ?
+ …

首先,我不确定是否应将此作为Ubuntu问题发布或在此处.但我猜它更像是一个Python问题,而不是一个OS问题.

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

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

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

例如.我看到CPU时间如下(通常每0.2秒),然后突然大跳('进程'数字在CPU利用率,即1个CPU完全使用将是1,Linux top显示123%将是1.2):

Process user | Process system | OS system % | OS idle %
19.9         | 10.5           | 6           | 74 
5.6          | 2.3            | 4           | 87
6.8          | 1.7            | 11          | 75
4.6          | 5.5            | 43          | 52
0.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身份运行的(不幸的是,它不得不用于相机库) upstart
• 当相机关闭时,应用程序重新启动(respawn在upstart中使用)并且这种情况每天发生多次,因此不是由于长时间运行,我也看到这在进程开始后很快发生
• 它是一遍又一遍地运行的相同代码,它不是由于运行我的代码的不同分支
• 目前有一个 …