Windows 服务增加 CPU 消耗

问：

在我的工作中，我负责六项 Windows 服务，这些服务是用 C# 2003 编写的。这些服务中的每一个都包含一个计时器，该计时器每分钟左右触发一次，其中大部分工作都发生在计时器上。

我的问题是，当这些服务运行时，它们开始在循环的每次迭代中消耗越来越多的 CPU 时间，即使它们没有有意义的工作要做（即，它们只是在空闲，在数据库中寻找要做的事情）。当它们启动时，每个服务平均使用 4 个 CPU 的 2-3%，这很好。24 小时后，每个服务将在其循环运行期间消耗整个处理器。

谁能帮忙？我不知是什么原因造成的。我们目前的解决方案是每天重新启动一次服务（它们会自行关闭，然后脚本会看到它们处于离线状态，并在凌晨 3 点左右重新启动它们）。但这不是一个长期的解决方案;我担心的是，随着服务变得越来越繁忙，每天重新启动一次可能还不够......但是，由于启动受到重大惩罚（它们都使用NHibernate进行数据访问），因此随着它们变得越来越繁忙，我们不想做的就是更频繁地重新启动它们。

@akmad：没错，这非常困难。

1. 是的，随着时间的推移，单独运行的服务将显示相同的症状。
2. 不，它没有。我们已经研究过了。这可能发生在上午 10 点或下午 6 点或半夜。没有一致性。
3. 我们愿意;他们是。这些服务正在做他们应该做的事情，仅此而已。
4. 不幸的是，这需要预先知道服务何时会耗尽 CPU，这是在不可预测的时间表上发生的，而且永远不会很快......这使得事情变得更加困难，因为我的老板会在他们开始出现问题时运行并重新启动它们，而不考虑调试问题。
5. 不，他们使用的 RAM 数量相当一致（每个大约 60-80MB，机器上 4GB）。

很好的建议，但请放心，我们已经尝试了所有常见的故障排除方法。我希望这是一个有人可能知道的 .NET 问题，我们可以努力解决。我老板的解决方案（我坚决不想实现）是在数据库中放置一个字段，该字段可以保存多次，以便服务在白天重新启动，这样他就可以让问题消失而不去想它。我拼命寻找真正问题的原因，以便我能够解决它，因为这个解决方案将在大约六个月内变成一场灾难。

@Yaakov Ellis：它们各有不同的功能。一个从异地某个位置的 Oracle 数据库中读取记录;另一个处理这些记录并将属于这些记录的文件传输到我们的系统;第三个检查这些文件，以确保它们是我们期望的样子;另一个是维护服务，它不断检查磁盘空间（我们有足够的空间）等内容，并轮询其他服务器以确保它们处于活动状态;一个运行只是为了确保所有其他系统都在运行并完成他们的工作，监控和报告错误，并重新启动任何未能保持整个系统每天 24 小时运行的东西。

所以，如果你问的是我认为你在问什么，不，所有这些服务（除了通过NHibernate访问数据库）都没有一件共同的事情，我可以指出这是一个潜在的问题。不幸的是，如果这被证明是实际的问题（这不会让我感到非常惊讶），整个事情可能会被搞砸——我最终会用简单的 SQL 重写所有这些问题。我希望这是一个垃圾收集器问题，或者比 NHibernate 更容易处理的问题。

@Joshdan：没什么秘密。正如我所说，我们已经尝试了所有常见的故障排除方法。分析是无用的：我们使用的探查器无法指向任何在 CPU 使用率较高时实际执行的代码。大约一个月前，这些服务被拆散了，寻找这个问题。对代码的每一部分都进行了分析，以试图找出我们的代码是否是问题所在;我不是来问的，因为我没有做功课。如果这是一个简单的案例，即服务所做的工作比预期的要多，那么就会被抓住。

这里的问题是，大多数时候，服务根本没有做任何事情，但仍然设法消耗了四个 CPU 内核的 25% 或更多：它们发现没有工作可做，并退出循环并等待下一次迭代。从字面上看，这应该几乎不需要 CPU 时间。

下面是我们看到的行为示例，在两天没有工作可做的服务上（在不变的环境中）。这是上周拍摄的：

第 1 天上午 8 点：平均 CPU 使用率约为 3% 第 1 天下午 6 点：平均 CPU 使用率约为 8% 第 2 天上午 7 点：平均 CPU 使用率约 20% 第 2 天上午 11 点：平均 CPU 使用率约 30%

在研究了所有可能的世俗原因之后，我在这里问了这个问题，因为我认为（事实证明是正确的）我会得到更多创新的答案（比如 Ubiguchi 的答案），或者指向我没有想到的事情（比如 Ian 的建议）。

CPU 峰值也会发生 紧接计时器之前 callback，在 timer 回调中， 或紧跟计时器 回调？

你误会了。这不是峰值。如果是这样，那就没有问题了;我可以处理尖峰。但事实并非如此......CPU 使用率普遍上升。即使服务什么都不做，等待下一个计时器命中。当服务启动时，一切都很好，很平静，图表看起来就像你所期望的......通常，使用率为 0%，当 NHibernate 访问数据库或服务执行一些微不足道的工作时，使用率会飙升至 10%。但是，在进程运行时，这始终增加到 25%（如果我让它走得太远，则更高）的使用率。

这使得 Ian 的建议成为合乎逻辑的灵丹妙药（当你不看的时候，NHibernate 会做很多事情）。唉，我已经实施了他的解决方案，但它没有效果（我没有证据证明这一点，但我实际上认为它让事情变得更糟......现在的平均使用量似乎上升得更快）。请注意，剥离 NHibernate“部分”（如您所建议）是不可行的，因为这会剥离服务中大约 90% 的代码，这将使我排除计时器作为问题（我绝对打算尝试），但不能帮助我排除 NHibernate 作为问题，因为如果 NHibernate 导致这种情况， 那么实施的狡猾的修复程序（见下文）将不得不成为系统工作方式;我们在这个项目上非常依赖NHibernate，以至于PM根本不会接受它导致了无法解决的结构性问题。

我刚刚注意到一种绝望感 问题 -- 你的问题 除非出现小奇迹，否则会继续

不要故意让它以这种方式脱落。目前，这些服务每天都在重新启动（可以选择输入一天中的任意小时数来关闭和重新启动），这修补了问题，但一旦它们进入生产机器并开始变得繁忙，就不能成为长期解决方案。无论我修复它们还是 PM 对它们保持这种限制，问题都不会继续存在。显然，我更愿意实施真正的修复，但由于最初的测试没有显示任何原因，并且服务已经过广泛审查，因此 PM 宁愿让它们多次重新启动，也不愿花更多时间尝试修复它们。这完全超出了我的控制范围，使你所说的奇迹比其他情况更重要。

这是非常有趣的（到目前为止 因为您信任您的探查器）。

我没有。但是，这些是用 .NET 1.1 编写的 Windows 服务，运行在 Windows 2000 计算机上，由狡猾的 Nant 脚本部署，使用旧版本的 NHibernate 进行数据库访问。在那台机器上，我几乎不会说我信任。