1: Fully Using available Cores
IIRC the CPU(s)
counts at the top of top
's output are normaised for the number of cores, so that 100% is all your available CPU resource being used. The %CPU
column isn't normalised though, so can be over 100%.
Top verify this (it may vary depending on the verison of top
on your system open one session per core and run gzip -c < /dev/zero > /dev/null
in them, while watching top
in another session. The CPU(s) figures should total ~100% rather than 100*cores (they do on top
on the systems I've just tried that on to confirm).
One complication that may affect the above test is hyperthreading if you have that available in your CPU and it is enabled. top
will see all the virtual cores as real ones (so with one two-core CPU with hyperthreading you'll see four cores in top
when you turn on the per-core display by pressing 1
), yet hyperthreading does not give the potential 100% boost in processing resource this would imply (see http://en.wikipedia.org/wiki/Hyper-threading). Using the same test on my netbook (2 cores with HT turned on, so 4 virtual cores) shows simialar results: to single-threaded CPU eating tasks make top
show processor use to be ~50% and four such processes make it show ~100% (though the total amount being processed is not twice as much due to the way HT shares CPU resources between the vcores in each core).
2: Process Listing
The %sys does not count seperate system processes. Any process can spend some time in "userland" (doing calculations, processing strings, and so forth) which is counted in %user and some time in "kernel space" (when it asks the kernel to allocate some memory or so forth) which is counted in %sys.
You should see all the processes that are currently present in top
's output, but processes "escape" being counted in top
s list if they are created and end within top
's polling interval (but the overall time used is still seen by top as it uses kernel-wide counts for these figures).
With modern equipment you could have many processes being created, doing some work, and ending, in the time that top spends idle (usally one second by default) between rescanning the current process list and displaying it.
You might find evidence to confirm if this is happening in your log files, though unfortunately it could also be processes that leave no log footpint.