How I Cut Useless SSD Writes on My Standalone Proxmox Node

By /

If you run Proxmox VE (PVE) as a standalone node in your homelab, your server might be quietly eating away at your consumer SSD’s lifespan.

Out of the box, Proxmox is enterprise-grade software engineered for high-availability (HA) data center clusters. Because of this, it is incredibly “chatty.” Even if it’s the only server in your house, Proxmox constantly writes cluster state updates, metrics, and logs to your boot drive 24/7.

I recently audited my own standalone node—which only runs an OPNsense routing VM and a Home Assistant automation VM—and discovered it was racking up a massive 127 GB of writes per day.

Here is how I broke down the math, checked my drive health, and implemented a permanent fix to stop the bleed.

The Diagnostics: Checking the Damage

Before changing any settings, you need to know your baseline. You can pull your drive’s cumulative lifetime metrics directly from its S.M.A.R.T. data using smartctl.

First, identify your boot drive name using lsblk, then run:

Bash

apt update && apt install smartmontools -y
smartctl -a /dev/sda

(Note: If you are using an NVMe drive, use /dev/nvme0n1 instead).

On my Teamgroup SATA boot SSD (which uses a Phison controller), I looked at ID 241 (Total_LBAs_Written). On this specific firmware, the raw value tracks cumulative gigabytes written. Mine read 62,953 GB (~61.5 TBW) over 11,826 power-on hours (about 1.35 years).

Doing the math:

$$\frac{62,953\text{ GB}}{492.75\text{ days}} \approx 127.7\text{ GB written per day}$$

For a lightweight home setup, 127 GB a day is massive write amplification.

Why Is a Standalone Node So Chatty?

According to community tracking on the Proxmox forums, an unoptimized, completely idle PVE node inherently writes 10 GB to 30 GB per day doing absolutely nothing.

  1. The HA Cluster Loop: Daemons like pve-ha-lrm (Local Resource Manager) and pve-ha-crm (Cluster Resource Manager) constantly pulse to broadcast their status to the Proxmox Cluster File System (pmxcfs), forcing a relentless drip of physical writes to the SSD.
  2. The Web UI Webhook: If you leave the Proxmox dashboard open in a browser tab, the GUI aggressively polls the PVE API endpoints every few seconds to refresh performance graphs, logging every single connection to disk.
  3. Aggressive Swappiness: Linux defaults to a swappiness value of 60, meaning it will actively push idle memory pages into the boot drive’s swap partition even if you have plenty of free RAM.

The Fix: Stripping Enterprise Overhead

If you aren’t clustering multiple servers together, you can safely disable these background safety nets without losing any core virtualization functionality.

Here are the two highest-yield tweaks to save your flash memory cells.

1. Stop, Disable, and Mask the HA Daemons

Simply disabling the high-availability services isn’t enough; standard Proxmox system updates (apt dist-upgrade) can occasionally trigger post-install scripts that turn them back on. To prevent this, we mask them, which symlinks the services to /dev/null so they can never be forcefully started by the OS.

Run the following commands in your PVE command line:

Bash

# Stop the active services
systemctl stop pve-ha-lrm.service pve-ha-crm.service

# Permanently mask them from starting
systemctl mask pve-ha-lrm.service pve-ha-crm.service

You can verify it worked by checking their status:

Bash

systemctl status pve-ha-lrm pve-ha-crm

You want to see: Loaded: masked (Reason: Unit pve-ha-lrm.service is masked.)

2. Drop the Aggressive Swappiness

For a dedicated hypervisor platform with plenty of system memory, you only want the OS to swap when absolutely necessary. Drop the swappiness coefficient from 60 down to 10.

Open your system configuration file:

Bash

nano /etc/sysctl.conf

Add the following line to the bottom of the file:

Ini, TOML

vm.swappiness = 10

Save and exit (Ctrl+O, Enter, Ctrl+X), then apply the changes instantly without a reboot:

Bash

sysctl -p

Proxmox 9:

You can safely create the file and force the kernel to register it immediately without a reboot by running these two commands:

Bash

# 1. Create the new configuration file path
echo "vm.swappiness = 10" > /etc/sysctl.d/99-homelab.conf

# 2. Tell systemd-sysctl to manually process the directory right now
systemctl restart systemd-sysctl.service

The Ultimate Truth Test

Because you can’t always trust that a config file applied correctly behind the scenes, you should always ask the live Linux kernel exactly what value it is holding in active memory.

Run this command to print the real-time runtime parameter directly from the kernel:

Bash

sysctl vm.swappiness

Final Verification

With the cluster loops blocked and swappiness managed, you can monitor your real-time write rates using iostat to make sure the disk has calmed down:

Bash

apt install sysstat -y
iostat -m -x 5

Watch the wMB/s (Megabytes written per second) column. On an idle, optimized node, this value should routinely drop to 0.00 between minor system flushes, rather than sustaining a constant heartbeat of writes.

By tailoring the underlying OS to match actual standalone consumer hardware rather than an enterprise SAN network, you can easily extend the lifespan of your homelab boot drives by years.

Scroll to Top