上下文切换 [英] context switch

查看:85
本文介绍了上下文切换的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述




我有一个客户端/服务器应用程序,使用一种线程/客户端方法。


我看到非常高的上下文切换/秒。有什么方法可以减少它?如果不减少线程,每个

线程在无限循环中睡眠时间更长?


在同一台机器上,我也运行一个mysql服务器。我可以在mysqld中看到相同金额的线程

,似乎mysql也在使用一个线程/客户端。但是它的b / b $上下文/开关要低得多。我怎样才能获得相同的表现?


非常感谢!

Ryan

解决方案

On Sun,2008年6月1日17:48:11 -0700,Ryan Liu< rl ** @ powercati.comwrote:


I有一个客户端/服务器应用程序,使用一种线程/客户端方法。


我看到非常高的上下文切换/秒。有什么方法可以减少它?如果不减少线程,每个

线程在无限循环中睡眠时间更长?


在同一台机器上,我也运行一个mysql服务器。我可以在mysqld中看到相同的金额

线程

,似乎mysql也在使用一个线程/客户端。但是它的b / b $上下文/开关要低得多。我怎样才能获得相同的性能?



简单的答案是:丢弃一个线程/客户端。设计。它在Windows上没有很好的规模。


在i / o类上使用异步API(特别是网络i / o,其中

我假设你正在谈论的),这将利用

Windows中的内置机制,旨在防止过多的上下文

切换和最小化线程数(i / o完成端口)。对于

示例,请使用Socket.BeginReceive,Stream.BeginRead等(当然,匹配

End ...方法)。


听到MySql使用一个线程/客户端我很惊讶,我很好奇

你怎么证实这一点。无论如何,我不可能回答如何获得相同的性能。不知道MySql的具体

实现细节,当然知道具体的

实现细节会告诉你如何获得相同的

性能。 :)


最后,当然,你应该问问自己这是否重要。如果

你只有少量的客户端且性能可以接受,那么大量的上下文切换可能不是问题。是的,它b / b
可能意味着设计效率更高,但如果代码有效并且b $ b满足您的需求,那么设计复杂化可能不是最好的/>
想法。


Pete


Ryan,


通常,当你运行的线程多于处理线程的处理器时,你将有上下文切换。


你如何分配线程?通常,您应该使用ThreadPool将任务分配给您的线程,因为ThreadPool会将

考虑在机器上的处理器数量以确定多少

线程保留在池中(并最小化上下文切换)。


此外,您确定上下文切换正在导致性能

影响?如果你切换到较少的线程,你怎么知道你现在会得到相同的

并发?

-

- Nicholas Paldino [.NET / C#MVP]

- mv*@spam.guard.caspershouse.com


Ryan Liu < rl ** @ powercati.comwrote in message

news:%2 **************** @ TK2MSFTNGP06.phx.gbl ...





我有一个客户端/服务器应用程序,使用一种线程/客户端方法。

我看到非常高的上下文切换/秒。有什么方法可以减少它?如果不减少线程,每个

线程在无限循环中睡眠时间更长?


在同一台机器上,我也运行一个mysql服务器。我可以在mysqld中看到相同数量的

线程,似乎mysql也在使用一个线程/客户端。但是它的b / b $上下文/开关要低得多。我怎样才能获得相同的表现?


非常感谢!

Ryan


On Sun,2008年6月1日18:01:04 -0700,Nicholas Paldino [.NET / C#MVP]

< mv*@spam.guard.caspershouse.comwrote:
< blockquote class =post_quotes>
Ryan,


一般情况下,当你有更多运行正在运行的b $ b线程时,你会有上下文切换比有处理器来处理线程。



True。这就是为什么IOCP是解决这个问题的好方法。 Windows

知道如果可以保持给定的IOCP线程忙,而不是让另一个线程运行
。等待IOCP的完成事件的线程如果另一个线程已经准备好处理它,则不会得到该事件。一个完美平衡的IOCP实现将具有完全平衡的IOCP线程数量,但是过一点将通常不会导致添加

上下文切换,作为一个更简单的i / o实现可能。


你如何分配线程?一般来说,你可能应该使用ThreadPool为你的线程分配任务,因为ThreadPool

会考虑机器上的处理器数量

确定池中要保留多少个线程(并最小化上下文

切换)。



你确定这是真的吗?更具体地说,虽然确实

ThreadPool使用CPU数来确定线程数,但

总线程数总是远高于

CPU的实际数量。在我的脑海中,它曾经是每个CPU 25个线程,而现在它已经是250个线程,或类似的东西。


我从来不知道ThreadPool是一个特别优秀的

上下文切换管理器。 :)


另外,你确定上下文切换导致性能影响?b $ b影响?如果你切换到更少的线程,你怎么知道你将获得与现在相同的并发?




一个非常好的问题。 :)


Pete


Hi,

I have a client/server application, using one thread/client approach.

I see very high context switch/sec. What are the ways to reduce it? Each
thread sleep longer in its endless loop if not reducing thread?

On the same machine, I also run a mysql server. I can see same amount thread
in mysqld, seems mysql is also using one thread/client. But its
context/swith is much lower. How can I get same performance?

Thanks a lot!
Ryan

解决方案

On Sun, 01 Jun 2008 17:48:11 -0700, Ryan Liu <rl**@powercati.comwrote:

I have a client/server application, using one thread/client approach.

I see very high context switch/sec. What are the ways to reduce it? Each
thread sleep longer in its endless loop if not reducing thread?

On the same machine, I also run a mysql server. I can see same amount
thread
in mysqld, seems mysql is also using one thread/client. But its
context/swith is much lower. How can I get same performance?

The simple answer is: discard the "one thread/client" design. It doesn''t
scale well on Windows.

Use the asynchronous API on the i/o classes (especially network i/o, which
I assume is what you''re talking about), and that will take advantage of
the built-in mechanisms in Windows designed to prevent excessive context
switching and minimizing thread count (i/o completion ports). For
example, use Socket.BeginReceive, Stream.BeginRead, etc. (with matching
"End..." methods, of course).

I''m surprised to hear that MySql uses "one thread/client", and I''m curious
how you''ve confirmed this. Regardless, it''s not possible to answer "how
can I get the same performance" without knowing the specific
implementation details for MySql, and of course knowing the specific
implementation details would tell you directly how to get the same
performance. :)

Finally, of course, you should ask yourself whether it''s important. If
you only have a small number of clients and performance is acceptable,
then a high number of context switches may not be a problem. Yes, it
might mean the design could be more efficient, but if the code works and
performs up to your needs, complicating the design may not be the best
idea.

Pete


Ryan,

Generally, you are going to have context switches when you have more
threads that are running than there are processors to handle the threads.

How are you allocating the threads? Generally, you should probably use
the ThreadPool to assign tasks to your threads, as the ThreadPool will take
into account the number of processors on the machine to determine how many
threads to keep in the pool (and minimize context switches).

Also, are you sure the context switches are causing a performance
impact? If you switch to less threads, how do you kno you will get the same
concurrency that you have now?
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Ryan Liu" <rl**@powercati.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

Hi,

I have a client/server application, using one thread/client approach.

I see very high context switch/sec. What are the ways to reduce it? Each
thread sleep longer in its endless loop if not reducing thread?

On the same machine, I also run a mysql server. I can see same amount
thread in mysqld, seems mysql is also using one thread/client. But its
context/swith is much lower. How can I get same performance?

Thanks a lot!
Ryan


On Sun, 01 Jun 2008 18:01:04 -0700, Nicholas Paldino [.NET/C# MVP]
<mv*@spam.guard.caspershouse.comwrote:

Ryan,

Generally, you are going to have context switches when you have more
threads that are running than there are processors to handle the threads.

True. Which is why IOCP is a good way to address the issue. Windows
knows to keep a given IOCP thread busy if it can, rather than letting
another thread run. Threads waiting on a completion event for an IOCP
won''t get the event if another thread is already ready to deal with it. A
perfectly balanced IOCP implementation will have exactly the right number
of IOCP threads, but going over a little will generally not cause addition
context switches, as a more na?ˉve i/o implementation might.

How are you allocating the threads? Generally, you should probably
use the ThreadPool to assign tasks to your threads, as the ThreadPool
will take into account the number of processors on the machine to
determine how many threads to keep in the pool (and minimize context
switches).

Are you sure this is true? More specifically, while it''s true that the
ThreadPool uses the CPU count to determine the number of threads, the
total thread count has always been much higher than the actual number of
CPUs. Off the top of my head, it used to be 25 threads per CPU, and now
it''s 250 threads, or something like that.

I''ve never known the ThreadPool to be a particularly good manager of
context-switching. :)

Also, are you sure the context switches are causing a performance
impact? If you switch to less threads, how do you kno you will get the
same concurrency that you have now?

A very good question. :)

Pete


这篇关于上下文切换的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆