---
title: Vector memory pressure
description: Describes what AutoOps detects and surfaces with the Vector memory pressure insight: HNSW dense-vector graphs use off-heap RAM on the node.
url: https://www.elastic.co/docs/reference/autoops-insights/elasticsearch/vector_memory_pressure
products:
  - Elastic Cloud Enterprise
  - Elastic Cloud Hosted
  - Elastic Cloud on Kubernetes
  - Elasticsearch
applies_to:
  - Elastic Cloud Hosted: Generally available
  - Elastic Cloud on Kubernetes: Generally available
  - Elastic Cloud Enterprise: Generally available
  - Self-managed Elastic deployments: Generally available
---

# Vector memory pressure
HNSW dense-vector graphs use off-heap RAM on the node. The cushion between available memory and that footprint is tight or shrinking, with elevated heap and other load signals.
<note>
  For a complete list of insights, refer to [AutoOps insights](https://www.elastic.co/docs/reference/autoops-insights/elasticsearch).
</note>


## Insight details


| Field     | Value                               |
|-----------|-------------------------------------|
| Component | Elasticsearch                       |
| Severity  | High                                |
| Scope     | Node                                |
| Domains   | performance, search, memory, vector |


## Example: What you might see in AutoOps

The following is an example of what you might see when this insight is triggered. Real insights use live data and links from your deployment or cluster.

### Vector memory pressure on es-data-01


#### What was detected

HNSW off-heap vector footprint leaves little free RAM. Affected node(s): `es-data-01` and `es-data-02`.
The node is near its off-heap memory limit.
Heap usage is elevated due to off-heap memory pressure spilling over.
Both search/index latency and disk read activity are elevated; the HNSW graph might start paging.

#### Recommendations

<note>
  AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
</note>

<dropdown title="Reduce vector footprint">
  **Condition**: Shown when vector footprint is growing, off-heap headroom is escaping, or the compression regime is tight.Reduce HNSW off-heap memory on this node where quality allows: use fewer dimensions, quantized or compressed vector mappings, delete or archive unneeded data, split indices, or reindex with a leaner mapping. See [BBQ HNSW](https://docs-edge.elastic.dev/docs/reference/elasticsearch/mapping-reference/bbq#bbq-hnsw) for options. Validate recall and latency against your SLOs after changes.
</dropdown>

<dropdown title="Switch to DiskBBQ vector index">
  **Condition**: Shown when JVM heap is elevated above the node's 24-hour median and this event is active.When HNSW indices keep the full graph in physical memory, switch to [DiskBBQ](https://docs-edge.elastic.dev/docs/reference/elasticsearch/mapping-reference/bbq#bbq-disk) to store most of the graph on disk instead of RAM. Expect different recall and latency versus HNSW; test before changing production mappings.
</dropdown>

<dropdown title="Upgrade node hardware">
  **Condition**: Shown when off-heap headroom is escaping or the compression regime is tight.This node is under memory pressure. Reduce heap size to less than 31 GB.
</dropdown>

<dropdown title="Tune kNN query load">
  **Condition**: Shown when search latency is elevated relative to baseline without a matching rate increase.Reduce kNN load when search latency is high: lower `num_candidates`, reduce concurrent query rate or client fan-out, and narrow `knn` or `script_score` usage where possible. Re-check latency and error rates after changes.
</dropdown>

<dropdown title="Enable and review search slow logs">
  **Condition**: Shown when search or index latency is elevated.Enable search slow logs with the action below, then review the slow log to find expensive queries. See [Slow logs](https://docs-edge.elastic.dev/docs/deploy-manage/monitor/logging-configuration/slow-logs) for configuration details.
  ```json

  {
    "index.search.slowlog.threshold.query.warn": "10s",
    "index.search.slowlog.threshold.query.info": "5s",
    "index.search.slowlog.threshold.query.debug": "2s",
    "index.search.slowlog.threshold.query.trace": "500ms",
    "index.search.slowlog.threshold.fetch.warn": "1s",
    "index.search.slowlog.threshold.fetch.info": "800ms",
    "index.search.slowlog.threshold.fetch.debug": "500ms",
    "index.search.slowlog.threshold.fetch.trace": "200ms"
  }
  ```

  <note>
    Requires the `manage` index privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
  </note>
</dropdown>

<dropdown title="Increase heap on node">
  **Condition**: Shown when configured max heap and OS memory metrics are available for the node.Current max heap is 30 GB. Set JVM heap to 31 GB (suitable for this machine type), then restart the node.
</dropdown>

<dropdown title="Tune circuit breakers">
  **Condition**: Shown when circuit breaker pressure is elevated and heap, search or index latency, or disk read stress is also present.Tune circuit breaker limits to prevent out-of-memory errors while allowing legitimate query and aggregation load. Adjust parent, fielddata, and request breaker settings in `elasticsearch.yml` based on your heap size and workload.
</dropdown>


#### Background and impact

Dense-vector fields that use HNSW keep approximate nearest-neighbor graphs primarily in physical memory, off the Java heap. A node can look healthy on heap charts while vector graphs still consume a large share of RAM.
When that off-heap footprint grows into a tight memory band, kNN and dense-vector workloads compete with indexing, search, and disk I/O on the same node. Latency can rise, thread pools can back up, and circuit breakers might trip if pressure continues.

## Guide

[Approximate knn search](https://docs-edge.elastic.dev/docs/deploy-manage/production-guidance/optimize-performance/approximate-knn-search)