From 9e5f546d7623fd2850be2b96fa621d8d0499e0f8 Mon Sep 17 00:00:00 2001 From: mhoennig Date: Wed, 26 Aug 2026 15:57:06 +0200 Subject: [PATCH] docs: Speicherzahlen der Zielumgebung berichtigt (D76-Nachtrag 3) Nachtrag 2 nannte "832 MB frei" - ein Schnappschuss, und dazu mehrdeutig zwischen `free` und `available`. Nachgemessen: 326-358 MB free, 978-1004 MB available von 3915 MB, dazu ~1 GB Swap belegt. Falsch war ausserdem die Annahme, ein Managed Webspace koenne den Verbrauch nicht zuordnen. `hidepid=invisible` verbirgt zwar fremde Prozesse, aber das systemd-cgroup-Accounting (`systemctl status pacs-.slice`, so auch im Hostsharing-Wiki) und die world-readable atop-Aufzeichnungen unter /var/log/atop/ geben sie her. Befund: nicht die Datenbanken. clamav-daemon 988 MB gegen mariadb 150 MB und postgresql 111 MB; alle zwoelf Webspaces zusammen 100 MB. MariaDB haelt 602 MB im Swap - die DBs sind auf je 25 % des RAM provisioniert und verlieren gegen den Virenscanner. Fuers Deployment: pacs-mih00.slice hat MemoryMax=3147M - eine Erlaubnis, keine Reservierung. `-Xmx` gehoert gegen das Freie bemessen; die JVM-Voreinstellung (~980 MB) ist genau die Groesse, die MariaDBs Puffer verdraengt hat. Co-Authored-By: Claude Opus 5 --- backend/docs/live-editing-proposal.md | 11 +++++++ docs/DECISIONS.md | 43 +++++++++++++++++++++++++-- 2 files changed, 52 insertions(+), 2 deletions(-) diff --git a/backend/docs/live-editing-proposal.md b/backend/docs/live-editing-proposal.md index 5214306..fa8a583 100644 --- a/backend/docs/live-editing-proposal.md +++ b/backend/docs/live-editing-proposal.md @@ -309,12 +309,23 @@ Gemessen auf `mih00.hostsharing.net`, wo die stabile Instanz | Java | **nur 17** | Backend verlangt 21 | | systemd `Linger` | **yes** | Ein eigener Dienst darf dauerhaft laufen | | PostgreSQL | lauscht auf 5432 | Der in `application.yaml` angedachte Umstieg wäre möglich | +| Speicher | 3,9 GB im Host, davon ~300 MB frei | `-Xmx` ist Pflicht, siehe unten | +| Webspace-Grenze | `MemoryMax=3147M` (cgroup) | Erlaubnis, keine Reservierung | **Long Polling trägt dort.** Die Zeitgrenzen sind großzügig, und der Worker-Pool ist groß genug. **Pufferung ist bei Long Polling ohnehin kein Thema** — anders als bei SSE kommt genau eine Antwort am Ende des Wartens, kein Strom von Teilstücken. +**Der Speicher ist die knappe Größe, nicht die Verbindungen.** Der Host hat +3,9 GB und ist überbucht (`Committed_AS` 12,0 GB gegen `CommitLimit` 5,9 GB); +frei sind rund 300 MB, ein weiteres GB liegt bereits im Swap. Unser Webspace +darf laut cgroup 3147 MB nehmen — das ist aber eine Erlaubnis, kein +reservierter Speicher. Die JVM braucht deshalb ein ausdrückliches `-Xmx`, +bemessen am tatsächlich Freien: Ihre Voreinstellung von ¼ des physischen RAM +(≈ 980 MB) ist genau die Größenordnung, die auf diesem Host schon MariaDBs +Puffer in den Swap gedrängt hat. Zahlen und Herleitung: D76-Nachtrag 3. + **Der einzige echte Einwand ist das fehlende HTTP/2.** Damit gilt im Browser das Limit von sechs Verbindungen je Herkunft. Ein Long-Poll belegt eine davon; hat jemand denselben Plan in drei Tabs offen, sind drei Verbindungen diff --git a/docs/DECISIONS.md b/docs/DECISIONS.md index 2ec2e78..0640bb0 100644 --- a/docs/DECISIONS.md +++ b/docs/DECISIONS.md @@ -5963,8 +5963,8 @@ zu senken — Entwicklung und Produktion laufen dann auf derselben Version, und `Linger=yes` erlaubt den dauerhaften Dienst ohne Root. Erwogen und **vorgemerkt statt verworfen** war ein natives Binary via GraalVM: Es löste das Problem vollständig (kein Java auf dem Server) und spart den Großteil des -knappen RAM — gemessen sind dort nur **832 MB frei** bei 3,9 GB gesamt, es ist -ein geteilter Server. Dagegen stehen derzeit drei Dinge: die glibc-Differenz +Speichers — der geteilte Host ist eng (berichtigte Zahlen in Nachtrag 3). +Dagegen stehen derzeit drei Dinge: die glibc-Differenz zwischen Ubuntu 24.04 (2.39) und Debian 12 (2.36), die einen Container-Build erzwingt; Liquibase braucht Metadaten aus einem Native-Agent-Lauf und Hibernate das Enhancement-Plugin; und ein offener Fehler in Spring Boot 4 @@ -5975,6 +5975,45 @@ einem anderen Stack. Unabhängig davon: Beim Deployment gehört ein `-Xmx` gesetzt, statt der JVM auf einem geteilten Server die Voreinstellung zu überlassen. +**Nachtrag 3 — die Speicherzahlen berichtigt, und die Zuordnung geht doch +(2026-08-26).** Nachtrag 2 nennt „nur **832 MB frei** bei 3,9 GB gesamt“ als +Argument für das native Image. Die Zahl war ein Schnappschuss und dazu +mehrdeutig: `free` und `available` sind verschiedene Dinge. Nachgemessen +schwankt es zwischen **326–358 MB `free`** und **978–1004 MB `available`** +von 3915 MB; dazu 4 GB Swap, davon rund **1 GB belegt**. + +**Die Annahme, ein Managed Webspace könne den Verbrauch nicht zuordnen, war +falsch.** `/proc` trägt zwar `hidepid=invisible`, aber es gibt zwei Wege +daran vorbei: das **systemd-cgroup-Accounting** (`systemctl status +pacs-.slice` — so nennt es auch das Hostsharing-Wiki, „RAM Belegung“) +und die **world-readable atop-Aufzeichnungen** unter `/var/log/atop/`, die +als root geschrieben werden und vier Wochen Historie im 10-Minuten-Takt +enthalten. + +**Es sind nicht die Datenbanken.** Gemessen je Dienst: `clamav-daemon` +**988 MB**, `apache2` 580 MB, `systemd-journald` 310 MB, `spamd` 224 MB, +`dovecot` 173 MB, `mariadb` **150 MB**, `postgresql@15-main` **111 MB**. +Beide Datenbanken zusammen sind gut 8 % dessen, was im `system.slice` steht; +der Virenscanner allein ist das Vierfache (atop, prozessgenau: `clamd` +RSIZE 969,5 MB = 25 % des Maschinenspeichers). **Alle Webspaces zusammen +belegen 100 MB**, unserer davon 30 MB. + +Die Datenbanken sind trotzdem beteiligt — als Verlierer: `mariadbd` hat laut +atop **602 MB im Swap**, also den größten Teil des belegten Gigabytes. +Provisioniert sind sie üppig (`shared_buffers` 979 MB, `innodb_buffer_pool_size` +979 MB, `key_buffer_size` 489 MB — 979 MB sind exakt 25 % von 3915 MB, eine +automatische Sizing-Regel, zweimal angewandt), residieren aber nur zu einem +Zehntel davon. `Committed_AS` 12,0 GB gegen `CommitLimit` 5,9 GB: Der Host +ist chronisch überbucht. **Das ist das schärfere GraalVM-Argument** als die +Momentaufnahme aus Nachtrag 2 — nicht „gerade wenig frei“, sondern „hier +gewinnt beim nächsten Engpass, wer zuerst da war“. + +**Das Budget fürs Deployment steht in `/etc/systemd/system/pacs-mih00.slice`: +`MemoryMax=3147M`.** Das ist eine **Erlaubnis, keine Reservierung** — frei +sind rund 300 MB. Ein `-Xmx` gehört also gegen das Freie bemessen, nicht +gegen die Grenze; und die JVM-Voreinstellung (¼ des physischen RAM ≈ 980 MB) +ist genau die Größenordnung, die MariaDBs Puffer in den Swap gedrängt hat. + **Nachtrag zu D13 — Paketwurzel `de.werkbaum`, und drei Fallen von Spring Boot 4 (2026-08-26).** Das Backend-Gerüst kam zunächst unter der Platzhalter-Wurzel `com.example.editor` herein und widersprach damit