Problem
The Dockerfile sets ENV JAVA_OPTS="" with no -Xmx / -XX:MaxRAMPercentage. With default container JVM ergonomics the heap is capped at ~25% of the container memory limit, which under-sizes it for the validator — whose working set runs from a few hundred MB to over 1 GB per validation. On container platforms (e.g. Cloud Run), the temp upload and output files also land on tmpfs (RAM), counting against the same memory limit.
In our measurements, 8 concurrent validations of a ~3 MB / ~13k-trip feed peaked around 1.2 GB heap / 1.7 GB RSS — comfortable when the heap is allowed to grow, but at risk under the default 25% ceiling on a small (e.g. 2 GB) instance, which would GC-thrash or OOM.
Proposal
- Set a sensible default in the image (e.g.
-XX:MaxRAMPercentage=75.0), and
- Document recommended
JAVA_OPTS per instance size plus the tmpfs implication in the README.
Happy to PR. Context: surfaced while test-driving #1.
Problem
The
DockerfilesetsENV JAVA_OPTS=""with no-Xmx/-XX:MaxRAMPercentage. With default container JVM ergonomics the heap is capped at ~25% of the container memory limit, which under-sizes it for the validator — whose working set runs from a few hundred MB to over 1 GB per validation. On container platforms (e.g. Cloud Run), the temp upload and output files also land on tmpfs (RAM), counting against the same memory limit.In our measurements, 8 concurrent validations of a ~3 MB / ~13k-trip feed peaked around 1.2 GB heap / 1.7 GB RSS — comfortable when the heap is allowed to grow, but at risk under the default 25% ceiling on a small (e.g. 2 GB) instance, which would GC-thrash or OOM.
Proposal
-XX:MaxRAMPercentage=75.0), andJAVA_OPTSper instance size plus the tmpfs implication in the README.Happy to PR. Context: surfaced while test-driving #1.