1 Solution
Accepted Solutions
Hallo Benny,
Du kannst hier zwei Umgebungsvariablen dem caas-bus mitgeben ( CAAS_BUS_MIN_MEMORY und CAAS_BUS_MAX_MEMORY 😞
Auszug caas-bus.yml
- name: CAAS_BUS_MIN_MEMORY
value: "2000m"
- name: CAAS_BUS_MAX_MEMORY
value: "2000m"
resources:
limits:
cpu: 4000m
memory: 4000Mi
Mindestens 1GB benötigt der caas-bus. Danach den POD neustarten und es sollte wieder gehen.
Um weitere Java-Heapspace-Probleme zu umgehen (auch bei den anderen PODS), setze mal in den ymls (das geht auch beim caas-bus) für ...
- caas-rest-api
- caas-adapter
... die Umgebungsvariable "_JAVA_OPTIONS" - Details dazu findest du hier: java - Difference between _JAVA_OPTIONS JAVA_TOOL_OPTIONS and JAVA_OPTS - Stack Overflow
- caas-adapter.yml (Auszug):
- name: _JAVA_OPTIONS
value: "-Xms256m -Xmx512m"
resources:
limits:
cpu: 1000m
memory: 1000Mi
requests:
cpu: 250m
memory: 250Mi
- caas-rest-api.yml (Auszug):
- name: _JAVA_OPTIONS
value: "-Xms512m -Xmx1024m"
resources:
limits:
cpu: 1000m
memory: 2000Mi
requests:
cpu: 250m
memory: 500Mi
Da die Mongo-DB kein Java-Process ist, funktioniert das oben beschriebene nicht für diesen POD/Container.
Deshalb hier ein Auszug wie man diese Limitierung aktivieren kann, die zu übernehmende Zeile ist Nr 5. Hier kannst du als Dezimalzahl (z.b. 1.5) den Heapspace in GB angeben. Wichtig ist, dass hierzu noch ca. 500 MB RAM für andere Teilprozesse benötigt werden:
containers:
- image: localhost:5000/e-spirit/caas-mongo:3.4.2
imagePullPolicy: Always
name: caas-mongo
args: ["mongod", "--auth", "--wiredTigerCacheSizeGB=1"]
Für die Zukunft relevant ist, dass man hier den entrypoint, welcher im default von e-Spirit mitkommt überschreibt. D.h. zuvor nachsehen, ob e-Spirit in einer neueren Version als 1.3.11 etwas geändert hat und dann hier die Argumente mit übernehmen.
Andernfalls nimmt sich die mongo-db ganz schön viel, nämlich Prozentual zu dem Node-RAM. Der eine Kubernetes Node hat bei mir 128GB RAM, demnach schaut es ohne obige Limitierung so aus, dass hier 48GB vom caas-mongo container "in Beschlag" genommen sind:
Zu diesem Thema mache ich bei Gelegenheit noch einen Community-Eintrag. Alle Java-PODs über den gleichen Weg zu konfigurieren, erscheint mir schon sehr sinnvoll (_JAVA_OPTIONS), da man hierüber dann sehr flexibel ist (remote-debugging, tracing, garbace collection settings, ..).
Viele Grüße
Markus
Hallo Benny,
Du kannst hier zwei Umgebungsvariablen dem caas-bus mitgeben ( CAAS_BUS_MIN_MEMORY und CAAS_BUS_MAX_MEMORY 😞
Auszug caas-bus.yml
- name: CAAS_BUS_MIN_MEMORY
value: "2000m"
- name: CAAS_BUS_MAX_MEMORY
value: "2000m"
resources:
limits:
cpu: 4000m
memory: 4000Mi
Mindestens 1GB benötigt der caas-bus. Danach den POD neustarten und es sollte wieder gehen.
Um weitere Java-Heapspace-Probleme zu umgehen (auch bei den anderen PODS), setze mal in den ymls (das geht auch beim caas-bus) für ...
- caas-rest-api
- caas-adapter
... die Umgebungsvariable "_JAVA_OPTIONS" - Details dazu findest du hier: java - Difference between _JAVA_OPTIONS JAVA_TOOL_OPTIONS and JAVA_OPTS - Stack Overflow
- caas-adapter.yml (Auszug):
- name: _JAVA_OPTIONS
value: "-Xms256m -Xmx512m"
resources:
limits:
cpu: 1000m
memory: 1000Mi
requests:
cpu: 250m
memory: 250Mi
- caas-rest-api.yml (Auszug):
- name: _JAVA_OPTIONS
value: "-Xms512m -Xmx1024m"
resources:
limits:
cpu: 1000m
memory: 2000Mi
requests:
cpu: 250m
memory: 500Mi
Da die Mongo-DB kein Java-Process ist, funktioniert das oben beschriebene nicht für diesen POD/Container.
Deshalb hier ein Auszug wie man diese Limitierung aktivieren kann, die zu übernehmende Zeile ist Nr 5. Hier kannst du als Dezimalzahl (z.b. 1.5) den Heapspace in GB angeben. Wichtig ist, dass hierzu noch ca. 500 MB RAM für andere Teilprozesse benötigt werden:
containers:
- image: localhost:5000/e-spirit/caas-mongo:3.4.2
imagePullPolicy: Always
name: caas-mongo
args: ["mongod", "--auth", "--wiredTigerCacheSizeGB=1"]
Für die Zukunft relevant ist, dass man hier den entrypoint, welcher im default von e-Spirit mitkommt überschreibt. D.h. zuvor nachsehen, ob e-Spirit in einer neueren Version als 1.3.11 etwas geändert hat und dann hier die Argumente mit übernehmen.
Andernfalls nimmt sich die mongo-db ganz schön viel, nämlich Prozentual zu dem Node-RAM. Der eine Kubernetes Node hat bei mir 128GB RAM, demnach schaut es ohne obige Limitierung so aus, dass hier 48GB vom caas-mongo container "in Beschlag" genommen sind:
Zu diesem Thema mache ich bei Gelegenheit noch einen Community-Eintrag. Alle Java-PODs über den gleichen Weg zu konfigurieren, erscheint mir schon sehr sinnvoll (_JAVA_OPTIONS), da man hierüber dann sehr flexibel ist (remote-debugging, tracing, garbace collection settings, ..).
Viele Grüße
Markus
