有时 IIS 未充分利用多核处理器

发布于 2024-09-30 23:42:37 字数 443 浏览 12 评论 0原文

我在服务器上遇到了 ASP.Net 应用程序的奇怪行为(Windows Server 2008 x64 上的 IIS7,处理器 Xeon Quad)。

Web 应用程序是一个简单的页面,大约一秒钟计算一些数学,然后显示结果。也就是说它几乎不消耗网络、磁盘、内存,而是完全使用处理器资源。

在负载测试中出现以下现象:IIS7使用处理器不超过25%,并不是因为世界不想更多地使用它。这 25% 相当于一个核心,但根据任务管理器性能选项卡分布在所有四个核心上。在另一台计算机(IIS7、Win 7、Quad)上一切正常:处理器全部 100% 得到利用。

对于每个行为变体(4 核处理器上的峰值负载为 25% 和 100%),我在 2 台计算机上找到了。 此处描述了类似的情况。什么会导致这种行为?

I have faced strange behavior of my ASP.Net application on the server (IIS7 on Windows Server 2008 x64, processor Xeon Quad).

The web application is the simple page which about one second calculates some math, and then displays result. That is it almost does not consume a network, a disk, memory, but completely uses processor resources.

The following phenomenon appears at load testing: IIS7 utilize processor no more than on 25% and not for the world does not wish to utilize it more. This 25% are equal to one core, but spread out on all four according to task manager performance tab. On the other computer (IIS7, Win 7, Quad) all works as well as should: the processor is utilized on all of 100%.

For each of behavior variants (peak loading of 25% and 100% on 4 core processors) I have found on 2 computers. The similar situation is described here. What can cause such behavior?

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

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

发布评论

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

评论(5

捎一片雪花 2024-10-07 23:42:37

这25%相当于一个核心,但是
根据分布在所有四个上
任务管理器性能选项卡。

事实检验:当你用完一个核心时,CPU 调度程序会在 2008 R2 之前在核心之间移动负载。从 2008 R2 开始,它会将其保留在一个核心上,以实际将其他核心移至深度睡眠状态。

因此,您所看到的基本上是一个使用一个 CPU 核心的应用程序。观点。

什么会导致这种行为?

您的代码或请求生成(以及您的代码)确保请求被序列化而不是并行处理。

在负载测试期间...您是否接受/保留会话cookie(例如:一个)并且在您的asp.net页面中是否启用了会话状态?这会将所有页面请求序列化到内存中的一个会话,并且很可能是罪魁祸首之一。另一种是在代码中做一些“愚蠢”的事情,将结果放在一个块中,并使算法有效地单线程 - 但如果没有您提供的有关如何编程和有效做什么的更多信息,就无法评估这一点。例如,我曾经见过一群猴子使用保存在应用程序对象中的一个数据库连接(为了不使数据库过载)编写在线商店,并使用那里的锁定/解锁方法有效地将他们的 asp 应用程序转换为单线程事物。这是显而易见的——但还有很多其他事情可能会出错。问题基本上是:

  • 您是否通过配置/测试场景执行某些操作来强制 IIS 序列化(这将在网络农业设置或会话状态的错误使用中)?
  • 您是否在页面中执行了任何有效将其锁定为单线程的操作?

IIS本身通过工作项应答请求(即使用大量线程),除非它可以序列化它们(会话一次只分配给一个线程,因此同一会话的第二个请求被序列化)。

This 25% are equal to one core, but
spread out on all four according to
task manager performance tab.

Reality check: when you use up one core, the CPU scheduler will move the load between cores before 2008 R2. Staring with 2008 R2 it will keep it on one core to actually move the other cores into deep sleep.

So, what you see is basically an application that uses one CPU core. Point.

What can cause such behavior?

Either your code, or your request generation (well, together with your code) make sure that the requests are serialized and not handled in parallel.

During load testing... do you accept / keep the session cookie (like: ONE) and in your asp.net page do you have session state enabled? This would serialize all page requests to the one session in memory and is one very likely culprit. Another one is doing "stupid" things in code the result in a block and make the algorithm effectively single threaded - but this can no be evaluated without a lot more information from you on how you program and what you effectively do. For example I have seen a bunch of monkeys once code an online shop using ONE database connection (to not overload the database) that was kept in the aplication object and using the lock / unlock methods there to effectively turn their asp application into a single threaded thing. This was obvious - but there are a lot of other things that can go wrong. The questions basically are:

  • Are you by configuration / test scenario doing something to force IIS to serialize (which would be among web farming settings or bad usage of session state)?
  • Do you do anything within the pages that is effectively locking them to single threaded?

IIS per se answers requests through work items (i.e. uses a LOT of threads) unless it HA to serialize them (sessions only are ever assigned to ONE thread at a time, so a second request for the same session is serialized).

难以启齿的温柔 2024-10-07 23:42:37

我怀疑它已经扩散了。更有可能的是,该算法没有并行化,因此代码在单个核心中运行。

I doubt it's spread out. More likely the algorithm is not parallelised and so the code runs in a single core.

梦里泪两行 2024-10-07 23:42:37

据我了解,在加载率为 100% 的那 2 台计算机上,已经安装了 32 位 Windows。在相同的 2 台计算机上,峰值负载为 25% - 64 位。但自定义更改“启用 32 位应用程序”=true 没有帮助。

I have understood, that on those 2 computers where loading was 100%, 32 bit Windows has been installed. On the same 2 computers, where peak loading was 25% - 64 bit. But customisation change "Enable 32 bit applications"=true has not helped.

自由范儿 2024-10-07 23:42:37

如果您的服务器正在使用多个工作进程,并且您确定负载测试软件正在并行发出请求,那么应用程序中的某些内容可能会变成串行。

这实际上很常见(我们为客户进行了大量的负载测试) - 它可以像大小为 1 的数据库池一样简单,也可以像某些共享资源被锁定在应用程序或内部的某个深度级别一样复杂。应用程序正在使用的库。我们见过这样的情况:提供应用程序页面的第一步会打开一个事务,该事务在页面完成之前不会提交。如果该事务正在锁定每个其他页面出于相同目的所需的表,则一次只能服务一个页面请求。

祝您找到问题好运 - 请务必让我们知道您的发现!

If your server is using multiple worker processes and you are sure that your load testing software is issuing requests in parallel, then something in your application is likely becoming serial.

This is actually pretty common (we do a lot of load testing for our customers) - it could be as simple as a database pool with a size of one or as complex as some shared resource being locked at some level deep within the application or within a library the application is using. We've seen cases where the first step in serving an application page opens a transaction that is not committed until the page is done. If that transaction is locking a table that is needed for the same purpose by every other page, then only one page request can be serviced at a time.

Good luck hunting down the problem - be sure to let us know what you find!

明天过后 2024-10-07 23:42:37

安装更新的操作系统后问题已解决。 “Windows Server 2008 Enterprise SP1 (c) 2009”而不是“Windows Server 2008 Standard SP2 (c) 2007”。

The problem has been solved after installation of fresher OS. "Windows Server 2008 Enterprise SP1 (c) 2009" instead of "Windows Server 2008 Standard SP2 (c) 2007".

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