Hot answers tagged context-switch
This depends very much on the type of application you run. If you've got applications which are very trigger-happy WRT syscalls you can expect to see high amounts of context switching. If most of your applications idle around and only wake up when there's stuff happening on a socket, you can expect to see low context switch rates. System calls System calls ...
my moderately loaded webserver sits at around 100-150 switches a second most of the time with peaks into the thousands. High context switch rates are not themselves an issue, but they may point the way to a more significant problem. edit: Context switches are a symptom, not a cause. What are you trying to run on the server? If you have a multiprocessor ...
I don't see what useful information there is to be gleaned from what you're trying to do, but you can change your clock resolution on Windows machines through the standard Win32 API. Different applications on the system that demand higher response times (such as multimedia apps) do this all the time. The clock resolution might be anywhere from 0.5ms up to ...
Try using pidstat -wt The 't' option shows the threads also. It might be a thread who is doing the context switches .
It'll be a multi-threaded application doing a lot of locking. Everytime it locks, the CPU will pre-empt its quantum and allows another thread to have a go. You can write M/T apps that spend all their time sloshing between threads, none of which end up doing any useful work, and because they are causing all those context-switches, the CPU spends more time ...
Well, quite interesting case. Try observing watch -tdn1 cat /proc/interrupts. Do you see any valuable changes there?
I assume these are legitimate interrupts because of network load, and not a result of hardware/driver problem. So: You can invest into TCP-offload network card (TOE), if you deal with TCP traffic. It does some processing of TCP/IP in the network card chip, and raises less interrupts (and context switches). Check if your kernel/OS/application/traffic ...
In your case I would assume that your kernel is not virtualizing some or all values in /proc/stat, so what you're seeing should be caused by activity in other containers or in the hardware node itself. You haven't mentioned your specific kernel version so we can't check for sure, but a similar issue was discussed in ...
I see that's a Nehalem processor with hyperthreading. The last time we asked the general consensus was to disable hyperthreading by default on a SQL Server specific box (and we disabled it on ours, with good results). Browsing around a few other sites, I'm hearing that advice echoed by other reputable folks. So, you might try turning off hyperthreading ...
Hardware interrupts are a normal part of computer operation. Your NIC is going "hey! hey! hey! hey!" telling your CPU that it needs attention. Excessive hardware interrupts are typically caused by bad drivers. So the first thing I would look at are your NIC drivers.
That indeed is a huge number of interrupts. This often is an APIC Problem, though. cat /proc/interrupts should tell. If you only see your interrupts hitting CPU0 try echo "2" > /proc/irq/"somenumber"/smp_affinity Which should push the irqs of process "somenumber" on CPU2.
Only top voted, non community-wiki answers of a minimum length are eligible