What

Make the Solr JVM heap configurable via a SOLR_HEAP environment variable instead of the hardcoded -m 4g in the dspacesolr entrypoint.

-      exec solr -p 8983 -f -m 4g
+      exec solr -p 8983 -f -m ${SOLR_HEAP:-4g}

Default is unchanged (4g) — with no SOLR_HEAP set, behavior is identical to today, so this is safe everywhere. This mirrors the pattern already used for the backend Tomcat heap in the same file (JAVA_OPTS: ${JAVA_OPTS:--Xmx4g}).

Why

-m 4g makes Solr start with -Xms4g -Xmx4g, and because the Solr image runs with -XX:+AlwaysPreTouch, the full 4 GB is committed at container start — regardless of how small the index actually is.

On hosts that run a single stack this is fine. But on shared multi-stack dev boxes it is the dominant memory cost. Example: dev-5.pc runs 6 DSpace stacks (customer-uk, zcu-pub, lindat, TUL, dspace-7_x, zcu-data) on 31 GB of RAM. Six Solr containers alone reserve 6 × 4 GB = 24 GB, which pushes the box permanently above 90% memory and into heavy swap — and trips the NewRelic RAM alerts continuously.

There is currently no way to lower the Solr heap without editing the tracked compose file, which the CI deploy re-checks-out and reverts on every run. This change provides a proper, persistent knob: low-RAM/dev hosts can set SOLR_HEAP in their --env-file (e.g. /opt/dspace-envs/.env.dspace.dev-5.* → SOLR_HEAP=1g) while production deployments keep the 4g default.

How to use

In the deploy env file for an instance:

SOLR_HEAP=1g

start.sh already passes --env-file, so compose interpolates it into the entrypoint at up time. Verified locally on dev-5.pc (instance 6): -m 1g → Solr RSS dropped from ~2.2 GB to ~430 MB.

Backport

This is a single, non-breaking line and should be backported to all customer/* branches so every customer deployment gains the knob (labelled accordingly).

Summary by CodeRabbit

• Chores
  • Solr Docker service now supports configurable heap memory allocation via environment variable, with a 4GB default.