{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/",
        "slug": "use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries",
        "url": "https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/"
        },
        "title": "Use systemd MemoryHigh and MemoryMax for different control boundaries",
        "summary": "A pressure threshold is not the same setting as the final enforced memory ceiling.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "priority": {
            "slug": "info",
            "name": "Information"
        },
        "featured": false,
        "image": {
            "theme": "network-infrastructure",
            "label": "Networks & infrastructure",
            "alt": "Resilient network core with engineered blue and gold data paths.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "it",
                "name": "IT",
                "url": "https://update.dsesecurity.com/topic/it/"
            },
            {
                "slug": "networks-infrastructure",
                "name": "Networks & Infrastructure",
                "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-10-20T18:15:26+00:00",
        "modified_at": "2026-10-20T18:34:33+00:00",
        "reviewed_on": "2026-10-20",
        "reading_minutes": 2,
        "word_count": 262,
        "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.",
        "primary_source": {
            "name": "Debian systemd manual — systemd.resource-control(5) — systemd — Debian trixie — Debian Manpages",
            "url": "https://manpages.debian.org/trixie/systemd/systemd.resource-control.5.en.html",
            "published_on": null,
            "authority": "manpages.debian.org"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<p>A pressure threshold is not the same setting as the final enforced memory ceiling.</p>\n<h2>Source facts</h2>\n<p>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.</p>\n<p>Source: <a href=\"https://manpages.debian.org/trixie/systemd/systemd.resource-control.5.en.html\">Debian systemd manual — systemd.resource-control(5) — systemd — Debian trixie — Debian Manpages</a>.</p>\n<h2>Applicability</h2>\n<p>Review unified-hierarchy memory controls and effective parent limits in the Debian trixie systemd.resource-control manual.</p>\n<h2>DSE recommendation</h2>\n<p>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.</p>\n<h2>Verification</h2>\n<p>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.</p>\n<h2>Official reference</h2>\n<p><a href=\"https://manpages.debian.org/trixie/systemd/systemd.resource-control.5.en.html\">Debian systemd manual — systemd.resource-control(5) — systemd — Debian trixie — Debian Manpages</a>. Reviewed October 20, 2026.</p>",
        "content_text": "A pressure threshold is not the same setting as the final enforced memory ceiling.\nSource facts\nThe 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.\nSource: Debian systemd manual — systemd.resource-control(5) — systemd — Debian trixie — Debian Manpages.\nApplicability\nReview unified-hierarchy memory controls and effective parent limits in the Debian trixie systemd.resource-control manual.\nDSE recommendation\nDSE 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.\nVerification\nIn 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.\nOfficial reference\nDebian systemd manual — systemd.resource-control(5) — systemd — Debian trixie — Debian Manpages. Reviewed October 20, 2026.",
        "content_markdown": "A pressure threshold is not the same setting as the final enforced memory ceiling.\n\n## Source facts\n\nThe 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.\n\nSource: [Debian systemd manual — systemd.resource-control(5) — systemd — Debian trixie — Debian Manpages](https://manpages.debian.org/trixie/systemd/systemd.resource-control.5.en.html).\n\n## Applicability\n\nReview unified-hierarchy memory controls and effective parent limits in the Debian trixie systemd.resource-control manual.\n\n## DSE recommendation\n\nDSE 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.\n\n## Verification\n\nIn 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.\n\n## Official reference\n\n[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."
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/",
                "url": "https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-10-20"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "IT",
                        "item": "https://update.dsesecurity.com/topic/it/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 3,
                        "name": "Use systemd MemoryHigh and MemoryMax for different control boundaries",
                        "item": "https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/#article",
                "identifier": "https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/",
                "url": "https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/",
                "headline": "Use systemd MemoryHigh and MemoryMax for different control boundaries",
                "description": "A pressure threshold is not the same setting as the final enforced memory ceiling.",
                "abstract": "A pressure threshold is not the same setting as the final enforced memory ceiling.",
                "articleBody": "A pressure threshold is not the same setting as the final enforced memory ceiling.\nSource facts\nThe 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.\nSource: Debian systemd manual — systemd.resource-control(5) — systemd — Debian trixie — Debian Manpages.\nApplicability\nReview unified-hierarchy memory controls and effective parent limits in the Debian trixie systemd.resource-control manual.\nDSE recommendation\nDSE 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.\nVerification\nIn 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.\nOfficial reference\nDebian systemd manual — systemd.resource-control(5) — systemd — Debian trixie — Debian Manpages. Reviewed October 20, 2026.",
                "datePublished": "2026-10-20T18:15:26+00:00",
                "dateModified": "2026-10-20T18:34:33+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/use-systemd-memoryhigh-and-memorymax-for-different-control-boundaries/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Use systemd MemoryHigh and MemoryMax for different control boundaries"
                },
                "articleSection": [
                    "IT",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "IT",
                    "Networks & Infrastructure",
                    "Guide",
                    "Information priority"
                ],
                "genre": "Guide",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "IT",
                        "url": "https://update.dsesecurity.com/topic/it/"
                    },
                    {
                        "@type": "Thing",
                        "name": "Networks & Infrastructure",
                        "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
                    }
                ],
                "wordCount": 262,
                "timeRequired": "PT2M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "Debian systemd manual — systemd.resource-control(5) — systemd — Debian trixie — Debian Manpages",
                    "url": "https://manpages.debian.org/trixie/systemd/systemd.resource-control.5.en.html"
                }
            }
        ]
    }
}