Verwenden Sie diese Seite, um die Bedingungsmerkmale für eine Vitalitäts-Policy zu definieren, die Sie neu erstellen. Klicken Sie zum Anzeigen dieser Seite
der Administrationskonsole auf Betriebsbedingte Policys >
Vitalitäts-Policys > Neu.
Erweiterte Informationen zu den Merkmalen einer Vitalitäts-Policy:
Altersbasierte Bedingung:
Maximales Alter |
Dieses Feld setzt
den Alterswert so, dass die Policy die zugehörigen Member erneut startet, wenn sie diesen Wert erreichen.
Zulässige Werte sind positive ganze Zahlen
zwischen 1 Stunde und 365 Tagen. Dezimalzahlen werden nicht unterstützt.
Wenn Sie beispielsweise 1,5 Tage angeben möchten, müssen Sie den Wert in Stunden konvertieren und
36 Stunden angeben. |
Reaktionsmodus |
- Kontrollieren:
Gibt an, dass die Vitalitäts-Policys aktiv sind und Empfehlungen zu Aktionen an den Administrator gesendet werden, der
diese auf der Seite "Laufzeit-Tasks" akzeptieren oder zurückweisen kann.
- Automatisch: Gibt an, dass die Vitalitäts-Policys aktiv sind und das System sowohl Daten protokolliert als auch
Aktionen ausführt.
|
Aktionen auswählen, die bei einem Verstoß gegen die Vitalitätsbedingung ausgeführt werden sollen. |
Server erneut starten: Startet den Server erneut. Für die Policy mit altersbasierten Bedingungen
muss die Aktion "Server erneut starten" gewählt werden.
|
Bedingung für die Erkennung unangemessener Antwortzeiten:
Antwortzeit |
Dieses Feld ist nur für die Vitalitäts-Policy für die Erkennung unangemessener Antwortzeiten verfügbar.
Die Policy für die Erkennung unangemessener Antwortzeiten startet die Member erneut, wenn die Ausführung der durchschnittlichen Anzahl von Anforderungen
eine bestimmte Dauer überschreitet. Die gültigen Werte für dieses Feld
liegen im Bereich von 1 Millisekunde und 60 Minuten einschließlich. |
Reaktionsmodus |
- Kontrollieren:
Gibt an, dass die Vitalitäts-Policys aktiv sind und Empfehlungen zu Aktionen an den Administrator gesendet werden, der
diese akzeptieren oder zurückweisen kann.
- Automatisch: Gibt an, dass die Vitalitäts-Policys aktiv sind und das System sowohl Daten protokolliert als auch
Aktionen ausführt.
|
Aktionen auswählen, die bei einem Verstoß gegen die Vitalitätsbedingung ausgeführt werden sollen. |
Server erneut starten: Startet den Server erneut. Für die Policy mit Workload-Bedingungen
muss die Aktion "Server erneut starten" gewählt werden.
|
Bedingung für überhöhte Anzahl von Überschreitungen des Anforderungszeitlimits
Gesamtspeicherbelegung |
Die Policy für die Erkennung überhöhter Speicherbelegung startet die Member erneut, wenn die Speicherbelegung
über einen bestimmten Zeitraum hinweg einen bestimmten Prozentsatz des Heap-Speichers überschreitet.
Der Prozentsatz der Gesamtspeicherbelegung wird in Kombination mit der Einstellung "Zeit über Speicherschwellenwert"
verwendet, um festzustellen, wann Member erneut gestartet werden müssen. Die gültigen Werte für dieses Feld sind alle ganze Zahlen von
1 bis 99. |
Reaktionsmodus |
- Kontrollieren:
Gibt an, dass die Vitalitäts-Policys aktiv sind und Empfehlungen zu Aktionen an den Administrator gesendet werden, der
diese akzeptieren oder zurückweisen kann.
- Automatisch: Gibt an, dass die Vitalitäts-Policys aktiv sind und das System sowohl Daten protokolliert als auch
Aktionen ausführt.
|
Aktionen auswählen, die bei einem Verstoß gegen die Vitalitätsbedingung ausgeführt werden sollen. |
- Thread-Speicherauszüge erstellen:
Erstellt Thread-Speicherauszüge für IBM Java Development Kit.
- Server erneut starten: Startet den Server erneut.
|
Speicherbedingung: Überhöhte Speicherbelegung:
Gesamtspeicherbelegung |
Die Policy für die Erkennung überhöhter Speicherbelegung startet die Member erneut, wenn die Speicherbelegung
über einen bestimmten Zeitraum hinweg einen bestimmten Prozentsatz des Heap-Speichers überschreitet.
Der Prozentsatz der Gesamtspeicherbelegung wird in Kombination mit der Einstellung "Zeit über Speicherschwellenwert"
verwendet, um festzustellen, wann Member erneut gestartet werden müssen. Die gültigen Werte für dieses Feld sind alle ganze Zahlen von
1 bis 99. |
Zeit über Speicherschwellenwert |
Dieses Feld ist nur für die Policy für die Erkennung überhöhter Speicherbelegung verfügbar. Die Policy für die Erkennung überhöhter Speicherbelegung startet die Member erneut, wenn die Speicherbelegung
über einen bestimmten Zeitraum hinweg einen bestimmten Prozentsatz des Heap-Speichers überschreitet.
Die gültigen Werte für dieses Feld sind 1 Sekunde bis 60 Minuten einschließlich. |
Reaktionsmodus |
- Kontrollieren:
Gibt an, dass die Vitalitäts-Policys aktiv sind und Empfehlungen zu Aktionen an den Administrator gesendet werden, der
diese akzeptieren oder zurückweisen kann.
- Automatisch: Gibt an, dass die Vitalitäts-Policys aktiv sind und das System sowohl Daten protokolliert als auch
Aktionen ausführt.
|
Aktionen auswählen, die bei einem Verstoß gegen die Vitalitätsbedingung ausgeführt werden sollen. |
Server erneut starten: Startet den Server erneut. Für die Policy mit Workload-Bedingungen
muss die Aktion "Server erneut starten" gewählt werden.
|
Speicherbedingung: Speicherverlust:
Erkennungsstufe für Bedingung |
Sie können zwischen den folgenden Erkennungsstufen wählen. Bei der Auswahl der Erkennungsstufe müssen Sie
abwägen, was Ihnen wichtiger ist - die Geschwindigkeit oder die Genauigkeit bei der Erkennung potenzieller Speicherverluste.
- Schnellere Erkennung, höhere Wahrscheinlichkeit falscher Alarme:
Eine schnellere Erkennungs-Policy erkennt zwar potenzielle Speicherverluste schneller,
hat aber im Gegensatz zur einer langsameren Erkennungs-Policy die höhere Wahrscheinlichkeit, dass
fälschlicherweise ein Speicherverlust gemeldet wird, weil die Analyse durchgeführt wird, bevor
der Java-Heap-Speicher auf seine konfigurierte Maximalgröße erweitert wurde.
- Standarderkennung, Standardwahrscheinlichkeit falscher Alarme: Eine Standarderkennungs-Policy
ist genauer als eine schnellere Policy, erkennt dafür aber Speicherverluste nicht so schnell.
Für die Standarderkennung und die schnellere Erkennung wird dieselbe Menge von Verlaufdaten benötig, aber bei der Standarderkennung
werden die Daten erst dann analysiert, wenn der Java-Heap-Speicher auf die konfigurierte Maximalgröße erweitert wurde.
- Langsamere Erkennung, geringere Wahrscheinlichkeit falscher Alarme: Eine langsamere Erkennungs-Policy
ist am genauesten, erkennt aber potenzielle Speicherverluste nicht so schnell wie die schnellere Erkennungs-Policy.
Für die langsamere Erkennung werden die meisten Verlaufdaten benötigt.
|
Reaktionsmodus |
- Kontrollieren:
Gibt an, dass die Vitalitäts-Policys aktiv sind und Empfehlungen zu Aktionen an den Administrator gesendet werden, der
diese akzeptieren oder zurückweisen kann.
- Automatisch: Gibt an, dass die Vitalitäts-Policys aktiv sind und das System sowohl Daten protokolliert als auch
Aktionen ausführt.
|
Aktionen auswählen, die bei einem Verstoß gegen die Vitalitätsbedingung ausgeführt werden sollen. |
- Nur JVM-Heap-Speicherauszüge für IBM Java Development Kit (JDK) erstellen: Erstellt
Heap-Speicherauszüge für IBM JDK.
- Server erneut starten: Startet den Server erneut.
|
Eskalationsbedingung
Erkennungsstufe für Bedingung |
Sie können zwischen den folgenden Erkennungsstufen wählen. Bei der Auswahl der Erkennungsstufe müssen Sie
abwägen, was Ihnen wichtiger ist - die Geschwindigkeit oder die Genauigkeit bei der Erkennung potenzieller Speicherverluste.
- Standarderkennung, Standardwahrscheinlichkeit falscher Alarme: Eine Standarderkennungs-Policy
ist weniger genau als eine langsamere Policy, erkennt dafür aber Speicherverluste schneller.
Diese Policy verwendet weniger Proben (N=10) für Antwortzeiten und
dWLM-Wertigkeiten (Deployment Workload Manager) und versucht, basierend auf den Proben einen Änderungspunkt (oder eine Trendwende) in den Messwerten zu erkennen.
Sie trifft Annahmen schneller, weil sie 20 Proben abwartet (10 für den linken Durchschnittswert und 10 für den rechten
Durchschnittswert), um eine Abweichung bei den Durchschnittswerten zu berechnen und einen lokalen Maximalwert zu ermitteln.
Die Proben werden in einem Intervall von 15 Sekunden erfasst. Eine Eskalation kann innerhalb von fünf Minuten nach ihrem Auftreten erkannt werden.
Da die Anzahl der Proben geringer ist, besteht eine höhere Wahrscheinlichkeit falscher Alarme, wenn die Proben sehr viele Lastspitzen und
-täler enthalten.
- Langsamere Erkennung, geringere Wahrscheinlichkeit falscher Alarme: Eine langsamere Erkennungs-Policy
ist am genauesten, erkennt aber potenzielle Speicherverluste nicht so schnell wie die Standarderkennungs-Policy.
Diese Policy verwendet mehr Proben (N=15) für Antwortzeiten und dWLM-Wertigkeiten (Deployment Workload Manager).
Sie trifft Annahmen weniger schnell, weil sie 30 Proben (15 für
den linken Durchschnittswert und 15 für den rechten Durchschnittswert) abwarten muss, um eine Abweichung der
Durchschnittswerte zu berechnen.
Die Erkennungszeit beträgt sieben Minuten und 30 Sekunden. Da die Anzahl der Proben höher ist,
wirken sich Proben mit Lastspitzen und -tälern nur geringfügig auf die Durchschnittswerte aus.
Die Wahrscheinlichkeit falscher Alarme ist somit geringer.
|
Reaktionsmodus |
- Kontrollieren:
Gibt an, dass die Vitalitäts-Policys aktiv sind und Empfehlungen zu Aktionen an den Administrator gesendet werden, der
diese akzeptieren oder zurückweisen kann.
- Automatisch: Gibt an, dass die Vitalitäts-Policys aktiv sind und das System sowohl Daten protokolliert als auch
Aktionen ausführt.
|
Aktionen auswählen, die bei einem Verstoß gegen die Vitalitätsbedingung ausgeführt werden sollen. |
Server erneut starten: Startet den Server erneut. Für die Policy mit Workload-Bedingungen
muss die Aktion "Server erneut starten" gewählt werden.
|
Workload-basierte Bedingung:
Gesamtanzahl der Anforderungen |
In diesem Feld
können Sie der Workload-Policy einen numerischen Wert für die Anforderungsanzahl zuordnen. Die Workload-basierte Policy startet die Member erneut, wenn die hier festgelegte Anzahl
von Anforderungen bearbeitet wurde. Gültige Werte sind alle ganzen Zahlen zwischen
1000 und 9223372036854775807. |
Reaktionsmodus |
- Kontrollieren:
Gibt an, dass die Vitalitäts-Policys aktiv sind und Empfehlungen zu Aktionen an den Administrator gesendet werden, der
diese akzeptieren oder zurückweisen kann.
- Automatisch: Gibt an, dass die Vitalitäts-Policys aktiv sind und das System sowohl Daten protokolliert als auch
Aktionen ausführt.
|
Aktionen auswählen, die bei einem Verstoß gegen die Vitalitätsbedingung ausgeführt werden sollen. |
Server erneut starten: Startet den Server erneut. Für die Policy mit Workload-Bedingungen
muss die Aktion "Server erneut starten" gewählt werden.
|
Klicken Sie auf Weiter, nachdem Sie die Felder ausgefüllt haben.