I run dnstools.ws which lets you perform DNS lookups, pings, traceroutes, etc. from 25 locations around the world. Each location is powered by a VPS running Debian, running a C# service that’s compiled to native code ahead-of-time using Native AOT. It uses ~60MB RAM.
Six of the the locations are powered by tiny “NAT VPSes” (native IPv6 with shared NAT IPv4) that only cost a few dollars a year, sponsored by various server providers. These usually have 256 MB RAM and 4-5 GB disk space.
This is great with OpenVZ and LXC. Since they’re containers that share the kernel with the host, kernel memory doesn’t count towards the container’s memory limit. I’m using ~75 MB RAM on those systems: ~60MB for the DNSTools worker and ~15MB for everything else (sshd, systemd, cron, rsyslogd, and unattended-upgrades). Plenty of room left.
I also have a few KVM systems with 256 MB RAM. These are what I’m struggling with.
Debian 13 (Trixie) increased the minimum hardware requirements from 256 MB to 512 MB RAM. It seems like this is a hard requirement - When running on a system using 256 MB RAM, the installer complains about having too little RAM, and OOMs during the installation. Even with a successful installation (e.g. upgrading from bookworm to trixie), it kernel panics on boot: “System is deadlocked on memory”.
I could try debootstrap to bootstrap a basic system, or Clonezilla to clone a working disk image over the network, but I think I’d hit the memory deadlock too.
Does Debian have smaller kernel images for VM environments, that use less RAM? Or should I just give up on Debian for this use case?
Does anyone have a recommendation for another distro I should use? I’ve been considering trying Alpine. C# does support compiling to use musl instead of glibc, so that’s not an issue. I’m also not tightly-coupled to systemd and can get rid of it.
I can mount a custom ISO on the systems, so booting from an ISO isn’t an issue.
Thanks!
Edit: Alpine looks very promising - no issue installing it and running my app on a 256MB VM. This is probably what I’ll end up using.
tui installer on netinst iso (13.4) says 320mb is required:
it does allow you to continue anyway, which switches to ‘low memory’ expert mode install. 320mb also gives this error. 384mb does not, but still enters the special install mode, where i was able to load enough installer components to set up networking to start an install. it did lose part of the display font partway through but it did finish and reboot ok (with ~104mb used). dropped the ram in virt-man to 256mb and it still booted.
edit: i just installed dietpi on this, which basically shreds debian down to the kernel and not much else, and rebuilds it as dietpi. went on without any issues, not even a complaint with 256mb. htop says 65mb used (this, before adding any server ‘apps’, mind you)… but i might just be able to upgrade a couple dietpi boxes i have that do only have 256mb ram.
Interesting! I wonder why I was hitting the memory deadlock on boot, but yours booted OK.
I might run a local VM, use dietpi, then clone the resulting VM to the hosting provider using Clonezilla.
i dunno. was your debian-installer running in lowmem mode? did it add extra stuff because of the detected vm environment (i did notice at least one extra thing here for qemu plus the network drivers needed).
this trixie-based dietpi here boots at 192mb allocated to the vm, but panics at 160mb.
the dietpi x64 ‘installer’ iso don’t use the debian-installer. they are clonezilla-based, preconfigured to use an included dietpi image, which does a first-run setup after it’s ‘restored’.
I was using debian-installer in lowmem mode, but it OOMd during the install. I haven’t tried adding swap yet though.
The Trixie system that I did manage to setup was an upgrade from Bookworm. That’s the one that’s hitting the memory deadlock on boot.
maybe see if the providers can bump the ram up a bit to get through the trixie installer? 384mb was enough here (i didn’t try to install with less), perhaps 512mb in your hosts’ environments will be enough.