同步花费的线程时间是否太高? [英] Is thread time spent in synchronization too high?

问题描述

今天，我使用Visual Studio 2010 Performance Analyzer剖析了我的C#应用​​程序之一.具体来说，我正在分析"并发性"，因为似乎我的应用程序应该具有更多的容量，然后才能进行演示.分析报告显示，线程在同步状态下花费了大约70-80％的时间.

Today I profiled one of my C# applications using the Visual Studio 2010 Performance Analyzer. Specifically, I was profiling for "Concurrency" because it seemed as though my app should have more capacity then it was demonstrating. The analysis report showed that the threads were spending ~70-80% of their time in a Synchronization state.

说实话，我不确定这是什么意思.这是否意味着该应用程序处于实时锁定状态?

To be honest, I'm not sure what this means. Does this mean that the application is suffering from a live-lock condition?

对于上下文...有大约30个以上长期运行的线程绑定到单个AppDomain(如果重要的话，则为 )，并且其中一些线程非常繁忙(例如，while(true) { _waitEvent.WaitOne(0); //do stuff }).

For context... there are ~30+ long-running threads bound to a single AppDomain (if that matters) and some of the threads are very busy (Ex. while(true) { _waitEvent.WaitOne(0); //do stuff }).

我意识到这是一个相当模糊的问题...我想我正在寻找一些关于线程同步状态含义的解释.多少太多了，为什么? 〜75％真的很糟糕吗?我线程太多吗?还是我应该开始在其他领域寻找?

I realize this is a fairly vague question... I guess I'm looking for some elucidation on the meaning the Synchronization state of threads. How much is too much, and why? Is ~75% really bad? Do I have too many threads? or should I just start looking in other areas?

推荐答案

我不确定这是什么意思.

I'm not sure what this means.

这意味着这些线程平均要花费75％的时间在等待另一个线程完成某些工作.

It means that the threads were on average spending 75% of their time waiting for another thread to finish some work.

这是否意味着应用程序处于实时锁定状态?

Does this mean that the application is suffering from a live-lock condition?

也许！

为不熟悉该术语的读者提供帮助:死锁"是指两个线程都彼此等待完成，因此它们永远等待. 活动锁定"是指两个线程试图避免死锁的情况，但是由于选择不当，无论如何都要花费大部分时间等待.想象一下一个有两个人的桌子，一把叉子和一把刀.双方都希望拿起这两种器皿，使用它们，然后放下它们.假设我拿起刀，而你拿起叉子.如果我们俩决定等待对方放下餐具，那我们就陷入僵局.如果我们俩都意识到我们将要陷入僵局，我放下了刀，然后放下了叉子，然后然后我拿起叉子，然后又拿起了刀子，我们就活着-锁定.我们可以无限期地重复此过程；我们都在努力解决问题，但我们的沟通效率不足，无法迅速解决.

To clarify for readers unfamiliar with the term: a 'deadlock' is when two threads are both waiting for each other to finish, and therefore they wait forever. A 'live lock' is a situation where two threads are trying to avoid a deadlock, but due to their poor choices, spend most of their time waiting anyway. Imagine for example a table with two people, a fork and a knife. Both people wish to pick up both utensils, use them, and then put them down. Suppose I pick up the knife and you pick up the fork. If we both decide to wait for the other to put the utensil down, we are deadlocked. If we both realize that we're about to deadlock, and I put down the knife, and you put down the fork and then I pick up the fork and you pick up the knife, we are live-locked. We can repeat this process indefinitely; we're both working to resolve the situation, but we're not communicating effectively enough to actually resolve it quickly.

但是，我的猜测是您没有处于实时锁定状态.我的猜测是，您只对少量只能一次由一个线程访问的关键资源产生巨大争用. Occam的Razor将表明您应该假设一个简单的假设-许多线程使用一种稀缺的资源轮流使用-而不是复杂的假设-一堆线程都试图告诉对方不，您先走".

However, my guess is that you're not in a live-lock situation. My guess is rather that you simply have enormous contention on a small number of critical resources that can only be accessed by one thread at a time. Occam's Razor would indicate that you should assume the simple hypothesis -- lots of threads taking turns using a scarce resource -- rather than the complicated hypothesis -- a whole bunch of threads all trying to tell each other "no, you go first".

单个AppDomain绑定了大约30多个长期运行的线程(如果有的话)，并且其中一些线程非常忙(例如，while(true){_waitEvent.WaitOne(0);//做东西}) ).

There are ~30+ long-running threads bound to a single AppDomain (if that matters) and some of the threads are very busy (Ex. while(true) { _waitEvent.WaitOne(0); //do stuff }).

听起来糟透了.

我意识到这是一个模糊的问题.

I realize this is a fairly vague question.

是的.

多少钱太多了，为什么?

How much is too much, and why?

好吧，假设您正试图驾车穿越城镇，并且您和城市中的所有其他驾驶员花费了您75％的时间停在红绿灯处，等待其他驾驶员.您告诉我:太多了，为什么?花一个小时的时间开车行驶15分钟，对于某些人来说可能是完全可以接受的，而对于其他人则完全不能接受.每次在高峰时间乘SR 520时，我都会花一个小时的交通来移动15分钟的路程.那对我来说是不可接受的，所以现在我坐公共汽车.

Well, suppose you were trying to drive across town, and you and every other driver in the city spent 75% of your time stopped at traffic lights waiting for other drivers. You tell me: is that too much, and why? Spending an hour in traffic to drive for 15 minutes distance might be perfectly acceptable to some people and utterly unacceptable to other people. Every time I take SR 520 at rush hour I spend an hour in traffic to move a distance that should take 15 minutes; that wasn't acceptable to me so now I take the bus.

这种糟糕的表现是否为您和您的客户所接受，这是您的要求.解决性能问题的费用昂贵.您应该问的问题是，承担诊断和解决问题的费用将获得多少利润.

Whether this lousy performance is acceptable to you and your customers or not is your call. Fixing performance problems is expensive. The question you should be asking is how much profit you'll gain by taking on the expense of diagnosing and fixing the problem.

〜75％真的很糟糕吗?

Is ~75% really bad?

您的线程花费的时间比所需时间长四倍.对我来说似乎不太好.

Your threads are taking four times longer than they need to. Doesn't seem too good to me.

我线程太多吗?

Do I have too many threads?

几乎可以肯定，是的. 30很多.

You almost certainly do, yes. 30 is a lot.

但这完全是您遇到的技术问题.问我是否有太多线程?"就像通过问"这个城市的汽车过多吗?"来解决交通拥堵一样.正确的问题是"为什么这个城市有这么多的交通信号灯?高速公路?"问题不是线程；而是线程. 问题在于他们彼此在等待，而不是不停地直奔目的地.

But that is completely the wrong technical question to ask in your situation. Asking "do I have too many threads?" is like trying to fix traffic congestion by asking "does this city have too many cars?" The right question to ask is "why are there so many traffic lights in this city where there could be freeways?" The problem isn't the threads; the problem is that they are waiting on each other instead of driving on through to their destinations without stopping.

我应该开始在其他地区寻找吗?

should I just start looking in other areas?

我们到底应该怎么知道?

How on earth should we know?

这篇关于同步花费的线程时间是否太高?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！