[THIN] Re: Context Switches

  • From: "Braebaum, Neil" <Neil.Braebaum@xxxxxxxxxxxxxxxxx>
  • To: "'thin@xxxxxxxxxxxxx'" <thin@xxxxxxxxxxxxx>
  • Date: Thu, 27 Mar 2003 15:54:33 -0000

From this, you could reasonably infer the reason behind your context


> -----Original Message-----
> From: Schneider, Chad M. [mailto:CMSchneider@xxxxxxxxx] 
> Sent: 27 March 2003 15:51
> To: 'thin@xxxxxxxxxxxxx'
> Subject: [THIN] Re: Context Switches
> In response to this, my page faults spike in accordance with 
> the context switches.  Same time frames.
> -----Original Message-----
> From: Bernd Harzog [mailto:Bernd.Harzog@xxxxxxxxxxx]
> Sent: Thursday, March 13, 2003 4:19 AM
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Context Switches
> Neil (and Chad),
> I spoke to Kevin Goodman about this (the person who founded 
> our company and who wrote TScale). He said that there is some 
> debate about whether the switch from user to kernel mode 
> within a process triggers a context switch - so Neil, you are 
> probably right. He did offer one insight as to what might be 
> happening to cause the number to go through the roof. He said 
> that it is likely that two or more processes are competing 
> for a locked resource, and the CPU is simply continuously 
> switching between them to see which one gets the locked 
> resource first. His suggestion as to how to track this down 
> is to do the following. Go into PerfMon and look at the 
> Process Performance Object. This object allows you to track 
> counters on a per process basis (per instance of a program 
> running on the server). Unfortunately, you cannot track 
> context switches this way, but you can track threads. So, his 
> suggestion is to select Threads as the object, and then to 
> select all of the instances of the main applications that are 
> running (you are going to end up with 25 sets of thread data 
> if you have 25 users of an application).
> The behavior that you ought to see is that when the context 
> switch problem occurs, a set of processes will drive the 
> thread count counters for themselves through the roof. Then 
> you will know which set of processes is causing the problem. 
> Once you know that then you are going to have to backtrack 
> through the configuration of those applications on your 
> servers (and whatever else supports the client running on the 
> terminal servers), and possibly also backtrack into the 
> source code (if it is your application).
>  -----Original Message-----
> From:         Braebaum, Neil 
> [mailto:Neil.Braebaum@xxxxxxxxxxxxxxxxx]=20
> Sent: Thursday, March 13, 2003 4:35 AM
> To:   'thin@xxxxxxxxxxxxx'
> Subject:      [THIN] Re: Context Switches
> Bernd - the "two kinds of context switches" - really equates to one.
> It really is just the OS switching from a user mode to kernel 
> mode for a process. When this occurs between two (pseudo) 
> concurrent sessions, you have to realise a certain degree of 
> this is inevitable.
> There is no discernable different in "types" of context 
> switch, though. Merely the cause.
> If the OS switches / timeslices between user mode processes - 
> you have to realise and accept that in doing so, some kernel 
> process activity will occur. And to be fair, some user mode 
> activity may well produce or spawn some kernel mode activity.
> There is no true distinction in the type of context switch - 
> so it's a bit unfair to say that MS don't differentiate or 
> provide a mechanism to measure this - there is no true 
> difference. What matters is the cause.
> > -----Original Message-----
> > From: Bernd Harzog [mailto:Bernd.Harzog@xxxxxxxxxxx]=20
> > Sent: 12 March 2003 18:04
> > To: thin@xxxxxxxxxxxxx
> > Subject: [THIN] Re: Context Switches
> >=20
> > Let me add my two cents. There are as Ron said two kinds of=20  
> >context switches. One kind occurs when the processor switches=20  
> >between two user mode tasks. So, if Ron and I are both=20  
> running an 
> >application on the same server when the CPU=20  switches 
> between doing 
> >work for Ron and work for me, that=20  causes a context 
> switch. That is 
> >a GOOD context switch,=20  because it is indicative of the CPU doing 
> >what it is suppose=20  to do, which is move so rapidly between doing 
> >work for=20  different users that each user never notices. 
> The second 
> >type=20  of context switch occurs when the CPU goes from user mode 
> >to=20  kernel mode, and then back again (two Context Switches).=20
> > These are BAD context switches, because when the CPU goes=20
> > into Kernel mode it blocks user mode operations and slows=20
> > everything down.
> >=20
> > So, you need to find out what kind of context switches you=20
> > are getting. Since MS does not do us the favor of breaking=20
> > them out, the only way to find out is to look at other=20
> > indicators of heavy Kernel Mode operations and see if they=20
> > are pegged as well. Try looking at pages/sec and page=20
> > faults/sec. If you see a heavy correlation between these and=20
> > the context switches you may have an indicator that it is=20
> > kernel mode related. If it is, call me, because I have=20
> > something new that I cannot talk about on the list that we=20
> > might want to discuss.
> >=20

This e-mail and its attachments are intended for the above named 
recipient(s) only and are confidential and may be privileged.
If they have come to you in error you must take no action based 
on them, nor must you copy or disclose them or any part of 
their contents to any person or organisation; please notify the 
sender immediately and delete this e-mail and its attachments from 
your computer system.

Please note that Internet communications are not necessarily secure 
and may be changed, intercepted or corrupted. We advise that 
you understand and observe this lack of security when e-mailing us 
and we will not accept any liability for any such changes, 
interceptions or corruptions. 

Although we have taken steps to ensure that this e-mail and its 
attachments are free from any virus, we advise that in keeping 
with good computing practice the recipient should ensure they 
are actually virus free.

Copyright in this e-mail and attachments created by us belongs 
to Littlewoods. 

Littlewoods takes steps to prohibit the transmission of offensive, 
obscene or discriminatory material.  If this message contains 
inappropriate material please forward the e-mail intact to 
postmaster@xxxxxxxxxxxxxxxxx and it will be investigated. 
Statements and opinions contained in this e-mail may not 
necessarily represent those of Littlewoods.

Please note that e-mail communication may be monitored.

Registered office: 
Littlewoods Retail Limited, 
Sir John Moores Building, 
100 Old Hall Street, 
L70 1AB 
Registered no: 421258 

This Week's Sponsor - Emergent Online
EOL's Universal Printer new Features include:
Network Printing, Pagestreaming, 2400 DPI.
No Client Software Required!

For Archives, to Unsubscribe, Subscribe or 
set Digest or Vacation mode use the below link:

Other related posts: