Beelink ME mini PC NAS N200 proxmox test
Hello there!
I've been running my homelab on a Ryzen 7 5825U box (8c/16t) for a while, and it's massively overkill for what's actually on it - a dozen lightweight LXCs and a couple of VMs that mostly just idle. I picked up a cheap Beelink N200 mini PC and wanted to know : could this thing realistically take over the fleet ? So instead of guessing, I cloned the whole setup onto it and tried to break it.
Writing this up because I didn't find what I expected. (I used Claude for my testing and for this message, english is not my native language).
TL;DR: I cloned my whole prod homelab fleet (10 LXCs + 2 VMs, 21 vCores total) onto an Intel N200 mini PC (4 cores, no hyperthreading, 12GB RAM) and threw everything at it — simultaneous boot storm, staged CPU stress, real service load (git/sync/VPN/cameras), and finally every single guest pegged at 100% CPU at once (5.25:1 core oversubscription). No breaking point: RAM and swap never budged, the host stayed responsive throughout, only management-plane latency roughly doubled under worst-case load and recovered instantly once the load stopped. Caveat: this fleet is mostly idle/I/O-bound in real life, so this isn't proof a CPU-hungry fleet would fare the same.
The test box
- CPU: Intel N200 — 4 physical cores, no hyperthreading, up to 3.7GHz turbo (this is the whole ballgame here, it's the only real constraint on this machine)
- RAM: 12GB total (~11.7GB usable), 7GB swap configured
- Storage:
- A 58GB eMMC on the board — present, but I'm not using it for anything
- A 256GB NVMe (Linkmore XE-300 Lite) as the boot/system drive running Proxmox itself
- 2x 1TB WD Green SN350 NVMe drives, concatenated/striped via ZFS (no mirror, no redundancy — pure stripe) giving ~1.81TB usable for VM/LXC storage. Yes, if one of those two dies I lose everything on it. Known tradeoff, this pool is for disposable test data, not anything I'd cry over.
- Networking: one physical NIC in use (the other two ports are unpopulated on this box)
- Proxmox VE 9.2.10, kernel 7.0.14
Setting up a fair test
A few things I made sure to get right before touching any numbers:
- Fully isolated test network. I didn't want test VMs anywhere near my real LAN, so I created a second bridge with no physical port attached at all (invisible from the real network), its own private subnet, and NAT out through the host for internet access when needed. New MAC addresses for everything — never reused anything from the production fleet's config.
- Dedicated storage. All test VMs/LXCs live on the ZFS stripe, not mixed in with the Proxmox boot disk.
- Cloned the real fleet's specs, not just made something up. I pulled the actual
.conffiles off my production box and recreated every guest with identical vCPU count, RAM, and swap allocations. 10 LXCs + 2 VMs, mirroring cores/RAM 1:1. The two VMs (a Python scraper and a Home Assistant OS instance in prod) were recreated as lightweight cloud-init shells with the same core/RAM allocation rather than the real disk images — I wasn't trying to test HAOS itself, just how the hypervisor schedules that much CPU demand.
Total allocated: 21 vCores across 4 physical cores — a 5.25:1 oversubscription ratio if literally everything asked for CPU at once. On the source 8c/16t machine the equivalent ratio is only about 2:1. This is the number that made me expect trouble.
For context, my actual production box (the 5825U) sits at a load average of ~0.15-0.18 running this exact fleet in real life — it's an almost entirely idle, I/O-bound workload (DNS, VPN, git server, password manager, camera NVR, home automation, sync). Only one container (a WireGuard VPN gateway) ever peaks above 3% CPU. So the open question wasn't "is this fleet heavy," it's "does a 4-core box choke on the scheduling overhead of that many guests even when each one individually barely does anything."
What I actually ran
1. Idle boot storm
Started all 12 guests simultaneously (cold LXC boot + VM cloud-init). Load average spiked to 5.77 transiently, then dropped below 1.5 within about 90 seconds and settled around 1.1-1.3. RAM landed around 5GB/11.7GB used. Zero swap touched. All 12 guests came up healthy and pingable.
2. Staged CPU stress (synthetic, stress-ng)
Went up in careful steps rather than nuking everything at once:
- 3 lightweight LXCs (4 vCores) at 80% load → load avg peaked at 1.91, host fully responsive.
- All 10 LXCs together (13 vCores) at 80% → peaked at 6.71, still totally responsive, no swap.
- The two heavy VMs (4 vCores each, the "scraper" and "HAOS" shells) run solo at 100% each, to get a clean baseline throughput number.
- Then both together at 100% simultaneously — 8 vCores fighting over 4 physical cores, a 2:1 squeeze:
- Load avg peaked at a fairly mild 4.83.
- Measured CPU throughput (stress-ng bogo-ops/sec) for each VM dropped to almost exactly half its solo number — the scheduler split the 4 cores 50/50 between them, cleanly, with no thrashing or starvation.
- Host stayed fully responsive the entire time (verified by timing a monitoring loop against wall-clock — zero scheduling lag detected).
I expected running two "needs 4 cores" VMs on a 4-core box simultaneously to be ugly. It wasn't — it degrades exactly the way a well-behaved CFS scheduler should: everyone gets a fair, proportional slice instead of anyone stalling.
3. Realistic I/O burst (not synthetic CPU load — actual services doing actual work)
I didn't want to only test synthetic CPU spin loops, so I installed the real lightweight services from the fleet and hit them concurrently with real workloads for 30 seconds:
- Git: 5 parallel
git cloneoperations against a real self-hosted Gitea instance (~91MB repo each) - File sync: added 500MB of fresh data to a Syncthing instance and triggered a real rescan/hash pass
- VPN throughput: a live WireGuard tunnel pushed through
iperf3for the full 30s - Camera/NVR: 4 concurrent RTSP viewers pulling a live H.264 stream from a
mediamtxinstance
All four running at once:
- 5/5 git clones succeeded cleanly
- WireGuard sustained ~1.9 Gbit/s the entire time, tunnel never hiccupped
- All 4 camera streams ran the full 30 seconds without a dropped connection
- Syncthing indexed everything with zero errors
- Load average peaked around 5.6, RAM stayed flat around 5.5-6GB, swap stayed at 0
4. The big one — ramping every single guest to 100% CPU at once
This is the test I actually built this whole environment for: find the breaking point. Instead of slamming all 21 vCores on at once, I added load one guest at a time, 15 seconds apart, watching the trend the whole way, so I could stop early if things went sideways. Order: the 10 LXCs one by one (up to 13 vCores), then the "HAOS" VM (17 vCores), then the "scraper" VM last (the full 21 vCores on 4 physical cores).
I also added a second metric beyond load average this time: I timed how long pct list (a basic Proxmox management call) took to respond, as a proxy for "is the hypervisor itself still snappy," since load average alone can be a misleading, laggy number under heavy oversubscription.
Results at full 21-vCore load (5.25:1 oversubscription, every single guest pegged at 100%):
- Load average (1-min) peaked at 18.34
- Management-plane latency (
pct list) went from a baseline of ~900ms to a peak of ~1.9 seconds — roughly 2x slower, but it never hung, never timed out, it just got proportionally slower - RAM stayed rock-stable the entire time, ~5.2-5.5GB used out of 11.7GB
- Swap never moved off 0MB — not even a single megabyte, even at the absolute worst-case CPU contention this fleet could produce
- The moment I killed the stress load, management latency snapped back to baseline (~900ms) instantly, while load average did its normal slow exponential decay afterward
- Verified clean teardown — zero stray processes left anywhere, all 12 guests still healthy
Verdict
I went in expecting to find a wall, especially once I calculated the 5.25:1 core oversubscription ratio (vs. ~2:1 on the source hardware). I didn't find one. Even at the worst-case scenario — every guest in the fleet pegged at 100% CPU simultaneously, more than 5x the available physical cores — the little N200 degraded gracefully instead of falling over: no OOM, no swap thrashing, no hung management daemon, just a proportional and fully-recoverable slowdown.
The catch, and it's an important one: this specific fleet is CPU-idle/I/O-bound in real life. Every container in it runs under 3% CPU in production except the VPN gateway (~8.6%). The "21 vCores" number is almost entirely paper allocation, not real demand — which is exactly why the synthetic all-cores-at-once test was useful as a worst-case stress probe, but also why it doesn't prove the N200 would handle a CPU-hungry fleet the same way. If your homelab is compile farms or transcoding or ML workloads instead of DNS/VPN/git/notes-apps, this result doesn't transfer.
For a fleet like mine — a bunch of small self-hosted services that mostly sit around waiting on network I/O — a $200-ish 4-core mini PC handled the full simultaneous-worst-case scenario without breaking a sweat. That's a genuinely different answer than I expected going in.
What I'd still want to test
- Sustained (multi-hour, not 30-40s bursts) load, to rule out thermal throttling on a mini PC's presumably modest cooling
- Real disk I/O contention pushed harder — my burst test used real services but only for 30 seconds
- What actually happens if you push past 100% per guest — I never asked for more CPU than each guest was configured for, so "guest fighting for cores it wasn't allocated" territory is unexplored
- The ZFS stripe (no redundancy) is a known soft spot — fine for disposable test data, not a decision I'd make for anything I cared about keeping
- Retesting on a proper 4-disk NVMe RAID10 (striped mirrors) instead of the current 2-disk stripe would be worth doing purely for the redundancy and better parallel read performance. I wouldn't expect it to meaningfully change RAM usage on its own though — ZFS RAM pressure comes mostly from ARC (the read cache, capped by default around 50% of host RAM), which applies regardless of pool topology. The real thing worth watching on a 12GB box like this is ARC competing with guest RAM in general, not something specific to going RAID10. Honestly, I'd love to do this with 4x 4TB NVMe drives instead of 1TB ones, but that's way outside the "cheap test box" budget right now :(
Power draw
I also measured this at the wall out of curiosity:
- ~10W with just Proxmox running and every guest powered off (idle host baseline)
- ~26.3W during the final worst-case test (all 21 vCores pegged at 100% simultaneously)
That 26.3W is probably close to a practical ceiling for this box under sustained full load — for a 4-core mini PC pulling this little power even maxed out, that's a pretty compelling efficiency story next to leaving an 8c/16t desktop chip idling 24/7.