Environment
- Comet version: latest (ghcr.io/g0ldyy/comet:latest)
- Database: PostgreSQL 16 (not SQLite)
- Deployment: Docker Compose, self-hosted (Raspberry Pi 4, 1.8GB RAM)
- CometNet: enabled, ~30+ active peers, database populated with thousands of torrents received via gossip (single announces of 500+ torrents observed)
Bug description
The /admin/api/metrics endpoint (used by the "Metrics" tab in the Admin Dashboard) takes an extremely long time to respond once the local database has accumulated a large number of torrents via CometNet gossip. Confirmed in logs:
GET /admin/api/metrics - 200 - 423.12s
The request eventually returns 200, but takes 423 seconds (~7 minutes). The dashboard/frontend gives up waiting long before that, so the Metrics tab displays 0 for Total Torrents, Unique Searches, and Active Scrapers, even though the database clearly has data (searches and CometNet gossip work fine).
Worse: it appears to crash the main worker. In the logs, a Gunicorn worker exits with code 1 right around the same time the slow metrics query is running/completing:
[ERROR] Worker (pid:561) exited with code 1
This has been reproduced multiple times, always correlated with a call to /admin/api/metrics. Checked dmesg for OOM kills — none found, so this does not appear to be a memory issue, but rather the query itself (possibly blocking the event loop or timing out) causing the worker to be killed/restarted.
Steps to reproduce
- Run Comet with CometNet enabled and Postgres as the database backend
- Let CometNet accumulate a large number of torrents via gossip over several days/weeks
- Open the Admin Dashboard → Metrics tab
- Observe: Metrics show 0, and shortly after, a worker crash appears in the logs
Expected behavior
The metrics query should be reasonably fast (indexed/aggregated) regardless of database size, or at minimum should not block/crash the worker.
Suspicion
Possibly an unindexed or full-table-scan query in the metrics aggregation code that doesn't scale well with CometNet-populated databases, and/or a Postgres-specific query performance issue (vs. SQLite) worth checking.
Environment
Bug description
The
/admin/api/metricsendpoint (used by the "Metrics" tab in the Admin Dashboard) takes an extremely long time to respond once the local database has accumulated a large number of torrents via CometNet gossip. Confirmed in logs:GET /admin/api/metrics - 200 - 423.12s
The request eventually returns 200, but takes 423 seconds (~7 minutes). The dashboard/frontend gives up waiting long before that, so the Metrics tab displays 0 for Total Torrents, Unique Searches, and Active Scrapers, even though the database clearly has data (searches and CometNet gossip work fine).
Worse: it appears to crash the main worker. In the logs, a Gunicorn worker exits with code 1 right around the same time the slow metrics query is running/completing:
[ERROR] Worker (pid:561) exited with code 1
This has been reproduced multiple times, always correlated with a call to /admin/api/metrics. Checked
dmesgfor OOM kills — none found, so this does not appear to be a memory issue, but rather the query itself (possibly blocking the event loop or timing out) causing the worker to be killed/restarted.Steps to reproduce
Expected behavior
The metrics query should be reasonably fast (indexed/aggregated) regardless of database size, or at minimum should not block/crash the worker.
Suspicion
Possibly an unindexed or full-table-scan query in the metrics aggregation code that doesn't scale well with CometNet-populated databases, and/or a Postgres-specific query performance issue (vs. SQLite) worth checking.