mongostat causing CPU 100% On a 64Bit Debian 6 OS with 4 CPU cores and 8GB RAM, I can reproduce an issue with mongostat.

Whenever I create an index, reIndex or even index in background, according to top, the CPU load is 40-60% and RAM is filling up to 90%. 
While index task is running, I try mongostat and watch the CPU load. Immediately, CPU load is nearly 100% and blocking. 


  mongostat
  
  connected to: 127.0.0.1


Nothing after that, only CPU load at the limit until Ctrl + C for stopping mongostat. Few seconds later, CPU load scales down to ~50% and all is fine again.

Trying mongostat again with the same behaviour...

Is mongodb expecting more CPUs or what's wrong?
The root issue here is the index building - when you are building an index, you do so (by default) in the foreground and it blocks all other operations (including the mongostat polling).  In addition, the index build requires external sorting, which is computationally intensive, and potentially significant IO.   In terms of how much CPU and IO hit you should expect, the size of the index, the number of keys and the amount of data will dictate that - generally, the more data you have and the more complex the index, the longer and more expensive this process will be.

To avoid this issue, you can set your index to build in the background, though you should note that until the fix for SERVER-2771 is available in a stable release (checked into 2.5.0 as of writing this answer) the indexes will build in the foreground on secondaries (and hence still be blocking operations).  That is why this guide to building indexes on Replica Sets is still required reading for building large indexes on a set.

Finally, in terms of why mongostat made things worse from a CPU perspective - it is likely unable to poll successfully due to the blocking operation of the index build and this is manifesting as increased CPU until you kill mongostat.  This should be pretty easy to reproduce, and (depending on the level of CPU impact, and the version you are using) would potentially be grounds for filing a bug.  If it still happens with a background index build, as described above, that would be far more worrying.