# Find queries with high memory usage

Rank terminal events by peak accounted memory to find requests that deserve inspection. This metric describes SQL memory for the request; it is not the process's full resident memory.

```sql
SELECT query_id, peak_memory_usage, query_duration_ms, query
FROM system.query_log
WHERE type = 'QueryFinish'
ORDER BY peak_memory_usage DESC
LIMIT 20
FORMAT json_each_row;
```

At terminal events, `memory_usage` and `peak_memory_usage` both report the peak accounted value. For a request still running, `system.processes` exposes current and peak values. Measurements remain available when `max_memory_usage` is zero.

## Reduce the work first

Inspect wide projections, large grouped results, joins and unbounded sorts. Select only required columns, filter the input to a representative range, and consider whether the consumer actually needs every returned row. A smaller result can also reduce buffered response memory and response-byte pressure.

Repeat the same query on the same data before comparing a change. If a memory ceiling is necessary, choose it from measured workloads and remember that a saved database value cannot relax a stricter server ceiling. A higher limit alone does not explain why usage grew.

See [memory limits](https://coordinatordb.com/docs/reference/settings/session-settings/max-memory-usage), [system.processes](https://coordinatordb.com/docs/reference/system-tables/processes) and [EXPLAIN](https://coordinatordb.com/docs/reference/statements/explain).