Unless you are prepared to deal with much larger Performance Sentry data files than usual, you should use appropriate filter settings when you collect Module data. Collecting the Module information is costly, and the average Windows Server executable routinely loads 50-100 assorted DLLs. Please be careful with this new function and implement a Module filter for all container processes [...]

A performance data Object called Module is created internally, when you include the Module Object in your Data Collection Set (DCS) data definition. Each instance of the Module Object shows a load module name, usually a DLL (dynamically linked library module) that is loaded within the specific process. The Module Object also has a parent [...]

OK, you asked for it. If you do not need to gather Module identification information, you can run the Performance Sentry collection service under a User Account. You can only set the Collection Service to run under a User Account manually using the Services Administrative Tool, which is illustrated below:

To function correctly, the User Account that [...]

Yes.
By design, the Performance Sentry Collection Service (dmperfss.exe) is installed to run under the built-in LocalSystem (SYSTEM) account. This built-in account, which most services use, has the authority to perform almost any internal function on the local machine. However, the LocalSystem account has no built-in facilities to access secure network resources, such as shared network [...]

No, to function properly the Performance Sentry collection service should be set up to run under the LocalSystem (or SYSTEM) account. The LocalSystem (or SYSTEM) account is a built-in account used by many services with an extraordinary level of privileges for accessing local system resources. These include privileges that cannot be granted to any User [...]