我试图找出 CPU 利用率不足的 C# 服务器应用程序的瓶颈在哪里。我认为这可能是由于磁盘 I/O 性能不佳，与应用程序本身无关，但我无法从这个假设中找出事实。
应用程序从本地 MSMQ 队列中读取消息，对每条消息进行一些处理，处理完消息后，将响应消息发送到另一个本地 MSMQ 队列。
我正在使用异步循环从队列中读取消息，尽可能快地将它们出列并使用 Task.Run 调度它们进行处理以启动每条消息的处理（并且不要等待这个 Task.Run .. 只是附加一个延续仅在其上发生故障以记录错误）。每条消息都是同时处理的，即在处理下一条消息之前无需等待一条消息完全处理完毕。
在消息处理结束时，我正在使用 MessageQueue 的 Send 方法（某种程度上是异步的，但不是真的，因为它必须等待磁盘写入才能返回 - 请参阅System.Messaging - 为什么 MessageQueue 不提供异步版本的 Send）。
对于基准测试，我在队列中排队 100K 消息（100K 消息的总大小约为 100MB），然后启动程序。在我的两台个人计算机上（一台为 SSD HD，另一台为 SATA2 HD，具有 i7 CPU 四核 -8 逻辑 proc-）在程序生命周期期间，CPU 使用率达到约 95%（将 100K 消息出列，处理它们并发送响应）。消息尽可能快地出列，尽可能快地处理（此处涉及 CPU），然后响应发送到不同本地队列的每条消息。
现在在运行非 HT 双核 CPU 的虚拟机上（不知道底层磁盘是什么，但性能似乎远不如我的……在基准测试期间，使用 Perfmon 我可以看到平均磁盘秒/写在 10-15 毫秒左右VM，而在我的个人机器上大约是 2 毫秒）当我运行同一个工作台时，我只能达到 ~55% 的 CPU（当我在机器上运行同一个工作台而不向队列发送响应消息时，我达到 ~90% 的 CPU ）。
我真的不明白这里有什么问题。似乎很清楚，将消息发送到队列是问题并减慢了程序的全局处理（以及要处理的消息的出队），但是为什么要考虑我正在使用 Task.Run 来启动每个出队消息的处理并最终响应发送，我不希望 CPU 未被充分利用。除非当一个线程正在发送消息时，它会在等待返回（磁盘写入）时阻止其他线程在同一内核上运行，在这种情况下，考虑到延迟比我的个人计算机上高得多，这可能是有意义的，但是一个线程等待 I/O 不应阻止其他线程运行。
我真的很想了解为什么我在这台机器上没有达到至少 95% 的 cpu 使用率。我盲目地说这是由于磁盘 i/o 性能较差，但考虑到我正在使用 Task.Run 同时运行处理，我仍然不明白为什么它会导致 CPU 利用率不足。也可能是一些与磁盘完全无关的系统问题，但考虑到 MessageQueue.Send 似乎是问题，并且这种方法最终将消息写入内存映射文件+磁盘，我看不出性能问题可能来自哪里除了磁盘。
这当然是系统性能问题，因为该程序最大限度地提高了我自己计算机上的 CPU 使用率，但我需要找出 VM 系统上的瓶颈到底是什么，以及它究竟为什么会影响我的应用程序的并发/速度。
任何想法 ？