Okay. You're within supported VM limitations. Most of these processes only operate when there is work to do (otherwise they are idle). SyslogCollector, on the other hand, is interrupt-driven. That is, it will take CPU every time the device receives a new syslog message. Its CPU impact can be mitigated if you reduce the number of syslog messages being sent to the server (e.g. by offloading them to a remote collector).
ANIServer is one of the work driven daemons. It will only run hot when it is performing a Campus Data Collection or servicing Campus Manager client requests. The client requests are short-lived, but Data Collection can put a sustained load on the server. However, if Data Collection is not running, then this process should fall back to near idle.
EPMServer is like SyslogCollector. It will take more CPU the more events are found by DFM. If your network is particularly problematic in terms of faults, then you will see this process along with its associated database take a big CPU hit. Reducing DFM polling frequencies, and adjusting thresholds to be more in tune with your requirements will help here.
UTMajorAcquisition is also work-driven. It will only run when a User Tracking acquisition is running. When the acquisition finishes, it will quit.
NOSServer is similar to EPMServer. It translates the EPM events and alerts into email, trap, and syslog notifications. If you reduce the events coming in and/or reduce what is sent as notifications, then you can reduce NOSServer's CPU impact.
ESS is an event bus. It is used for inter-process communication, and will be mostly idle unless processes are generating a lot of IPC events. This typically occurs when jobs are running.
ConfigMgmtServer is responsible for fetching configs from devices. It will generally be idle unless one runs a Sync Archive job.
CampusOGSServer is related to ANIServer. This process will take CPU time when clients connect to Topology Services, or launch Campus Manager device selectors. Its overall hit will be bursty and short-lived.
