在我的工作中，我负责使用 C# 2003 编写的六个 Windows 服务。这些服务中的每一个都包含一个计时器，它每分钟左右触发一次，它们的大部分工作都发生在这里。
我的问题是，随着这些服务的运行，它们开始通过循环的每次迭代消耗越来越多的 CPU 时间，即使它们没有有意义的工作要做（即，它们只是闲置，浏览数据库做某事）。当它们启动时，每个服务平均使用（大约）4 个 CPU 的 2-3%，这很好。24 小时后，每个服务将在其循环运行期间消耗整个处理器。
任何人都可以帮忙吗？我不知道是什么原因造成的。我们当前的解决方案是每天重新启动一次服务（它们会自行关闭，然后脚本会看到它们处于脱机状态并在凌晨 3 点左右重新启动它们）。但这不是一个长期的解决方案；我担心的是，随着服务变得越来越忙，每天重新启动一次可能还不够……但是由于启动会受到很大的损失（它们都使用 NHibernate 进行数据访问），随着它们变得越来越忙，这正是我们没有的想要做的是更频繁地重新启动它们。
@akmad：的确，这非常困难。
- 是的，独立运行的服务会随着时间的推移显示相同的症状。
- 不，它没有。我们已经看过了。这可能发生在上午 10 点或下午 6 点或半夜。没有一致性。
- 我们的确是; 他们是。这些服务正在做他们应该做的，没有别的。
- 不幸的是，这需要预先知道服务何时会用尽 CPU，这发生在不可预知的时间表上，而且永远不会很快……这使事情变得更加困难，因为我的老板会在它们开始运行并重新启动它们时问题而不考虑调试问题。
- 不，他们使用相当一致的 RAM 量（每个大约 60-80MB，机器上的 4GB）。
很好的建议，但请放心，我们已经尝试了所有常见的故障排除方法。我希望这是一个有人可能知道的 .NET 问题，我们可以努力解决。我老板的解决方案（我特别不想实施）是在数据库中放置一个字段，该字段包含多次，以便白天重新启动服务，这样他就可以让问题消失而不去想它. 我正在拼命寻找真正问题的原因，以便我能够解决它，因为这个解决方案将在大约六个月内变成一场灾难。
@Yaakov Ellis：它们每个都有不同的功能。一个从异地某处的 Oracle 数据库中读取记录；另一个处理这些记录并将属于这些记录的文件传输到我们的系统；第三个检查这些文件以确保它们是我们所期望的；另一个是维护服务，它不断检查磁盘空间（我们有足够的空间）并轮询其他服务器以确保它们处于活动状态；一个运行只是为了确保所有这些其他的都在运行并完成它们的工作，监视和报告错误，并重新启动任何未能保持整个系统一天 24 小时运行的任何东西。
所以，如果你问我认为你在问什么，不，所有这些服务都没有一件常见的事情（除了通过 NHibernate 访问数据库），我可以指出这是一个潜在的问题。不幸的是，如果事实证明这是真正的问题（这不会让我大吃一惊），整个事情可能会被搞砸——我最终会用简单的 SQL 重写所有这些。我希望这是一个垃圾收集器问题或者比 NHibernate 更容易处理的问题。
@Joshdan：没有秘密。正如我所说，我们已经尝试了所有常见的故障排除方法。分析没有帮助：当 CPU 使用率很高时，我们使用的分析器无法指向任何实际执行的代码。大约一个月前，这些服务在寻找这个问题时被拆散了。分析每一段代码，试图找出我们的代码是否是问题所在；我不在这里问，因为我还没有完成我的作业。如果这是一个简单的案例，即服务所做的工作比预期的要多，那就会被抓住。
这里的问题是，大多数时候，服务根本没有做任何事情，但仍然设法消耗 25% 或更多的四个 CPU 内核：它们没有工作要做，退出循环并等待下一次迭代。从字面上看，这应该几乎不需要 CPU 时间。
这是我们看到的行为示例，在两天内没有工作的服务上（在不变的环境中）。这是上周捕获的：
第 1 天，早上 8 点：平均。CPU 使用率约 3%
第 1 天，下午 6 点：平均。CPU 使用率约 8%
第 2 天，早上 7 点：平均。CPU 使用率约 20%
第 2 天，上午 11 点：平均。CPU使用率约30%
在查看了所有可能的世俗原因之后，我在这里提出了这个问题，因为我认为（事实证明是正确的）我会得到更多创新的答案（比如 Ubiguchi 的），或者指向我没有的事情的指针'没想到（就像伊恩的建议）。
那么 CPU 峰值是在定时器回调之前、在定时器回调中还是在定时器回调之后立即发生？
你误会了。这不是一个尖峰。如果是，就没有问题；我可以处理尖峰。但它不是...... CPU使用率普遍上升。即使服务什么也不做，等待下一个计时器命中。当服务启动时，一切都很平静，图表看起来就像你所期望的那样......通常，使用率为 0%，当 NHibernate 访问数据库或服务执行一些微不足道的工作时，使用率会飙升至 10% . 但这会在进程运行时始终增加 25% 的使用率（如果我让它走得太远的话会更多）。
这使得 Ian 的建议成为合乎逻辑的灵丹妙药（当您不注意时， NHibernate 会做很多事情）。唉，我已经实施了他的解决方案，但它没有产生效果（我没有证据证明这一点，但我实际上认为这让事情变得更糟......平均使用量似乎现在上升得更快）。请注意，删除 NHibernate“部分”（如您所推荐）是不可行的，因为这将删除服务中大约 90% 的代码，这将让我排除计时器问题（我绝对打算尝试），但不能帮助我排除 NHibernate 的问题，因为如果 NHibernate 导致了这种情况，那么实施的狡猾修复（见下文）将不得不成为系统工作的方式；我们在这个项目中非常依赖 NHibernate，以至于 PM 根本不会接受它会导致无法解决的结构性问题。
我刚刚注意到这个问题有一种绝望的感觉——除非出现小奇迹，否则你的问题将继续存在
不要让它以这种方式脱落。目前，这些服务每天都在重新启动（可以选择输入一天中的任意小时数让它们关闭和重新启动），这可以解决问题，但一旦进入生产机器就不能成为长期解决方案并开始变得忙碌。无论是我修复它们还是 PM 对它们保持这种约束，这些问题都不会继续存在。显然，我更愿意实施真正的修复，但由于最初的测试没有发现原因，而且服务已经经过广泛审查，PM 宁愿让它们重新启动多次，也不愿花更多时间尝试修复它们. 这完全超出了我的控制，让你所说的奇迹变得比其他情况更重要。
这非常有趣（只要您信任您的分析器）。
我不。但是，这些是用 .NET 1.1 编写的 Windows 服务，在 Windows 2000 机器上运行，由一个狡猾的 Nant 脚本部署，使用旧版本的 NHibernate 进行数据库访问。那台机器上几乎没有我会说我信任的东西。