Scanner Sizing Guidance for Mend Reachability

Reachability analysis runs inside the SCA agent's JVM as an additional process, so it requires extra memory headroom on top of the current scan allocation.

Reachability Engine Version

The sizing below applies to Reachability engine version 26.8.1.3 or later. Earlier versions use more memory during reachability analysis and are more likely to fail with out-of-memory errors.

By default, the scanner updates the Reachability engine to the latest version each time the scanner container starts. The scanner logs show the update with entries like:

[INFO] com.wss.github.scanner.service.ScaWrapper - [CTX=...;SCAN_CTX=...;SCAN_ID=...]    [agent=sca, agent_version=26.6.2, command=Scan, engine=npm, level=info, state=ENGINE_UPDATE] Updating Reachability
[DEBUG] com.wss.github.scanner.service.ScaWrapper - [CTX=...;SCAN_CTX=...;SCAN_ID=...]    [agent=sca, agent_version=26.6.2, command=Scan, engine=npm, level=debug, state=ENGINE_UPDATE] trying to download persisted Reachability engine
[DEBUG] com.wss.github.scanner.service.ScaWrapper - [CTX=...;SCAN_CTX=...;SCAN_ID=...]    [agent=sca, agent_version=26.6.2, command=Scan, engine=npm, level=debug, state=ENGINE_UPDATE] updating reachability utilities

To disable the automatic update, contact your Mend Customer Success Manager. With the update disabled, confirm that the engine version meets the requirement above before applying this sizing.

To confirm the engine version, look in the scanner logs for the reachability-core version entry:

[DEBUG] com.wss.github.scanner.service.ScaWrapper - [CTX=...;SCAN_CTX=...;SCAN_ID=...]    [agent=sca, agent_version=26.6.2, command=Scan, engine=npm, level=debug, state=UTILITY_UPDATE] [Reachability] 21:18:44.634 [main] INFO  c.m.p.common.client.PrioritizeClient -- Version Info: {groupId=com.mend.analysis, artifactId=reachability-core, version=26.9.1.3}

The version value is the engine version. This entry appears whether or not the automatic update is enabled.

Scanner Pod Memory Sizing

• Starting allocation: the larger of these values:

  • Current memory x 1.25.

  • 16 GB.

  The 16 GB minimum gives the Reachability engine at least 4 GB of JVM heap. By default, the JVM limits the heap to 25% of container memory (see -XX:MaxRAMPercentage in the Java command reference).

  • Examples:

    • Scanners currently at 12 GB should start at 16 GB.

    • Scanners at 16 GB should start at 20 GB.

• Fine-tuning: After running reachability scans on the largest repositories, adjust the allocation using scan metrics (see "How to Observe Memory Usage" below).

• Target allocation: the larger of these values:

  • The memory allocation before Reachability was enabled.

  • 16 GB.

  • Highest observed memory value x 1.4 x 4. The observed value is JVM heap. Multiplying by 4 converts it to container memory under the default 25% heap limit. The 1.4 factor adds a 40% buffer above the observed peak.

  The formula covers only the memory the Reachability engine needs. Other functions in the scanner container still need the memory the scanner had before Reachability was enabled.

  • Examples:

    • A scanner that ran at 16 GB before Reachability, with an observed peak of 4,000 MB, gives 4,000 x 1.4 x 4 = 22,400 MB. The target allocation is about 22 GB.

    • A scanner that ran at 24 GB before Reachability, with an observed peak of 1,800 MB, gives about 10 GB from the formula. The target allocation stays at 24 GB.

CPU

• CPU is not the bottleneck for reachability. Maintain the current CPU allocation (minimum 4 cores).

• Important: Adding CPU cores can increase peak memory consumption. If memory is constrained on the largest repositories, avoid increasing CPU allocation, as this may raise memory pressure rather than improve performance.

How to Observe Memory Usage

The method for observing memory usage depends on the scanning mode:

• Standalone Mend CLI (pipeline scan): The scanMetrics.json file is generated after each scan and can be used directly to review memory consumption.

• Repo Integration: The scanner runs in an ephemeral container that is destroyed after each scan, so scanMetrics.json is not preserved. Use the scanner logs instead (see below).

Reading Memory from Scanner Logs (Repo Integration)

Look for log entries like:

[Reachability] ... INFO ... -- Memory at reachability analysis start: 240MB
[Reachability] ... INFO ... -- Memory at reachability analysis end: 74MB

Important notes on interpreting these values:

• The reported value is the JVM committed heap. It reflects how much heap memory the JVM has claimed from the OS. It is not a precise consumption measurement, but it serves as a directional signal for sizing purposes.

• Multiple start/end pairs will appear per scan. One pair is logged per supported language detected in the repository. Each pair follows a Started running prioritize service for {language} log line. If more pairs than expected appear, the scanner may have run more than once (e.g., per module, or for both base and PR branch).

• To determine the peak for a given scan, take the highest "Memory at reachability analysis end" value across all pairs. Committed heap does not shrink during a scan, so the last (or highest) end value represents the total footprint.

Use that highest value as the observed peak when applying the peak x 1.4 x 4 formula to settle on the final allocation.