neondatabase/neon · error

invalid monitor Config: sys_buffer_bytes cannot be 0

Error message

invalid monitor Config: sys_buffer_bytes cannot be 0

What it means

`Runner::new` in the vm-monitor rejects a `Config` where `sys_buffer_bytes == 0`. That field estimates memory reserved for the system and feeds the file-cache sizing math, so zero would make the calculations meaningless. It comes from the monitor's configuration file (the `--config` argument), normally written by the Neon control plane.

Source

Thrown at libs/vm_monitor/src/runner.rs:118

        // We want our threshold to be met gracefully instead of letting postgres get OOM-killed
        // (or if there's room, spilling to swap).
        // So we guarantee that there's at least `cgroup_min_overhead_fraction` of total memory
        // remaining above the threshold.
        (total_mem as f64 * (1.0 - self.cgroup_min_overhead_fraction)) as u64
    }
}

impl Runner {
    /// Create a new monitor.
    #[tracing::instrument(skip_all, fields(?config, ?args))]
    pub async fn new(
        config: Config,
        args: &Args,
        ws: WebSocket,
        kill: broadcast::Receiver<()>,
        token: CancellationToken,
    ) -> anyhow::Result<Runner> {
        anyhow::ensure!(
            config.sys_buffer_bytes != 0,
            "invalid monitor Config: sys_buffer_bytes cannot be 0"
        );

        let dispatcher = Dispatcher::new(ws)
            .await
            .context("error creating new dispatcher")?;

        let mut state = Runner {
            config,
            filecache: None,
            cgroup: None,
            dispatcher,
            counter: 1, // NB: must be odd, see the comment about the field for more.
            last_upscale_request_at: None,
            kill,
        };

View on GitHub (pinned to 8f60b04da4)

Solutions

1. Set a non-zero `sys_buffer_bytes` in the monitor's config file (order of a few hundred MiB, e.g. 400000000)
2. Check for typos/casing in the key so deserialization actually picks it up
3. Diff against a config file from a known-working deployment
4. If the config is generated by the control plane, verify the attached config parameters/secret

Example fix

// before (monitor config file): field missing -> defaults to 0
{ "period": "1s", "scaling_config": { ... } }

// after: explicit non-zero value (key name per vm_monitor Config serde schema)
{ "period": "1s", "sys_buffer_bytes": 400000000, "scaling_config": { ... } }

if config.sys_buffer_bytes == 0 {
    anyhow::bail!("refusing to start: sys_buffer_bytes must be set to a non-zero value in the monitor config");
}

When it happens

Trigger: Starting the vm-monitor with a config file that omits `sys_buffer_bytes` (integer field defaults to 0 via serde) or explicitly sets it to 0.

Common situations: Hand-writing a dev/test config and forgetting the field; a control-plane template regression that stopped populating the key; a key-name typo or casing mismatch so serde never reads the provided value.

Related errors

• incompatible resource_multipler and spread_factor
• {} did not start+pass status checks within {:?} seconds
• process failed to start: {e}
• resource_multiplier must be between 0.0 and 1.0 exclusive, g
• spread_factor must be >= 0, got {}

AI-assisted analysis of neondatabase/neon@8f60b04da4 (2026-08-16). Data as JSON: /api/errors/532a746810d73232. Report an issue: GitHub.