Das ist zwar etwas weit hergeholt, aber wir haben derzeit einige Probleme mit einer unserer Dockerized Java-Anwendungen:Stackoverlow-Frage
Wir haben das Docker-Speicherlimit auf 2 GB festgelegt, was weit über dem liegt, was die Java-Anwendung jemals nutzen könnte. Daher suche ich ernsthaft nach einer möglichen Ursache für dieses Problem.
Ist es möglich, dass das System während der Defragmentierung/Komprimierung des Speichers eine höhere Speichernutzung für die Anwendung meldet, für die es diese Vorgänge ausführt (auf dem ihm zugewiesenen Speicher) und deshalb den OOM-Killer von Docker auslöst?
Weitere Informationen zu einem der EC2-Server
cat /proc/Seitentypinfo
Page block order: 9
Pages per block: 512
Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10
Node 0, zone DMA, type Unmovable 1 0 0 1 2 1 1 0 1 0 0
Node 0, zone DMA, type Movable 0 0 0 0 0 0 0 0 0 1 3
Node 0, zone DMA, type Reclaimable 0 0 0 0 0 0 0 0 0 0 0
Node 0, zone DMA, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0
Node 0, zone DMA, type Isolate 0 0 0 0 0 0 0 0 0 0 0
Node 0, zone DMA32, type Unmovable 2160 1450 509 358 72 0 0 0 0 0 0
Node 0, zone DMA32, type Movable 39753 18110 3832 317 88 18 2 0 0 0 0
Node 0, zone DMA32, type Reclaimable 479 970 7 6 3 0 1 0 0 0 0
Node 0, zone DMA32, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0
Node 0, zone DMA32, type Isolate 0 0 0 0 0 0 0 0 0 0 0
Node 0, zone Normal, type Unmovable 72 410 350 0 0 0 0 0 0 0 0
Node 0, zone Normal, type Movable 132228 61046 1635 0 0 0 0 0 0 0 0
Node 0, zone Normal, type Reclaimable 0 2 7 1 0 0 0 0 0 0 0
Node 0, zone Normal, type HighAtomic 2 0 15 11 7 2 0 0 0 0 0
Node 0, zone Normal, type Isolate 0 0 0 0 0 0 0 0 0 0 0
Number of blocks type Unmovable Movable Reclaimable HighAtomic Isolate
Node 0, zone DMA 1 7 0 0 0
Node 0, zone DMA32 59 1391 78 0 0
Node 0, zone Normal 448 5888 127 1 0
cat /proc/sys/vm/extfrag_threshold
500
cat /sys/kernel/debug/extfrag/extfrag_index
Node 0, zone DMA -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000
Node 0, zone DMA32 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 0.988 0.994 0.997 0.999
Node 0, zone Normal -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 0.979 0.990 0.995 0.998 0.999
frei -h
total used free shared buff/cache available
Mem: 15G 11G 1.5G 1.2M 2.4G 3.7G
Swap: 4.0G 907M 3.1G
Dieses Problem haben wir nur auf unseren Produktionsservern (die seit fast einem Jahr laufen), unsere unteren Umgebungen werden jedes Wochenende gestoppt und wir haben es bisher nicht geschafft, dieses Problem manuell auszulösen. Trotzdem werden wir nächste Woche versuchen, die Server auszutauschen, in der Hoffnung, dass dieses Problem dann weitaus weniger wahrscheinlich auftritt.
Ich weiß, das ist weit hergeholt, ich bin kein Experte auf dem Gebiet der Linux-Speicherverwaltung und es ist sehr unwahrscheinlich, dass dies die Grundursache ist, aber es ist eine Frage, auf die ich gerne eine Antwort wüsste.