Kapitel 10 Einführung in die Steuerung des reellen Arbeitsspeichers mithilfe des Resource Capping Daemons

Mit dem Resource Capping Daemon rcapd können Sie den Speicherverbrauch durch Prozesse steuern, die in Projekten ausgeführt werden, für die Resource Caps (Ressourcenbegrenzungen) definiert sind.

Solaris 10 8/07: Wenn Zonen auf dem System ausgeführt werden, können Sie den rcapd von der globalen Zone aus einsetzen, um den Speicherverbrauch in nicht-globalen Zonen zu regulieren. Lesen Sie dazu Kapitel 18Planen und Konfigurieren von nicht-globalen Zonen (Vorgehen).

In diesem Kapitel werden folgende Themen behandelt.

• Einführung in den Resource Capping Daemon

• Funktionsweise von Memory Resource Caps

• Attribute zur Begrenzung der Nutzung des reellen Speichers für Projekte

• rcapd-Konfiguration

• Überwachen der Ressourcenauslastung mit rcapstat

• Mit rcapd verwendete Befehle

Informationen zu Verfahren, bei denen der rcapd eingesetzt wird, finden Sie in Kapitel 11Verwalten des Resource Capping Daemons (Vorgehen).

Neuerungen bei der Steuerung des reellen Arbeitsspeichers mithilfe des Resource Capping Daemons

Solaris 10: Sie können jetzt den Befehl projmod verwenden, um das Attribut rcap.max-rss in der Datei /etc/project einzurichten.

Solaris 10 11/06: Es wurden Informationen zum Aktivieren und Deaktivieren des Resource Capping Daemons als ein Service in der Solaris Service Management Facility (SMF) hinzugefügt.

Eine vollständige Liste der neuen Funktionen in Solaris 10 sowie eine Beschreibung der Solaris-Releases finden Sie in Neuerungen in Oracle Solaris 9 10/10.

Einführung in den Resource Capping Daemon

Eine Resource Cap (Speicherbegrenzung) ist ein oberer Grenzwert, der für den Verbrauch einer Ressource, z. B. von reellem Arbeitsspeicher, eingerichtet wird. Dabei werden Memory Caps für den reellen Speicher auf Projektbasis unterstützt.

Der Resource Capping Daemon und die dazugehörigen Dienstprogramme stellen Mechanismen bereit, mit denen eine Memory Cap für den reellen Speicher durchgesetzt und verwaltet werden kann.

Wie eine Resource Control kann eine Memory Resource Cap mithilfe von Attributen für Projekteinträge in der project-Datenbank definiert werden. Während Resource Controls synchron über den Kernel durchgesetzt werden, werden Memory Resource Caps asynchron auf Benutzerebene über den Resource Capping Daemon durchgesetzt. Bei asynchroner Durchsetzung tritt aufgrund des vom Daemon verwendeten Sampling-Intervalls immer eine kurze Verzögerung auf.

Weitere Informationen zu rcapd finden Sie in der Manpage rcapd(1M) Informationen zu Projekten und der project-Datenbank finden Sie in Kapitel 2Einführung in Projekte und Aufgaben und in der Manpage project(4) Weitere Informationen zu Resource Controls finden Sie in Kapitel 6Einführung in die Resource Controls.

Funktionsweise von Memory Resource Caps

Der Daemon misst in regelmäßigen Intervallen die Ressourcenauslastung durch Projekte, für die eine Memory Resource Cap eingerichtet wurde. Das Sampling-Intervall des Daemons wird vom Administrator festgelegt. Weitere Informationen finden Sie unter Festlegen der Messintervalle Wenn die Speicherauslastung durch das System den Schwellenwert für die Memory Cap-Durchsetzung überschreitet und andere Bedingungen erfüllt sind, führt der Daemon Maßnahmen aus, um den Ressourcenverbrauch durch Projekte mit Memory Caps zu reduzieren, bis der Schwellenwert oder ein darunter liegender Wert erreicht ist.

Das virtuelle Speichersystem teilt den reellen Speicher in Segmente auf, die als Pages (Seiten) bezeichnet werden. Pages sind die grundlegende Einheit des reellen Arbeitsspeichers im Solaris-Subsystem zur Speicherverwaltung. Um Daten aus einer Datei in den Speicher einzulesen, liest das virtuelle Speichersystem jeweils eine Page ein; man sagt auch, es erfolgt ein Page-in einer Datei. Zur Reduzierung des Ressourcenverbrauchs kann der Daemon ein Page-out bzw. eine Verlegung von selten genutzten Pages auf ein Swap-Gerät, einen Bereich außerhalb des reellen Speichers, durchführen.

Der Daemon verwaltet den reellen Speicher durch Regulieren der Resident Set-Größe der Arbeitslast eines Projekts in Relation zur Working Set-Größe. Ein Resident Set umfasst mehrere Pages, die im reellen Speicher festgespeichert sind. Ein Working Set umfasst mehrere Pages, die von der Arbeitslast des Projekts während des Verarbeitungszyklus aktiv genutzt werden. Das Working Set ändert sich über die Zeit, abhängig vom Betriebsmodus des Prozesses und dem Typ der verarbeiteten Daten. Im Idealfall hat jede Arbeitslast Zugriff auf ausreichend reellen Speicher, so dass das zugehörige Working Set resident bleiben kann (und nicht ausgelagert wird). Jedoch kann das Working Set auch die Nutzung von sekundären Festplattenspeicher umfassen. Dieser Bereich enthält Speicher, der nicht in den reellen Speicher passt.

Es kann nur jeweils eine Instanz von rcapd ausgeführt werden.

Attribute zur Begrenzung der Nutzung des reellen Speichers für Projekte

Zum Definieren einer Memory Resource Cap für ein Projekt stellen Sie eine Resident Set Size (RSS)-Cap ein, indem Sie das folgende Attribut zum project-Datenbankeintrag hinzufügen:

rcap.max-rss

Die Gesamtmenge des reellen Speichers in Byte, der Projektprozessen zur Verfügung steht.

Beispielsweise stellt die folgende Zeile in der Datei /etc/project eine RSS-Cap von 10 GB für ein Projekt namens db ein.

db:100::db,root::rcap.max-rss=10737418240

Das System rundet den angegebenen Cap-Wert eventuell auf die Größe einer Page ab.

Mit dem Befehl projmod können Sie das Attribut rcap.max-rss in der Datei /etc/project einstellen:

# projmod -s -K rcap.max-rss=10GB db

Die Datei /etc/project enthält dann die folgende Zeile:

db:100::db,root::rcap.max-rss=10737418240

rcapd-Konfiguration

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.

Verwenden des Resource Capping Daemons auf einem System mit installierten Zonen

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.

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.

Schwellenwert für die Memory Cap-Durchsetzung

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.

Festlegen der Memory Cap-Werte

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.

Auswirkungen auf das E/A-System

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.

Auswirkungen auf die CPU-Nutzung

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).

Berichte zum Shared Memory

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).

rcapd-Vorgangsintervalle

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.

Festlegen der rcapd-Suchintervalle

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.

Festlegen der Messintervalle

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.

Überwachen der Ressourcenauslastung mit rcapstat

Mit rcapstat überwachen Sie die Ressourcenauslastung durch Projekte, für die eine Memory Cap eingerichtet wurde. Ein Beispiel für einen rcapstat-Bericht finden Sie unter Erstellen von Berichten mit rcapstat.

Sie können das Messintervall für den Bericht und die Häufigkeit festlegen, wie oft Statistiken wiederholt werden.

Intervall

Legt das Messintervall in Sekunden fest. Das Standardintervall ist 5 Sekunden.

Zählung

Legt die Häufigkeit fest, wie oft Statistiken wiederholt werden. In der Standardeinstellung meldet rcapstat Statistiken, bis ein Signal zur Beendigung empfangen wurde oder der Prozess rcapd beendet wird.

Die Paging-Statistiken im ersten Bericht von rcapstat zeigen die Aktivität seit dem Starten des Daemons. Nachfolgende Berichte spiegeln die Aktivität nach der Veröffentlichung des jeweils letzten Berichts wider.

Die folgende Tabelle enthält Definitionen der Spaltenüberschriften eines rcapstat-Berichts.

Mit rcapd verwendete Befehle