15

mscorsvw.exe（预编译程序集的 .NET 优化）占用了我的 CPU 的很大一部分 - 50-100%。

这篇文章（和许多其他文章）说

ngen.exe 执行queueditems

从命令行应该杀死它。对我来说，该命令只是挂起。有没有更好的方法来杀死这个过程？

我没有尝试重新启动。在过去的几天里，我不止一次看到我的 CPU 利用率飙升，我怀疑这是我的问题；我想知道如何杀死它。

4

6 回答 6

15

尝试

ngen queue status

希望不仅仅是“我在跑步”，还展示了它试图编译的内容。该ngen queue stop命令将停止服务。

当安装程序部署程序集并要求服务使用ngen install. 显然你的机器上有一个坏的，我猜它一次又一次地失败来编译一个程序集。检查 Windows 事件日志以获取有关此的面包屑。卸载执行此操作的程序。

于 2011-06-24T15:51:25.687 回答
10

这篇文章（和许多其他文章）说

ngen.exe 执行queueditems

从命令行应该杀死它。对我来说，该命令只是挂起。有没有更好的 > 方法来杀死这个过程？

没有; 它不会杀死它。相反，它故意让它变得更糟。而不是涓涓细流的后台编译（这样你通常不会注意到它），它会一次处理所有排队的项目。这需要一些时间才能完成。它不会挂起，它会非常努力地工作。当它完成时，它就完成了，将没有更多的东西需要后台编译。

请注意，最近的升级（很可能）已添加后台编译作业（您可能安装了服务包）。Windows 通过使用 .NET JIT 编译器对所有托管程序集进行 AOT 编译来帮您一个忙，该编译器了解您的确切硬件和处理器类型，因此它将发出最优化的代码。通过这种方式，.NET 确保软件在未来运行得更快，代价是现在编译您的程序集

在您间接链接到您自己的众多资源中，请阅读以下资源，例如：

于 2011-06-24T15:39:33.303 回答
5

在我看来，.NET 有一些有问题的设计，当需要“及时”编译器运行所有内容以在 It's Time 之前编译它时。

通常有两个mscorsvw守护进程在运行，一个用于 64 位，一个用于 32 位（它们彼此同步）。100% 的 CPU 利用率是您对编译器的期望，但它以低优先级完成，并且一次不应占用超过一个内核。多核 CPU 的一个优点是，像这样的东西仍然为您留下一个核心来驱动用户界面交互。（请注意，搜索索引器是另一个相同类型的守护进程，按照相同的思路设计。）如果您有一个单核 CPU，那么您会真正注意到增加的负载。

于 2011-08-11T07:03:44.813 回答
3

有时这会导致典型的错误。我的 SQL Server msiexec.exe 进程在安装 SQL Server 2012 SP1 后继续运行，照常等待下一次更新。

于 2013-01-04T02:00:10.383 回答
2

安装 SQL 2012 后我遇到了同样的问题。运行命令 ngen queue status 后，我看到它正在运行的是 CLR 优化过程。再次使用此线程，我可以看到有两个服务 Microsoft.NET Framework NGEN v4.0.30319_X64 和 Microsoft.NET Framework NGEN v4.0.30319_X64 指示 32 位和 64 位优化代码。

我看到这两个是启动的，x86版本是罪魁祸首。我停止了服务，CPU 从 100% 恢复到 0%，内存减少了大约 2GB。

于 2013-01-14T18:28:27.523 回答
-1

看，.NET 杀死了单核媒体中心 PC。旧电脑慢了几个小时，基于网络的视频变得无法观看。如此多的能源效率 - 我必须让我的 PC 24/7 编译以偶尔赶上吗？用户控制的进程不优先。最好的是它不会放弃自动更新......包括.NET！这导致所有资源的再次重新编译，永远不会在补丁星期二之前完成。我没有发现建议的解决方法（'ngen.exe install /queue' 或 'ngen.exe update' - 在相关框架目录中找到 ngen）响应。所以。我在 services.msc 中禁用 Microsoft .NET Framework NGEN 服务 - 或通过命令行（'sc config clr_optimization_v4.xxxx start= disabled' 其中 xxxx 是版本号；通过 sc 查询或目录名称或 services.msc 获取版本号）；' stop' 会在几秒钟内重新启动。考虑或尝试完全删除 .NET 4。

于 2016-10-08T00:15:50.657 回答