Understanding memory usage

Understanding memory usage

Qdrant operates with two types of memory:

• Resident memory (aka RSSAnon) - memory used for internal data structures like the ID tracker, plus components that stay fully in RAM. On Qdrant 1.19 or newer this is controlled per-component with memory: pinned (e.g. quantized vectors, payload indexes); see memory tier legacy settings for deployments on version 1.18 or older.

• OS page cache - memory used for caching disk reads, which can be released when needed. Original vectors are normally stored in page cache, so the service won't crash if RAM is full, but performance may degrade. On Qdrant 1.19 or newer this corresponds to memory: cached (pre-warmed into page cache at startup) or memory: cold (lazy disk reads, not pre-warmed); on 1.18 or older it's controlled via the on_disk boolean on vectors, HNSW config, sparse vector index, and payload index. See Memory Tiers docs (available on 1.19+).

It is normal for the OS page cache to occupy all available RAM, but if resident memory is above 80% of total RAM, it is a sign of a problem.

Memory usage monitoring

• Qdrant exposes memory usage through the /metrics endpoint. See Monitoring docs.

How much memory is needed for Qdrant?

Optimal memory usage depends on the use case.

• For regular search scenarios, general guidelines are provided in the Capacity planning docs.

For a detailed breakdown of memory usage at large scale, see Large scale memory usage example.

Payload indexes and HNSW graph also require memory, along with vectors themselves, so it's important to consider them in calculations.

Additionally, Qdrant requires some extra memory for optimizations. During optimization, optimized segments are fully loaded into RAM, so it is important to leave enough headroom. The larger max_segment_size is, the more headroom is needed.

When to put HNSW index on disk

Putting frequently used components (such as HNSW index) on disk might cause significant performance degradation. On Qdrant 1.19 or newer this is set with memory: cold in hnsw_config; on 1.18 or older with hnsw_config.on_disk: true. There are some scenarios, however, when it can be a good option:

• Deployments with low latency disks - local NVMe or similar.
• Multi-tenant deployments, where only a subset of tenants is frequently accessed, so that only a fraction of data & index is loaded in RAM at a time.
• For deployments with inline storage enabled.