Hi, Valdis: Thanks for the informative reply! There are actually plenty of processes stuck in D-state, among them are systemd-logind and snmpd.
1) Check your dmesg/syslog for any WARN, BUG, or OOPS messages with tracebacks, which probably indicates the kernel bug that caused the problem.
2) cat /proc/NNN/stack will give you a hint where the syscall is wedged.
http://ix.io/CMN It seems that they all have something to do with autofs or filesystem. As shown in this graph: https://i.imgur.com/C1bPHTX.png , the ultimate cause of the massive process massacre is due to memory excessive memory usage of some processes in the noon of Dec 2. However, I did not see OOM in dmesg. Is there a way to adjust system overall OOM aggressiveness so the kernel will kill the offending processes early, before the kernel become mal-functioning? Many thanks, Yun-Chih