Cpu Utilization High for Sleeping Processes

Does using sleep in scripts consume cpu cycles?

In Linux sleep doesn't consume CPU cycles, at least not more than not sleeping would. If the kernel doesn't find anything better to do, it will use the time to do some useful stuff in the idle process - and if that doesn't have anything to do, the kernel would temporarily halt the CPU until an external event occurs to lower power consumption.

In any case I'd say that "a lot of sleep" usually is a symptom of bad coding - how did the programmer know before execution what would be the time that would be spent before the next event would occur! An IO-bound program should be blocked waiting for events most of time, not sleeping! If the program is CPU-bound, then it should be calculating the results most of the time, not sleeping.

Why does Thread.Sleep( ... ) avoids CPU using 100% of a heavy execution from a multithread windows service based application?

When looking at the CPU usage in task manager what you're actually looking at is the percentage of non-noop commands over a given interval of time. A given core of a CPU can't be 34% on. Either it's doing something, or it's not, but it can switch back and forth literally billions of times per second. By inserting Sleep commands the result is that the CPU is spending a lot more time doing nothing, even though it has work that it could be doing. When the time spent nothing is averaged together with the time spent doing something the result is less than 100% usage. If you slept for longer periods of time, but did so less often, you'd see it jumping between 0 and 100% (which is what's really happening, you just can't visualize it currently).

At what point do short sleeps increase CPU util rather than reduce it

Sleeping is an option of last resort. Instead, have a look at the tool in the concurrent API, especially the Queues which allow you to put a task to sleep until a message arrives on which it should act.

Or look at Akka which allows you to easily build a system where a few threads process thousands of messages. The main drawback here is that you have to design your system around Akka - it's really not something that you can easily retrofit.

If speed is your main concern, look at blocking free algorithms like this one "Single Producer/Consumer lock free Queue step by step" or LMAX Disruptor.

http://ashkrit.blogspot.com/2012/11/lock-free-bounded-queue.html
A fast queue in Java

How do we use sleep() in Linux to keep our CPU usage reasonable while still having decent timing accuracy?

The only way to guarantee this is to use real-time OS scheduling. Otherwise, you are at the scheduler's mercy and could be preempted at any time (e.g. if there is some high-priority/low-nice process eating your CPU cycles). Indeed, sleep() is just a convenient way to ask for a preemption of a specific duration. It's always possible you will sleep for substantially longer than you ask. This is why Windows does not even try to sleep for <1ms; it isn't capable of that level of precision once you factor in scheduler nondeterminism. Out of the box, Linux isn't either, but it can be configured (via sched_setscheduler(2)) to be real-time, so it will make the attempt if you ask.

Why Thread.Sleep() is so CPU intensive?

Just a guess:

I don't think it's Thread.Sleep() that's tying up the CPU - it's the fact that you're causing threads to be tied up responding to a request for so long, and the system needs to spin up new threads (and other resources) to respond to new requests since those sleeping threads are no longer available in the thread pool.