Docker : my container was OOMKilled

Intro

Un container Docker dispose de ressources limitées à sa création (cpu, mémoire…). Il se peut que le container crashe subitement s’il dispose de ressources insuffisantes. Dans le cas d’un manque de mémoire, on aura donc une erreur du type OOMKilled.

Vérification de l’état du container

Toutes les informations sur l’état du container :

docker inspect --format="{{json .State}}" $INSTANCE_ID

Retourne par exemple :

{"Status":"running","Running":true,"Paused":false,"Restarting":false,
"OOMKilled":false,"Dead":false,"Pid":2862,"ExitCode":0,"Error":"",
"StartedAt":"2018-06-13T13:41:47.205270058Z","FinishedAt":"2018-06-13T13:39:41.797869481Z"}

Flag OOMKilled :

docker inspect --format='{{.State.OOMKilled}}' $INSTANCE_ID

Retourne true si OOM

Flag ExitCode :

docker inspect --format='{{.State.ExitCode}}' $INSTANCE_ID

Retourne 137 en cas de crash dû à OOM.
137 = (128+9) Container received a SIGKILL

Tracer le problème dans une JVM

Au sein d’une JVM, on peut essayer de tracer l’erreur.

Voir par exemple les paramètres :

java -XX:+PrintFlagsFinal -version | grep -i outofmemoryerror

bool CrashOnOutOfMemoryError = false {product}
bool ExitOnOutOfMemoryError = false {product}
bool HeapDumpOnOutOfMemoryError = false {manageable}
ccstrlist OnOutOfMemoryError = {product}

Une version de JVM container-friendly

Des paramètres ont été rajoutés dans les versions récentes de la JVM, pour essayer d’adapter les paramètres mémoire de la JVM (Xms, Xmx) avec ceux du container dans lequel elle s’exécute.

A partir de JDK 8u131+ et JDK 9 on trouve donc de nouveaux paramètres, notamment pour la mémoire :

-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap

Tickets concernés

Références

Publicités