From 0628ec58ba0cace3335a6cc027e85680221d2acf Mon Sep 17 00:00:00 2001 From: mARTin-B78 Date: Mon, 7 Sep 2026 19:06:41 +0200 Subject: [PATCH] fix: Build-Speicher auf dem Container -- NODE_OPTIONS statt Rateschluss Der Deploy starb mit "Ineffective mark-compacts near heap limit". Nodes Standard-Heap richtet sich nach dem Arbeitsspeicher und liegt auf dem Container bei rund 1,5 GB -- zu wenig fuer next build. update-app.sh setzt jetzt --max-old-space-size=2048. Ich hatte zuerst ESLint im Build verdaechtigt (mein ignoreDuringBuilds: false aus v1.117.4) und die Aenderung zurueckgenommen. Eine Messung widerlegte das: Spitzenspeicher mit ESLint 2.590 MB, ohne 2.595 MB -- kein Unterschied. Die Ruecknahme ist damit hinfaellig, ESLint bleibt im Build. Der Build braucht rund 2,6 GB. Bei 3 GB Container-RAM bleibt das knapp; NODE_OPTIONS ist die Sofortmassnahme, mehr RAM fuer LXC 202 die eigentliche Loesung. Steht als Block J in TODO.md, zusammen mit der Alternative, den Build auf den Spark zu verlagern. v1.119.3 Co-Authored-By: Claude Opus 5 --- CHANGELOG.md | 15 +++++++++++++++ TODO.md | 28 ++++++++++++++++++++++++++++ next.config.js | 9 +++++++-- package-lock.json | 4 ++-- package.json | 2 +- scripts/update-app.sh | 5 ++++- 6 files changed, 57 insertions(+), 6 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 5cfcf54..a388295 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,21 @@ All notable changes to this project are documented in this file. +## [1.119.3] - 2026-09-07 + +### Fixed +- `scripts/update-app.sh` setzt beim Build `NODE_OPTIONS="--max-old-space-size=2048"`. + Nodes Standard-Heap richtet sich nach dem Arbeitsspeicher und landet auf dem + Produktionscontainer bei rund 1,5 GB — zu wenig für `next build`, der Deploy starb mit + `FATAL ERROR: Ineffective mark-compacts near heap limit`. + +### Notes +- **Gemessen, nicht vermutet:** ESLint im Build ist *nicht* die Ursache. Spitzenspeicher + mit ESLint 2.590 MB, ohne 2.595 MB. `eslint.ignoreDuringBuilds` bleibt daher auf `false` + — eine zwischenzeitliche Rücknahme beruhte auf einer falschen Annahme. +- Der Build braucht rund **2,6 GB**. Bei 3 GB Container-RAM bleibt das knapp; mehr Speicher + für LXC 202 steht als Block J in `TODO.md`. + ## [1.119.2] - 2026-09-07 ### Changed diff --git a/TODO.md b/TODO.md index 24adcb4..359b017 100644 --- a/TODO.md +++ b/TODO.md @@ -286,6 +286,34 @@ Umgestellt auf `dataSources.query()`; die Suche filtert jetzt auf `data_source` --- +## Block J — Build-Speicher auf dem Container + +### J1. Container-RAM erhöhen *(empfohlen)* +- [ ] LXC 202 von 3 GB auf 6 GB anheben (Proxmox → Container → Resources → Memory) + +**Warum:** `next build` braucht **rund 2,6 GB Spitzenspeicher** (gemessen). Bei 3 GB +Container-RAM bleibt fast nichts übrig — der laufende PM2-Prozess und das System teilen +sich den Rest. Der Deploy vom 07.09. starb deshalb mit +`FATAL ERROR: Ineffective mark-compacts near heap limit`. + +`scripts/update-app.sh` setzt jetzt `NODE_OPTIONS="--max-old-space-size=2048"`, weil Nodes +Standard-Heap auf diesem Container bei nur rund 1,5 GB liegt. Das ist die Sofortmaßnahme, +aber bei 2,6 GB Bedarf bleibt es knapp. **Mehr RAM ist die eigentliche Lösung** und in +Proxmox ein Klick. + +**Nicht die Ursache — geprüft:** ESLint im Build. Gemessener Spitzenspeicher mit ESLint +2.590 MB, ohne 2.595 MB. Kein Unterschied. + +### J2. Alternative: woanders bauen +- [ ] Erwägen, den Build auf dem Spark laufen zu lassen und nur `.next/standalone` zu + übertragen + +**Warum:** Dann braucht der Produktionscontainer überhaupt keinen Build-Speicher mehr — +er würde nur noch fertige Dateien erhalten und PM2 neu starten. Grösserer Umbau des +Deploy-Wegs, aber die sauberste Trennung. + +--- + ## Block I — UI-Wünsche ### I1. Aktuellen Tag auch im Spaltenkopf hervorheben *(erledigt, bitte ansehen)* diff --git a/next.config.js b/next.config.js index 838d40a..c73a0a4 100644 --- a/next.config.js +++ b/next.config.js @@ -4,8 +4,13 @@ const { version } = require('./package.json'); const nextConfig = { output: 'standalone', eslint: { - // Aus: Der Build soll ESLint-Fehler melden. Warnungen (aktuell ~695, überwiegend - // no-explicit-any) blockieren den Build nicht — nur Errors tun das. + // Aus: Der Build meldet ESLint-Fehler. Warnungen blockieren ihn nicht, nur Errors. + // + // Kurzzeitig stand hier wieder true, weil ich ESLint fuer den OOM-Absturz des Builds + // auf dem Produktionscontainer verantwortlich hielt. Eine Messung widerlegte das: + // Spitzenspeicher mit ESLint 2.590 MB, ohne 2.595 MB -- kein Unterschied. Die Ursache + // war Nodes Standard-Heap-Limit von rund 1,5 GB; dafuer setzt scripts/update-app.sh + // jetzt NODE_OPTIONS. ignoreDuringBuilds: false, }, typescript: { diff --git a/package-lock.json b/package-lock.json index e1232af..bb6cf76 100644 --- a/package-lock.json +++ b/package-lock.json @@ -1,12 +1,12 @@ { "name": "my-weekly-todo-list", - "version": "1.119.2", + "version": "1.119.3", "lockfileVersion": 3, "requires": true, "packages": { "": { "name": "my-weekly-todo-list", - "version": "1.119.2", + "version": "1.119.3", "license": "MIT", "dependencies": { "@auth/prisma-adapter": "^2.11.1", diff --git a/package.json b/package.json index 4ad89eb..38912a6 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "my-weekly-todo-list", - "version": "1.119.2", + "version": "1.119.3", "description": "A web-based weekly task management application that organizes to-dos and calendar events in a single, intuitive weekly view", "main": "index.js", "scripts": { diff --git a/scripts/update-app.sh b/scripts/update-app.sh index 6ce614f..9ab664e 100755 --- a/scripts/update-app.sh +++ b/scripts/update-app.sh @@ -95,8 +95,11 @@ main() { log "--- Regenerating Prisma client ---" npx prisma generate + # Der Standard-Heap von Node richtet sich nach dem Arbeitsspeicher und landet auf + # diesem Container bei rund 1,5 GB. Das reichte fuer `next build` nicht mehr, der Build + # starb mit "JavaScript heap out of memory". 2 GB lassen genug Luft fuer den Rest. log "--- Building application ---" - npm run build + NODE_OPTIONS="--max-old-space-size=2048" npm run build # next.config.js sets output: 'standalone', and Next.js does NOT copy public/ or # .next/static/ into .next/standalone — that is a documented manual step. Skipping it