# Use systemd MemoryHigh and MemoryMax for different control boundaries

> A pressure threshold is not the same setting as the final enforced memory ceiling.

- Canonical URL: https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:15:26+00:00
- Modified: 2026-10-20T18:34:33+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

A pressure threshold is not the same setting as the final enforced memory ceiling.

## Potentially affected

Review unified-hierarchy memory controls and effective parent limits in the Debian trixie systemd.resource-control manual.

## DSE recommendation

DSE recommends choosing a pressure-management threshold and an unacceptable-consumption ceiling separately.

## Article

A pressure threshold is not the same setting as the final enforced memory ceiling.

## Source facts

The Debian systemd.resource-control manual describes MemoryHigh as a throttling threshold: memory can exceed it, but reclaim and process slowdown are applied aggressively. MemoryMax is an absolute boundary that can invoke the unit’s out-of-memory killer when usage cannot be contained. The manual recommends MemoryHigh as the primary control and MemoryMax as a last defense.

Source: [Debian systemd manual — systemd.resource-control(5) — systemd — Debian trixie — Debian Manpages](https://manpages.debian.org/trixie/systemd/systemd.resource-control.5.en.html).

## Applicability

Review unified-hierarchy memory controls and effective parent limits in the Debian trixie systemd.resource-control manual.

## DSE recommendation

DSE recommends choosing a pressure-management threshold and an unacceptable-consumption ceiling separately. Measure the service’s working set, startup behavior, and latency under reclaim rather than copying one value into both settings. Inspect the effective parent boundary before increasing a service-level allowance. Preserve memory pressure and OOM evidence so a change addresses observed behavior. Keep service owners informed that slowing under MemoryHigh and termination at MemoryMax are different expected outcomes with different recovery implications.

## Verification

In a nonproduction service, apply representative memory demand and inspect effective limits, pressure signals, responsiveness, and any termination event. Confirm monitoring distinguishes reclaim-related slowdown from OOM failure. Verify the recovery procedure preserves required state before authorizing the final production thresholds. Retain the effective service and parent limits with the measured workload. Have the application owner approve both the reclaim-time response and the failure/recovery result, documenting why the two thresholds serve different service decisions.

## Official reference

[Debian systemd manual — systemd.resource-control(5) — systemd — Debian trixie — Debian Manpages](https://manpages.debian.org/trixie/systemd/systemd.resource-control.5.en.html). Reviewed October 20, 2026.

## Primary reference

- Name: Debian systemd manual — systemd.resource-control(5) — systemd — Debian trixie — Debian Manpages
- Authority: manpages.debian.org
- URL: https://manpages.debian.org/trixie/systemd/systemd.resource-control.5.en.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Use systemd MemoryHigh and MemoryMax for different control boundaries,” DSE Security, https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.