Python脚本分析CPU使用情况
在这篇文章中，我将讨论一个工具，用以分析Python中CPU使用情况。CPU分析是通过分析CPU执行代码的方式来测量代码的性能，以此找到代码中的不妥之处，然后处理它们。
接下来我们将看看如何跟踪Python脚本使用时CPU使用情况，重点关注以下几个方面：
1、cProfile
2、line_profiler
3、pprofile
测量CPU使用率
对于这篇文章，我将主要使用与内存分析中使用脚本相同的脚本，具体如下：
在讨论CPU分析时，最常用的工具之一是cProfile，主要是因为它内置在CPython2和PyPy2中。这是一个确定性的分析器，意味着在运行程序时会收集一组统计数据，例如我们代码的各个部分的执行次数或执行时间。此外，cProfile在系统上的开销比其他内置的分析器（配置文件）要低。
其输出如下：
即使使用这个文本输出，很容易看到我们的脚本多次调用了list.append方法。
如果我们使用gprof2dot，我们可以以图形的方式看到cProfile输出。要使用它，我们必须首先安装graphviz，之后是一些依赖包，最后在Ubuntu上使用如下命令：
我们得到以下output.png文件：
这样更容易看到一切。我们来仔细看看它的输出。您可以看到脚本中的函数调用如下：
1、第一行：Python文件名，行号和方法名称
2、第二行：代码块占用全部时间的百分比
3、第三行：括号中，方法本身占全部时间的百分比
4、第四行：调用函数的次数
例如，在顶部的第三个红色方块中，方法primes占用了98.28％的时间，其中65.44％的内容在其中进行，调用了40次。其余的时间花在Python中的list.append（22.33％）和range（11.51％）中。
作为一个简单的脚本，我们只需要重写我们的脚本，具体的如下所示：
您还可以以编程方式使用cProfile，例如：
这在某些情况下很有用，例如多进程性能测量
line_profiler
此分析器在行级提供关于工作负载的信息。它使用Cython在C中实现，并将其与cProfile进行比较时发现其具有较小的开销。
源代码可以在这里找到，也可以在这里找到PyPI页面。与cProfile相比，它具有一样的开销，不过却要花费12倍的时间来获取配置文件。
要使用它，您需要先通过pip添加它：pip install pip install Cython ipython == 5.4.1 line_profiler（CPython2）。这个分析器的一个主要缺点是它不支持PyPy。
就像使用memory_profiler一样，您需要在要分析的函数中添加一个装饰器。在我们的例子中，您需要在03.primes-v1.py中定义我们的primes函数之前添加@profile。然后调用它：
你将得到如下输出：
我们看到，重复调用list.append的两个循环花了最多的时间。
根据作者说明，pprofile是一个“线程测量和统计的纯python分析器”。
它受到line_profiler的启发，修复了很多缺点，但是由于它完全用Python编写，所以它也可以与PyPy成功使用。与cProfile相比，使用CPython时的分析时间要多28倍，而使用PyPy时，分析时间要多10倍，而且细节水平更加细化。
我们也支持PyPy！除此之外，它支持剖析线程，这在各种情况下可能会很方便。
要使用它，您需要先通过pip添加它：pip install pprofile（CPython2）/ pypy -m pip install pprofile（PyPy），然后调用它：
输出与我们以前看到的不同，我们得到如下结果：
我们现在可以更详细地看到一切。让我们来看看输出。您可以获得脚本的整个输出，并且在每行之前，您可以看到对其进行的调用次数，运行时间（秒），每次调用的时间和全局时间的百分比，pprofile为我们的输出添加了额外的行（如第44和50行，以（call）开头）与累积指标。
再次，我们看到，重复调用list.append的两个循环花了我们脚本中最多的时间。
vprof是一个Python分析器，为各种Python程序特性（如运行时间和内存使用）提供丰富的交互式可视化。它是一个基于Node.JS的图形化的显示在网页中的结果。
使用它，您可以看到与Python脚本相关的以下一个或全部：
1、CPU使用图
2、代码分析
4、代码热图
要使用它，您需要先通过pip添加它：pip install vprof（CPython2）/ pypy -m pip install vprof（PyPy），然后调用它：
在每种情况下，您将看到代码散点图的以下内容
以及代码分析的以下内容。
结果以图形方式看到，我们可以悬停鼠标或单击每行以获取更多信息。再次，我们看到，重复调用list.append的两个循环花了我们脚本中最多的时间。
英文原文：https://pythonfiles.wordpress.com//hunting-performance-in-python-code-part-3/
文章来源：Python程序员
《Spark大数据平台应用实战》郭俊（Jason）老师新课开课了，本周可继续报名，本课程将会结合精典案例讲解Spark Job的整个生命周期。学习它并掌握它，是大数据风口下IT人的必备技能。
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点扫一扫体验手机阅读
Parallel Python实现程序的并行多cpu多核利用【pp模块】
<span type="1" blog_id="1357112" userid='
157篇文章，311W+人气，5粉丝
大数据时代的微服务之路
￥51.00429人订阅
<span type="1" blog_id="1357112" userid='python设置CPU亲缘性 - 小交响曲 - 博客园
随笔 - 102, 文章 - 0, 评论 - 63, 引用 - 0
由于未知的原因，一个python程序总是占用一个CPU核心，导致一个使用率满的，另一个很低，不均衡。固然可以在任务管理中设置进程相关性为所有处理器，但是每次都设置太过麻烦，查了下可以使用windows的API设置，但是要在python中设置，需要做点工作。
首先，python要有pywin32的支持，地址：
其次，下载affinity模块安装，这里提供了访问SetProcessAffinityMask的方法，地址:
然后就可以使用了。举例如下，在程序的开始地方加上代码
1 import affinity # need pywin32
2 import os
4 affinity.set_process_affinity_mask(os.getpid(), 3L) # set all cpu to run
运行程序，在任务管理器中可以看到程序在使用两个CPU。
说明：程与指定cpu绑定：SetProcessAffinityMask(GetCurrentProcess(),&dwMask);
dwMask为CPU序号的或运算值：1（0001）代表只运行在CPU1，2（0010）代表只运行在CPU2，3（0011）代表可以运行在CPU1和CPU2，以此类推。
还没找到python获取CPU核心数量的函数，所以手工查看一下了，貌似win32con可以做到，linux下也没研究。。。
CPU亲缘性介绍
按照默认设置，当系统将线程分配给处理器时，Windows使用软亲缘性来进行操作。这意味着如果所有其他因素相同的话，它将设法在它上次运行的那个处理器上运行线程。让线程留在单个处理器上，有助于重复使用仍然在处理器的内存高速缓存中的数据。
有一种新的计算机结构，称为NUMA（非统一内存访问），在该结构中，计算机包含若干块插件板，每个插 件板上有4个CPU和它自己的内存区。当CPU访问的内存是它自己的插件板上的内存时，NUMA系统运行的性能最好。如果CPU需要访问位于另一个插件板上的内 存时，就会产生巨大的性能降低。在这样的环境中，就需要限制来自一个进程中的线程在共享同一个插件版的CPU上运行。为了适应这种计算机结构的需要，Windows允许你设置进程和线程的亲缘性。换句话说，你可以控制哪个CPU能够运行某些线程。这称为硬亲缘性。请注意，子进程可以继承进程的亲缘性。
（1）无论计算机中实际拥有多少个CPU，Windows98及以前系统只使用一个CPU，上述API不被支持。
（2）在大多数环境中，改变线程的亲缘性就会影响调度程序有效地在 各个CPU之间移植线程的能力，而这种能力可以最有效地使用CPU时间。Python怎么利用多核cpu
原文链接http://www.cnblogs.com/stubborn412/p/4033651.html
GIL 与 Python 线程的纠葛
GIL 是什么东西？它对我们的 python 程序会产生什么样的影响？我们先来看一个问题。运行下面这段 python 程序，CPU 占用率是多少？
# 请勿在工作中模仿，危险:)
def dead_loop():
while True:
dead_loop()
答案是什么呢，占用 100％ CPU？那是单核！还得是没有超线程的古董 CPU。在我的双核 CPU 上，这个死循环只会吃掉我一个核的工作负荷，也就是只占用 50％ CPU。那如何能让它在双核机器上占用 100％ 的 CPU 呢？答案很容易想到，用两个线程就行了，线程不正是并发分享 CPU 运算资源的吗。可惜答案虽然对了，但做起来可没那么简单。下面的程序在主线程之外又起了一个死循环的线程
import threading
def dead_loop():
while True:
# 新起一个死循环线程
t = threading.Thread(target=dead_loop)
# 主线程也进入死循环
dead_loop()
按道理它应该能做到占用两个核的 CPU 资源，可是实际运行情况却是没有什么改变，还是只占了 50％ CPU 不到。这又是为什么呢？难道 python 线程不是操作系统的原生线程？打开 system monitor 一探究竟，这个占了 50% 的 python 进程确实是有两个线程在跑。那这两个死循环的线程为何不能占满双核 CPU 资源呢？其实幕后的黑手就是 GIL。
GIL 的迷思：痛并快乐着
GIL 的全称为 Global Interpreter Lock ，意即全局解释器锁。在 Python 语言的主流实现 CPython 中，GIL 是一个货真价实的全局线程锁，在解释器解释执行任何 Python 代码时，都需要先获得这把锁才行，在遇到 I/O 操作时会释放这把锁。如果是纯计算的程序，没有 I/O 操作，解释器会每隔 100 次操作就释放这把锁，让别的线程有机会执行（这个次数可以通过sys.setcheckinterval 来调整）。所以虽然
CPython 的线程库直接封装操作系统的原生线程，但 CPython 进程做为一个整体，同一时间只会有一个获得了 GIL 的线程在跑，其它的线程都处于等待状态等着 GIL 的释放。这也就解释了我们上面的实验结果：虽然有两个死循环的线程，而且有两个物理 CPU 内核，但因为 GIL 的限制，两个线程只是做着分时切换，总的 CPU 占用率还略低于 50％。
看起来 python 很不给力啊。GIL 直接导致 CPython 不能利用物理多核的性能加速运算。那为什么会有这样的设计呢？我猜想应该还是历史遗留问题。多核 CPU 在 1990 年代还属于类科幻，Guido van Rossum 在创造 python 的时候，也想不到他的语言有一天会被用到很可能 1000＋ 个核的 CPU 上面，一个全局锁搞定多线程安全在那个时代应该是最简单经济的设计了。简单而又能满足需求，那就是合适的设计（对设计来说，应该只有合适与否，而没有好与不好）。怪只怪硬件的发展实在太快了，摩尔定律给软件业的红利这么快就要到头了。短短
20 年不到，代码工人就不能指望仅仅靠升级 CPU 就能让老软件跑的更快了。在多核时代，编程的免费午餐没有了。如果程序不能用并发挤干每个核的运算性能，那就意谓着会被淘汰。对软件如此，对语言也是一样。那 Python 的对策呢？
Python 的应对很简单，以不变应万变。在最新的 python 3 中依然有 GIL。之所以不去掉，原因嘛，不外以下几点：
欲练神功，挥刀自宫：
CPython 的 GIL 本意是用来保护所有全局的解释器和环境状态变量的。如果去掉 GIL，就需要多个更细粒度的锁对解释器的众多全局状态进行保护。或者采用 Lock-Free 算法。无论哪一种，要做到多线程安全都会比单使用 GIL 一个锁要难的多。而且改动的对象还是有 20 年历史的 CPython 代码树，更不论有这么多第三方的扩展也在依赖 GIL。对 Python 社区来说，这不异于挥刀自宫，重新来过。
就算自宫，也未必成功：
有位牛人曾经做了一个验证用的 CPython，将 GIL 去掉，加入了更多的细粒度锁。但是经过实际的测试，对单线程程序来说，这个版本有很大的性能下降，只有在利用的物理 CPU 超过一定数目后，才会比 GIL 版本的性能好。这也难怪。单线程本来就不需要什么锁。单就锁管理本身来说，锁 GIL 这个粗粒度的锁肯定比管理众多细粒度的锁要快的多。而现在绝大部分的 python 程序都是单线程的。再者，从需求来说，使用 python 绝不是因为看中它的运算性能。就算能利用多核，它的性能也不可能和 C/C++ 比肩。费了大力气把
GIL 拿掉，反而让大部分的程序都变慢了，这不是南辕北辙吗。
难道 Python 这么优秀的语言真的仅仅因为改动困难和意义不大就放弃多核时代了吗？其实，不做改动最最重要的原因还在于：不用自宫，也一样能成功！
那除了切掉 GIL 外，果然还有方法让 Python 在多核时代活的滋润？让我们回到本文最初的那个问题：如何能让这个死循环的 Python 脚本在双核机器上占用 100％ 的 CPU？其实最简单的答案应该是：运行两个 python 死循环的程序！也就是说，用两个分别占满一个 CPU 内核的 python 进程来做到。确实，多进程也是利用多个 CPU 的好方法。只是进程间内存地址空间独立，互相协同通信要比多线程麻烦很多。有感于此，Python 在 2.6 里新引入了 multiprocessing这个多进程标准库，让多进程的
python 程序编写简化到类似多线程的程度，大大减轻了 GIL 带来的不能利用多核的尴尬。
这还只是一个方法，如果不想用多进程这样重量级的解决方案，还有个更彻底的方案，放弃 Python，改用 C/C++。当然，你也不用做的这么绝，只需要把关键部分用 C/C++ 写成 Python 扩展，其它部分还是用 Python 来写，让 Python 的归 Python，C 的归 C。一般计算密集性的程序都会用 C 代码编写并通过扩展的方式集成到 Python 脚本里（如 NumPy 模块）。在扩展里就完全可以用 C 创建原生线程，而且不用锁 GIL，充分利用 CPU 的计算资源了。不过，写 Python
扩展总是让人觉得很复杂。好在 Python 还有另一种与 C 模块进行互通的机制 : ctypes
利用 ctypes 绕过 GIL
ctypes 与 Python 扩展不同，它可以让 Python 直接调用任意的 C 动态库的导出函数。你所要做的只是用 ctypes 写些 python 代码即可。最酷的是，ctypes 会在调用 C 函数前释放 GIL。所以，我们可以通过 ctypes 和 C 动态库来让 python 充分利用物理内核的计算能力。让我们来实际验证一下，这次我们用 C 写一个死循环函数
void DeadLoop()
while (true);
用上面的 C 代码编译生成动态库 libdead_loop.so （Windows 上是 dead_loop.dll）
，接着就要利用 ctypes 来在 python 里 load 这个动态库，分别在主线程和新建线程里调用其中的 DeadLoop
from ctypes import *
from threading import Thread
lib = cdll.LoadLibrary("libdead_loop.so")
t = Thread(target=lib.DeadLoop)
lib.DeadLoop()
这回再看看 system monitor，Python 解释器进程有两个线程在跑，而且双核 CPU 全被占满了，ctypes 确实很给力！需要提醒的是，GIL 是被 ctypes 在调用 C 函数前释放的。但是 Python 解释器还是会在执行任意一段 Python 代码时锁 GIL 的。如果你使用 Python 的代码做为 C 函数的 callback，那么只要 Python 的 callback 方法被执行时，GIL 还是会跳出来的。比如下面的例子：
typedef void Callback();
void Call(Callback* callback)
callback();
from ctypes import *
from threading import Thread
def dead_loop():
while True:
lib = cdll.LoadLibrary("libcall.so")
Callback = CFUNCTYPE(None)
callback = Callback(dead_loop)
t = Thread(target=lib.Call, args=(callback,))
lib.Call(callback)
注意这里与上个例子的不同之处，这次的死循环是发生在 Python 代码里 (DeadLoop 函数) 而 C 代码只是负责去调用这个 callback 而已。运行这个例子，你会发现 CPU 占用率还是只有 50％ 不到。GIL 又起作用了。
其实，从上面的例子，我们还能看出 ctypes 的一个应用，那就是用 Python 写自动化测试用例，通过 ctypes 直接调用 C 模块的接口来对这个模块进行黑盒测试，哪怕是有关该模块 C 接口的多线程安全方面的测试，ctypes 也一样能做到。
虽然 CPython 的线程库封装了操作系统的原生线程，但却因为 GIL 的存在导致多线程不能利用多个 CPU 内核的计算能力。好在现在 Python 有了易经筋（multiprocessing）, 吸星大法（C 语言扩展机制）和独孤九剑（ctypes），足以应付多核时代的挑战，GIL 切还是不切已经不重要了，不是吗。
没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！(python30)
(python_gogo)
(sjkjsdkf)
第三方登录：