fix(vespa-config): increased heap size for vespa

[SahilKumar000]

Description

Testing

Additional Notes

Summary by CodeRabbit

• Refactor

  • Reorganized service configuration to clearly separate container and content nodes.
  • Standardized JVM memory settings for the container.

• Chores

  • Removed explicit JVM arguments for the main query container in deployment configuration.
  • Set container JVM allocated memory to 15%.
  • Reduced thread pool max threads from 64 to 8.

• Impact

  • Streamlined deployment configuration and more predictable resource usage.
  • No changes to visible features or behavior.

[coderabbitai]

Walkthrough

Removes explicit JVM args for the main query container in docker-compose. Restructures Vespa services.xml by moving container node definitions, adding a nodes block, setting jvm allocated-memory to 15%, specifying a node hostalias, and reducing container threadpool maxthreads from 64 to 8. No functional control-flow changes noted.

Changes

Cohort / File(s)	Summary of Changes
Deployment compose (container JVM args) deployment/portable/docker-compose.infrastructure.yml	Removed VESPA_CONTAINER_JVMARGS entry for the main query container, eliminating the prior 4g–8g JVM settings; other services unchanged.
Vespa services configuration server/vespa/services.xml	Reorganized container configuration: introduced <nodes> under <container>, added <jvm allocated-memory='15%'/>, added <node hostalias='node1'/>, and reduced <http><server>...<threadpool maxthreads='8'/> from 64. Document and tuning elements retained but repositioned.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• refactor(memory): raise RAM and heap limits for Vespa services #1102 — Also modifies main query container JVM arguments in compose (changes to 10g–20g), overlapping configuration surface.
• perf(memory): rebalance JVM heap sizes across Vespa production container #1085 — Introduced the 4g–8g VESPA_CONTAINER_JVMARGS later removed here, directly related to this reversal.

Suggested reviewers

• shivamashtikar
• zereraz
• kalpadhwaryu
• devesh-juspay
• junaid-shirur

Poem

Hop hop, I tweak with gentle care,
Trim JVM clouds, make configs fair.
Threads now eight, memories align,
Nodes stand tall in tidy line.
A whisker’s nudge, a nimble art—
Deployments hum, a lighter heart.
(\_/)
(^‿^) 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Title Check	⚠️ Warning	The title claims a heap size increase for Vespa, but the changes actually remove the fixed 4g–8g JVM arguments and introduce a dynamic <jvm allocated-memory='15%'/> setting rather than raising the heap size. There is no explicit increase in heap allocation in the diff. This makes the title misleading and not reflective of the primary change.	Please update the title to accurately describe the memory configuration change, for example “refactor(vespa-config): remove fixed JVM heap settings and add dynamic allocated-memory configuration,” so that it reflects the removal of VESPA_CONTAINER_JVMARGS and the new allocated-memory approach.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/vespa-config

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Summary of Changes

Hello @SahilKumar000, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refines the resource allocation for Vespa services by adjusting JVM memory settings and optimizing container thread pool configurations. The changes aim to improve the stability and performance of the Vespa deployment by providing a more explicit memory allocation strategy and reducing potential CPU contention.

Highlights

• Vespa Container Memory Allocation: A new JVM memory allocation setting has been introduced in services.xml for the Vespa container, explicitly allocating 15% of available memory.
• Thread Pool Optimization: The maximum threads for the container's handler thread pool in services.xml have been reduced from 64 to 8, aiming to optimize CPU load and reduce contention.
• Docker Compose JVM Args Refinement: Explicit VESPA_CONTAINER_JVMARGS for the main query container have been removed from docker-compose.infrastructure.yml, streamlining JVM argument management.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the Vespa configuration to increase the container heap size by switching from an environment variable (VESPA_CONTAINER_JVMARGS) to a percentage-based allocation in services.xml. This is a good approach for managing memory. My review includes a few suggestions to improve code style and consistency in services.xml. Also, please note that docker-compose.infrastructure-cpu.yml still contains the old VESPA_CONTAINER_JVMARGS setting; you may want to remove it for consistency across configurations.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (3)

server/vespa/services.xml (3)

10-13: Threadpool maxthreads=8 may throttle request concurrency

container.handler.threadpool.maxthreads=8 caps concurrent HTTP handler work (incl. /document/v1 and search). With searchnode.requestthreads.search=32 and summary=8, this can become the bottleneck.

• Verify latency/throughput under expected load; consider a higher cap (e.g., 32) if CPU allows.

---

24-52: Memory headroom: container heap + proton limits could approach 100%

• Proton resource-limits.memory=0.85 controls internal throttling; combined with a larger container heap, the node may run tight on memory.
• Ensure container memory limits are set in Docker/infra and that combined process footprints leave OS headroom (swap off recommended).

Action: Validate effective process RSS at steady state and adjust either container heap percent or proton memory limit accordingly.

---

73-75: Both container and content pinned to hostalias 'node1'

This is fine for single-node/dev. If targeting multi-node/HA later, plan to separate hostaliases (or use counts) to avoid co-scheduling and single-point-of-failure.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 35d1b9c and d7d2d44.

📒 Files selected for processing (2)

• deployment/portable/docker-compose.infrastructure.yml (0 hunks)
• server/vespa/services.xml (1 hunks)

💤 Files with no reviewable changes (1)

• deployment/portable/docker-compose.infrastructure.yml

🔇 Additional comments (2)

server/vespa/services.xml (2)

18-21: Align PR title with actual change magnitude

Title says “increased heap size”, but allocated-memory='15%' might be lower than previous JVM args (removed in docker-compose). Please quantify before/after Xmx to avoid confusion and document in the PR.

---

18-21: Confirm JVM heap sizing and reserved memory

• <jvm allocated-memory="15%"> is valid under <container><nodes> and sets the JVM max heap (-Xmx) to 15% of available memory; it does not set -Xms.
• To reserve headroom for native/direct buffer allocations and the OS, consider adding <jvm reserved-memory="…"/>.
• Verify at runtime (startup logs or vespa-model-inspect) that -Xmx is applied as expected and that any Docker/cgroup memory limits are accounted for.