No description
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. |
||
|---|---|---|
| .forgejo/workflows | ||
| .github | ||
| assets | ||
| bin | ||
| config | ||
| docs | ||
| k8s | ||
| lib | ||
| lib_ml | ||
| notebooks | ||
| priv | ||
| rel | ||
| rust/prop_grid_rs | ||
| scripts | ||
| test | ||
| vendor | ||
| .credo.exs | ||
| .dockerignore | ||
| .formatter.exs | ||
| .gitignore | ||
| .tool-versions | ||
| AGENTS.md | ||
| algo.md | ||
| app.json | ||
| bugs.md | ||
| CLAUDE.md | ||
| Dockerfile | ||
| Dockerfile.base | ||
| elevation.md | ||
| LICENSE | ||
| mix.exs | ||
| mix.lock | ||
| prediction.md | ||
| README.md | ||
| tail_logs.sh | ||
| updates.md | ||
Microwaveprop
To start your Phoenix server:
- Run
mix setupto install and setup dependencies - Start Phoenix endpoint with
mix phx.serveror inside IEx withiex -S mix phx.server
Now you can visit localhost:4000 from your browser.
Ready to run in production? Please check our deployment guides.
Learn more
- Official website: https://www.phoenixframework.org/
- Guides: https://hexdocs.pm/phoenix/overview.html
- Docs: https://hexdocs.pm/phoenix
- Forum: https://elixirforum.com/c/phoenix-forum
- Source: https://github.com/phoenixframework/phoenix