Exercise 3: Daily OOM Kills From an Unmeasured MemoryMax= — Possible Solution
====================================================================

What went wrong:

Per the chapter's own warn-box, this is exactly the described failure
mode: "a MemoryMax= set without first observing real usage via
systemd-cgtop can OOM-kill a service during entirely legitimate,
normal peak load." The team set a hard 256M ceiling without ever
measuring what this service's own memory usage actually looks like
during real operation -- it's entirely plausible, and consistent with
the described symptom, that the service's own genuine, healthy peak
memory usage during its busiest traffic window simply exceeds 256M
under completely normal, non-buggy operation. Since MemoryMax= is a
hard ceiling that triggers the cgroup-scoped OOM killer the instant
it's crossed (per this chapter's own earlier material), the service
gets killed every single day at the exact moment its real,
legitimate workload naturally needs more memory than the arbitrarily
chosen 256M limit allows -- not because anything is actually broken,
but because the limit itself was never grounded in real observed
behavior.

The correct process that should have been followed:

Per the chapter's own explicit guidance, systemd-cgtop should have
been used FIRST, to observe the service's own real memory usage
across a representative period -- specifically including its own peak
traffic window, since that's exactly the scenario a limit needs to
accommodate. Only once the team had a genuine, evidence-based
understanding of what "normal, healthy" memory usage looks like for
this service (including its real peaks, not just its typical idle
usage) should MemoryMax= have been set, with a value chosen to sit
comfortably above that observed peak -- catching a genuine runaway
leak (this chapter's own actual use case) without also killing the
service for its own ordinary, expected behavior. This is precisely
the "measure before you optimize" discipline the chapter explicitly
connects back to perf1's own approach to diagnosing resource issues.

WHY THIS WORKS AS AN ANSWER
------------------------------
This diagnoses the root cause (an arbitrary limit set without
measurement, colliding with genuine peak-load usage) by directly
applying the chapter's own warn-box, then prescribes the correct
process (observe with systemd-cgtop first, including peak load, then
set an informed limit) rather than simply suggesting "raise the
number."