1: Fully Using available Cores
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
tops 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.