Why does a system apper to “hang” when there are many processes in 'D' state?

Question

I have noticed that on a (linux) system if there are many processes in "D" (Uninterruptible) state, the system starts "hanging". The D state is mostly due to process waiting on I/O.

By "hang" I mean that, I can't type commands on the console or starting new processes is very slow, leading me to believe that the cpu is "busy" doing something. But my understanding is that a process in D state is not doing anything, but just waiting. This should need any cpu computation and in fact free the cpu and let it schedule other tasks.

I'm definitely missing something, cause the D state processes also add to the load average of a system. I don't understand why this is done, how does a process in uninterruptible sleep contribute to load?

Answer 1

When you type a command on the console, this "command" - if not a shell builtin command - is also a system file, an executable one. When you type "ls" ALL dirs in your PATH variable are searched in order for an executable called "ls" - at least as long as "ls" wasn't hashed before.

This search means accessing the disc, several times on several directories. If as you wrote you have many processes waiting for I/O, also your shell will have to wait before it can search for your typed command.

Also some commands you type will also want to read and/or write to some file on the disk, adding to the waiting for I/O processes ...

This doesn't add CPU load, but it adds I/O load which also counts in Linux to "total load", why? I think this is just a matter of definition. See http://en.wikipedia.org/wiki/Load_%28computing%29 .

Therefore, distributing your I/O on several discs (not partitions) could improve your performance. Having the system on one disc, and your data on other discs will help. Think also that just starting a new shell makes it search your $HOME for files like .profile, .bashrc and others, and if the disc is busy with many other I/O this can take some time.

Answer 2

D is uninteruptible sleep. Yes, in theory processes in D state are sleeping and not directly using I/O. But from my experience with processes in this state, it most likely means something is gorked in a device driver. If you have many 'D' state processes, then Something Very Bad(tm) is happening to your OS. This may be spin loops in a driver (wasting CPU cycles), buffers being read and thrown away, whatever. I'd check your system logs and dmesg for any device or device driver errors.

In conclusion, D isn't a natural state, an occasional process might be ignorable, but if you have lots of D procs and are experiencing slowness, you have some spelunking to do.