通过“系统”诊断CPU使用率100%的原因过程

发布于 2024-09-11 06:38:44 字数 625 浏览 2 评论 0原文

我有一个 Windows 服务器应用程序,使用 Win32 API 用 C++ 实现,它执行大量串行和 TCP/IP 通信。随着它的运行,CPU 使用率逐渐增加,直到达到 100%。任务管理器表明大部分(>75%)CPU 使用率是由“系统”进程占用的。如果我终止服务器进程,CPU 使用率就会恢复正常。

是否有任何“简单”的方法可以准确诊断问题所在?

我怀疑 I/O 连接正在打开并且从未关闭,因此操作系统花费越来越多的时间来服务这些请求,但我想在尝试解决问题之前验证情况是否如此。


更新:在使用 xperf 后,我发现系统进程一半以上的时间都花在 ntoskrnl.exe!KxWaitForSpinLockAndAcquire 上。我对此一无所知,但该函数的名称向我表明可能存在死锁/争用问题。

系统经常使用的其他函数包括 NETIO.SYS!FilterMatchEnumNETIO.SYS!MatchConditionOverlapNETIO.SYS!IsFilterVisible 和 <代码>MpNWMon.sys!NetFlowUpendByCompletionHandle。

I have a Windows server application, implemented in C++ using the Win32 API, that does a lot of serial and TCP/IP communication. As it runs, CPU usage gradually increases, until it reaches 100%. Task Manager indicates that most (>75%) of the CPU usage is by the "System" process. If I kill my server process, then CPU usage returns to normal.

Are there any "easy" ways to diagnose exactly what the problem is?

I suspect that I/O connections are being opened and never closed, so the OS is spending more and more time servicing those requests, but I'd like to verify that is the case before I try to fix the problem.


Update: After playing around with xperf, I've found that the System process is spending more than half of its time in ntoskrnl.exe!KxWaitForSpinLockAndAcquire. I don't know anything about this, but the name of the function suggests to me that there might be a deadlock/contention issue.

Other functions that System is using a lot include NETIO.SYS!FilterMatchEnum, NETIO.SYS!MatchConditionOverlap, NETIO.SYS!IsFilterVisible, and MpNWMon.sys!NetFlowUpendByCompletionHandle.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

猫弦 2024-09-18 06:38:44

如果您还没有使用 sysinternals 工具,我建议您查看一下。

我非常喜欢的一个工具是 Handle 工具,它显示您在系统中打开的所有文件。

另一种似乎直接适用于您的场景的是 ProcDump,它允许当给定进程超过 CPU 使用率的 x% 时,您转储进程信息。

I recommend checking out the sysinternals tools if you haven't already.

One tool there I like very much is the Handle tool, which shows you all the files that are open in the system.

Another one which seems directly applicable to your scenario is ProcDump, which allows you to dump process information when a given process exceeds x% of CPU usage.

拥抱我好吗 2024-09-18 06:38:44

使用进程资源管理器,但打开您自己的进程而不是系统进程。系统进程可能只是响应您的请求。由于您没有它的代码,因此您将很难知道它对

您自己的流程做了什么:

  • 打开显示的性能选项卡
    句柄计数等,
  • 打开 tcp-ip 选项卡,显示
    连接。
  • 另请检查窗格
    流程的下半部分
    显示您的流程的资源管理器
    事件、文件等。

希望您可以从其中之一看到哪些资源被过度使用。

Portmon 也值得一试,看看活动是否符合预期。

Use process explorer, but open your own process rather than the System process. The system process is likely just responding to your requests. Since you don't have the code for it, you are going to have a hard time knowing what it's doing

for your own process:

  • Open the performance tab that shows
    the handle counts etc,
  • Open the tcp-ip tab that shows the
    connections.
  • Check also the pane on
    the lower half of the process
    explorer for your process showing
    events, files, etc..

Hopefully you can see what resource is being over used from one of those.

Portmon may also be worth a try to see if the activity is as expected.

森罗 2024-09-18 06:38:44

我建议使用 sysinternal 的 进程监视器Portmon,它应该显示 TCP 连接和串行端口活动的状态。

如果您看到它与 CPU 使用率之间存在相关性,那么您就有了很好的领先优势。

I suggest using sysinternal's Process Monitor and Portmon, which should show you the status of TCP connections and serial port activity.

If you see a correlation between that and the CPU usage then you have a good lead.

又怨 2024-09-18 06:38:44

用户转储。当进程处于这种情况时,获取进程的用户转储。然后将转储加载到 winDbg 中并查看它正在做什么。一个非常有用的命令是 !runaway。这将告诉您哪些线程使用最多的 CPU。然后查看这些线程,看看它们在做什么。

Userdump. Get a userdump of your process when it is in this situation. Then load the dump in winDbg and see what it is doing. One really useful command is !runaway. This will tell you which threads are using the most CPU. Then look at those threads to see what they are doing.

大海や 2024-09-18 06:38:44

您的句柄数是多少 - 如果该数字正在上升,则表明某些内容尚未关闭。

What's your handle count - if that's rising, it would point to something not being closed.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文