（Unix/Python）活动监视器%CPU

我有一个项目，我正在为我的另一个项目开发一个分布式计算模型。我的一个脚本是多进程的，监视目录中的更改，解码pickle，根据pickle所指向的节点为它们创建身份验证密钥，然后重新对它们进行加密。（编辑：这些过程都在循环中运行。）

我的问题是，在OSX中查看活动监视器时，我的%CPU列显示运行脚本的主进程的100%。这三个100%显示的是manager脚本和两个节点（我在一台机器上模拟模型，目的是将来将模型移动到一个实时集群网络）。这是坏的吗？我的系统使用率显示为27.50%、用户12.50%和65%空闲

首先，我自己也尝试过研究，我唯一的想法是，这些数字显示，进程在其活动的整个时间内都在使用CPU，并且从不空闲

我能得到一些澄清吗

根据评论更新： 我的流程以无休止的循环运行，监视其各自目录中文件的更改，以便从manager流程/脚本（项目最终实现中集群中的一台单独计算机）接收新的“作业”。也许有一种更好的方法可以在这种形式下等待I/O，而不需要太多处理器时间？

解决方案（如果是次优的）： 在每个循环结束时执行

时间。睡眠（n）

周期

0.1

秒。将CPU时间降低到不超过0.4%

尽管如此，我仍在寻找一种减少CPU时间的更为优化的方法，在不使用Python标准库中未包含的模块的情况下，我希望避免使用

time.sleep（n）

周期，因为我希望系统能够随时响应，并且如果输入文件的负载非常高，我不希望它在处理文件时浪费时间睡觉

我的进程在忙等待的情况下运行，因此导致它们使用了过多的CPU时间：

while True:
    files = os.path.listdir('./sub_directory/')

    if files != []:
        do_something()

---

这是我执行的每个脚本/流程的基础。

我同意你的结论。那里有没有无止境的循环？如果您监视IO并且超时为0，它将立即超时，您将100%忙于计算python内容（而不是等待IO）。那么这不是一件坏事吗？是的，我的循环是无止境的，管理器和节点不断地检查特定目录中的相关文件。在我的主要项目的最终实现中，管理者将不断监控各种形式的输入（IMAP、STDIN、XMPP、Web、语音等），并将这些输入作为“作业”分发给集群中要处理的其他节点，以便我可以使用真正的并行计算（即使用节点的“整个”CPU处理一个作业）。我将更新这个问题。在循环中放置一个小的睡眠将极大地提高CPU，而不会增加延迟，只要这些东西是I/O绑定的。监控目录绝对不应该使用100%的CPU时间。你是怎么做到的？你可以用来监视文件/目录。