Highlights
Runs on a 256 MB Raspberry Pi
The trail update needed ~1.1 GB and was OOM-killed on small boxes, and the sensor needed 153 MB, twice that across a trail reload. Measured in a 221 MB container with no swap, against the full 1.9M-trail set:
| 3.4 | 3.5 | |
|---|---|---|
| trail update (peak) | 1,144 MB | 69 MB |
| sensor (steady) | 153 MB | 32 MB |
| sensor during a reload | 304 MB | 58 MB |
- The static trail set is streamed from its cache instead of being held in memory whole: the update peaks at ~255 MB on every machine now, not 1.1 GB.
- Below 768 MB available (container and systemd limits included), the merge spills to a SQLite file. Same code, byte-identical
trails.csv. UPDATE_SERVERdownloads stream to disk.- The sensor's trail store is file-backed (reclaimable page cache instead of heap); lookups measured the same speed.
- Hosts with under 1 GB get a capture ring of 10% of RAM instead of 64 MB.
Thanks to @gpaterson for the report and the idea (#19641).
32-bit ARM sensor
New static ARMv6 build, arm-unknown-linux-musleabihf: one binary for every 32-bit Raspberry Pi, Pi 1 and Zero included, on Raspberry Pi OS, DietPi or Alpine. install.sh picks it automatically, also on a 64-bit kernel with a 32-bit userland. Each release replays a trail through it on an emulated Pi 1 CPU and refuses to publish a binary that does not detect it.
Also
- Basic sensor status on the dashboard (#19627).
- Windows installer (
install.ps1); NetBSD and OpenBSD added to the tested platform matrix. - Workflows and shell scripts are linted in CI.
Full list in CHANGELOG.
Full Changelog: 3.4...3.5