Grundlagen der Messung

Innerhalb des Java Programms stehen Methoden zur Verfügung, um die Größe des Speichers zu ermitteln, den die JVM aktuell vom Betriebssystem angefordert hat und zusätzlich, wie viel davon aktuell noch frei ist. Der Wert des belegten Speichers ergibt sich als Differenz. Die Werte sind aber nur ein Augenblicks-Bild, das nach wenigen Millisekunden schon verändert ist. Um einigermaßen aussagefähige Werte zu erhalten, muss man in relativ dichter Folge die Speicherauslastung immer wieder messen und kann dann durch Mathematik den Minimalwert, den Maximalwert, den Mittelwert und die Tendenz berechnen.

Durch die selbständige Arbeitsweise des Garbage Collectors wird es aber schwierig, Memory Leaks zu finden, weil bei mittlerer Speicherauslastung noch gar nicht ernstlich aufgeräumt wurde. Wir können nicht unterscheiden zwischen dem Speicher, der noch von ungültigen Objekten belegt wird, der aber später freigeräumt wird und dem Speicher, den der Garbage Collector nicht frei räumen kann. Die Summe aller Memory Leaks könnte man nur bestimmen, wenn aktuell kein einziges "lebendes" oder "totes" Objekt im Speicher liegen würde. Ein lebendes Objekt ist dabei ein Objekt, das noch innerhalb des Programms arbeitet. Sein Speicher ist vor dem Freigeben geschützt. Ein totes Objekt wird im Programm nicht mehr gebraucht. Es liegt aber noch im Speicher, weil der Garbage Collector es noch nicht zerstört hat und seinen Speicher noch nicht wieder frei gegeben hat.

In unserem Fall ist der Minimalwert des belegten Speichers wichtig. Dieser Wert wird periodisch im Abstand einiger Sekunden immer wieder ermittelt. Daraus werden zwei Werte abgeleitet, das absolute Minimum und das "gewichtete" aktuelle Minimum. Durch gelegentlichen Start des Garbage Collectors versuchen wir möglichst wenige tote Objekte mitzumessen. Dieser Start wird bei hoher Systemlast verzögert, so dass durch den Garbage Collector kein Performance-Nachteil für den Lobster_data entsteht. Das bedeutet aber, dass wir während einer Periode hoher Systemlast keine relevanten Werte erhalten.

Startverzögerung der Messung

Systeme verhalten sich beim Start und beim Herunterfahren anders, als während des kontinuierlichen Betriebs. Zur Überbrückung der Startphase beginnt die Memory Guard Application nach dem Systemstart erst nach einer Verzögerung mit der Messung. Diese Verzögerung wird durch den Parameter delayMinutes festgelegt. Danach startet die laufende Messung alle periodeMillis Millisekunden.

Bewertung der Messwerte

Das absolute Minimum des belegten Speichers und das aktuelle Minimum werden verglichen. Der Vergleich erfolgt im Zeitraster checkMinutes. Wenn das aktuelle Minimum um mehr als die Toleranz toleranceMB über dem absoluten Minimum liegt, wird die "gelbe Linie" erreicht. In diesem Fall wird versucht, die toten Objekte frei zu geben. Dadurch wird normalerweise wieder der grüne Bereich erreicht.

Normalerweise pendelt der Status also immer zwischen "grün" und "gelb". Mit dem Konfigurations-Parameter verbose=true werden Detail-Meldungen im Control Center unter Allgemeine Meldungen angezeigt, auch der Status "grün", "gelb" oder "rot".

Bei einem belasteten System wird der Start des Garbage Collectors verzögert, jedoch nicht länger als 10 mal checkMinutes. Als belastet gilt es, wenn mehr als 1/3 des RAM belegt ist.

Wird der grüne Bereich länger als redDelayMinutes nicht wieder erreicht, geht das System in den "roten" Alarmbereich über. In diesem Fall wird ein E-Mail mit einer Alarm-Meldung an die konfigurierte Adresse gesendet. Die Sendung wird nach weiteren redDelayMinutes wiederholt, wenn der "rote" Zustand weiter besteht.