Navigationslinks überspringen | |
Druckansicht beenden | |
![]() |
SystemAdministrationshandbuch: Oracle Solaris Container - RessourcenAdministration und Solaris Zones Oracle Solaris 10 1/13 Information Library (Deutsch) |
1. Einführung in Solaris 10-RessourcenAdministration
2. Einführung in Projekte und Aufgaben
3. Verwalten von Projekten und Aufgaben (Vorgehen)
4. Einführung in das Extended Accounting
5. Verwalten des Extended Accounting (Vorgehen)
6. Einführung in die Resource Controls
7. Verwalten von Resource Controls (Vorgehen)
8. Einführung in den Fair Share Scheduler
9. Verwalten des Fair Share Scheduler (Vorgehen)
10. Einführung in die Steuerung des reellen Arbeitsspeichers mithilfe des Resource Capping Daemons
Neuerungen bei der Steuerung des reellen Arbeitsspeichers mithilfe des Resource Capping Daemons
Einführung in den Resource Capping Daemon
Funktionsweise von Memory Resource Caps
Attribute zur Begrenzung der Nutzung des reellen Speichers für Projekte
Verwenden des Resource Capping Daemons auf einem System mit installierten Zonen
Schwellenwert für die Memory Cap-Durchsetzung
Festlegen der Memory Cap-Werte
Überwachen der Ressourcenauslastung mit rcapstat
11. Verwalten des Resource Capping Daemons (Vorgehen)
12. Einführung in Resource Pools
13. Erstellen und Verwalten von Resource Pools (Vorgehen)
14. Beispiel für die Konfiguration der RessourcenAdministration
15. Resource Controls in der Solaris Management-Konsole
16. Einführung in Solaris Zones
17. Einführung in die Konfiguration einer nicht-globalen Zone
18. Planen und Konfigurieren von nicht-globalen Zonen (Vorgehen)
19. Einführung in das Installieren, Anhalten, Klonen und Deinstallieren von nicht-globalen Zonen
20. Installieren, Booten, Anhalten, Deinstallieren und Klonen von nicht-globalen Zonen (Vorgehen)
21. Einführung in das Anmeldeverfahren bei einer nicht-globalen Zone
22. Anmelden bei nicht-globalen Zonen (Vorgehen)
23. Verschieben und Migrieren von nicht-globalen Zonen (Vorgehen)
24. Oracle Solaris 10 9/10: Migrieren eines reellen Oracle Solaris-Systems in eine Zone (Aufgaben)
27. Verwaltung der Oracle Solaris-Zonen (Überblick)
28. Verwaltung der Oracle Solaris-Zonen (Aufgaben)
29. Aktualisieren eines Oracle Solaris 10-Systems mit installierten nicht-globalen Zonen
30. Behebung von verschiedenen Problemen mit Oracle Solaris Zones
31. Allgemeine Informationen zu Branded Zones und der Linux Branded Zone
32. Einführung in die Planung der Konfiguration einer lx Branded Zone
33. Konfigurieren einer lx Branded Zone (Vorgehen)
34. Einführung in das Installieren, Booten, Anhalten, Klonen und Deinstallieren von lx Branded Zones
35. Installieren, Booten, Anhalten, Deinstallieren und Klonen von lx Branded Zones (Vorgehen)
36. Anmelden bei lx Branded Zones (Vorgehen)
37. Verschieben und Migrieren von lx Branded Zones (Vorgehen)
38. Verwalten und Ausführen von Anwendungen in lx Branded Zones (Vorgehen)
Mit dem Befehl rcapadm konfigurieren Sie den Resource Capping Daemon. Sie können die folgenden Aktionen durchführen:
Einrichten eines Schwellenwertes für die Cap-Durchsetzung
Einrichten der Intervalle für Vorgänge, die vom rcapd durchgeführt werden
Aktivieren oder Deaktivieren des Resource Capping
Anzeigen des aktuellen Status des konfigurierten Resource Capping Daemon
Zum Konfigurieren des Daemons müssen Sie als Superuser angemeldet sein oder über das „Process Management“-Profil verfügen. Das „Process Management“-Profil enthält die Prozessmanager-Rolle und die Systemadministrator-Rolle.
Konfigurationsänderungen können gemäß des Konfigurationsintervalls (siehe rcapd-Vorgangsintervalle) oder bei Bedarf durch Senden von SIGHUP (siehe Manpage kill(1)) in den rcapd eingebracht werden.
Erfolgt die Eingabe ohne Argumente, zeigt rcapadm den aktuellen Status des Resource Capping Daemons an, sofern dieser konfiguriert wurde.
In den folgenden Unterabschnitten werden die Cap-Durchsetzung, Cap-Werte und die Intervalle für rcapd-Vorgänge beschrieben.
Sie können die Resident Set Size (RSS)-Nutzung einer Zone durch Einstellen der Ressource capped-memory während der Zonenkonfiguration einrichten. Weitere Informationen finden Sie unter Solaris 10 8/07: Steuerung des reellen Speichers und der capped-memory-Ressource. Zur Durchsetzung von Memory Caps für Projekte in einer Zone (einschließlich der globalen Zone) führen Sie den Befehl rcapd in der Zone aus.
Sie können die Menge an Speicher, die von einer angegebenen Zone maximal beansprucht werden kann, temporär bis zum nächsten Neustart begrenzen. Lesen Sie dazu So legen Sie eine temporäre Resource Cap für eine Zone fest.
Wenn Sie rcapd in einer Zone verwenden, um den Speicherverbrauch durch Projektprozesse zu regulieren, für die Resource Caps definiert wurden, müssen Sie den Daemon in dieser Zone konfigurieren.
Beim Einrichten von Memory Caps für Anwendungen in unterschiedlichen Zonen muss allgemein nicht berücksichtigt werden, dass die Anwendungen in unterschiedlichen Zonen gespeichert sind. Die Ausnahme sind Services, die in allen Zonen ausgeführt werden. In allen Zonen ausgeführte Services verbrauchen Speicher. Dieser Speicherverbrauch muss bei der Ermittelung der erforderlichen Größe des reellen Speichers für ein System und der Memory Caps berücksichtigt werden.
Hinweis - Sie können rcapd nicht in einer lx Branded Zone ausführen. Sie können den Daemon jedoch von der globalen Zone aus verwenden, um den Speicher in der Branded Zone zu begrenzen.
Der Schwellenwert für die Memory Cap-Durchsetzung ist ein Prozentsatz der Systemspeicherauslastung, bei dem eine Cap-Durchsetzung ausgelöst wird. Wenn das System diese Auslastung überschreitet, werden die Memory Caps durchgesetzt. Der von Anwendungen und Kernel genutzte reelle Speicher ist in diesem Prozentsatz enthalten. Der Prozentsatz der Auslastung legt fest, wie Memory Caps durchgesetzt werden.
Um Memory Caps durchzusetzen, kann Speicher von Projekt-Arbeitslasten ausgelagert werden (Page-out).
Speicher wird ausgelagert, um den Betrag des Speichers zu reduzieren, der bei einer bestimmten Arbeitslast über die Memory Cap hinausgeht.
Speicher kann ausgelagert werden, um den Anteil an reellem Speicher zu reduzieren, der über den Memory Cap-Schwellenwert des Systems hinaus genutzt wird.
Eine Arbeitslast kann reellen Speicher bis ihrer Memory Cap nutzen. Eine Arbeitslast kann weiteren Speicher nutzen, solange die Systemspeicherauslastung unter dem Memory Cap-Schwellenwert bleibt.
Informationen zum Einrichten eines Schwellenwerts für die Memory Cap-Durchsetzung finden Sie unter So richten Sie einen Schwellenwert für die Memory Cap-Durchsetzung ein.
Ist der Schwellenwert eines Projekts zu niedrig angesetzt, steht eventuell nicht genügend Speicher für die Arbeitslast bereit, um unter normalen Bedingungen effektiv zu arbeiten. Das auftretende Paging (da die Arbeitslast mehr Speicher benötigt) hat negative Auswirkungen auf die Systemleistung.
Projekte, deren Memory Caps zu hoch eingerichtet wurden, verbrauchen eventuell den verfügbaren reellen Speicher, bevor ihre Memory Cap überschritten sind. In diesem Fall wird der reelle Speicher vom Kernel und nicht von rcapd verwaltet.
Bei der Festlegung von Memory Caps müssen Sie die folgenden Faktoren berücksichtigen.
Der Daemon kann versuchen, die Nutzung des reellen Speichers durch eine Projekt-Arbeitslast zu reduzieren, wenn die gemessene Nutzung die Memory Cap des Projekts überschreitet. Während der Cap-Durchsetzung werden die Swap-Geräte und andere Geräte verwendet, die von der Arbeitslast zugewiesene Dateien enthalten. Die Leistung der Swap-Geräte ist ein wichtiger Faktor für die Ermittlung der Leistung einer Arbeitslast, die ihren Memory Cap-Schwellenwert regelmäßig überschreitet. Die Ausführung der Arbeitslast ähnelt dem Ausführen der Arbeitslast auf einem Computer, dessen reeller Speicher der Memory Cap der Arbeitslast entspricht.
Die CPU-Nutzung durch den Daemon hängt von der Anzahl der Prozesse in der Projekt-Arbeitslast, für die das Capping durchgeführt wird, sowie von der Größe der Arbeitslast-Adressräume ab.
Ein kleiner Teil der CPU-Zeit des Daemons wird für das Messen der Nutzung durch jede Arbeitslast aufgewendet. Das Hinzufügen von Prozessen zu Arbeitslasten verlängert die Zeit, die für das Messen der Nutzung aufgewendet werden muss.
Ein weiterer Teil der CPU-Zeit des Daemons wird für die Durchsetzung von Memory Caps aufgewendet, wenn diese überschritten werden. Die aufgewendete Zeit ist proportional zur Größe des betroffenen virtuellen Speichers. Die aufgewendete CPU-Zeit verlängert oder verkürzt sich bei Änderungen der Gesamtgröße des Arbeitslast-Adressraums. Diese Daten werden in der Spalte vm der rcapstat-Ausgabe aufgeführt. Weitere Informationen finden Sie unter Überwachen der Ressourcenauslastung mit rcapstat und in der Manpage rcapstat(1).
Der Daemon rcapd meldet den RSS von Speicherseiten, die mit anderen Prozessen gemeinsam genutzt werden bzw. im gleichen Prozess mehrmals zugewiesen sind, als verhältnismäßig genauen Schätzwert. Wenn Prozesse in unterschiedlichen Projekten den gleichen Speicherbereich gemeinsam nutzen, wird dieser Speicherplatz zum RSS-Gesamtwert für alle Projekte, die auf diesen Speicher zugreifen, hinzugerechnet.
Dieser Schätzwert ist beispielsweise für Datenbanken nützlich, die Shared Memory ausgiebig verwenden. Bei Datenbanken können Sie zur Festlegung eines geeigneten Anfangsstandardwerts mithilfe der Optionen -J bzw. -Z des Befehls prstat eine Stichprobe des Speicherbedarfs eines Projekts ermitteln. Weitere Informationen finden Sie in der Manpage prstat(1M).
Sie können die Intervalle für die regelmäßig vom rcapd ausgeführten Vorgänge ändern.
Alle Intervalle werden in Sekunden angegeben. Die rcapd-Vorgänge und die zugehörigen Standardintervalle sind in der folgenden Tabelle angegeben.
|
Informationen zum Einrichten der Intervalle finden Sie unter So richten Sie Vorgangsintervalle ein.
Mit dem Suchintervall wird festgelegt, wie oft rcapd nach neuen Prozessen sucht. Bei Systemen mit vielen aktiven Prozessen dauert das Suchen in der Liste länger. In diesem Fall sollte das Intervall vergrößert werden, um die insgesamt aufgewendete CPU-Zeit zu reduzieren. Das Suchintervall muss jedoch mindestens der Zeit entsprechen, die ein Prozess existieren muss, um zu einer Arbeitslast mit Memory Cap beizutragen. Ist das Suchintervall zu lang, kann rcapd bei Arbeitslasten, die sehr viele kurzlebige Prozesse ausführen, eventuell nicht alle erforderlichen Prozesse erfassen.
Das mit rcapadm konfigurierte Messintervall ist der kürzeste Zeitraum, den rcapd zwischen dem Messen einer Ressourcennutzung durch eine Arbeitslast und dem Durchsetzen der Memory Cap wartet, wenn diese überschritten wird. Wenn Sie dieses Intervall reduzieren, setzt rcapd in den meisten Fällen die Memory Cap häufiger durch, was wiederum zu erhöhtem E/A-Datenverkehr aufgrund von Paging führen kann. Andererseits kann ein kürzeres Intervall die Auswirkungen eines von einer Arbeitslast verursachten plötzlichen Anstiegs der Ressourcennutzung auf andere Arbeitslasten verringern. Das Zeitfenster zwischen Messungen, in dem die Arbeitslast Speicher uneingeschränkt verbrauchen und möglicherweise Speicher von anderen Arbeitslasten mit Memory Cap wegnehmen könnte, wird eingeengt.
Ist das für rcapstat eingerichtete Messintervall kürzer als das für rcapd mit rcapadm, könnte die Ausgabe bei einigen Intervallen null sein. Dies liegt daran, dass rcapd die Statistiken nicht häufiger als das für rcapadm eingerichtete Intervall aktualisiert. Das für rcapadm eingerichtete Intervall ist unabhängig von dem Messintervall, das von rcapstat verwendet wird.