Found while auditing pod memory: :weather_grid_cache is by far the largest ETS table (~32 MiB compressed per entry, vs ~2 MiB/entry for ScoreCache) because each cell is a 22-field weather row instead of a scalar score. Cap of 24 meant the cache could hoard up to ~768 MiB on a single pod, and hot pods sit at 3-5 GiB against a 6 GiB limit — most of that headroom belongs to GridCache. The cap was sized for 'analysis + 18 forecasts + stragglers' but the real access pattern is current-hour + a short forward scrub. Beyond that, fall back to ScalarFile.read_bounds (sub-100 ms per file) instead of permanently parking ~500 MiB on data nobody looks at. Worst-case GridCache spend drops 768 MiB → 256 MiB. Steady-state win is smaller (most pods don't fill all 24 slots), but bounds the tail. |
||
|---|---|---|
| .. | ||
| microwaveprop | ||
| microwaveprop_web | ||
| mix/tasks | ||
| microwaveprop.ex | ||
| microwaveprop_web.ex | ||