Skip to main content

Deployment for target expired - Java heap space

Comments

2 comments

  • Zendesk API User
    Author: markus_priegl - 10/19/2017 14:52

    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

    0
  • Zendesk API User
    Author: kannengi - 10/20/2017 10:06

    Hallo Markus,

    danke für die kompetente Antwort!

    Funktioniert wieder alles :-)

    Viele Grüße,

    Benny

    0

Please sign in to leave a comment.