Fix PostgreSQL shared_buffers (was 96GB on 32GB host)

timescaledb-tune had configured shared_buffers=96396MB — three times the
physical RAM of the host. The kernel was giving PG everything it could
(~30GB of shared memory), leaving <100MB free for everything else.
This caused the OS page cache to be constantly evicted, every query to
hit disk, and telemetry writes to balloon to 20+ seconds.

New settings (standard 25/50 rule for 32GB):
- shared_buffers: 96GB → 8GB
- effective_cache_size: 16GB (query planner hint)
- work_mem: 16MB per operation
- maintenance_work_mem: 1GB (for vacuum/index)
- max_wal_size: 4GB

Requires a db container restart to take effect.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

docker-compose.yml

@@ -41,6 +41,19 @@ services:
   db:
     image: timescale/timescaledb:2.19.3-pg14
     container_name: dereth-db
+    # Override PostgreSQL memory settings. The default timescaledb-tune values
+    # targeted a much larger machine — shared_buffers was set to 96GB on a
+    # 32GB host, causing the kernel to swap-thrash and leaving <100MB free.
+    # These values follow the standard recommendation: shared_buffers ~25% RAM,
+    # effective_cache_size ~50% RAM, work_mem modest to avoid multiplication
+    # blow-up across the ~20-connection pool.
+    command: >
+      postgres
+      -c shared_buffers=8GB
+      -c effective_cache_size=16GB
+      -c work_mem=16MB
+      -c maintenance_work_mem=1GB
+      -c max_wal_size=4GB
     environment:
       POSTGRES_DB: dereth
       POSTGRES_USER: postgres