What happened?
Once the Search page is open, the browser tab's memory grows without limit until the machine runs out of RAM and freezes. The amount of data on the page makes no difference.
Clean reproduction on a freshly rebooted machine, measured in Firefox about:processes. HyperDX was the only tab with its own content process:
| Time |
HyperDX tab (http://localhost) memory |
Tab CPU |
| 19:10 |
290 MB |
0.05% |
| 19:12 |
523 MB |
8% |
| 19:13 |
1 GB |
64% |
| 19:14 |
1 GB |
3.3% |
| 19:16 |
1.2 GB (RSS from ps, tab open for 6 min) |
13% |
At the same time, the whole selected time range (last 12 h) contained 281 log rows, 176 KiB of log bodies in total, with only a few new rows arriving per minute.
Earlier the same day, the tab was left open for ~3 hours. It reached 5.6 GB resident (73% of the VM's 8 GB), filled swap, pushed load average to 100–140, and made the VM unresponsive; it needed a hard reset. This happened twice.
The HyperDX backend is not the problem. Resident memory inside the all-in-one container during the freeze: clickhouse-server 281 MB, api 105 MB, next-server 47 MB, mongod 39 MB, otel collector 35 MB.
Expected: tab memory stays roughly flat, proportional to the rows kept on screen, no matter how long the page stays open.
Possibly related: #764 ("fix: Optimize live tail memory"), which changed DBSearchPage.tsx / useOffsetPaginatedQuery.tsx. This may be a regression.
Steps to reproduce
- Run
docker.hyperdx.io/hyperdx/hyperdx-all-in-one:2.39.1 and send it a low stream of logs over OTLP gRPC (a few short JSON log lines per minute).
- Open Search with source Logs, time range Last 12 hours, and Live Tail on (default settings).
- Open
about:processes in another tab and watch the HyperDX tab: it climbs by hundreds of MB per minute and never comes back down.
How are you running HyperDX?
- All-in-one image
docker.hyperdx.io/hyperdx/hyperdx-all-in-one:2.39.1, the current latest, under Docker Compose
- Host: Rocky Linux 10.2 VM on Proxmox, 8 vCPU, 8 GB RAM, Docker 29.8.1
- Built-in ClickHouse, no external database
Where does it show up?
- UI → Search page (Logs source, Live Tail on)
- Browser: Firefox 140.15.0esr on Linux (XFCE, software rendering, no GPU)
Logs
- No errors in the API or collector logs.
- Screenshots of
about:processes at 19:10, 19:12, 19:13 and 19:14 are attached.
- Browser console:
<paste anything relevant, or "nothing unusual">
What happened?
Once the Search page is open, the browser tab's memory grows without limit until the machine runs out of RAM and freezes. The amount of data on the page makes no difference.
Clean reproduction on a freshly rebooted machine, measured in Firefox
about:processes. HyperDX was the only tab with its own content process:http://localhost) memoryps, tab open for 6 min)At the same time, the whole selected time range (last 12 h) contained 281 log rows, 176 KiB of log bodies in total, with only a few new rows arriving per minute.
Earlier the same day, the tab was left open for ~3 hours. It reached 5.6 GB resident (73% of the VM's 8 GB), filled swap, pushed load average to 100–140, and made the VM unresponsive; it needed a hard reset. This happened twice.
The HyperDX backend is not the problem. Resident memory inside the all-in-one container during the freeze: clickhouse-server 281 MB, api 105 MB, next-server 47 MB, mongod 39 MB, otel collector 35 MB.
Expected: tab memory stays roughly flat, proportional to the rows kept on screen, no matter how long the page stays open.
Possibly related: #764 ("fix: Optimize live tail memory"), which changed
DBSearchPage.tsx/useOffsetPaginatedQuery.tsx. This may be a regression.Steps to reproduce
docker.hyperdx.io/hyperdx/hyperdx-all-in-one:2.39.1and send it a low stream of logs over OTLP gRPC (a few short JSON log lines per minute).about:processesin another tab and watch the HyperDX tab: it climbs by hundreds of MB per minute and never comes back down.How are you running HyperDX?
docker.hyperdx.io/hyperdx/hyperdx-all-in-one:2.39.1, the currentlatest, under Docker ComposeWhere does it show up?
Logs
about:processesat 19:10, 19:12, 19:13 and 19:14 are attached.<paste anything relevant, or "nothing unusual">