Breadcrumbs

Scanner Sizing Guidance for Mend Reachability

Disclaimer: This document serves as a general guideline for scanner sizing when enabling Mend Reachability. Actual resource requirements may vary significantly based on repository size and complexity, number of supported languages detected, dependency graph depth, and specific infrastructure constraints. Teams should adapt these recommendations to their unique environment and validate all sizing decisions against observed scan metrics in their specific deployment context.

This guidance mostly applies to self-hosted repo integration deployments where the scanner runs in customer-managed infrastructure. For Mend-hosted environments, scanner resources are managed by Mend.

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.

Memory Sizing

  • Start with +50% over the current memory allocation (minimum increase of 4-6 GB).

    • Example: scanners currently at 12 GB should start at 18 GB. Scanners at 16 GB should start at 24 GB.

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

  • Target allocation: highest observed memory value x 1.4 (40% buffer above observed peak).

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 formula to settle on the final allocation.