Ich benutze ein M2 Macbook Pro mit dem Dev Container Setup. Die Speichernutzung scheint sehr hoch zu sein, ist das normal? Ich sehe etwa 4 GB Speichernutzung, bevor ich etwas ausführe, und benötige dann etwa 10 GB, um einen erfolgreichen Build und die vollständige App mit etwa 8 GB auszuführen.
Bevor die offizielle Dev Container-Konfiguration geteilt wurde, hatte ich meine eigene devcontainer.json, die nicht das discourse_dev-Basisimage verwendete. Sie verbraucht im Ruhezustand nur 2 GB RAM und 6 GB während des Betriebs von Discourse, daher bin ich neugierig, worin der Unterschied liegen könnte.
Basisimage: mcr.microsoft.com/devcontainers/base:debian-12
mit diesen “Features”:
"features": {
"ghcr.io/rocker-org/devcontainer-features/apt-packages:1": {
"packages": "software-properties-common libpq-dev vim curl expect debconf-utils build-essential zlib1g-dev libssl-dev openssl libcurl4-openssl-dev libreadline6-dev libpcre3 libpcre3-dev imagemagick advancecomp jhead jpegoptim libjpeg-turbo-progs optipng pngcrush pngquant gnupg2"
},
"ghcr.io/devcontainers/features/ruby:1": {
"version": "3.3.4"
},
"ghcr.io/devcontainers/features/node:1": {
"version": "18",
"pnpmVersion": "9"
},
"ghcr.io/devcontainers/features/rust:1": {
"version": "1.75.0"
},
"ghcr.io/itsmechlark/features/redis-server:1": {},
"ghcr.io/devcontainers/features/go:1": {},
"ghcr.io/azutake/devcontainer-features/go-packages-install:0": {
"PACKAGES": "github.com/mailhog/MailHog@latest"
},
},
einschließlich eines weiteren Container-DB-Dienstes, der das postgres:14-Image ausführt.
Das offizielle Image soll die Entwicklung vereinfachen, indem es alles bündelt, was notwendig ist, um Discourse nahtlos auszuführen, auf Kosten höherer Speicheranforderungen, und Ihre benutzerdefinierte Einrichtung scheint eine fein abgestimmte Kontrolle über Versionen und installierte Bibliotheken zu haben.
Verbraucht das Entwicklerimage auch etwa 8-10 GB RAM?
Jetzt liegt es nach dem Neustart aller Dinge bei etwa 6 GB, also werde ich davon ausgehen, dass das “typisch” ist, und alles, was darüber hinausgeht, auf einen möglichen Speicherleck irgendwo im Entwicklungsstack (wahrscheinlich Docker Desktop) schieben.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.