How do you troubleshoot out-of-memory errors when loading a large Milvus collection?

An out-of-memory error during collection loading almost always comes down to the loaded data (segments plus their indexes) exceeding the available memory across the Query Nodes assigned to hold it, and the fix generally involves either reducing what needs to be loaded or increasing available capacity.

1. Check the index type's memory footprint - HNSW's graph structure is memory-heavier than quantized options like IVF_PQ or a disk-based option like DiskANN; switching index type can substantially reduce memory requirements for the same data volume.
2. Check replica count - each additional replica requires its own full copy of the loaded data; reducing replica count (or only increasing it once base loading succeeds) frees up memory during troubleshooting.
3. Check whether the whole collection needs to be loaded at once - loading only the specific partitions actually needed for current workloads, rather than the entire collection, reduces the memory footprint for that load operation.
4. Check Query Node resource allocation - confirm the Query Nodes assigned to this collection actually have the memory limits/requests configured to accommodate the expected data volume, especially in Kubernetes deployments where resource limits are explicitly set.
5. Consider tiered storage or mmap-based loading - where available, loading segments via memory-mapped files rather than requiring everything to be fully memory-resident can reduce peak memory usage, trading some search latency for a smaller memory footprint.
6. Scale out Query Node count - if the data genuinely needs to be fully loaded and none of the above trade-offs are acceptable, adding more Query Nodes spreads the same total data across more machines, each needing less memory individually.

The right fix depends on which constraint is actually binding: a memory-constrained environment that can't easily add hardware benefits most from switching to a lighter-weight index or scoping the load to fewer partitions, while a workload that genuinely needs everything loaded and searchable at full recall is better served by scaling out Query Node capacity instead.