Endpoints with a high volume of activity may see an increase in memory utilization by the repmgr.exe process. This has most commonly been seen on Windows Servers, but can also be experienced on Windows desktops. The majority of endpoints do not experience this behavior. This issue is only experienced on endpoints with a high rate of activity and generally only in environments that have Enterprise EDR (EEDR) enabled.
The problem can be identified by:
"c:\program files\confer\repcli" counters | findstr /i AdminPort:KernelToUserBulkEventTransfer:SendDurationCount
"c:\program files\confer\repcli" counters | findstr /i KernelComms:BulkEventTransfer(ms)Count
Having a delta between the first and second number indicates that repmgr.exe can't keep up with the rate of events coming from kernel. The larger the delta the more memory that will be utilized as any delta is stored in memory. The below example shows a delta of ~50K (4250241 - 4200346)
AdminPort:KernelToUserBulkEventTransfer:SendDurationCount=4250241
KernelComms:BulkEventTransfer(ms)Count=4200346
There are currently three options to workaround this:
This configuration can be set two different ways:
Manually
Per policy
PscrQueueMax=4000
"c:\program files\confer\repcli" updateconfig
Contact Broadcom Carbon Black Support. When requesting this, please provide the name of the policy the configuration should be set on. We recommend only setting this configuration for sensors that have experienced the issue.
See Event Reporting and Sensor Operation Exclusions. For help contact Broadcom Carbon Black support.
An upcoming release will address this issue without the need for manual intervention