code index load all project index into RAM

[NaccOll]

App Version

v3.24.0

API Provider

OpenAI Compatible

Model Used

Qwen/Qwen3-Embedding-8B and Qwen/Qwen3-Embedding-0.6B

Roo Code Task Links (Optional)

No response

🔁 Steps to Reproduce

1. Set up Qdrant using the provided docker-compose.yaml
2. Configure RooCode to use Qdrant for code indexing
3. Index a codebase with multiple project. eg. RooCode (~70k text blocks)
4. Observe memory usage in Docker/System Monitor

💥 Outcome Summary

Expected: Qdrant should manage memory efficiently, not loading all indexes into RAM
Actual: Qdrant loads all vector indexes into memory, consuming:

• 1.5GB for RooCode with Qwen3-Embedding-8B (>10GB for multiple projects)
• 900MB for RooCode with Qwen3-Embedding-0.6B (>5GB for multiple projects)
• Scaling linearly with number of indexed projects

📄 Relevant Logs or Errors (Optional)

System: Windows 10/11
Docker: Desktop 4.40.0
Memory: 32G RAM

[roomote]

I'm here to help out the maintainers and am going to see if I can fix the issue or at least get close enough to be helpful! I'll investigate the Qdrant memory usage issue with code indexing.

[roomote]

I have submitted PR #6264 to fix this issue: #6264

Summary of Changes

The PR configures Qdrant to use on-disk storage instead of loading all indexes into RAM, which should significantly reduce memory consumption.

Key changes:

• Modified QdrantVectorStore to accept memory optimization configuration
• Set on_disk: true for both vectors and HNSW indexes by default
• Added memory-mapped file support for segments larger than 50k vectors
• Reduced HNSW search parameter (ef) from 128 to 64 for better memory efficiency
• Added configuration options to allow users to customize memory settings if needed

Expected Impact:

• Memory usage should be significantly reduced as indexes are stored on disk
• The OS will manage memory through memory-mapped files, loading only what is needed
• Search performance may have a slight impact, but should still be acceptable for most use cases
• Users can adjust settings if they need to optimize for performance over memory

The implementation maintains backward compatibility while defaulting to memory-efficient settings.

[daniel-lxs]

@roomote-agent Create a new PR with the implementations of the previous #6264 but save the constants on a relevant place in @roo-code/types.

Don't reduce the HNSW search parameter initially on the PR so that I can test late if reducing this affects the results negatively.

[roomote]

I understand the request. I will create a new PR that implements the Qdrant memory optimization from PR #6264, but with the following changes:

1. Move the constants to a relevant place in @roo-code/types package
2. Keep the HNSW search parameter (ef) at the original value (128) instead of reducing it to 64, so you can test later if reducing it affects results negatively

I will start working on this implementation now.