In diesem Teil wird die Solaris 10-Ressourcenverwaltung vorgestellt, mit der Sie festlegen können, wie Anwendungen verfügbare Systemressourcen nutzen.
Die Funktionen zur Ressourcenverwaltung bilden eine Komponente der Solaris Container-Umgebung. Mit der Ressourcenverwaltung können Sie festlegen, wie verfügbare Systemressourcen durch Anwendungen genutzt werden. Folgende Vorgehensweisen sind möglich:
Computerressourcen, z. B. Prozessorzeit, zuweisen
Die Auslastung der vorgenommenen Zuweisungen überwachen und dann ggf. anpassen
Extended Accounting-Daten zur Analyse, Abrechnung und Kapazitätsplanung erzeugen
In diesem Kapitel werden die folgenden Themen behandelt.
Moderne Computerumgebungen müssen flexibel auf sich ändernde Arbeitslasten reagieren können, die von verschiedenen Anwendungen auf einem System erzeugt werden. Eine Arbeitslast ist die Zusammenfassung aller Prozesse einer Anwendung oder Anwendungsgruppe. Ohne die Funktionen der Ressourcenverwaltung reagiert Solaris auf die Ansprüche von Arbeitlasten, indem es sich den neuen Anforderungen dynamisch anpasst. Diese Standardreaktion bedeutet allgemein, dass allen Aktivitäten auf einem System der gleiche Zugriff auf Ressourcen gewährt wird. Mit der Solaris-Ressourcenverwaltung können Arbeitslasten jedoch individuell behandelt werden. Folgende Vorgehensweisen sind möglich:
Den Zugriff auf eine bestimmte Ressource einschränken
Arbeitslasten bestimmte Ressourcen bevorzugt anbieten
Arbeitslasten voneinander isolieren
Als Ressourcenverwaltung wird die Fähigkeit bezeichnet, arbeitslastübergreifende Leistungseinbußen zu minimieren. Dies wird kombiniert mit Funktionen zur Überwachung von Ressourcennutzung und -auslastung. Die Ressourcenverwaltung wird über verschiedene Algorithmen umgesetzt. Diese Algorithmen verarbeiten die Kapazitätsanforderungen, die eine Anwendung während ihrer Ausführung stellt.
Mit den Funktionen der Ressourcenverwaltung können Sie das Standardverhalten des Betriebssystems in Bezug auf die verschiedenen Arbeitslasten anpassen. Verhalten bezieht sich hier auf die Entscheidungen der Betriebssystemalgorithmen, wenn eine Anwendung Ressourcenanforderungen an das System stellt. Mit den Funktionen der Ressourcenverwaltung können Sie:
Ressourcen verweigern oder eine Anwendung bevorzugen, indem Sie ihr einen größeren Anteil an den Ressourcen zuweisen
Bestimmte Zuweisungen kollektiv anstatt über isolierte Mechanismen behandeln
Die Übernahme einer Systemkonfiguration, die Funktionen der Ressourcenverwaltung verwendet, dient mehreren Zwecken. Folgende Vorgehensweisen sind möglich:
Die wahllose Belegung von Ressourcen durch eine Anwendung verhindern
Die Priorität einer Anwendung basierend auf externen Ereignissen ändern
Ressourcengarantien gleichmäßig an ein Anwendungsset verteilen, um maximale Systemauslastung zu erreichen
Bei der Planung einer ressourcenverwalteten Konfiguration sind die primären Anforderungen:
Die konkurrierenden Arbeitslasten auf dem System zu erkennen
Kooperierende Arbeitslasten von solchen Arbeitslasten zu unterschieden, deren Leistungsanforderungen sich negativ auf die primären Arbeitslasten auswirken
Nachdem kooperierende und konkurrierende Arbeitslasten identifiziert wurden, erstellen Sie eine Ressourcenkonfiguration, die den besten Kompromiss zwischen den betrieblichen Zielen Ihres Unternehmens und den Einschränkungen der Systemkapazitäten darstellt.
Eine effektive Ressourcenverwaltung in einem Solaris-System erfolgt über das Zusammenspiel von Mechanismen zur Steuerung, Benachrichtigung und Überwachung. Einige dieser Funktionen werden über Erweiterungen für vorhandene Mechanismen bereitgestellt, z. B. das proc(4)-Dateisystem, Prozessorsets und Scheduling-Klassen. Andere Funktionen sind nur für die Ressourcenverwaltung verfügbar. Diese Funktionen werden in den folgenden Kapiteln beschrieben.
Eine Ressource ist ein beliebiger Aspekt eines Computersystems, der geändert werden kann, um das Verhalten einer Anwendung zu beeinflussen. Somit ist eine Ressource ein Leistungsmerkmal, das eine Anwendung implizit oder explizit anfordert. Wird dieses Leistungsmerkmal verweigert oder ist es eingeschränkt, wird eine robust geschriebene Anwendung langsamer ausgeführt.
Im Gegensatz zur Identifizierung von Ressourcen kann die Klassifizierung von Ressourcen auf verschiedenen Achsen erfolgen. Die Achsen können implizit vs. explizit angefordert, zeitbasiert (z. B. CPU-Zeit) vs. zeitunabhängig (z. B. zugewiesene CPU-Shares) usw. darstellen.
Im Allgemeinen wird die Scheduler-basierte Ressourcenverwaltung für Ressourcen eingesetzt, die eine Anwendung implizit anfordern kann. So fordert eine Anwendung z. B. implizit zusätzliche CPU-Zeit an, um die Ausführung fortsetzen zu können. Eine andere Anwendung fordert implizit Bandbreite an, um Daten auf ein Netzwerk-Socket zu schreiben. Für implizit angeforderten Ressourcen können Einschränkungen hinsichtlich der Gesamtnutzung festgelegt werden.
Es können zusätzliche Schnittstellen eingeführt werden, so dass Bandbreite oder CPU-Serviceebenen explizit ausgehandelt werden können. Explizit angeforderte Ressourcen (beispielsweise eine Anforderung für einen zusätzlichen Thread) können mithilfe von Einschränkungen verwaltet werden.
Im Betriebssystem Solaris gibt es drei Arten von Steuerungsmechanismen: Einschränkungen, Scheduling und Partitionierung.
Mit Einschränkungen kann der Administrator oder Anwendungsentwickler Grenzen für den Verbrauch von bestimmten Ressourcen durch eine Arbeitslast festlegen. Mit bekannten Grenzen wird das Erstellen von Szenarien zum Ressourcenverbrauch einfacher. Grenzen vereinfachen auch die Steuerung fehlerhafter Anwendungen, die sich andernfalls durch unkontrollierte Ressourcenanforderungen negativ auf die Systemleistung oder -verfügbarkeit auswirken würden.
Einschränkungen stellen Komplikationen für eine Anwendung dar. Das Zusammenspiel von Anwendung und System kann bis zu einem Punkt modifiziert werden, an dem die Anwendung nicht mehr ordnungsgemäß funktioniert. Eine Möglichkeit, dieses Risiko zu mindern, besteht darin, die Einschränkungen nur an Anwendungen mit unbekannten Ressourcenverhalten anzuwenden. Die in Kapitel 6Einführung in die Resource Controls beschriebene Funktion der Resource Controls stellt einen solchen Einschränkungsmechanismus dar. Neuere Anwendungen können so geschrieben werden, dass sie sich ihrer Ressourceneinschränkungen bewusst sind, aber nicht alle Autoren nutzen diese Möglichkeit.
Scheduling bedeutet, verschiedene Zuweisungsentscheidungen in bestimmten Intervallen zu treffen. Eine getroffene Entscheidung basiert auf einem berechenbaren Algorithmus. Eine Anwendung, die ihre aktuell zugewiesenen Ressourcen nicht benötigt, überlässt sie einer anderen Anwendung zur Nutzung. Scheduling-basierte Ressourcenverwaltung ermöglicht die volle Auslastung eines nicht vollständig genutzten Systems und steuert gleichzeitig die Zuweisungen in einem kritisch oder übermäßig ausgelastetem Szenario. Der zu Grunde liegende Algorithmus definiert, wie der Begriff „gesteuert“ interpretiert wird. In einigen Fällen kann der Scheduling-Algorithmus garantieren, dass alle Anwendungen einen bestimmten Zugriff auf die Ressourcen haben. Der in Kapitel 8Einführung in den Fair Share Scheduler beschriebene Fair Share Scheduler (FSS) verwaltet und steuert den Zugriff von Anwendungen auf CPU-Ressourcen.
Die Partitionierung bindet eine Arbeitslast an einen Teil der verfügbaren Systemressourcen. Diese Binding garantiert, dass immer eine bekannte Ressourcenmenge für die Arbeitslast zur Verfügung steht. Mit der in Kapitel 12Einführung in Resource Pools beschriebenen Funktion der Resource Pools können Sie die Arbeitslasten auf bestimmte Teile des Computers beschränken.
Mit Konfigurationen, in denen die Partitionierung eingesetzt wird, lassen sich systemweite Überlastungen vermeiden. Andererseits könnte durch eben dieses Vermeiden von Überlastungen die Fähigkeit, eine möglichst hohe Systemauslastung zu erreichen, beeinträchtigt werden. Befindet sich die an eine Ressourcengruppe (z. B. Prozessoren) gebundene Arbeitslast im Leerlauf, steht diese gebundene Ressourcengruppe nicht mehr anderen Arbeitslasten zur Verfügung.
Teile der Konfiguration einer Ressourcenverwaltung können in einem Netzwerk-Namen-Service platziert werden. So kann der Administrator die Einschränkungen einer Ressourcenverwaltung auf mehrere Computer anstatt nur auf ein System anwenden. Verwandte Arbeiten können einen gemeinsamen Bezeichner nutzen, und die Gesamtnutzung dieser Arbeiten kann anhand der Accounting-Daten tabellarisch dargestellt werden.
Die Konfiguration der Ressourcenverwaltung und arbeitslastbezogene Bezeichner werden in Kapitel 2Einführung in Projekte und Aufgaben ausführlich beschrieben. Das Extended Accounting, das diese Bezeichner mit der Ressourcennutzung durch Anwendungen verbindet, ist in Kapitel 4Einführung in das Extended Accounting beschrieben.
Die Ressourcenverwaltung kann zusammen mit der Partitionierungssoftware Solaris Zones verwendet werden, um die Anwendungsumgebung genau anzupassen. Die Interaktionen zwischen den Funktionen der Ressourcenverwaltung und Solaris Zones werden in den entsprechenden Abschnitten dieses Handbuchs beschrieben.
Die Ressourcenverwaltung wird immer dann eingesetzt, wenn sichergestellt werden muss, dass Ihre Anwendungen vorgeschriebene Reaktionszeiten einhalten.
Die Ressourcenverwaltung kann auch die Ressourcenauslastung erhöhen. Durch Kategorisieren und Priorisieren der Nutzung können freie Kapazitäten außerhalb der Hauptbelastungszeiten effizient genutzt und so häufig den Bedarf für zusätzliche Prozessorleistung eliminiert werden. Außerdem können Sie sicherstellen, dass Ressourcen aufgrund sich ändernder Arbeitslasten nicht ungenutzt bleiben.
Die Ressourcenverwaltung eignet sich besonders für Umgebungen, in denen zahlreiche Anwendungen auf einem Server zusammengelegt sind.
Die hohen Kosten für die Verwaltung mehrerer Computer und deren Komplexität sprechen dafür, mehrere Anwendungen auf großen, besser skalierbaren Servern zu konsolidieren. Doch anstatt jeder Arbeitslast auf einem separaten System den vollen Zugriff auf die Systemressourcen zu gewähren, können Sie die Ressourcenverwaltung einsetzen, um Arbeitslasten innerhalb des Systems zu trennen. Die Ressourcenverwaltung kann zur Senkung der Gesamtkosten beitragen, indem mehrere unterschiedliche Anwendungen auf einem einzigen Solaris-System ausgeführt und gesteuert werden.
Wenn Sie Internet- und Anwendungsservices bereitstellen, können Sie mit der Ressourcenverwaltung:
Mehrere Webserver auf einem Computer hosten. Den Ressourcenverbrauch jeder Website steuern und jede Site vor potentiellem übermäßigen Ressourcenverbrauch anderer Sites schützen.
Den übermäßigen Verbrauch von CPU-Ressourcen durch ein fehlerhaftes Common Gateway Interface (CGI)-Skript verhindern.
Den Verbrauch des gesamten verfügbaren virtuellen Speicher durch eine fehlerhafte Anwendung verhindern.
Sicherstellen, dass die Anwendungen eines Kunden keine Anwendungen anderer Kunden beeinflussen, die am gleichen Standort ausgeführt werden.
Unterschiedliche Serviceebenen oder -klassen auf dem gleichen Computer bereitstellen.
Accounting-Daten für Abrechnungszwecke beziehen.
Ein ideales Einsatzgebiet für die Ressourcenverwaltung ist ein System, das zahlreiche Benutzer mit unterschiedlichen Anforderungen bedient, z. B. bei einem Bildungsinstitut. Wenn unterschiedliche Arbeitslasten vorliegen, kann die Software so konfiguriert werden, dass sie bestimmten Projekten Prioritäten einräumt.
Beispielsweise benötigen die Broker großer Maklerfirmen in unregelmäßigen Abständen schnellen Zugriff auf Ressourcen, um eine Abfrage oder eine Berechnung durchzuführen. Andere Systembenutzer haben hingegen konsistente Arbeitslasten. Wenn Sie den Projekten der Broker einen proportional größeren Betrag der Rechenleistung zuweisen, haben sie die benötigte Reaktionsschnelligkeit.
Die Ressourcenverwaltung eignet sich auch ideal für die Unterstützung von Thin-Client-Systemen. Diese Plattformen bieten statusfreie Konsolen mit Frame-Buffern und Eingabegeräte, z. B. SmartCards. Die tatsächliche Berechnung erfolgt auf einen gemeinsam genutzten Server, die gesamte Umgebung entspricht einem Timesharing-Modell. Mit den Funktionen der Ressourcenverwaltung können Sie die Benutzer auf dem Server voneinander isolieren. In diesem Fall kann ein Benutzer, der eine übermäßig hohe Last erzeugt, keine Hardwareressourcen monopolisieren oder die Leistung anderer Benutzer des gleichen Systems negativ beeinflussen.
Die folgende Übersicht der Schritte bietet einen allgemeinen Überblick der Schritte, die zum Einrichten der Ressourcenverwaltung auf dem System erforderlich sind.
Aufgabe |
Beschreibung |
Siehe |
---|---|---|
Identifizieren der Arbeitslasten auf dem System und Kategorisieren jeder Arbeitslast nach Projekt. |
Erstellen von Projekteinträgen entweder in der Datei /etc/project, in der NIS-Map oder im LDAP-Verzeichnisservice. | |
Priorisieren der Arbeitslasten auf dem System. |
Festlegen der unternehmenskritischen Anwendungen. Diese Arbeitslasten benötigen eventuell bevorzugten Zugriff auf Ressourcen. |
Lesen Sie die betrieblichen Ziele Ihres Unternehmens. |
Überwachen der Echtzeitaktivität auf dem System. |
Verwenden der Leistungswerkzeuge zum Anzeigen des aktuellen Ressourcenverbrauchs durch Arbeitslasten, die auf dem System ausgeführt werden. Schränken Sie aufgrund der Ergebnisse den Zugriff auf bestimmte Ressourcen ein oder isolieren Sie bestimmte Arbeitslasten. |
Überwachung nach System und in den Manpages cpustat(1M), iostat(1M), mpstat(1M), prstat(1M), sar(1) und vmstat(1M) |
Vornehmen von vorübergehenden Änderungen an Arbeitslasten, die auf dem System ausgeführt werden. |
Prüfen der im Solaris System verfügbaren Resource Controls, um festzustellen, welche Werte geändert werden können. Die Werte können während der Aufgaben- oder Prozessausführung von der Befehlszeile aus geändert werden. |
Verfügbare Resource Controls, Globale und lokale Aktionen mit Resource Control-Werten, Vorübergehendes Aktualisieren der Resource Control-Werte bei laufendem System und in den Manpages rctladm(1M) und prctl(1). |
Einstellen der Resource Controls und Projektattribute für jeden Projekteintrag in der project-Datenbank oder der Namen-Service-Projektdatenbank. |
Jeder Projekteintrag in der Datei /etc/project oder der Namen-Service-Projektdatenbank kann eine oder mehrere Resource Controls oder Attribute enthalten. Resource Controls schränken Aufgaben und Prozesse ein, die an das Projekt angehängt sind. Jedem für eine Resource Control eingerichteten Schwellenwert können eine oder mehrere Aktionen zugewiesen werden, die beim Erreichen des Schwellenwerts ausgeführt werden. Resource Controls können über die Befehlszeilenschnittstelle eingerichtet werden. Bestimmte Konfigurationsparameter können auch über die Solaris Management Console eingerichtet werden. |
project-Datenbank, Format der lokalen Datei /etc/project , Verfügbare Resource Controls, Globale und lokale Aktionen mit Resource Control-Werten und Kapitel 8Einführung in den Fair Share Scheduler |
Einrichten einer oberen Grenze für den Ressourcenverbrauch des reellen Speichers durch Prozesse, die an ein Projekt angehängt sind. |
Der Daemon zur Durchsetzung einer Ressourcenbegrenzung (Resource Cap Enforcement Daemon) setzt eine Begrenzung des reellen Speichers durch, die mit dem Projektattribut rcap.max-rss in der Datei /etc/project definiert wurde. |
project-Datenbank und Kapitel 10Einführung in die Steuerung des reellen Arbeitsspeichers mithilfe des Resource Capping Daemons |
Erstellen von Resource Pool-Konfigurationen. |
Resource Pools stellen eine Möglichkeit dar, Systemressourcen wie z. B. Prozessoren zu partitionieren und diese Partitionen auch nach einem Neustart beizubehalten. Sie können in jedem Eintrag in der Datei /etc/project ein project.pool-Attribut hinzufügen. |
project-Datenbank und Kapitel 12Einführung in Resource Pools |
Einrichten des Fair Share Scheduler (FSS) als standardmäßigem System-Scheduler. |
Sicherstellen, dass alle Benutzerprozesse auf einem System mit nur einer CPU oder einem Prozessorset zur gleichen Scheduling-Klasse gehören. |
Konfigurieren des FSS und in der Manpage dispadmin(1M) |
Aktivieren des Extended Accounting zum Überwachen und Aufzeichnen des Ressourcenverbrauchs auf Aufgaben- oder Projektbasis. |
Verwenden der Extended Accounting-Daten zur Bewertung der aktuellen Resource Controls und Planung der Kapazitätsanforderungen künftiger Arbeitslasten. Die aggregierte Nutzung kann systemweit aufgezeichnet werden. Um vollständige Nutzungsstatistiken für verwandte, mehrere Systeme umfassende Arbeitslasten zu erhalten, kann der Projektname auf mehreren Computern gemeinsam genutzt werden. |
So aktivieren Sie das Extended Accounting für Prozesse, Aufgaben und Flows und in der Manpage acctadm(1M) |
(Optional) Wenn zusätzliche Anpassungen an der Konfiguration vorgenehmen werden müssen, können Sie die Werte weiterhin über die Befehlszeile ändern. Sie können die Werte während der Aufgaben- oder Prozessausführung über die Befehlszeile ändern. |
Änderungen an bestehenden Aufgaben können vorübergehend angewendet werden, ohne dass das Projekt neu gestartet werden muss. Passen Sie die Werte weiter an, bis Sie mit der Leistung zufrieden sind. Dann aktualisieren Sie die aktuellen Werte in der Datei /etc/project oder in der Namen-Service-Projektdatenbank. |
Vorübergehendes Aktualisieren der Resource Control-Werte bei laufendem System und in den Manpages rctladm(1M) und prctl(1) |
(Optional) Erfassen der Extended Accounting-Daten. |
Schreiben der Extended Accounting-Datensätze für aktive Prozesse und Aufgaben. Die erzeugten Dateien können für Planung, Chargeback und Abrechnungszwecke verwendet werden. Darüber hinaus gibt es eine Perl-Schnittstelle zu libexacct, mit der Sie benutzerdefinierte Skripten zur Berichterstattung und Extraktion entwickeln können. |
wracct(1M) Manpage und Perl-Schnittstelle für libexacct |
In diesem Kapitel werden die Funktionen Projekt und Aufgabe der Solaris-Ressourcenverwaltung beschrieben. Mit Projekten und Aufgaben werden Arbeitslasten bezeichnet (mit einem Label versehen) und voneinander getrennt.
In diesem Kapitel werden folgende Themen behandelt:
Wie Projekte und Aufgaben verwendet werden, lesen Sie in Kapitel 3Verwalten von Projekten und Aufgaben (Vorgehen).
Zu den Erweiterungen von Solaris 10 gehören:
Unterstützung für skalierte Wert- und Einheitenmodifizierer für Ressourcenobjektwerte und -befehle
Verbesserte Validierung und vereinfachter Umgang mit dem Projektattributfeld
Überarbeitetes Ausgabeformat und neue Optionen für die Befehle prctl und projects
Möglichkeit zum Einstellen eines Benutzer-Standardprojekts mit dem Befehl useradd und Bearbeiten der Informationen mit den Befehlen usermod und passmgmt
Neben den Informationen in diesem Kapitel und in Kapitel 6Einführung in die Resource Controls sollten Sie auch die folgenden Manpages lesen:
Zu den Erweiterungen von Solaris 10 5/08 gehört die neue Option -A des Befehls projmod. Siehe Mit Projekten und Aufgaben verwendete Befehle.
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.
Um die Reaktionen von Arbeitslasten zu optimieren, müssen Sie zunächst die Arbeitslasten identifizieren können, die auf dem analysierten System ausgeführt werden. Diese Informationen sind jedoch mit einem rein prozessorientierten oder einen rein benutzerorientierten Ansatz nur schwer zu beziehen. Das Solaris System bietet Ihnen jedoch zwei zusätzliche Funktionen, mit denen Sie Arbeitslasten voneinander trennen und identifizieren können: das Projekt und die Aufgabe. Das Projekt bietet einen netzwerkweit geltenden administrativen Bezeichner für miteinander verwandte Arbeiten. Die Aufgabe fasst eine Prozessgruppe zu einer überschaubaren Einheit, einer Arbeitslastkomponente zusammen.
Die in der Namen-Service-Datenbank project angegebenen Resource Controls sind auf Prozess, Aufgabe und Projekt eingestellt. Da Resource Controls für Prozesse und Aufgaben über die Systemaufrufe fork und settaskid vererbt werden, gehen alle diese Resource Controls auf alle Prozesse und Aufgaben über, die innerhalb des Projekt erstellt werden. Weitere Informationen zu diesen Systemaufrufen finden Sie in den Manpages fork(2) und settaskid(2).
Basierend auf ihrer Projekt- oder Aufgabenmitgliedschaft können laufende Prozesse mit standardmäßigen Solaris-Befehlen bearbeitet werden. Mit dem Extended Accounting können Berichte zur Prozess- und Aufgabennutzung erstellt und jeder Datensatz mit einem übergeordneten Projektbezeichner versehen werden. Dieser Prozess ermöglicht, dass die Offline-Analyse von Arbeitslasten mit der Online-Überwachung abgestimmt wird. Der Projektbezeichner kann über die Namen-Service-Datenbank project auf mehreren Computern genutzt werden. Auf diese Weise kann der Ressourcenverbrauch durch verwandte Arbeitslasten, die auf mehreren Computern ausgeführt werden (oder mehrere Computer umfassen), über alle Computer analysiert werden.
Der Projektbezeichner ist ein administrativer Bezeichner zur Identifikation von verwandten Aufgaben. Der Projektbezeichner ist im Prinzip das Arbeitslast-Tag-Äquivalent zu den Benutzer- und Gruppenbezeichnern. Ein Benutzer oder eine Gruppe können zu einem oder mehreren Projekten gehören. Mit diesen Projekten werden die Arbeitslasten dargestellt, an denen der Benutzer (oder die Benutzergruppe) teilnehmen darf. Diese Mitgliedschaft kann als Basis des Chargeback verwendet werden, auf der z. B. die Nutzung oder die ursprünglichen Ressourcenzuordnungen basieren. Obwohl einem Benutzer ein Standardprojekt zugewiesen sein muss, können die vom Benutzer gestarteten Prozesse zu jedem Projekt gehören, bei dem der Benutzer Mitglied ist.
Jedem Benutzer muss ein Standardprojekt zugewiesen sein, damit er bzw. sie sich beim System anmelden kann. Ein Benutzer ist automatisch Mitglied dieses Standardprojekts. Dies gilt auch dann, wenn der Benutzer nicht in der für das Projekt angegebenen Benutzer- oder Gruppenliste enthalten ist.
Da jeder Prozess auf einem System über eine Projektmitgliedschaft verfügt, ist ein Algorithmus erforderlich, der bei der Anmeldung ein Standardprojekt oder einen anderen Anfangsprozess zuweist. Dieser Algorithmus ist in der Manpage getprojent(3C) beschrieben. Zur Ermittlung des Standardprojekts führt das System die im Folgenden aufgeführten Schritte in der angegebenen Reihenfolge aus. Wenn kein Standardprojekt gefunden wurde, wird die Benutzeranmeldung oder Anfrage nach einem Prozessstart verweigert.
Das System führt nacheinander die folgenden Schritte aus, um das Standardprojekt eines Benutzers zu ermitteln:
Verfügt der Benutzer über einen Eintrag mit einem project-Attribut in der Datenbank mit den erweiterten Benutzerattributen /etc/user_attr, wird der Wert des project-Attributs als Standardprojekt verwendet. Weitere Informationen finden Sie in der Manpage user_attr(4).
Ist ein Projekt mit dem Namen user.Benutzer-ID in der project-Datenbank vorhanden, wird dieses Projekt als Standardprojekt verwendet. Weitere Informationen entnehmen Sie bitte der Manpage krb5.conf (4).project(4)
Ist ein Projekt mit dem Namen group.Gruppenname in der project-Datenbank vorhanden und ist Gruppenname der Name der Standardgruppe des Benutzers (gemäß der passwd-Datei), wird dieses Projekt als Standardprojekt verwendet. Weitere Informationen zur passwd-Datei finden Sie in der Manpage passwd(4).
Ist das Sonderprojekt default in der project-Datenbank vorhanden, wird dieses Projekt als Standardprojekt verwendet.
Die Logik wird von der Bibliotheksfunktion getdefaultproj() bereitgestellt. Weitere Informationen finden Sie in der Manpage getprojent(3PROJECT).
Mit den folgenden Befehlen und der Option -K sowie einem Schlüssel=Wert-Paar können Sie die Benutzerattribute in lokalen Dateien einrichten:
Ändern vom Benutzerinformationen
Einrichten des Standardprojekts eines Benutzers
Ändern vom Benutzerinformationen
Lokale Dateien können Folgende umfassen:
/etc/group
/etc/passwd
/etc/project
/etc/shadow
/etc/user_attr
Wenn eine lokale Datei mit einem Netzwerk-Namen-Service wie NIS um zusätzliche Einträge ergänzt wird, können diese Befehle nicht zum Ändern der vom Netzwerk-Namen-Service bereitgestellten Daten verwendet werden. Mit den Befehlen kann jedoch Folgendes mit einer externen Namen-Service-Datenbank verglichen werden:
Eindeutigkeit des Benutzernamens (bzw. der Rolle)
Eindeutigkeit der Benutzer-ID
Vorhandensein der angegebenen Gruppennamen
Weitere Informationen finden Sie in den Manpages passmgmt(1M), useradd(1M), usermod(1M) und user_attr(4).
Sie können die Projektdaten in einer lokalen Datei, in einer Network Information Service (NIS)-Projektmap oder in einem Lightweight Directory Access Protocol (LDAP)-Verzeichnisservice speichern. Die Datei /etc/project oder der Namen-Service wird bei der Anmeldung und bei allen Anfragen zum Kontomanagement durch die plugfähige Authentifizierung (Pluggable Authentication Module, PAM) verwendet, um einen Benutzer an einen Standardprojekt zu binden.
Aktualisierungen der Einträge in der Projektdatenbank, ob an der Datei /etc/project oder an einer Repräsentation der Datenbank in einem Netzwerk-Namen-Service, werden nicht für die jeweils aktiven Projekte übernommen. Die Aktualisierungen werden jedoch für neue Aufgaben übernommen, die einem Projekt über die Befehle login oder newtask hinzugefügt werden. Weitere Informationen finden Sie in den Manpages login(1) und newtask(1).
Zu den Vorgängen, bei denen Identitäten geändert oder eingestellt werden, gehören die Anmeldung beim System, das Aufrufen des Befehls rcp oder rsh, oder das Verwenden von ftp oder su. Wenn ein Vorgang u. a. eine Identität ändert oder einstellt, wird ein Set mit konfigurierbaren Modulen verwendet, um Funktionen zur Authentifizierung, Kontoverwaltung und Sitzungsverwaltung bereitzustellen.
Das PAM-Modul zur Kontoverwaltung für Projekte ist in der Manpage pam_projects(5) dokumentiert. Eine Übersicht zum PAM finden Sie in Kapitel 17, Using PAM in System Administration Guide: Security Services.
Die Ressourcenverwaltung unterstützt die project-Datenbanken der Namen-Services. Der Speicherort der project-Datenbank ist in der Datei /etc/nsswitch.conf definiert. Standardmäßig wird files zuerst aufgelistet, aber die Quellen können in einer beliebigen Reihenfolge erscheinen.
project: files [nis] [ldap] |
Wenn mehrere Quellen für die Projektinformationen aufgelistet sind, sorgt die Datei nsswitch.conf dafür, dass die Suche nach Informationen in der ersten aufgeführten Quelle beginnt, dann werden alle aufgeführten Quellen nacheinander durchsucht.
Weitere Informationen zur Datei /etc/nsswitch.conf finden Sie in Kapitel 2, The Name Service Switch (Overview) in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) und in der Manpage nsswitch.conf(4).
Wenn Sie files als project-Datenbankquelle in der Datei nsswitch.conf auswählen, sucht der Anmeldeprozess in der Datei /etc/project nach Projektinformationen. Weitere Informationen finden Sie in den Manpages projects(1) und project(4).
Die Datei project enthält für jedes vom System erkannte Projekt einen einzeiligen Eintrag in dem folgenden Format:
projname:projid:comment:user-list:group-list:attributes |
Die Felder sind wie folgt definiert:
Der Name des Projekts. Der Name muss aus einer Zeichenfolge mit alphanumerischen Zeichen, Unterstrichen (_), Bindestrichen (-) und Punkten (.) bestehen. Der Punkt, der für Projekte mit besonderer Bedeutung für das Betriebssystem reserviert ist, kann nur in denNamen der Benutzer-Standardprojekte verwendet werden. Projname darf keinen Doppelpunkt (: ) oder ein Absatzzeichen enthalten.
Die einmalige numerische ID des Projekts (PROJID) innerhalb des Systems. Der Höchstwert im Feld Projid ist UID_MAX ( 2147483647).
Eine Beschreibung des Projekts.
Eine durch Kommata getrennte Liste der im Projekt zulässigen Benutzer.
In diesem Feld können Platzhalter verwendet werden. Bei einem Sternchen (*) ist es allen Benutzern gestattet, dem Projekt beizutreten. Bei einem Ausrufezeichen gefolgt von einem Sternchen (!*) sind alle Benutzer vom Projekt ausgeschlossen. Ein Ausrufezeichen (!) gefolgt von einem Benutzernamen schließt den angegebenen Benutzer vom Projekt aus.
Eine durch Kommata getrennte Liste der im Projekt zulässigen Gruppen.
In diesem Feld können Platzhalter verwendet werden. Bei einem Sternchen (*) ist es allen Gruppen gestattet, dem Projekt beizutreten. Bei einem Ausrufezeichen gefolgt von einem Sternchen (!*) sind alle Gruppen·vom Projekt ausgeschlossen. Ein Ausrufezeichen (!) gefolgt von einem Gruppennamen schließt die angegebene Gruppe vom Projekt aus.
Eine durch Semikola getrennte Liste von Name/Wert-Paaren, zum Beispiel Resource Controls (siehe Kapitel 6Einführung in die Resource Controls). Name ist eine willkürliche Zeichenfolge, die das objektbezogene Attribut angibt, und Wert ist der optionale Wert für das Attribut.
name[=value] |
In Name/Wert-Paaren sind die Namen auf Buchstaben, Zahlen, Unterstriche und Punkte beschränkt. Ein Punkt wird in der Regel als Trennzeichen zwischen den Kategorien und Unterkategorien der Resource Control (rctl) verwendet. Das erste Zeichen eines Attributnamens muss ein Buchstabe sein. Der Name ist abhängig von der Groß-/Kleinschreibung.
Werte können mithilfe von Kommata und Klammern strukturiert werden, um eine Rangfolge herzustellen.
Ein Semikolon dient zum Trennen von Name/Wert-Paaren. Es kann nicht in einer Wertdefinition verwendet werden. Ein Doppelpunkt dient zum Trennen von Projektfeldern. Er kann nicht in einer Wertdefinition verwendet werden.
Programmroutinen, die diese Datei einlesen, stoppen bei einem falsch formatierten Eintrag. Projekte, die hinter einem falschen formatierten Eintrag aufgeführt sind, werden nicht zugewiesen.
Das folgende Beispiel zeigt die Standarddatei /etc/project:
system:0:System::: user.root:1:Super-User::: noproject:2:No Project::: default:3:::: group.staff:10:::: |
Das folgende Beispiel zeigt die Standarddatei /etc/project, an deren Ende Projekteinträge hinzugefügt wurden:
system:0:System::: user.root:1:Super-User::: noproject:2:No Project::: default:3:::: group.staff:10:::: user.ml:2424:Lyle Personal::: booksite:4113:Book Auction Project:ml,mp,jtd,kjh:: |
Sie können der Datei /etc/project auch Resource Controls und Attribute hinzufügen:
Wie Sie einem Projekt Resource Controls hinzufügen, können Sie unter Einrichten von Resource Controls nachlesen.
Wie Sie mithilfe des in der Manpage rcapd(1M) beschriebenen Resource Capping Daemon eine Memory Resource Cap für ein Projekt hinzufügen, ist unter Attribute zur Begrenzung der Nutzung des reellen Speichers für Projekte beschrieben.
Wie Sie einem Projekteintrag ein project.pool-Attribut hinzufügen, können Sie unter Erstellen der Konfiguration nachlesen.
Wenn Sie NIS verwenden, können Sie in der Datei /etc/nsswitch.conf angeben, die NIS-Projektmaps nach Projekten zu durchsuchen:
project: nis files |
Die NIS-Maps, entweder project.byname oder project.bynumber, weisen das gleiche Format wie die Datei /etc/project auf:
projname:projid:comment:user-list:group-list:attributes |
Weitere Informationen finden Sie in Kapitel 4, Network Information Service (NIS) (Overview) in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
Wenn Sie LDAP verwenden, können Sie in der Datei /etc/nsswitch.conf angeben, die LDAP-Datenbank project nach Projekten zu durchsuchen:
project: ldap files |
Weitere Informationen zu LDAP finden Sie in Kapitel 8, Introduction to LDAP Naming Services (Overview/Reference) in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). Weitere Informationen zum Schema für Projekteinträge in einer LDAP-Datenbank finden Sie unter Solaris Schemas in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
Jede erfolgreiche Anmeldung bei einem Projekt erstellt eine neue Aufgabe, die den Anmeldeprozess enthält. Eine Aufgabe ist eine Sammlung von Prozessen, die ein Arbeitsset über die Zeit darstellt. Eine Aufgabe kann auch als eine Arbeitslastkomponente betrachtet werden. Jeder Aufgabe wird automatisch eine Aufgaben-ID zugewiesen.
Jeder Prozess ist Mitglied einer Aufgabe, und jede Aufgabe ist einem Projekt zugeordnet.
Alle Vorgänge in Prozessgruppen, z. B. die Signalübermittlung, werden auch für Aufgaben unterstützt. Sie können eine Aufgabe auch an ein Prozessorset binden und eine Scheduling-Priorität und -klasse für die Aufgabe einrichten, wodurch alle aktuellen und folgenden Prozesse in der Aufgabe geändert werden.
Eine Aufgabe wird immer dann erstellt, wenn ein Projekt verbunden wird. Aufgaben werden mit den folgenden Aktionen, Befehle und Funktionen erstellt:
login
cron
newtask
setproject
su
Eine abgeschlossene Aufgabe wird mit einer der folgenden Methoden erstellt. Alle weiteren Versuche, neue Aufgaben zu erstellen, schlagen fehl.
Geben Sie den Befehl newtask mit der Option -F ein.
Setzen Sie das Attribut task.final auf ein Projekt in der project-Datenbank des Namen-Service. Alle Aufgaben, die mit setproject in diesem Projekt erstellt werden, weisen das Flag TASK_FINAL auf.
Weitere Informationen finden Sie in den Manpages login(1), newtask(1), cron(1M), su(1M) und setproject(3PROJECT).
Accounting-Daten für Prozesse können mit dem Extended Accounting bereitgestellt werden. Die Daten werden auf Aufgabenebene zusammengefasst.
Die in der folgenden Tabelle aufgeführten Befehle stellen die primäre administrative Schnittstelle zu Projekten und Aufgaben dar.
Manpage |
Beschreibung |
---|---|
Zeigt die Projektmitgliedschaften der Benutzer an. Listet Projekte in der project-Datenbank auf. Druckt Informationen zu bestimmten Projekten. Wenn keine Projektnamen angegeben sind, werden Informationen zu allen Projekten angezeigt. Geben Sie den Befehl projects mit der Option -l ein, um eine ausführliche Ausgabe zu drucken. |
|
Führt die Standard-Shell des Benutzers oder einen angegebenen Befehl aus und platziert den Ausführungsbefehl in einer neuen Aufgabe, deren Eigentümer das angegebene Projekt ist. newtask kann auch zum Ändern der Aufgabe und der Projektbindung für einen laufenden Prozess verwendet werden. Geben Sie den Befehl mit der Option -F ein, um eine abgeschlossene Aufgabe zu erstellen. |
|
Aktualisiert die Informationen in den Passwortdateien. Geben Sie diesen Befehl mit der Option -K Schlüssel=Wert ein, um Benutzerattribute hinzuzufügen oder Benutzerattribute in lokalen Dateien zu ersetzen. |
|
Fügt einen neuen Projekteintrag in die Datei /etc/project ein. Der Befehl projadd erstellt den Projekteintrag nur auf dem lokalen System. projadd kann keine Daten ändern, die über den Netzwerk-Namen-Service bereitgestellt werden. Kann zum Bearbeiten von Projektdateien verwendet werden, bei denen es sich nicht um die Standarddatei /etc/project handelt. Bietet eine Syntaxüberprüfung der project-Datei. Validiert und bearbeitet Projektattribute. Unterstützt skalierte Werte. |
|
Ändert die Informationen zu einem Projekt auf dem lokalen System. projmod kann keine Daten ändern, die über den Netzwerk-Namen-Service bereitgestellt werden. Sie können mit diesem Befehl jedoch die Eindeutigkeit des Projektnamens und der Projekt-ID gegen einen externen Namen-Service prüfen. Kann zum Bearbeiten von Projektdateien verwendet werden, bei denen es sich nicht um die Standarddatei /etc/project handelt. Bietet eine Syntaxüberprüfung der project-Datei. Validiert und bearbeitet Projektattribute. Kann zum Hinzufügen eines neuen Attributs, zum Hinzufügen von Werten zu einem Attribut oder zum Entfernen eines Attributs verwendet werden. Unterstützt skalierte Werte. Kann ab Solaris-Release 10 5/08 mit der Option -A zum Anwenden der in der Projektdatenbank des aktiven Projekts gefundenen Resource Control-Werte verwendet werden. Vorhandene Werte, die nicht mit den in der Datei project definierten Werten übereinstimmen, wie z. B. mithilfe des Befehls prctl manuell eingegebene Werte, werden entfernt. |
|
Löscht ein Projekt vom lokalen System. projdel kann keine Daten ändern, die über den Netzwerk-Namen-Service bereitgestellt werden. |
|
Fügt Standard-Projektdefinitionen zu lokalen Dateien hinzu. Geben Sie diesen Befehl mit der Option -K Schlüssel=Wert ein, um Benutzerattribute hinzuzufügen oder zu ersetzen. |
|
Löscht ein Benutzerkonto aus der lokalen Datei. |
|
Ändert die Anmeldeinformationen eines Benutzers auf dem System. Geben Sie diesen Befehl mit der Option -K Schlüssel=Wert ein, um Benutzerattribute hinzuzufügen oder zu ersetzen. |
In diesem Kapitel wird beschrieben, wie die Leistungsmerkmale Projekt und Aufgabe der Solaris-Ressourcenverwaltung verwendet werden.
In diesem Kapitel werden folgende Themen behandelt.
Eine allgemeine Einführung in die Leistungsmerkmale Projekte und Aufgaben finden Sie in Kapitel 2Einführung in Projekte und Aufgaben.
Wenn Sie diese Funktionen auf einem Solaris-System mit installierten Zonen verwenden, sind über die Systemaufruf-Schnittstellen, die Prozess-IDs akzeptieren, nur Prozesse in der gleichen Zone sichtbar (wenn diese Befehle in einer nicht-globalen Zone ausgeführt werden).
Aufgabe |
Beschreibung |
Siehe |
---|---|---|
Anzeigen von Beispielen für Befehle und Optionen, die mit Projekten und Aufgaben verwendet werden können. |
Anzeigen von Aufgaben- und Projekt-IDs, Anzeigen von verschiedenen Statistiken zu Prozessen und Projekten, die aktuell auf dem System ausgeführt werden. | |
Definieren eines Projekts. |
Hinzufügen eines Projekteintrags zur Datei /etc/project und Ändern der Werte für diesen Eintrag. |
So definieren Sie ein Projekt und zeigen das aktuelle Projekt an |
Löschen eines Projekts. |
Entfernen eines Projekteintrags aus der Datei /etc/project. | |
Validieren der project-Datei oder der Projektdatenbank. |
Überprüfen der Syntax der Datei /etc/project oder Sicherstellen der Eindeutigkeit des Projektnamens und in der Projekt-ID anhand des externen Namen-Services. | |
Abrufen von Informationen zur Projektmitgliedschaft. |
Anzeigen der aktuellen Projektmitgliedschaft des aufrufenden Prozesses. | |
Erstellen einer neuen Aufgabe. |
Erstellen einer neuen Aufgabe in einem bestimmten Projekt mit dem Befehl newtask. | |
Zuweisen eines laufenden Prozesses zu einer anderen Aufgabe und einem anderen Projekt. |
Zuweisen einer Prozessnummer zu einer neuen Aufgaben-ID in einem bestimmten Projekt. |
So verschieben Sie einen laufenden Prozess in eine neue Aufgabe |
Hinzufügen und Arbeiten mit Projektattributen. |
Verwenden der Projektdatenbank- Administrationsbefehle zum Hinzufügen, Bearbeiten, Validieren und Entfernen von Projektattributen. |
Im folgenden Abschnitt sind Beispiele für Befehle und Optionen aufgeführt, die mit Projekten und Aufgaben verwendet werden können.
Mit dem Befehl ps und der Option -o können Sie die Aufgaben- und Projekt-IDs anzeigen. Um beispielsweise die Projekt-ID anzuzeigen, geben Sie Folgendes ein:
# ps -o user,pid,uid,projid USER PID UID PROJID jtd 89430 124 4113 |
Mit dem Befehl id und der Option -p können Sie die aktuelle Projekt-ID nebst Benutzer- und Gruppen-IDs drucken. Wenn der Operand Benutzer angegeben ist, wird das Projekt gedruckt, das dem Anmeldenamen dieses Benutzers zugeordnet ist:
# id -p uid=124(jtd) gid=10(staff) projid=4113(booksite) |
Um nur Prozesse mit einer Projekt-ID in einer bestimmten Liste zu suchen, geben Sie die Befehle pgrep und pkill mit der Option -J ein:
# pgrep -J projidlist # pkill -J projidlist |
Um nur Prozesse mit einer Aufgaben-ID in einer bestimmten Liste zu suchen, geben Sie die Befehle pgrep und pkill mit der Option -T ein:
# pgrep -T taskidlist # pkill -T taskidlist |
Um verschiedene Statistiken zu Prozessen und Projekten anzuzeigen, die aktuell auf dem System ausgeführt werden, geben Sie den Befehl prstat mit der Option -J ein:
% prstat -J PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 21634 jtd 5512K 4848K cpu0 44 0 0:00.00 0.3% prstat/1 324 root 29M 75M sleep 59 0 0:08.27 0.2% Xsun/1 15497 jtd 48M 41M sleep 49 0 0:08.26 0.1% adeptedit/1 328 root 2856K 2600K sleep 58 0 0:00.00 0.0% mibiisa/11 1979 jtd 1568K 1352K sleep 49 0 0:00.00 0.0% csh/1 1977 jtd 7256K 5512K sleep 49 0 0:00.00 0.0% dtterm/1 192 root 3680K 2856K sleep 58 0 0:00.36 0.0% automountd/5 1845 jtd 24M 22M sleep 49 0 0:00.29 0.0% dtmail/11 1009 jtd 9864K 8384K sleep 49 0 0:00.59 0.0% dtwm/8 114 root 1640K 704K sleep 58 0 0:01.16 0.0% in.routed/1 180 daemon 2704K 1944K sleep 58 0 0:00.00 0.0% statd/4 145 root 2120K 1520K sleep 58 0 0:00.00 0.0% ypbind/1 181 root 1864K 1336K sleep 51 0 0:00.00 0.0% lockd/1 173 root 2584K 2136K sleep 58 0 0:00.00 0.0% inetd/1 135 root 2960K 1424K sleep 0 0 0:00.00 0.0% keyserv/4 PROJID NPROC SIZE RSS MEMORY TIME CPU PROJECT 10 52 400M 271M 68% 0:11.45 0.4% booksite 0 35 113M 129M 32% 0:10.46 0.2% system Total: 87 processes, 205 lwps, load averages: 0.05, 0.02, 0.02 |
Um verschiedene Statistiken zu Prozessen und Aufgaben anzuzeigen, die aktuell auf dem System ausgeführt werden, geben Sie den Befehl prstat mit der Option -T ein:
% prstat -T PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 23023 root 26M 20M sleep 59 0 0:03:18 0.6% Xsun/1 23476 jtd 51M 45M sleep 49 0 0:04:31 0.5% adeptedit/1 23432 jtd 6928K 5064K sleep 59 0 0:00:00 0.1% dtterm/1 28959 jtd 26M 18M sleep 49 0 0:00:18 0.0% .netscape.bin/1 23116 jtd 9232K 8104K sleep 59 0 0:00:27 0.0% dtwm/5 29010 jtd 5144K 4664K cpu0 59 0 0:00:00 0.0% prstat/1 200 root 3096K 1024K sleep 59 0 0:00:00 0.0% lpsched/1 161 root 2120K 1600K sleep 59 0 0:00:00 0.0% lockd/2 170 root 5888K 4248K sleep 59 0 0:03:10 0.0% automountd/3 132 root 2120K 1408K sleep 59 0 0:00:00 0.0% ypbind/1 162 daemon 2504K 1936K sleep 59 0 0:00:00 0.0% statd/2 146 root 2560K 2008K sleep 59 0 0:00:00 0.0% inetd/1 122 root 2336K 1264K sleep 59 0 0:00:00 0.0% keyserv/2 119 root 2336K 1496K sleep 59 0 0:00:02 0.0% rpcbind/1 104 root 1664K 672K sleep 59 0 0:00:03 0.0% in.rdisc/1 TASKID NPROC SIZE RSS MEMORY TIME CPU PROJECT 222 30 229M 161M 44% 0:05:54 0.6% group.staff 223 1 26M 20M 5.3% 0:03:18 0.6% group.staff 12 1 61M 33M 8.9% 0:00:31 0.0% group.staff 1 33 85M 53M 14% 0:03:33 0.0% system Total: 65 processes, 154 lwps, load averages: 0.04, 0.05, 0.06 |
Die Optionen -J und -T können nicht zusammen verwendet werden.
Der Befehl cron gibt eine settaskid aus, mit der sichergestellt wird, dass jeder cron-, at- und batch-Job in einer separaten Aufgabe mit dem entsprechenden Standardprojekt für den übermittelnden Benutzer ausgeführt wird. Darüber hinaus erfassen die Befehle at und batch die aktuelle Projekt-ID, wodurch sichergestellt wird, dass die Projekt-ID beim Ausführen eines at-Jobs wiederhergestellt wird.
Mit dem Befehl su wird das Standardprojekt des Zielbenutzers als Teil einer simulierten Anmeldung durch das Erstellen einer neuen Aufgabe aufgenommen.
Um das Standardprojekt des Benutzers mit dem Befehl su zu ändern, geben Sie Folgendes ein:
# su user |
Im folgenden Beispiel wird gezeigt, wie Sie einen Projekteintrag mit dem Befehl projadd hinzufügen und diesen Eintrag dann mit dem Befehl projmod ändern.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Zeigen Sie die Standarddatei /etc/project auf dem System mit dem Befehl projects -l an.
# projects -l system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10::::system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs: |
Fügen Sie ein Projekt mit dem Namen booksite hinzu. Weisen Sie das Projekt dem Benutzer mark mit der Projekt-ID 4113 zu.
# projadd -U mark -p 4113 booksite |
Zeigen Sie die Datei /etc/project noch einmal an.
# projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs: booksite projid : 4113 comment: "" users : mark groups : (none) attribs: |
Fügen Sie einen Kommentar, der das Projekt beschreibt, in das Kommentarfeld ein.
# projmod -c `Book Auction Project' booksite |
Zeigen Sie die Änderungen in der Datei /etc/project an.
# projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs: booksite projid : 4113 comment: "Book Auction Project" users : mark groups : (none) attribs: |
Wie Sie Projekte, Aufgaben und Prozesse an einen Pool binden, können Sie unter Einrichten von Pool-Attributen und Binden an einen Pool nachlesen.
Im folgenden Beispiel wird gezeigt, wie Sie ein Projekt mit dem Befehl projdel löschen.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Entfernen Sie das Projekt booksite mit dem Befehl projdel.
# projdel booksite |
Zeigen Sie die Datei /etc/project an.
# projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs: |
Melden Sie sich als der Benutzer mark an und geben Sie projects ein, um die Projekte anzuzeigen, die diesem Benutzer zugeordnet sind.
# su - mark # projects default |
Wenn keine Bearbeitungsoptionen angegeben sind, validiert der Befehl projmod den Inhalt der Datei project.
Zum Validieren einer NIS-Map melden Sie sich als Superuser an und geben Folgendes ein:
# ypcat project | projmod -f — |
Der Befehl ypcat project | projmod -f - ist noch nicht implementiert.
Zum Überprüfen der Syntax der Datei /etc/project geben Sie Folgendes ein:
# projmod -n |
Geben Sie den Befehl id mit der Option -p ein, um die aktuelle Projektmitgliedschaft des aufrufenden Prozesses anzuzeigen.
$ id -p uid=100(mark) gid=1(other) projid=3(default) |
Melden Sie sich als ein Mitglied des Zielprojekts booksite an.
Erstellen Sie eine neue Aufgabe im Projekt booksite. Geben Sie dazu den Befehl newtask mit der Option -v (verbose) ein, um die System-Aufgaben-ID zu beziehen.
machine% newtask -v -p booksite 16 |
Die Ausführung von newtask erstellt eine neue Aufgabe im angegebenen Projekt und platziert die Standard-Shell des Benutzers in dieser Aufgabe.
Zeigen Sie die aktuelle Projektmitgliedschaft des aufrufenden Prozesses an.
machine% id -p uid=100(mark) gid=1(other) projid=4113(booksite) |
Der Prozess ist jetzt Mitglied des neuen Projekts.
Im folgenden Beispiel wird gezeigt, wie Sie einen laufenden Prozess einer anderen Aufgabe und einem neuen Projekt zuweisen. Um diese Aktion auszuführen, müssen Sie entweder als Superuser angemeldet oder Eigentümer des Prozesses und Mitglied des neuen Projekts sein.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Wenn Sie Eigentümer des Prozesses oder Mitglied des neuen Projekts sind, können Sie diesen Schritt überspringen.
Beziehen Sie die Projekt-ID des Prozesses book_catalog.
# pgrep book_catalog 8100 |
Ordnen Sie den Prozess 8100 der neuen Aufgaben-ID im Projekt booksite zu.
# newtask -v -p booksite -c 8100 17 |
Die Option -c gibt an, dass newtask auf den bestehenden benannten Prozess angewendet wird.
Bestätigen Sie die Zuordnung der Aufgabe zur Prozess-ID.
# pgrep -T 17 8100 |
Mit den Projektdatenbank-Administrationsbefehlen projadd und projmod können Sie die Projektattribute bearbeiten.
Die Option -K gibt eine Ersatzliste der Attribute an. Attribute werden durch Semikola (;) voneinander getrennt. Wenn die Option -K mit der Option -a angegeben ist, wird das Attribut oder der Attributwert hinzugefügt. Wenn die Option -K mit der Option -r angegeben ist, wird das Attribut oder der Attributwert entfernt. Wenn die Option -K mit der Option -s angegeben ist, wird das Attribut oder der Attributwert ersetzt.
Geben Sie den Befehl projmod mit den Optionen -a und -K ein, um einem Projektattribut Werte hinzuzufügen. Wenn das Attribut nicht existiert, wird es erstellt.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Geben Sie das Resource Control-Attribut task.max-lwps ohne Werte in das Projekt myproject ein. Eine in das Projekt aufgenommene Aufgabe weist nur den Systemwert für das Attribut auf.
# projmod -a -K task.max-lwps myproject |
Anschließend können Sie dem Projekt myproject einen Wert für task.max-lwps hinzufügen. Der Wert setzt sich aus einer Berechtigungsstufe, einem Schwellenwert und einer Aktion zusammen, die ausgeführt wird, wenn der Schwellenwert erreicht ist.
# projmod -a -K "task.max-lwps=(priv,100,deny)" myproject |
Da Resource Controls mehrere Werte akzeptieren, können Sie der vorhandenen Werteliste mit den gleichen Optionen einen weiteren Wert hinzufügen.
# projmod -a -K "task.max-lwps=(priv,1000,signal=KILL)" myproject |
Mehrere Werte werden durch Kommata voneinander getrennt. Der Eintrag task.max-lwps lautet jetzt wie folgt:
task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL) |
Bei diesem Verfahren werden folgende Werte angenommen:
task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL) |
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Um einen Attributwert von der Resource Control task.max-lwps im Projekt myproject zu entfernen, geben Sie den Befehl projmod mit den Optionen -r und -K ein.
# projmod -r -K "task.max-lwps=(priv,100,deny)" myproject |
Wenn task.max-lwps mehrere Werte enthält, z. B.:
task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL) |
wird nur der erste entsprechende Wert gelöscht. Das Ergebnis wäre:
task.max-lwps=(priv,1000,signal=KILL) |
Um die Resource Control task.max-lwps aus dem Projekt myproject zu entfernen, geben Sie den Befehl projmod mit den Optionen -r und -K ein.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Entfernen Sie das Attribut task.max-lwps und alle zugehörigen Werte aus dem Projekt myproject:
# projmod -r -K task.max-lwps myproject |
Um einen anderen Wert für das Attribut task.max-lwps im Projekt myproject einzusetzen, geben Sie den Befehl projmod mit den Optionen -s und -K ein. Wenn das Attribut nicht existiert, wird es erstellt.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Ersetzen Sie die aktuellen Werte für task.max-lwps durch die angezeigten neuen Werte:
# projmod -s -K "task.max-lwps=(priv,100,none),(priv,120,deny)" myproject |
Das Ergebnis wäre:
task.max-lwps=(priv,100,none),(priv,120,deny) |
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Um die aktuellen Werte für die Resource Control task.max-lwps aus dem Projekt myproject zu entfernen, geben Sie Folgendes ein:
# projmod -s -K task.max-lwps myproject |
Mit den in Kapitel 2Einführung in Projekte und Aufgaben beschriebenen Leistungsmerkmalen Projekt und Aufgabe zum Bezeichnen und Trennen von Arbeitslasten können Sie den Ressourcenverbrauch durch einzelne Arbeitslasten überwachen. Mit dem Subsystem Extended Accounting können Sie detaillierte Statistiken zum Ressourcenverbrauch durch Prozesse und Aufgaben erfassen.
In diesem Kapitel werden folgende Themen behandelt.
Wenn Sie direkt mit der Arbeit in Extended Accounting beginnen möchten, lesen Sie So aktivieren Sie das Extended Accounting für Prozesse, Aufgaben und Flows.
mstate-Daten für das Prozess-Accounting können jetzt erstellt werden. Lesen Sie dazu So zeigen Sie die verfügbaren Accounting-Ressourcen an.
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.
Das Subsystem Extended Accounting kennzeichnet Nutzungsdatensätze mit dem Projekt, für das die Arbeit ausgeführt wurde. Sie können das Extended Accounting auch zusammen mit dem in Kapitel 36, Verwenden von Flow Accounting und Erfassen von Statistiken (Aufgaben) in Systemverwaltungshandbuch: IP ServicesSystem Administration Guide: IP Services beschriebenen Internet Protocol Quality of Service (IPQoS) Flow Accounting-Modul verwenden, um Informationen zu den Netzwerkabläufen auf einem System zu erfassen.
Bevor Sie die Mechanismen einer Ressourcenverwaltung anwenden können, müssen Sie den Ressourcenverbrauch durch die verschiedenen Arbeitslasten auf dem System einschätzen. Das Extended Accounting im Betriebssystem Solaris kann den System- und Netzwerk-Ressourcenverbrauch auf Aufgaben- oder Prozessbasis oder auf Basis von Selektoren, die vom IPQoS-Modul flowacct bereitgestellt werden, flexibel erfassen. Weitere Informationen finden Sie unter ipqos(7IPP).
Im Gegensatz zu Online-Überwachungstools, die die Systemnutzung in Echtzeit messen, können Sie mit dem Extended Accounting Verlaufsdaten zur Nutzung auswerten. Mit diesen Ergebnissen können Sie Einschätzungen der Kapazitätsanforderungen künftiger Arbeitslasten erstellen.
Wenn Ihnen Daten aus dem Extended Accounting zur Verfügung stehen, können Sie Software zum Ressourcen-Chargeback, zur Arbeitlastüberwachung oder zur Kapazitätsplanung entwickeln oder erwerben.
Das Extended Accounting im Betriebssystem Solaris verwendet für die Accounting-Daten ein mit Versionsnummer gekennzeichnetes, erweiterbares Dateiformat. Dateien in diesem Dateiformat können mithilfe der in der Bibliothek libexacctenthaltenen API geöffnet oder erstellt werden (siehe libexacct(3LIB)). Diese Dateien können dann auf jeder Plattform mit aktiviertem Extended Accounting analysiert werden. Die darin enthaltenen Daten können zur Kapazitätsplanung und für das Chargeback verwendet werden.
Bei aktiviertem Extended Accounting werden Statistiken erfasst, die mit der libexacct-API ausgewertet werden können. libexacct ermöglicht sogar eine vorwärts- und rückwärts gerichtete Auswertung der exacct-Dateien. Die API unterstützt von libexacct erzeugte Drittanbieterdateien sowie vom Kernel erstellte Dateien. Weiterhin gibt es eine Perl-Schnittstelle zu libexacct, mit der Sie benutzerdefinierte Skripten zur Berichterstattung und Extraktion entwickeln können. Lesen Sie dazu Perl-Schnittstelle für libexacct.
Beispielsweise verfolgt die Aufgabe bei aktiviertem Extended Accounting die aggregierte Ressourcennutzung ihrer Mitgliederprozesse. Nach Beendigung der Aufgabe wird ein Aufgaben-Accounting-Datensatz gespeichert. Für laufende Prozesse und Aufgaben können auch Zwischendatensätze gespeichert werden. Weitere Informationen zu Aufgaben finden Sie in Kapitel 2Einführung in Projekte und Aufgaben.
Das Extended Accounting-Format ist wesentlich flexibler als das der SunOS-Accounting-Legatsoftware (siehe What is System Accounting? in System Administration Guide: Advanced Administration ). Mit dem Extended Accounting können Accounting-Metriken zwischen einzelnen Releases und sogar während des Systembetriebs zum System hinzugefügt bzw. davon gelöscht werden.
Das Extended Accounting und die Accounting-Legatsoftware können gleichzeitig auf einem System aktiviert sein.
Programmroutinen zum Erstellen von exacct-Datensätzen erfüllen zwei Aufgaben.
Das Erstellen von exacct-Drittanbieterdateien.
Das Erstellen von Markierungsdatensätzen (Tags), die mithilfe des Systemaufrufs putacct in die vom Kernel erzeugte Accounting-Datei eingebettet werden (siehe getacct(2)).
Der Systemaufruf putacct ist auch von der Perl-Schnittstelle verfügbar.
Das Format ermöglicht, dass verschiedene Arten von Accounting-Datensätzen erfasst werden können, ohne dass jede Änderung eine explizite Versionsänderung erfordert. Gut geschriebene Anwendungen zur Verarbeitung von Accounting-Daten ignorieren Datensätze, die sie nicht verstehen.
Die Bibliothek libexacct konvertiert und erstellt Dateien im exacct-Format. Diese Bibliothek ist die einzige unterstützte Schnittstelle für Dateien im exacct-Format.
Die Systemaufrufe getacct, putacct und wracct gelten nicht für Flows. Der Kernel erstellt Flow-Datensätze und schreibt sie in die Datei, wenn das IPQoS Flow-Accounting konfiguriert ist.
Wenn das Extended Accounting in der globalen Zone ausgeführt wird, sammelt es Daten und erstellt Berichte für das gesamte System (einschließlich der nicht-globalen Zonen). Der globale Administrator kann darüber hinaus den Ressourcenverbrauch pro Zone festlegen. Weitere Informationen finden Sie unter Extended Accounting auf einem Solaris-System mit installierten Zonen.
Die aktuelle Konfiguration des Extended Accounting ist in der Datei/etc/acctadm.conf gespeichert. Diese Datei wird über die Schnittstelle acctadm und nicht vom Benutzer bearbeitet.
Standardmäßig werden die Extended Accounting-Daten im Verzeichnis /var/adm/exacct gespeichert. Mit dem Befehl acctadm können Sie einen anderen Speicherort für die Accounting-Datendateien von Prozessen und Aufgaben zuweisen. Weitere Informationen finden Sie unter acctadm(1M).
Befehl |
Beschreibung |
---|---|
Ändert verschiedene Attribute des Extended Accounting, startet und stoppt das Extended Accounting und dient zum Auswählen der Accounting-Attribute für das Verfolgen von Prozessen, Aufgaben und Flows. |
|
Schreibt die Extended Accounting-Datensätze für aktive Prozesse und Aufgaben. |
|
Zeigt die zuvor aufgerufenen Befehle an. lastcomm kann Prozessdaten entweder aus dem standardmäßigen Accounting oder dem Extended Accounting verarbeiten. |
Weitere Informationen zu den Befehlen, die Aufgaben und Projekten zugeordnet sind, finden Sie unter Beispiele für Befehle und Befehlsoptionen. Informationen zum IPQoS Flow-Accounting finden Sie in der Manpage ipqosconf(1M).
Mit der Perl-Schnittstelle können Sie Perl-Skripten erstellen, die vom exacct-Framework erstellte Accounting-Dateien lesen können. Auch lassen sich Perl-Skripten zum Schreiben von exacct-Dateien erstellen.
Die Schnittstelle entspricht in der Funktion der zu Grunde liegenden C API. Wenn möglich, werden die von der zu Grunde liegenden C API erfassten Daten als Perl-Datentypen dargestellt. Diese Funktion vereinfacht den Datenzugriff und macht das Packen und Entpacken des Puffers überflüssig. Darüber hinaus wird die gesamte Speicherverwaltung von der Perl-Bibliothek übernommen.
Die einzelnen Projekt-, Aufgabe- und exacct-bezogenen Funktionen werden in Gruppen aufgeteilt. Jede Funktionsgruppe befindet sich in einem separaten Perl-Modul. Jedes Modul beginnt mit dem standardmäßigen Sun-Präfix Sun::Solaris:: für Perl-Pakete. Alle von der Perl-Bibliothek exacct bereitgestellten Klassen befinden sich im Sun::Solaris::Exacct-Modul.
Die zu Grunde liegende libexacct(3LIB)-Bibliothek stellt die Vorgänge für Dateien im exacct-Format, Katalog-Tags und exacct-Objekte bereit. exacct-Objekte sind in zwei Typen unterteilt:
Elemente, die Einzeldatenwerte darstellen (Skalare)
Gruppen, die Elementlisten darstellen
In der folgenden Tabelle werden die einzelnen Module zusammenfassend beschrieben.
Modul (darf keine Leerzeichen enthalten) |
Beschreibung |
Weitere Informationen |
---|---|---|
Sun::Solaris::Project |
Dieses Modul bietet Funktionen für den Zugriff auf die Funktionen zur Projektbearbeitung getprojid(2), endprojent(3PROJECT) , fgetprojent(3PROJECT), getdefaultproj(3PROJECT), getprojbyid(3PROJECT), getprojbyname(3PROJECT), getprojent(3PROJECT), getprojidbyname(3PROJECT), inproj(3PROJECT), project_walk(3PROJECT), setproject(3PROJECT) und setprojent(3PROJECT). |
Project(3PERL) |
Sun::Solaris::Task |
Dieses Modul bietet Funktionen für den Zugriff auf die Funktionen zur Aufgabenbearbeitung gettaskid(2) und settaskid(2). |
Task(3PERL) |
Sun::Solaris::Exacct |
Dieses Modul ist das übergeordnete exacct-Modul. Dieses Modul bietet Funktionen für den Zugriff auf die exacct-bezogenen Systemaufrufe getacct(2), putacct(2) und wracct(2). Dieses Modul bietet darüber hinaus Funktionen zum Zugriff auf die libexacct(3LIB)-Bibliotheksfunktion ea_error(3EXACCT). Weiterhin werden Konstanten für alle exacct EO_*, EW_*, EXR_*, P_*, und TASK_*-Makros in diesem Modul bereitgestellt. |
Exacct(3PERL) |
Sun::Solaris::Exacct:: Catalog |
Dieses Modul enthält die objektorientierten Methoden für den Zugriff auf die Bitfelder in einem exacct-Katalog-Tag. Darüber hinaus bietet dieses Modul Zugriff auf die Konstanten der Makros EXC_*, EXD_* und EXD_*. |
Exacct::Catalog(3PERL) |
Sun::Solaris::Exacct:: File |
Dieses Modul bietet enthält objektorientierten Methoden für den Zugriff auf die Funktionen der libexacct-Accounting-Datei ea_open(3EXACCT), ea_close(3EXACCT), ea_get_creator(3EXACCT), ea_get_hostname(3EXACCT), ea_next_object(3EXACCT), ea_previous_object(3EXACCT) und ea_write_object(3EXACCT). |
Exacct::File(3PERL) |
Sun::Solaris::Exacct:: Object |
Dieses Modul enthält die objektorientierten Methoden für den Zugriff auf ein einzelnes Objekt einer exacct-Accounting-Datei. Ein exacct-Objekt wird als ein Verweis dargestellt, der in der entsprechenden Unterklasse Sun::Solaris::Exacct::Object enthalten ist. Das Modul ist weiter in die Objekttypen „Item“ und „Group“ unterteilt. Auf dieser Ebene gibt es Methoden für den Zugriff auf die Funktionen ea_match_object_catalog(3EXACCT) und ea_attach_to_object(3EXACCT). |
Exacct::Object(3PERL) |
Sun::Solaris::Exacct:: Object::Item |
Dieses Modul enthält die objektorientierten Methoden für den Zugriff auf ein einzelnes Element in einer exacct-Accounting-Datei. Objekte dieses Typs erben von Sun::Solaris::Exacct::Object. |
Exacct::Object::Item(3PERL) |
Sun::Solaris::Exacct:: Object::Group |
Dieses Modul enthält die objektorientierten Methoden für den Zugriff auf eine einzelne Gruppe einer exacct-Accounting-Datei. Objekte dieses Typs erben von Sun::Solaris::Exacct::Object. Diese Objekte bieten Zugriff auf die Funktion ea_attach_to_group(3EXACCT) Die in der Gruppe enthaltenen Elemente werden als ein Perl-Array dargestellt. |
Exacct::Object::Group(3PERL) |
Sun::Solaris::Kstat |
Dieses Modul enthält eine an Perl gebundene Hash-Schnittstelle für die kstat-Funktion. Ein in Perl geschriebenes Nutzungsbeispiel dieses Moduls finden Sie in /bin/kstat. |
Kstat(3PERL) |
Beispiele, in denen die Verwendung der in der obigen Tabelle beschriebenen Module gezeigt wird, finden Sie unter Verwenden der Perl-Schnittstelle für libexacct.
In diesem Kapitel wird die Verwaltung des Extended Accounting beschrieben.
Eine Einführung in das Extended Accounting finden Sie in Kapitel 4Einführung in das Extended Accounting.
Aufgabe |
Beschreibung |
Siehe |
---|---|---|
Aktivieren des Extended Accounting. |
Verwenden des Extended Accounting zur Überwachung des Ressourcenverbrauchs durch einzelne, auf dem System ausgeführte Projekte. Mit dem Extended Accounting können Sie Verlaufsdaten für Aufgaben, Prozesse und Flows erfassen. |
So aktivieren Sie das Extended Accounting für Prozesse, Aufgaben und Flows, So aktivieren Sie das Extended Accounting mit einem Startskript |
Anzeigen des Extended Accounting-Status. |
Ermitteln des Status des Extended Accounting. | |
Anzeigen der verfügbaren Accounting-Ressourcen. |
Anzeigen der auf dem System verfügbaren Accounting-Ressourcen. | |
Deaktivieren des Prozess-, Aufgaben- und Flow-Accounting. |
Deaktivieren des Extended Accounting. |
So deaktivieren Sie das Prozess-, Aufgaben- und Flow-Accounting |
Verwenden der Perl-Schnittstelle für das Extended Accounting. |
Verwenden der Perl-Schnittstelle zum Entwickeln von benutzerdefinierten Skripten zur Berichterstattung und Extraktion. |
Benutzer können Extended Accounting verwalten (starten, beenden, Konfigurationsparameter ändern), wenn Sie über ein entsprechendes Rechteprofil für den zu verwaltenden Extended Accounting-Typ verfügen:
Flow Management
Process Management
Task Management
Mit dem Befehl acctadm aktivieren Sie das Extended Accounting für Aufgaben, Prozesse und Flows. Der optionale finale Parameter für acctadm gibt an, ob der Befehl an den Accounting-Komponenten eines Prozesses, einer Systemtask oder eines Flows ausgeführt werden soll.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Aktivieren Sie das Extended Accounting für Prozesse.
# acctadm -e extended -f /var/adm/exacct/proc process |
Aktivieren Sie das Extended Accounting für Aufgaben.
# acctadm -e extended,mstate -f /var/adm/exacct/task task |
Aktivieren Sie das Extended Accounting für Flows.
# acctadm -e extended -f /var/adm/exacct/flow flow |
Weitere Informationen finden Sie unter acctadm(1M).
Aktivieren Sie das Extended Accounting für die ständige Ausführung, indem Sie das Skript /etc/init.d/acctadm mit /etc/rc2.d verknüpfen.
# ln -s /etc/init.d/acctadm /etc/rc2.d/Snacctadm # ln -s /etc/init.d/acctadm /etc/rc2.d/Knacctadm |
Die Variable n wird durch eine Zahl ersetzt.
Anschließend müssen Sie das Extended Accounting mindestens einmal manuell aktivieren, um die Konfiguration einzurichten.
Weitere Informationen zur Accounting-Konfiguration finden Sie unter Konfiguration des Extended Accounting.
Zum Anzeigen des aktuellen Status des Extended Accounting geben Sie den Befehl acctadm ohne Argumente ein.
# acctadm Task accounting: active Task accounting file: /var/adm/exacct/task Tracked task resources: extended Untracked task resources: none Process accounting: active Process accounting file: /var/adm/exacct/proc Tracked process resources: extended Untracked process resources: host Flow accounting: active Flow accounting file: /var/adm/exacct/flow Tracked flow resources: extended Untracked flow resources: none |
Im obigen Beispiel ist das Systemtask-Accounting im erweiterten Modus und im mstate-Modus aktiv. Prozess- und Flow-Accounting sind im erweiterten Modus aktiv.
In Bezug auf das Extended Accounting bezieht sich „microstate“ (mstate) auf die erweiterten Daten, die den Microstate-Prozessübergängen zugeordnet sind, die in der Prozessnutzungsdatei zur Verfügung stehen (siehe proc(4)). Diese Daten enthalten wesentlich mehr Details über die Aktivitäten des Prozesses als allgemeine oder erweiterte Datensätze.
Die verfügbaren Ressourcen variieren von System zu System und von Plattform zu Plattform. Mit dem Befehl acctadm und der Option -r können Sie die auf dem System verfügbaren Accounting-Ressourcengruppen anzeigen.
# acctadm -r process: extended pid,uid,gid,cpu,time,command,tty,projid,taskid,ancpid,wait-status,zone,flag, memory,mstatedisplays as one line basic pid,uid,gid,cpu,time,command,tty,flag task: extended taskid,projid,cpu,time,host,mstate,anctaskid,zone basic taskid,projid,cpu,time flow: extended saddr,daddr,sport,dport,proto,dsfield,nbytes,npkts,action,ctime,lseen,projid,uid basic saddr,daddr,sport,dport,proto,nbytes,npkts,action |
Zum Deaktivieren des Prozess-, Aufgaben- und Flow-Accounting geben Sie jeweils den Befehl acctadm mit der Option-x ein.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Deaktivieren Sie das Prozess-Accounting.
# acctadm -x process |
Deaktivieren Sie das Aufgaben-Accounting.
# acctadm -x task |
Deaktivieren Sie das Flow-Accounting.
# acctadm -x flow |
Überprüfen Sie, ob Aufgaben-, Prozess-und Flow-Accounting deaktiviert wurden.
# acctadm Task accounting: inactive Task accounting file: none Tracked task resources: extended Untracked task resources: none Process accounting: inactive Process accounting file: none Tracked process resources: extended Untracked process resources: host Flow accounting: inactive Flow accounting file: none Tracked flow resources: extended Untracked flow resources: none |
Mit dem folgenden Code drucken Sie rekursiv den Inhalt eines exacct-Objekts. Diese Eigenschaft wird von der Bibliothek als Funktion Sun::Solaris::Exacct::Object::dump() bereitgestellt. Diese Eigenschaft ist auch über die Convenience-Funktion ea_dump_object() verfügbar.
sub dump_object { my ($obj, $indent) = @_; my $istr = ' ' x $indent; # # Retrieve the catalog tag. Because we are # doing this in an array context, the # catalog tag will be returned as a (type, catalog, id) # triplet, where each member of the triplet will behave as # an integer or a string, depending on context. # If instead this next line provided a scalar context, e.g. # my $cat = $obj->catalog()->value(); # then $cat would be set to the integer value of the # catalog tag. # my @cat = $obj->catalog()->value(); # # If the object is a plain item # if ($obj->type() == &EO_ITEM) { # # Note: The '%s' formats provide s string context, so # the components of the catalog tag will be displayed # as the symbolic values. If we changed the '%s' # formats to '%d', the numeric value of the components # would be displayed. # printf("%sITEM\n%s Catalog = %s|%s|%s\n", $istr, $istr, @cat); $indent++; # # Retrieve the value of the item. If the item contains # in turn a nested exacct object (i.e., an item or # group),then the value method will return a reference # to the appropriate sort of perl object # (Exacct::Object::Item or Exacct::Object::Group). # We could of course figure out that the item contained # a nested item orgroup by examining the catalog tag in # @cat and looking for a type of EXT_EXACCT_OBJECT or # EXT_GROUP. # my $val = $obj->value(); if (ref($val)) { # If it is a nested object, recurse to dump it. dump_object($val, $indent); } else { # Otherwise it is just a 'plain' value, so # display it. printf("%s Value = %s\n", $istr, $val); } # # Otherwise we know we are dealing with a group. Groups # represent contents as a perl list or array (depending on # context), so we can process the contents of the group # with a 'foreach' loop, which provides a list context. # In a list context the value method returns the content # of the group as a perl list, which is the quickest # mechanism, but doesn't allow the group to be modified. # If we wanted to modify the contents of the group we could # do so like this: # my $grp = $obj->value(); # Returns an array reference # $grp->[0] = $newitem; # but accessing the group elements this way is much slower. # } else { printf("%sGROUP\n%s Catalog = %s|%s|%s\n", $istr, $istr, @cat); $indent++; # 'foreach' provides a list context. foreach my $val ($obj->value()) { dump_object($val, $indent); } printf("%sENDGROUP\n", $istr); } } |
Mit dem folgenden Skript erstellen Sie einen neuen Gruppendatensatz und schreiben ihn in eine Datei namens /tmp/exacct.
#!/usr/bin/perl use strict; use warnings; use Sun::Solaris::Exacct qw(:EXACCT_ALL); # Prototype list of catalog tags and values. my @items = ( [ &EXT_STRING | &EXC_DEFAULT | &EXD_CREATOR => "me" ], [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_PID => $$ ], [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_UID => $< ], [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_GID => $( ], [ &EXT_STRING | &EXC_DEFAULT | &EXD_PROC_COMMAND => "/bin/rec" ], ); # Create a new group catalog object. my $cat = ea_new_catalog(&EXT_GROUP | &EXC_DEFAULT | &EXD_NONE) # Create a new Group object and retrieve its data array. my $group = ea_new_group($cat); my $ary = $group->value(); # Push the new Items onto the Group array. foreach my $v (@items) { push(@$ary, ea_new_item(ea_new_catalog($v->[0]), $v->[1])); } # Open the exacct file, write the record & close. my $f = ea_new_file('/tmp/exacct', &O_RDWR | &O_CREAT | &O_TRUNC) || die("create /tmp/exacct failed: ", ea_error_str(), "\n"); $f->write($group); $f = undef; |
Mit dem folgenden Perl-Skript drucken Sie den Inhalt einer exacct-Datei.
#!/usr/bin/perl use strict; use warnings; use Sun::Solaris::Exacct qw(:EXACCT_ALL); die("Usage is dumpexacct <exacct file>\n") unless (@ARGV == 1); # Open the exact file and display the header information. my $ef = ea_new_file($ARGV[0], &O_RDONLY) || die(error_str()); printf("Creator: %s\n", $ef->creator()); printf("Hostname: %s\n\n", $ef->hostname()); # Dump the file contents while (my $obj = $ef->get()) { ea_dump_object($obj); } # Report any errors if (ea_error() != EXR_OK && ea_error() != EXR_EOF) { printf("\nERROR: %s\n", ea_error_str()); exit(1); } exit(0); |
Das Folgende ist ein Beispiel für eine Ausgabe, die durch das Ausführen von Sun::Solaris::Exacct::Object->dump() an der Datei erzeugt wird, die unter So erstellen Sie einen neuen Gruppendatensatz und schreiben ihn in eine Datei erstellt wurde.
Creator: root Hostname: localhost GROUP Catalog = EXT_GROUP|EXC_DEFAULT|EXD_NONE ITEM Catalog = EXT_STRING|EXC_DEFAULT|EXD_CREATOR Value = me ITEM Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_PID Value = 845523 ITEM Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_UID Value = 37845 ITEM Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_GID Value = 10 ITEM Catalog = EXT_STRING|EXC_DEFAULT|EXD_PROC_COMMAND Value = /bin/rec ENDGROUP |
Nachdem Sie den Ressourcenverbrauch durch Arbeitslasten auf dem System gemäß der Beschreibung in Kapitel 4Einführung in das Extended Accounting ermittelt haben, können Sie Grenzwerte für die Ressourcennutzung einrichten. Grenzwerte verhindern, dass Arbeitslasten Ressourcen übermäßig verbrauchen. Zum Einrichten der Grenzwerte werden Resource Controls verwendet, die als Einschränkung eingesetzt werden.
In diesem Kapitel werden die folgenden Themen behandelt.
Informationen zur Verwaltung von Resource Controls finden Sie in Kapitel 7Verwalten von Resource Controls (Vorgehen).
Die folgende Liste der Resource Controls ersetzt die System V Interprocess Communication (IPC)-Tunables /etc/system:
project.max-shm-ids
project.max-msg-ids
project.max-sem-ids
project.max-shm-memory
process.max-sem-nsems
process.max-sem-ops
process.max-msg-qbytes
Die folgenden Resource Controls für Ereignis-Ports wurden hinzugefügt:
project.max-device-locked-memory
project.max-port-ids
process.max-port-events
Die folgende kryptografische Resource Control wurde hinzugefügt:
project.max-crypto-memory
Die folgenden zusätzlichen Resource Controls wurden hinzugefügt:
project.max-lwps
project.max-tasks
project.max-contracts
Weitere Informationen finden Sie unter Verfügbare Resource Controls.
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.
Im Betriebssystem Solaris wurde das Konzept einer prozessbasierten Ressourceneinschränkung auf die in Kapitel 2Einführung in Projekte und Aufgaben beschriebenen Funktionen Aufgabe und Projekt erweitert. Diese Erweiterungen werden über Resource Controls (rctls) umgesetzt. Darüber hinaus sind Zuweisungen, die über die Tunables /etc/system eingestellt wurden, jetzt automatisiert oder können ebenfalls über Resource Controls konfiguriert werden.
Eine Resource Control ist durch das Präfix zone, project, task oder process gekennzeichnet. Resource Controls können systemweit überwacht werden. Die Werte von Resource Controls können bei laufendem System aktualisiert werden.
Eine Liste der standardmäßigen Resource Controls für dieses Release finden Sie unter Verfügbare Resource Controls. Informationen zu den verfügbaren zonenweiten Resource Controls finden Sie unter Ressourcentypeigenschaften.
Eine Liste der standardmäßigen Resource Controls für dieses Release finden Sie unter Verfügbare Resource Controls.
UNIX-Systeme verfügen traditionell über eine Funktion zur Begrenzung des maximalen Ressourcenverbrauchs (rlimit). Mit „rlimit“ können Administrator einen oder mehrere numerische Grenzwerte für die Ressourcen einrichten, die ein Prozess maximal verbrauchen darf. Diese Grenzwerte enthalten die verwendete CPU-Zeit pro Prozess, die Kerndateigröße pro Prozess und die maximale Heap-Größe pro Prozess. Heap-Größe ist der für das Prozessdatensegment zugewiesene Scratch-Speicher.
Resource Controls bilden u. a. Kompatibilitätsschnittstellen für den maximalen Ressourcenverbrauch. Vorhandene Anwendungen, für die ein maximaler Ressourcenverbrauch festgelegt wurde, laufen unverändert weiter. Diese Anwendungen können auf die gleiche Weise überwacht werden wie Anwendungen, die geändert wurden, um von den Vorteilen der Resource Controls profitieren zu können.
Prozesse können über verschiedene Arten von prozessübergreifender Kommunikation (Interprocess Communication, IPC) miteinander kommunizieren. IPC ermöglicht die Übertragung oder Synchronisierung von Informationen zwischen Prozessen. Vor dem Solaris-Release 10 wurden die einstellbaren IPC-Parameter durch Hinzufügen eines Eintrags zur Datei /etc/system gesetzt. Die Resource Controls umfassen jetzt Funktionen, die das Verhalten der IPC-Funktionen des Kernel definieren. Diese Resource Controls ersetzen die /etc/system-Tunables.
Auf diesem Solaris-System können in der Datei /etc/system veraltete Parameter enthalten sein. In diesem Fall dienen die Parameter zur Initialisierung der Standardwerte für Ressourcenobjekte gemäß den vorigen Solaris-Versionen. Von der Verwendung der veralteten Parameter wird jedoch abgeraten
Um festzustellen, welche IPC-Objekte zur Nutzung durch ein Projekt beitragen, verwenden Sie den Befehl ipcs mit der Option -J. Eine Beispielanzeige finden Sie unter So verwenden Sie ipcs Weitere Informationen zum Befehl ipcs finden Sie unter ipcs(1).
Informationen zur Einstellung eines Solaris-Systems finden Sie im Oracle Solaris Tunable Parameters Reference Manual .
Resource Controls bieten einen Mechanismus zur Einschränkung der Systemressourcen. Mit diesem Mechanismus kann verhindert werden, dass Prozesse, Aufgaben, Projekte und Zonen bestimmte angegebene Systemressourcen verbrauchen. Das System lässt sich besser verwalten, da übermäßiger Ressourcenverbrauch verhindert wird.
Die Einschränkungsmechanismen können auch in Prozessen zur Kapazitätsplanung verwendet werden. Wenn eine Anwendung auf eine Einschränkung trifft, kann diese auch Informationen zu den Ressourcenanforderungen der Anwendung liefern, ohne dass diese Ressourcen unbedingt verweigert werden.
Resource Controls können auch als einfache Attribute für die Ressourcenverwaltung verwendet werden. Beispielsweise wird die Anzahl der CPU-Shares, die einem Projekt in der Scheduling-Klasse Fair Share Scheduler (FSS) zur Verfügung stehen, von der Resource Control project.cpu-shares definiert. Da dem Projekt von der Resource Control eine feste Anzahl an Shares zugewiesen wird, werden die Aktionen, die dem Überschreiten der Resource Control zugeordnet sind, nicht angewendet. In diesem Zusammenhang wird der aktuelle Wert für die Resource Control project.cpu-shares als Attribut für das angegebene Projekt betrachtet.
Ein anderer Projektattributtyp dient zum Begrenzen des Speicherressourcenverbrauchs durch Prozesse, die an ein Projekt angehängt sind. Dieser Attribute haben das Präfix rcap, z. B. rcap.max-rss. Dieser Attributtyp wird wie eine Resource Control in der project-Datenbank konfiguriert. Während Resource Controls synchron vom Kernel durchgesetzt werden, werden Resource Caps (Speicherbegrenzungen) asynchron auf Benutzerebene über den Resource Capping Daemon rcapd durchgesetzt. Weitere Informationen zum rcapd finden Sie in Kapitel 10Einführung in die Steuerung des reellen Arbeitsspeichers mithilfe des Resource Capping Daemons und in der Manpage rcapd(1M).
Mit dem Attribut project.pool wird eine Pool-Bindung eines Projekt angegeben. Weitere Informationen zu Resource Pools finden Sie in Kapitel 12Einführung in Resource Pools.
Resource Controls werden über die project-Datenbank konfiguriert. Lesen Sie dazu Kapitel 2Einführung in Projekte und Aufgaben. Resource Controls und andere Attribute werden im letzten Feld eines project-Datenbankeintrags gesetzt. Die den einzelnen Resource Controls zugewiesenen Werte werden in Klammern eingeschlossen und erscheinen als durch Kommata getrennter Klartext. Die Werte in Klammern bilden eine „Aktionsklausel“. Jede Aktionsklausel setzt sich aus einem Schwellenwert, einer Berechtigungsstufe und einer Aktion zusammen, die einem bestimmten Schwellenwert zugeordnet ist. Jede Resource Control kann mehrere Aktionsklauseln enthalten, die ebenfalls durch Kommata voneinander getrennt sind. Der folgende Eintrag definiert taskbasiert eine Lightweight-Prozessgrenze und prozessbasiert einen Grenzwert für die maximale CPU-Zeit für ein Projekt. Wenn ein Prozess eine Stunde lang andauert, sendet die Resource Control process.max-cpu-time dem Prozess ein SIGTERM. Dauert der Prozess 1 Stunde und 1 Minute an, wird ein SIGKILL an den Prozess gesendet (siehe Tabelle 6–3).
development:101:Developers:::task.max-lwps=(privileged,10,deny); process.max-cpu-time=(basic,3600,signal=TERM),(priv,3660,signal=KILL) typed as one line |
Auf Systemen mit aktivierten Zonen werden zonenweite Resource Controls in einem etwas anderen Format in der Zonenkonfiguration angegeben. Weitere Informationen finden Sie unter Konfigurationsdaten in einer Zone.
Mit dem Befehl rctladm können Sie Echtzeitabfragen an Resource Controls mit globalem Geltungsbereich richten und Modifikationen daran vornehmen. Mit dem Befehl prctl können Sie Echtzeitabfragen an Resource Controls mit lokalem Geltungsbereich richten und Modifikationen daran vornehmen.
Weitere Informationen finden Sie unter Globale und lokale Aktionen mit Resource Control-Werten, rctladm(1M) und prctl(1).
Auf einem System mit installierten Zonen können Sie rctladm in einer nicht-globalen Zone nicht zum Ändern von Einstellungen verwenden. Mit rctladm können Sie in einer nicht-globalen Zone den globalen Logging-Status jeder Resource Control anzeigen.
In der folgenden Tabelle ist eine Liste der standardmäßige Resource Controls für dieses Release aufgeführt.
Dabei wird die Ressource beschrieben, die von einer Resource Control eingeschränkt wird. Darüber hinaus sind die Standardeinheiten in der Tabelle aufgeführt, die von der project-Datenbank für diese Ressourcen verwendet werden. Es gibt zwei Arten von Standardeinheiten:
Mengen stellen eine begrenzte Anzahl dar.
Indizes stellen einen maximal gültigen Bezeichner dar.
Somit gibt project.cpu-shares die Anzahl der Shares an, auf die das Projekt Anrecht hat. process.max-file-descriptor gibt die maximale Anzahl an Dateien an, die einem Prozess vom Systemaufruf open(2) zugewiesen werden können.
Tabelle 6–1 Standardmäßige Resource Controls
Name der Resource Control |
Beschreibung |
Standardeinheit |
---|---|---|
project.cpu-cap |
Solaris 10 8/07: Absoluter Grenzwert der CPU-Ressourcen, die von einem Projekt beansprucht werden können. Der Wert 100 bedeutet 100-prozentige Beanspruchung einer CPU als project.cpu-cap-Einstellung. Der Wert 125 bedeutet 125 Prozent, da 100% der vollständigen Beanspruchung einer CPU auf einem System mit eingestellten Ressourcengrenzwerten entspricht. |
Menge (CPU-Anzahl) |
project.cpu-shares |
Anzahl der CPU-Shares, die diesem Projekt zur Nutzung mit dem Fair Share Scheduler zugeteilt sind (lesen Sie dazu auch die Manpage FSS(7)). |
Menge (Shares) |
project.max-crypto-memory |
Gesamter Kernel-Speicher, der von libpkcs11 für die Hardware-Crypto-Beschleunigung verwendet werden kann. Zuweisungen für Kernel-Puffer und sitzungsbezogene Strukturen werden gegen diese Resource Control verrechnet. |
Größe (Byte) |
project.max-locked-memory |
Gesamtmenge des zulässigen physikalisch gesperrten Speichers. Wenn priv_proc_lock_memory einem Benutzer zugewiesen ist, sollten Sie eventuell auch diese Resource Control einstellen, um zu verhindern, dass der Benutzer den gesamten Speicher sperrt. Solaris 10 8/07: Diese Resource Control ersetzt ab dem Solaris-Release 10 8/07 die Resource Control project.max-device-locked-memory. |
Größe (Byte) |
project.max-port-ids |
Maximal zulässige Anzahl der Ereignis-Ports. |
Menge (Anzahl der Ereignis-Ports) |
project.max-sem-ids |
Höchstzahl der für dieses Projekt zulässigen Semaphor-IDs. |
Menge (Semaphor-IDs) |
project.max-shm-ids |
Höchstzahl der für dieses Projekt zulässigen Shared Memory-IDs. |
Menge (Shared Memory-IDs) |
project.max-msg-ids |
Höchstzahl der für dieses Projekt zulässigen Nachrichtenwartesch- langen-IDs. |
Menge (Nachrichtenwarteschlangen-IDs) |
project.max-shm-memory |
Gesamtmenge des für dieses Projekt System V Shared Memory. |
Größe (Byte) |
project.max-lwps |
Höchstzahl der gleichzeitig für dieses Projekt verfügbaren LWPs. |
Menge (LWPs) |
project.max-tasks |
Höchstzahl der für dieses Projekt zulässigen Aufgaben. |
Menge (Anzahl der Aufgaben) |
project.max-contracts |
Höchstzahl der für dieses Projekt zulässigen Contracts. |
Menge (Contracts) |
task.max-cpu-time |
Maximale CPU-Zeit, die für die Prozesse dieser Aufgabe verfügbar ist. |
Zeit (Sekunden) |
task.max-lwps |
Höchstzahl der LWPs, die gleichzeitig für die Prozesse dieser Aufgabe zur Verfügung stehen. |
Menge (LWPs) |
process.max-cpu-time |
Maximale CPU-Zeit, die für diesen Prozess zur Verfügung steht. |
Zeit (Sekunden) |
process.max-file-descriptor |
Maximaler Dateideskriptorindex, der für diesen Prozess zur Verfügung steht. |
Index (maximaler Dateideskriptor) |
process.max-file-size |
Maximaler Datei-Offset, der für das Schreiben durch diesen Prozess zur Verfügung steht. |
Größe (Byte) |
process.max-core-size |
Maximale Größe einer Kerndatei, die von diesem Prozess erstellt wird. |
Größe (Byte) |
process.max-data-size |
Maximaler Heap-Speicher, der für diesen Prozess zur Verfügung steht. |
Größe (Byte) |
process.max-stack-size |
Maximales Stack-Speichersegment, das für diesen Prozess zur Verfügung steht. |
Größe (Byte) |
process.max-address-space |
Maximale Größe des Adressraums, als Summe der Segmentgrößen, der für diesen Prozess zur Verfügung steht. |
Größe (Byte) |
process.max-port-events |
Maximal zulässige Anzahl der Ereignisse pro Ereignis-Ports. |
Menge (Anzahl der Ereignisse) |
process.max-sem-nsems |
Maximal zulässige Anzahl der Semaphoren pro Semaphoren-Set. |
Menge (Semaphoren pro Set) |
process.max-sem-ops |
Maximal zulässige Anzahl an Semaphor-Vorgängen pro semop-Aufruf (der Wert wird zur semget()-Zeit von der Resource Control kopiert). |
Menge (Anzahl der Vorgänge) |
process.max-msg-qbytes |
Höchstzahl der Byte pro Nachricht in einer Nachrichtenwarteschlange (der Wert wird zur msgget()-Zeit von der Resource Control kopiert). |
Größe (Byte) |
process.max-msg-messages |
Höchstzahl der Nachrichten in einer Nachrichtenwarteschlange (der Wert wird zur msgget()-Zeit von der Resource Control kopiert). |
Menge (Anzahl der Nachrichten) |
Sie können die Standardwerte für Resource Controls auf einem System anzeigen, für das keine Resource Controls eingestellt oder geändert wurden. Ein solches System enthält ausschließlich Standardeinträge in der Datei /etc/system oder in der project-Datenbank. Zum Anzeigen der Werte verwenden Sie den Befehl prctl.
Zonenweite Resource Controls schränken die gesamte Ressourcennutzung aller Prozesseinheiten innerhalb einer Zone ein. Zonenweite Resource Controls können auch mithilfe der globalen Eigenschaftennamen eingestellt werden. Dies wird unter Einrichten von zonenweiten Resource Controls und unter So konfigurieren Sie die Zone beschrieben.
Tabelle 6–2 Zonenweite Resource Controls
Name der Resource Control |
Beschreibung |
Standardeinheit |
---|---|---|
zone.cpu-cap |
Solaris 10 5/08: Absoluter Grenzwert der CPU-Ressourcen, die von einer nicht-globalen Zone beansprucht werden können. Der Wert 100 bedeutet 100-prozentige Beanspruchung einer CPU als project.cpu-cap-Einstellung. Der Wert 125 bedeutet 125 Prozent, da 100% der vollständigen Beanspruchung einer CPU auf einem System mit eingestellten Ressourcengrenzwerten entspricht. |
Menge (CPU-Anzahl) |
zone.cpu-shares |
Anzahl der Fair Share Scheduler (FSS) CPU-Shares für diese Zone |
Menge (Shares) |
zone.max-locked-memory |
Gesamtmenge des in einer Zone verfügbaren, physikalisch gesperrten Speichers. Wenn priv_proc_lock_memory einer Zone zugewiesen ist, können Sie auch diese Resource Control einstellen, um zu verhindern, dass die Zone den gesamten Speicher sperrt. |
Größe (Byte) |
zone.max-lwps |
Höchstzahl der gleichzeitig in dieser Zone verfügbaren LWPs. |
Menge (LWPs) |
zone.max-msg-ids |
Höchstzahl der für diese Zone zulässigen Nachrichtenwartesch- langen-IDs. |
Menge (Nachrichten- warteschlan- gen-IDs) |
zone.max-sem-ids |
Höchstzahl der für diese Zone zulässigen Semaphor-IDs. |
Menge (Semaphor- IDs) |
zone.max-shm-ids |
Höchstzahl der für diese Zone zulässigen Shared Memory-IDs. |
Menge (Shared Memory-IDs) |
zone.max-shm-memory |
Gesamtmenge des für diese Zone zulässigen System V Shared Memory. |
Größe (Byte) |
zone.max-swap |
Gesamtmenge des Swap-Bereichs, der von Benutzerprozess- Adressraumzuordnungen und tmpfs-Mounts für diese Zone verwendet wird. |
Größe (Byte) |
Informationen zum Konfigurieren der zonenweiten Resource Controls finden Sie unter Ressourcentypeigenschaften und So konfigurieren Sie die Zone. Wie die zonenweiten Resource Controls in lx Branded Zones verwendet werden, können Sie unter So konfigurieren, prüfen und übernehmen Sie eine lx Branded Zone nachlesen.
Eine zonenweite Resource Control kann auch auf die globale Zone angewendet werden. Weitere Informationen finden Sie in Kapitel 17Einführung in die Konfiguration einer nicht-globalen Zone und unter Verwenden des Fair Share Scheduler auf einem Solaris-System mit installierten Zonen.
Für alle Resource Controls sind globale Flags definiert, die den Typ aller Resource Controls kennzeichnen. Mit diesen Flags teilt das System Anwendungen, wie z. B. dem Befehl prctl, allgemeine Typinformationen mit. Anhand dieser Information können Anwendungen Folgendes feststellen:
Die für eine Resource Control geltende Einheit
Der korrekte Maßstab, wenn skalierte Werte zu interpretierten sind
Die folgenden globalen Flags sind verfügbar:
Globales Flag |
Zeichenfolge für den Resource Control-Typ |
Modifikator |
Skalierung |
---|---|---|---|
RCTL_GLOBAL_BYTES |
Byte |
B |
1 |
|
KB |
210 |
|
|
MB |
220 |
|
|
GB |
230 |
|
|
TB |
240 |
|
|
PB |
250 |
|
|
EB |
260 |
|
RCTL_GLOBAL_SECONDS |
Sekunden |
s |
1 |
|
Ks |
103 |
|
|
Ms |
106 |
|
|
Gs |
109 |
|
|
Ts |
1012 |
|
|
Ps |
1015 |
|
|
Es |
1018 |
|
RCTL_GLOBAL_COUNT |
count |
none |
1 |
|
K |
103 |
|
|
M |
106 |
|
|
G |
109 |
|
|
T |
1012 |
|
|
P |
1015 |
|
|
E |
1018 |
Skalierte Werte können mit Resource Controls verwendet werden. Das folgende Beispiel zeigt einen skalierten Schwellenwert:
task.max-lwps=(priv,1K,deny)
Einheitenmodifikatoren werden von den Befehlen prctl, projadd und projmod akzeptiert. Sie können Einheitenmodifikatoren nicht in der project-Datenbank verwenden.
Der Schwellenwert für eine Resource Control ist der Punkt, an dem die Durchsetzung lokaler Aktionen ausgelöst wird oder globale Aktionen, z. B. eine Protokollierung, auftreten können.
Jeder Schwellenwert für eine Resource Control muss einer Berechtigungsstufe zugewiesen sein. Diese Berechtigungsstufe muss einen der folgenden drei Typen aufweisen.
„basic“, dieser Typ kann vom Eigentümer des aufrufenden Prozesses bearbeitet werden
„privileged“, dieser Typ kann nur von berechtigten Aufrufern (Superuser) bearbeitet werden
„system“, dieser Typ ist für die Dauer der Betriebssysteminstanz feststehend
Eine Resource Control besitzt garantiert einen Systemwert, der entweder vom System oder dem Ressourcen-Provider definiert wird. Der Systemwert legt fest, wie viel der Ressource von der aktuellen Implementation des Betriebssystems bereitgestellt werden kann.
Es können beliebige viele „privileged“ Werte definiert werden, aber es ist nur ein „basic“ Wert zulässig. Vorgänge, die ohne Angabe eines „privileged“ Werts ausgeführt werden, wird standardmäßig ein „basic“ Wert zugeordnet.
Die Berechtigungsstufe eines Resource Control-Werts wird im Berechtigungsfeld des Resource Control-Block als RCTL_BASIC, RCTL_PRIVILEGED oder RCTL_SYSTEM definiert. Weitere Informationen finden Sie unter setrctl(2) Werte, denen die Berechtigungsstufen „basic“ und „privileged“ zugewiesen sind, können Sie mit dem Befehl prctl ändern.
Es gibt zwei Kategorien von Aktionen für Resource Control-Werte: global und lokal.
Globale Aktionen gelten für Resource Control-Werte jeder Resource Control in einem System. Mit dem Befehl rctladm, der in der Manpage rctladm(1M) ausführlich beschrieben ist, können Sie:
Den globalen Status von aktiven System-Resource Controls anzeigen
Globale Protokollierungsaktionen einrichten
Die globale Protokollierungsaktion für Resource Controls kann aktiviert oder deaktiviert werden. Weisen Sie der Aktion syslog einen bestimmten Wert zu, um einen Schweregrad zuzuweisen, syslog=Schweregrad. Mögliche Einstellungen für Schweregrad sind:
debug
info
notice
warning
err
crit
alert
emerg
Standardmäßig werden Verletzungen der Resource Controls nicht global protokolliert. Im Solaris-Release 10 5/08 wurde für Resource Controls, für die keine globalen Aktionen konfiguriert werden können, die Ebene n/a hinzugefügt.
Lokale Aktionen werden für einen Prozess durchgeführt, der versucht, den Resource Control-Wert zu übersteigen. Jedem Schwellenwert, der für eine Resource Control eingerichtet wurde, können eine oder mehrere Aktionen zugewiesen werden. Es gibt drei Arten von lokalen Aktionen: none, deny und signal=. Diese drei Aktionen werden wie folgt verwendet:
Bei Ressourcenanforderungen, die größer sind als der Schwellenwert, wird keine Aktion durchgeführt. Mit dieser Aktion kann die Ressourcennutzung überwacht werden, ohne die Ausführung von Anwendungen zu beeinflussen. Sie können auch eine globale Nachricht aktivieren, die immer dann angezeigt wird, wenn die Resource Control überschritten wird. Der den Schwellenwert überschreitende Prozess wird davon nicht beeinflusst.
Ressourcenanforderungen, die größer sind als der Schwellenwert, werden verweigert. Beispielsweise führt eine Resource Control task.max-lwps mit der Aktion deny dazu, dass ein fork-Systemaufruf fehlschlägt, wenn der neue Prozess den Wert der Resource Control überschreitet. Weitere Informationen finden Sie in der Manpage fork(2).
Sie können die Aktion einer globalen Signalnachricht aktivieren, wenn der Schwellenwert der Resource Control überschritten wird. Beim Überschreiten des Schwellenwerts wird ein Signal an den Prozess gesendet. Wenn der Prozess zusätzliche Ressourcen verbraucht, werden keine zusätzlichen Signale gesendet. Die verfügbaren Signale sind in Tabelle 6–3 aufgeführt.
Nicht alle Aktionen können an jeder Resource Control angewendet werden. Beispielsweise kann ein Prozess nicht die Anzahl der CPU-Shares überschreiten, die dem Projekt zugewiesen sind, bei dem der Prozess Mitglied ist. Aus diesem Grund ist die Aktion „deny“ für die Resource Control project.cpu-shares nicht zulässig.
Aufgrund der Implementierungseinschränkungen können die globalen Eigenschaften einer Resource Control den Bereich an verfügbaren Aktionen einschränken, die für diesen Schwellenwert eingerichtet werden können. (Weitere Informationen finden Sie in der Manpage rctladm(1M) Eine Liste der verfügbaren Signalaktionen finden Sie in der folgenden Tabelle. Weitere Informationen zu Signalen können Sie in der Manpage signal(3HEAD) nachlesen.
Tabelle 6–3 Für Resource Control-Werte verfügbare Signale
Signal |
Beschreibung |
Anmerkung |
---|---|---|
SIGABRT |
Beendet den Prozess. |
|
SIGHUP |
Sendet ein „Aufhängen“-Signal. Tritt ein, wenn ein Netzbetreiber eine offene Leitung abwirft. Das Signal wird an die Prozessgruppe gesendet, die das Terminal steuert. |
|
SIGTERM |
Beendet den Prozess. Von der Software gesendetes Beendigungssignal. |
|
SIGKILL |
Beendet den Prozess und bricht das Programm ab. |
|
SIGSTOP |
Stoppt den Prozess. Job-Steuerungssignal. |
|
SIGXRES |
Grenzwert der Resource Control überschritten. Wird von der Resource Control erzeugt. |
|
SIGXFSZ |
Beendet den Prozess. Grenzwert für die Dateigröße überschritten. |
Verfügbar nur für Resource Controls mit der Eigenschaft RCTL_GLOBAL_FILE_SIZE (process.max-file-size). Weitere Informationen finden Sie unter rctlblk_set_value(3C). |
SIGXCPU |
Beendet den Prozess. Grenzwert für die CPU-Zeit überschritten. |
Verfügbar nur für Resource Controls mit der Eigenschaft RCTL_GLOBAL_CPUTIME (process.max-cpu-time). Weitere Informationen finden Sie unter rctlblk_set_value(3C). |
Jede Resource Control auf einem System verfügt über ein bestimmtes Set zugewiesener Eigenschaften. Dieses Eigenschaftenset ist als eine Reihe von Flags definiert, die allen gesteuerten Instanzen dieser Ressource zugeordnet sind. Globale Flags können nicht bearbeitet werden, aber die Flags können mit rctladm oder dem Systemaufruf getrctl abgerufen werden.
Lokale Flags definieren das Standardverhalten und die Konfiguration eines bestimmten Schwellenwerts der Resource Control für einen bestimmten Prozess oder eine Prozessansammlung. Die lokalen Flags für einen Schwellenwert wirken sich nicht auf das Verhalten anderer definierter Schwellenwerte für die gleiche Resource Control aus. Demgegenüber wirken sich globale Flags auf das Verhalten jedes Werts aus, der einer bestimmten Resource Control zugeordnet ist. Lokale Flags können innerhalb der Einschränkungen durch die entsprechenden globalen Flags mit dem Befehl prctl oder dem Systemaufruf setrctl bearbeitet werden. Lesen Sie dazu setrctl(2).
Eine vollständige Liste der lokalen Flags, globalen Flags und deren Definitionen finden Sie unter rctlblk_set_value(3C).
Um das Systemverhalten beim Erreichen des Schwellenwerts einer bestimmten Resource Control festzulegen, zeigen Sie die globalen Flags der Resource Control an. Dazu verwenden Sie den Befehl rctladm. Um beispielsweise die Werte für die Resource Control process.max-cpu-time anzuzeigen, geben Sie Folgendes ein:
$ rctladm process.max-cpu-time process.max-cpu-time syslog=off [ lowerable no-deny cpu-time inf seconds ] |
Die globalen Flags geben Folgendes an:
Superuser-Berechtigungen sind nicht erforderlich, um privilegierte Werte für diese Resource Control zu senken.
Auch wenn die Schwellenwerte überschritten werden, wird der Zugriff auf diese Resource Control niemals verweigert.
SIGXCPU kann gesendet werden, wenn Schwellenwerte für diese Resource Control erreicht wurden.
Der Zeit-Wert für die Resource Control.
Resource Control-Werte mit dem Zugriffsprivileg basic können nicht eingestellt werden. Es sind nur Resource Control-Werte mit den entsprechenden Zugriffsprivilegien zulässig.
Eine lokale Signalaktion kann nicht an Resource Control-Werten gesetzt werden.
Die globale syslog-Meldungsaktion kann für diese Resource Control nicht gesetzt werden.
Die Ressourcenanforderung immer verweigern, wenn die Grenzwerte überschritten werden.
Ein ganzzahliger Zählwert für die Resource Control.
Größeneinheit für die Resource Control.
Geben Sie den Befehl prctl ein, um die lokalen Werte und Aktionen für die Resource Control anzuzeigen.
$ prctl -n process.max-cpu-time $$ process 353939: -ksh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT process.max-cpu-time privileged 18.4Es inf signal=XCPU - system 18.4Es inf none |
Das Flag max (RCTL_LOCAL_MAXIMAL) ist für beide Schwellenwerte gesetzt, und das Flag inf (RCTL_GLOBAL_INFINITE) ist für diese Resource Control definiert. Ein inf-Wert hat eine unendliche Menge. Der Wert wird nie durchgesetzt. Daher stellen die konfigurierten Schwellenwerte unendliche Werte dar, die nie überschritten werden.
Für eine Ressource können mehrere Resource Controls vorhanden sein. Eine Resource Control kann auf jeder Inhaltsstufe im Prozessmodell existieren. Wenn Resource Controls für die gleichen Ressourcen auf unterschiedlichen Inhaltsstufen aktiv sind, wird die Resource Control auf der niedrigsten Inhaltsstufe zuerst durchgesetzt. Aus diesem Grund wird die Aktion für process.max-cpu-time vor der Aktion für task.max-cpu-time ausgeführt, wenn beide Resource Controls gleichzeitig durchgesetzt werden.
Häufig ist der Ressourcenverbrauch von Prozessen unbekannt. Um mehr Informationen zu erhalten, können Sie die globalen Resource Control-Aktionen verwenden, die über den Befehl rctladm verfügbar sind. Geben Sie den Befehl rctladm ein, um eine syslog-Aktion für eine Resource Control einzurichten. Wenn dann eine von dieser Resource Control verwaltete Einheit auf einen Schwellenwert trifft, wird eine Systemmeldung auf der konfigurierten Protokollstufe aufgezeichnet. Weitere Informationen finden Sie in Kapitel 7Verwalten von Resource Controls (Vorgehen) und in der Manpage rctladm(1M).
Jede in Tabelle 6–1 aufgeführte Resource Control kann einem Projekt entweder bei der Anmeldung zugewiesen werden, oder wenn newtask, su oder andere projektbezogene Startprogramme wie at, batch oder cron aufgerufen werden. Jeder initiierte Befehl wird in einer separaten Aufgabe mit dem Standardprojekt des aufrufenden Benutzers gestattet. Weitere Informationen finden Sie in den Manpages login(1), newtask(1), at(1), cron(1M) und su(1M).
Aktualisierungen der Einträge in der project-Datenbank, ob an der Datei /etc/project oder an einer Darstellung der Datenbank in einem Netzwerk-Namen-Service werden nicht an den derzeit aktiven Projekten angewendet. Die Aktualisierungen werden angewendet, wenn eine neue Aufgabe über eine Anmeldung oder newtask zum Projekt hinzugefügt wird.
In der project-Datenbank geänderte Werte gelten nur für neue Aufgaben, die in einem Projekt gestartet werden. Sie können jedoch in die Befehle rctladm und prctl verwenden, um die Resource Controls bei laufendem System zu aktualisieren.
Der Befehl rctladm wirkt sich systemweit auf den globalen Protokollierungsstatus jeder Resource Control aus. Mit diesem Befehl können Sie den globalen Status anzeigen und die Stufe der syslog-Protokollierung einstellen, wenn Resource Controls überschritten werden.
Mit dem Befehl prctl können Sie die Werte und Aktionen von Resource Controls auf Prozess-, Aufgaben- oder Projektbasis anzeigen oder vorübergehend ändern. Als Eingabe wird eine Projekt-, Aufgaben- oder Prozess-ID verwendet. Der Befehl arbeitet auf der Stufe mit der Resource Control, auf der sie definiert ist.
Alle Änderungen an Werten und Aktionen werden unmittelbar übernommen. Diese Änderungen gelten jedoch nur für den aktuellen Prozess, die aktuelle Aufgabe oder das aktuelle Projekt. Die Änderungen werden nicht in der project-Datenbank aufgezeichnet. Wird das System neu gestartet, gehen die Änderungen verloren. Permanente Änderungen an Resource Controls müssen in der project-Datenbank vorgenommen werden.
Alle Einstellungen für Resource Controls, die in der project-Datenbank geändert werden können, können auch mit dem Befehl prctl geändert werden. Es können sowohl allgemeine als auch privilegierte Werte hinzugefügt oder gelöscht werden. Auch deren Aktionen können geändert werden. Standardmäßig wird der Typ „basic“ für alle Vorgänge angewendet, Prozesse und Benutzer mit Superuser-Berechtigungen können jedoch auch „privileged“ Resource Controls ändern. System-Resource Controls können nicht geändert werden.
In der folgenden Tabelle sind die Befehle aufgeführt, die mit Resource Controls verwendet werden können.
Befehl |
Beschreibung |
---|---|
Ermöglicht das Überwachen, welche IPC-Objekte zur Nutzung durch ein Projekt beitragen |
|
Ermöglicht das Erstellen von Echtzeitabfragen und Modifikationen an Resource Controls mit lokalem Geltungsbereich |
|
Ermöglicht das Erstellen von Echtzeitabfragen und Modifikationen an Resource Controls mit globalem Geltungsbereich |
In der Manpage resource_controls(5) finden Sie Beschreibungen der Resource Controls, die über die Projektdatenbank zur Verfügung stehen, einschließlich Einheiten und Skalierungsfaktoren.
In diesem Kapitel wird die Verwaltung von Resource Controls beschrieben.
Eine Einführung in die Resource Controls finden Sie in Kapitel 6Einführung in die Resource Controls.
Aufgabe |
Beschreibung |
Siehe |
---|---|---|
Einrichten der Resource Controls. |
Einrichten der Resource Controls für ein Projekt in der Datei /etc/project. | |
Abrufen oder Ändern der Werte von Resource Controls für aktive Prozesse, Aufgaben oder Projekte mit lokalem Geltungsbereich. |
Durchführen von Echtzeitabfragen oder Änderungen von Resource Controls, die einem aktiven Prozess, einer Aufgabe oder einem Projekt im System zugeteilt sind. | |
Anzeigen oder Aktualisieren des globalen Zustands von Resource Controls auf einem laufenden System. |
Anzeigen des globalen Logging-Status jeder Resource Control im System. Darüber hinaus wird die Stufe der syslog-Protokollierung festgelegt, wenn Resource Controls überschritten werden. | |
Berichten des Status der aktiven prozessübergreifenden Kommunikation (Interprocess Communication, IPC). |
Anzeigen von Informationen zur aktiven prozessübergreifenden Kommunikation. Überwachen, welche IPC-Objekte zur Nutzung durch ein Projekt beitragen. | |
Feststellen, ob einem Webserver ausreichend CPU-Kapazität zugeordnet ist. |
Einrichten einer globalen Aktion für eine Resource Control. Mit dieser Aktion können Sie einen Bericht alle Einheiten erstellen, deren Resource Control-Wert zu niedrig eingestellt ist. |
So stellen Sie fest, ob einem Webserver ausreichend CPU-Kapazität zugeordnet ist |
Dieses Verfahren fügt ein Projekt namens x-files zur Datei /etc/project hinzu und legt die maximale Anzahl der LWPs für eine Aufgabe fest, die in dem Projekt erstellt wird.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Geben Sie den Befehl projadd mit der Option -K ein, um ein Projekt mit der Bezeichnung x-files zu erstellen. Legen Sie die maximale Anzahl der LWPs für eine Aufgabe, die in dem Projekt erstellt wird, mit 3 fest.
# projadd -K 'task.max-lwps=(privileged,3,deny)' x-files |
Zeigen Sie den Eintrag in der Datei /etc/project mithilfe einer der folgenden Methoden an:
Geben Sie Folgendes ein:
# projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: . . . x-files projid : 100 comment: "" users : (none) groups : (none) attribs: task.max-lwps=(privileged,3,deny) |
Geben Sie Folgendes ein:
# cat /etc/project system:0:System::: . . . x-files:100::::task.max-lwps=(privileged,3,deny) |
Nach dem Implementieren der Schritte dieses Verfahrens kann der Superuser, wenn er durch Verbinden des Projekts mit newtask eine neue Aufgabe im Projekt x-files erstellt, nicht mehr als drei LWPs erstellen, solange diese Aufgabe ausgeführt wird. Dies wird in der folgenden, mit Anmerkungen versehenen Beispielsitzung gezeigt.
# newtask -p x-files csh # prctl -n task.max-lwps $$ process: 111107: csh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT task.max-lwps privileged 3 - deny - system 2.15G max deny - # id -p uid=0(root) gid=1(other) projid=100(x-files) # ps -o project,taskid -p $$ PROJECT TASKID x-files 73 # csh /* creates second LWP */ # csh /* creates third LWP */ # csh /* cannot create more LWPs */ Vfork failed # |
Die Datei /etc/project kann Einstellungen für mehrere Resource Controls für jedes Projekt sowie mehrere Schwellenwerte für jede Resource Control enthalten. Schwellenwerte sind in den Aktionsklauseln definiert, die bei mehreren Werten durch Kommata voneinander getrennt sind.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Geben Sie den Befehl projmod mit den Optionen -s und -K ein, um die Resource Controls für das Projekt x-files einzustellen:
# projmod -s -K 'task.max-lwps=(basic,10,none),(privileged,500,deny); process.max-file-descriptor=(basic,128,deny)' x-filesone line in file |
Die folgenden Resource Controls werden eingerichtet:
Eine basic-Resource Control ohne Aktion mit Bezug auf die maximale Anzahl der LWPs pro Aufgabe.
Eine privilegierte deny-Resource Control mit Bezug auf die maximale Anzahl der LWPs pro Aufgabe. Diese Resource Control sorgt dafür, dass das Erstellen von LWPs über den Höchstwert hinaus fehlschlägt (wie vorherigen Beispiel So richten Sie die maximale Anzahl der LWPs für jede Aufgabe in einem Projekt ein gezeigt).
Ein Grenzwert für die maximale Anzahl der Dateideskriptoren pro Prozess auf der Stufe basic. Dieser Grenzwert lässt alle offenen Aufrufe fehlschlagen, die den Höchstwert übersteigen.
Zeigen Sie den Eintrag in der Datei mithilfe einer der folgenden Methoden an:
Geben Sie Folgendes ein:
# projects -l . . . x-files projid : 100 comment: "" users : (none) groups : (none) attribs: process.max-file-descriptor=(basic,128,deny) task.max-lwps=(basic,10,none),(privileged,500,deny) one line in file |
Geben Sie Folgendes ein:
# cat etc/project . . . x-files:100::::process.max-file-descriptor=(basic,128,deny); task.max-lwps=(basic,10,none),(privileged,500,deny) one line in file |
Mit dem Befehl prctl erstellen Sie Echtzeitabfragen oder Änderungen von Resource Controls, die einem aktiven Prozess, einer Aufgabe oder einem Projekt im System zugeteilt sind. Weitere Informationen finden Sie in der Manpage prctl(1).
Dieses Verfahren muss auf einem System verwendet werden, bei dem keine Resource Controls eingestellt oder geändert wurden. Es können nur nicht standardmäßige Einträge in der Datei /etc/system oder in der project-Datenbank vorliegen.
Verwenden Sie den Befehl prctl an einem beliebigen Prozess, z. B. der aktuell ausgeführten Shell.
# prctl $$ process: 100337: -sh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT process.max-port-events privileged 65.5K - deny - system 2.15G max deny - process.crypto-buffer-limit system 16.0EB max deny - process.max-crypto-sessions system 18.4E max deny - process.add-crypto-sessions privileged 100 - deny - system 18.4E max deny - process.min-crypto-sessions privileged 20 - deny - system 18.4E max deny - process.max-msg-messages privileged 8.19K - deny - system 4.29G max deny - process.max-msg-qbytes privileged 64.0KB - deny - system 16.0EB max deny - process.max-sem-ops privileged 512 - deny - system 2.15G max deny - process.max-sem-nsems privileged 512 - deny - system 32.8K max deny - process.max-address-space privileged 16.0EB max deny - system 16.0EB max deny - process.max-file-descriptor basic 256 - deny 100337 privileged 65.5K - deny - system 2.15G max deny - process.max-core-size privileged 8.00EB max deny - system 8.00EB max deny - process.max-stack-size basic 8.00MB - deny 100337 privileged 8.00EB - deny - system 8.00EB max deny - process.max-data-size privileged 16.0EB max deny - system 16.0EB max deny - process.max-file-size privileged 8.00EB max deny,signal=XFSZ - system 8.00EB max deny - process.max-cpu-time privileged 18.4Es inf signal=XCPU - system 18.4Es inf none - task.max-cpu-time system 18.4Es inf none - task.max-lwps system 2.15G max deny - project.max-contracts privileged 10.0K - deny - system 2.15G max deny - project.max-device-locked-memory privileged 499MB - deny - system 16.0EB max deny - project.max-port-ids privileged 8.19K - deny - system 65.5K max deny - project.max-shm-memory privileged 1.95GB - deny - system 16.0EB max deny - project.max-shm-ids privileged 128 - deny - system 16.8M max deny - project.max-msg-ids privileged 128 - deny - system 16.8M max deny - project.max-sem-ids privileged 128 - deny - system 16.8M max deny - project.max-tasks system 2.15G max deny - project.max-lwps system 2.15G max deny - project.cpu-shares privileged 1 - none - system 65.5K max none - zone.max-lwps system 2.15G max deny - zone.cpu-shares privileged 1 - none - system 65.5K max none - |
Zeigen Sie den maximalen Dateideskriptor für die aktuell ausgeführte Shell an.
# prctl -n process.max-file-descriptor $$ process: 110453: -sh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT process.max-file-descriptor basic 256 - deny 110453 privileged 65.5K - deny - system 2.15G max deny |
In diesem Beispielverfahren wird mit dem Befehl prctl ein neuer privilegierter Wert hinzugefügt, um zu verhindern, dass mehr als drei LWPs pro Projekt für das x-files-Projekt verwendet werden. Das Ergebnis ist mit dem Resultat unter So richten Sie die maximale Anzahl der LWPs für jede Aufgabe in einem Projekt ein vergleichbar.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Geben Sie newtask ein, um dem Projekt x-files eine neue Aufgabe hinzuzufügen.
# newtask -p x-files |
Geben Sie den Befehl id mit der Option -p ein, um zu überprüfen, ob der Beitritt zum richtigen Projekt erfolgte.
# id -p uid=0(root) gid=1(other) projid=101(x-files) |
Fügen Sie einen neuen privilegierten Wert für project.max-lwps hinzu, der die Anzahl der LWPs auf drei begrenzt.
# prctl -n project.max-lwps -t privileged -v 3 -e deny -i project x-files |
Überprüfen Sie das Ergebnis.
# prctl -n project.max-lwps -i project x-files process: 111108: csh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT project.max-lwps privileged 3 - deny - system 2.15G max deny - |
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Geben Sie den Befehl prctl mit der Option -r ein, um den niedrigsten Wert der Resource Control process.max-file-descriptor zu ändern.
# prctl -n process.max-file-descriptor -r -v 128 $$ |
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Zeigen Sie den Wert der Resource Control project.cpu-shares im Projekt group.staff an.
# prctl -n project.cpu-shares -i project group.staff project: 2: group.staff NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT project.cpu-shares privileged 1 - none - system 65.5K max none |
Ersetzen Sie den aktuellen Wert für project.cpu-shares von 1 durch den Wert 10.
# prctl -n project.cpu-shares -v 10 -r -i project group.staff |
Zeigen Sie den Wert der Resource Control project.cpu-shares im Projekt group.staff an.
# prctl -n project.cpu-shares -i project group.staff project: 2: group.staff NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT project.cpu-shares privileged 10 - none - system 65.5K max none |
Mit dem Befehl rctladm können Sie Echtzeitabfragen und Modifikationen des globalen Status von Resource Controls durchführen. Weitere Informationen finden Sie in der Manpage rctladm(1M).
Sie können beispielsweise den Befehl rctladm mit der Option -e eingeben, um das globale Attribut syslog einer Resource Control zu aktivieren. Wenn der Schwellenwert der Resource Control überschritten wird, protokolliert das System eine Benachrichtigung auf der angegebenen syslog-Stufe. Um das globale Attribut syslog der Resource Control process.max-file-descriptor zu aktivieren, geben Sie Folgendes ein:
# rctladm -e syslog process.max-file-descriptor |
Der Befehl rctladm ohne Argumente zeigt die globalen Flags (einschließlich des Flags für den globalen Typ) für jede Resource Control an.
# rctladm process.max-port-events syslog=off [ deny count ] process.max-msg-messages syslog=off [ deny count ] process.max-msg-qbytes syslog=off [ deny bytes ] process.max-sem-ops syslog=off [ deny count ] process.max-sem-nsems syslog=off [ deny count ] process.max-address-space syslog=off [ lowerable deny no-signal bytes ] process.max-file-descriptor syslog=off [ lowerable deny count ] process.max-core-size syslog=off [ lowerable deny no-signal bytes ] process.max-stack-size syslog=off [ lowerable deny no-signal bytes ] . . . |
Mit dem Dienstprogramm ipcs können Sie Informationen zur aktiven prozessübergreifenden Kommunikation (Interprocess Communication, IPC) anzeigen. Weitere Informationen finden Sie in der Manpage ipcs(1).
Geben Sie den Befehl ipcs mit der Option -J ein, um anzuzeigen, welcher Projekt-Grenzwert einem IPC-Objekt zugeordnet ist.
# ipcs -J IPC status from <running system> as of Wed Mar 26 18:53:15 PDT 2003 T ID KEY MODE OWNER GROUP PROJECT Message Queues: Shared Memory: m 3600 0 --rw-rw-rw- uname staff x-files m 201 0 --rw-rw-rw- uname staff x-files m 1802 0 --rw-rw-rw- uname staff x-files m 503 0 --rw-rw-rw- uname staff x-files m 304 0 --rw-rw-rw- uname staff x-files m 605 0 --rw-rw-rw- uname staff x-files m 6 0 --rw-rw-rw- uname staff x-files m 107 0 --rw-rw-rw- uname staff x-files Semaphores: s 0 0 --rw-rw-rw- uname staff x-files |
Mit einer globalen Aktion für eine Resource Control können Sie benachrichtigt werden, wenn ein Element durch einen zu niedrig eingestellten Resource Control-Wert behindert wird.
Angenommen, Sie möchten feststellen, ob ein Webserver über ausreichend CPUs für die typische Arbeitslast verfügt. Sie können die sar-Daten auf CPU-Zeit im Wartezustand und den Lastdurchschnitt analysieren. Sie können aber auch die Extended Accounting-Daten auswerten, um die Anzahl der gleichzeitigen Prozesse zu ermitteln, die für den Webserver-Prozess ausgeführt werden.
Der einfachste Ansatz ist jedoch, eine Aufgabe für den Webserver zu erstellen. Dann richten Sie eine globale Aktion mit dem Befehl syslog ein, um immer dann benachrichtigt zu werden, wenn eine Aufgabe die für die Kapazitäten des Computers eingerichtete Anzahl an LWPs überschreitet.
Weitere Informationen finden Sie in der Manpage sar(1).
Geben Sie den Befehl prctl ein, um eine privilegierte Resource Control (mit einem Superuser als Eigentümer) für die Aufgaben einzurichten, die einen httpd-Prozess enthalten. Begrenzen Sie die Gesamtzahl der LWPs für jede Aufgabe auf 40 und deaktivieren Sie alle lokalen Aktionen.
# prctl -n task.max-lwps -v 40 -t privileged -d all `pgrep httpd` |
Aktivieren Sie die globale Aktion eines Systemprotokolls für die Resource Control task.max-lwps.
# rctladm -e syslog task.max-lwps |
Überwachen Sie, ob die Arbeitslast die Resource Control auslöst.
In diesem Fall werden /var/adm/messages wie die Folgende angezeigt:
Jan 8 10:15:15 testmachine unix: [ID 859581 kern.notice] NOTICE: privileged rctl task.max-lwps exceeded by task 19 |
Die Analyse von Arbeitslastdaten kann ergeben, dass eine bestimmte Arbeitslast oder Arbeitslastgruppe CPU-Ressourcen monopolisiert. Wenn diese Arbeitslasten keine Ressourceneinschränkungen zur CPU-Nutzung verletzen, können Sie die Zuweisungsrichtlinie für die CPU-Zeit des Systems ändern. Mit der in diesem Kapitel beschriebenen Fair Share Scheduling-Klasse können Sie CPU-Zeit basierend auf Shares anstatt nach dem Prioritätsschema der Timesharing Scheduling-Klasse (TS) zuweisen.
In diesem Kapitel werden die folgenden Themen behandelt.
Um direkt in das Arbeiten mit dem Fair Share Scheduler einzusteigen, lesen Sie Kapitel 9Verwalten des Fair Share Scheduler (Vorgehen).
Eine der wichtigsten Aufgaben des Betriebssystems ist zu entscheiden, welche Prozesse wann Zugriff auf die Systemressourcen erhalten. Der Prozess-Scheduler, oder Dispatcher, ist der Teil des Kernel, der die Zuweisung der CPU-Ressourcen zu den Prozessen steuert. Der Scheduler unterstützt das Konzept von Scheduling-Klassen. Jede Klasse definiert eine Scheduling-Richtlinie, über die Prozesse innerhalb der Klasse geplant werden. Der standardmäßige Scheduler im Betriebssystem Solaris, der TS-Scheduler, versucht jedem Prozess etwa den gleichen Zugriff auf die verfügbaren CPU-Ressourcen zu gewähren. Dennoch kommt es häufig vor, dass bestimmte Prozesse mehr Ressourcen als andere Prozesse erhalten sollen.
Mit dem Fair Share Scheduler (FSS) können Sie die Zuordnung von verfügbaren CPU-Ressourcen zwischen den Arbeitslasten steuern. Die Zuordnung erfolgt dabei nach der Wichtigkeit der Arbeitslasten. Diese Wichtigkeit wird durch die Anzahl der Shares (Anteile) an CPU-Ressourcen ausgedrückt, die Sie jeder Arbeitslast zuweisen.
Indem Sie einem Projekt CPU-Shares zuweisen, können Sie die Ansprüche dieses Projekts auf CPU-Ressourcen steuern. Der FSS garantiert eine faire Verteilung der CPU-Ressourcen unter den Projekten. Die Verteilung basiert auf den zugewiesenen Shares und erfolgt unabhängig von der Anzahl an Prozessen, die an ein Projekt angehängt sind. Die Fairness des FSS zeigt sich durch Reduzieren der Projektansprüche bei starker CPU-Nutzung und Erhöhen der Ansprüche bei geringerer CPU-Nutzung. Dies geschieht immer in Übereinstimmung mit anderen Projekten.
Der FSS setzt sich aus einem Kernel-Scheduling-Klassenmodul und klassenspezifischen Versionen der Befehle dispadmin(1M) und priocntl(1) zusammen. Vom FSS verwendete Projekt-Shares werden über die Eigenschaft project.cpu-shares in der project(4)-Datenbank angegeben.
Wenn Sie die Resource Control project.cpu-shares auf einem System mit installierten Zonen verwenden, lesen Sie Konfigurationsdaten in einer Zone, Resource Controls in nicht-globalen Zonen und Verwenden des Fair Share Scheduler auf einem Solaris-System mit installierten Zonen.
Der Begriff „Share“ dient zum Festlegen des Anteils der CDU-Ressourcen eines Systems, der einem Projekt zugeordnet wird. Wenn Sie einem Projekt mehr CPU-Shares als einem anderen Projekt zuweisen, erhält das erste Projekt mehr CPU-Ressourcen vom Fair Share Scheduler.
CPU-Shares sind kein Synonym für „Prozentsatz der CPU-Ressourcen“. Shares dienen zum Festlegen der relativen Wichtigkeit von Arbeitslasten in Relation zu anderen Arbeitslasten. Wenn Sie einem Projekt CPU-Shares zuweisen, ist nicht die Anzahl der Shares, die ein Projekt erhält, wichtig. Wichtig ist, wie viele Shares das Projekt im Vergleich zu anderen Projekten hat. Darüber hinaus müssen Sie berücksichtigen, wie viele andere Projekte um CPU-Ressourcen konkurrieren.
Prozesse in Projekten mit null Shares werden immer mit der niedrigsten Systempriorität (0) ausgeführt. Diese Prozesse werden nur dann ausgeführt, wenn Projekte mit mehr als null Shares keine CPU-Ressourcen verbrauchen.
Eine Projektarbeitslast auf einem Solaris-System umfasst in der Regel mehrere Prozesse. Aus Sicht des Fair Share Scheduler kann jede Projektarbeitslast den Status idle (Wartezustand) oder active (aktiv) aufweisen. Ein Projekt wird als im Wartezustand betrachtet, wenn keiner der darin enthaltenen Prozesse CPU-Ressourcen verbraucht. In der Regel bedeutet dies, dass solche Prozesse entweder ruhen (auf den Abschluss eines E/A-Vorgangs warten) oder gestoppt sind. Ein Projekt wird als aktiv angesehen, wenn mindestens einer der darin enthaltenen Prozesse CPU-Ressourcen verbraucht. Die Summe der Shares aller aktiven Projekte dient zum Berechnen des Anteils an CPU-Ressourcen, der den Projekten zugeordnet wird.
Sind mehrere Projekte aktiv, werden die zugewiesenen CPU-Ressourcen für jedes Projekt reduziert, der Anteil an den Ressourcen bleibt für die einzelnen Projekte jedoch unverändert.
Die Zuweisung von Shares ist nicht das Gleiche wie Auslastung. Ein Projekt, dem 50 % der CPU-Ressourcen zugeordnet sind, wird im Durchschnitt nur 20 % der CPU nutzen. Darüber hinaus dienen die Shares eines Projekts nur dann als Grenzwert für die CPU-Nutzung, wenn das Projekt mit anderen Projekten um CPU-Ressourcen konkurriert. Unabhängig davon, wie viele Shares einem Projekt zugewiesen sind, es erhält immer 100 % der Rechenleistung, wenn es allein auf dem System ausgeführt wird. Verfügbare CPU-Zyklen gehen nie verloren. Sie werden zwischen den Projekten aufgeteilt.
Das Zuweisen nur weniger Shares zu einer regen Arbeitslast könnte deren Performance herabsetzen. Jedoch wird nicht verhindert, dass diese Arbeitslast ihre Arbeit abschließt, sofern das System nicht überlastet ist.
Angenommen, Sie haben ein System mit zwei CPUs, die zwei parallele CPU-gebundene Arbeitslasten namens A und B ausführen. Jede Arbeitslast wird als ein separates Projekt ausgeführt. Die Projekte wurden so konfiguriert, dass Projekt A SA Shares zugewiesen sind und Projekt B SB Shares.
Unter dem traditionellen TS-Scheduler erhält jede Arbeitslast, die auf dem System aufgeführt wird, durchschnittlich den gleichen Anteil an CPU-Ressourcen. Jede Arbeitslast würde 50 % der Systemkapazität erhalten.
Wenn diese Projekte unter der Kontrolle des FSS-Schedulers mit SA=SB ausgeführt werden, erhalten diese Projekte ebenfalls in etwa die gleichen Anteile an CPU-Ressourcen. Sind diesen Projekten jedoch unterschiedlich viele Shares zugewiesen, ist auch die Zuordnung von CPU-Ressourcen unterschiedlich.
Die folgenden drei Beispiele zeigen, wie in verschiedenen Konfigurationen mit Shares gearbeitet wird. Diese Beispiele zeigen, dass Shares nur dann mathematisch korrekt für die Darstellung der Nutzung verwendet werden können, wenn der Bedarf den verfügbaren Ressourcen entspricht oder diese übersteigt.
Wenn·A und B jeweils zwei CPU-gebundene Prozesse enthalten und S A = 1 und S B = 3 ist, beträgt die Gesamtanzahl der Shares 1 + 3 = 4. Bei dieser Konfiguration, ausreichender CPU-Bedarf vorausgesetzt, werden den Projekten A und B 25% bzw. 75% der CPU-Ressourcen zugewiesen.
Wenn·A und B über jeweils nur einen CPU-gebundenen Prozess verfügen und S A = 1 und S B = 100 ist, beträgt die Gesamtanzahl der Shares 101. Kein Projekt kann mehr als eine CPU benutzen, weil jedes Projekt über nur einen laufenden Prozess verfügt. Da bei dieser Konfiguration keine Konkurrenz zwischen den Projekten um CPU-Ressourcen besteht, werden Projekt A und Projekt B jeweils 50% aller CPU-Ressourcen zugewiesen. Bei dieser Konfiguration ist die Anzahl an CPU-Shares irrelevant. Die den Projekten zugewiesenen Ressourcen wären auch dann gleich (50/50), wenn beiden Projekten null Shares zugewiesen wären.
Wenn A und B jeweils zwei CPU-gebundene Prozesse haben und Projekt A 1 Share, Projekt B 0 Shares zugeordnet wurden, erhält Projekt B keine CPU-Ressourcen und Projekt A alle CPU-Ressourcen. Prozesse in B werden immer mit der Systempriorität 0 ausgeführt. Mit anderen Worten, sie werden nie ausgeführt, da Prozesse in Projekt A immer höhere Prioritäten haben.
Projekte sind die Arbeitslastcontainer im FSS-Scheduler. Die einem Projekt zugewiesenen Benutzergruppen werden als einzeln steuerbare Blöcke betrachtet. Beachten Sie, dass Sie für jeden einzelnen Benutzer ein Projekt mit einer individuellen Anzahl an Shares erstellen können.
Benutzer können Mitglieder mehrerer Projekte sein, denen unterschiedlich viele Shares zugeordnet sind. Durch das Verschieben von Prozessen von einem Projekt zu einem anderen können den Prozessen CPU-Ressourcen verschiedener Größenordnungen zugewiesen werden.
Weitere Informationen zur project(4)-Datenbank und den Namen-Services finden Sie unter project-Datenbank.
Die Konfiguration der CPU-Shares wird vom Namen-Service als Eigenschaft der project-Datenbank verwaltet.
Wenn die erste Aufgabe (bzw. der erste Prozess) einem mit der Bibliotheksfunktion setproject(3PROJECT) erstellten Projekt zugeordnet ist, wird die Anzahl der CPU-Shares, die als Resource Control project.cpu-shares in der project-Datenbank definiert wurde, an den Kernel übergeben. Einem Projekt, für das keine Resource Control project.cpu-shares definiert wurde, wird ein Share zugewiesen.
Im folgenden Beispiel setzt der Eintrag in der Datei /etc/project die Anzahl der Shares für das Projekt x-files auf 5:
x-files:100::::project.cpu-shares=(privileged,5,none) |
Wenn Sie die Anzahl der CPU-Shares, die einem Projekt in der Datenbank zugeordnet ist, während der Ausführung von Prozessen ändern, wird diese Änderung nicht unmittelbar übernommen. Das Projekt muss neu gestartet werden, damit die Änderung wirksam wird.
Soll die Anzahl der einem Projekt zugeordneten Shares nur vorübergehend geändert werden, ohne die Projektattribute in der project-Datenbank zu ändern, verwenden Sie den Befehl prctl. Um beispielsweise den Wert der Resource Control project.cpu-shares für das Projekt x-files auf 3 zu ändern, während die dem Projekt zugeordneten Prozesse ausgeführt werden, geben Sie Folgendes ein:
# prctl -r -n project.cpu-shares -v 3 -i project x-files |
Weitere Informationen finden Sie in der Manpage prctl(1).
Ersetzt den aktuellen Wert der angegebenen Resource Control.
Gibt den Namen der Resource Control an.
Gibt den Wert der Resource Control an.
Gibt den ID-Typ des nächsten Arguments an.
Gibt das Objekt der Änderung an. In diesem Fall ist das Objekt das Projekt x-files.
Das Projekt system mit der Projekt-ID 0 enthält alle Systemdaemons, die von den Initialisierungsskripten beim Booten gestartet wurden. system kann als ein Projekt mit einer unbegrenzten Anzahl an Shares betrachtet werden. Dies bedeutet, dass system immer als erstes geplant wird, ungeachtet der Anzahl an Shares, die anderen Projekten zugewiesen wurden. Wenn Sie nicht möchten, dass das Projekt system eine unbegrenzte Anzahl an Shares erhält, können Sie in der project-Datenbank festlegen, wie viele Shares diesem Projekt zugeordnet werden sollen.
Wie bereits beschrieben, erhalten Prozesse, die Projekten mit null Shares zugeordnet sind, immer eine Systempriorität von null. Projekte mit einem oder mehr Shares werden mit den Prioritäten eins und höher ausgeführt. Somit werden Projekte mit null Shares nur dann geplant, wenn CPU-Ressourcen verfügbar sind, die nicht von einem Projekt mit mehr als null Shares angefordert sind.
Einem Projekt können nicht mehr als 65535 Shares zugewiesen werden.
Mit FSS und Prozessorsets kann die Aufteilung von CPU-Ressourcen unter den Projekten, die auf den einzelnen Prozessorsets ausgeführt werden, besser als mit Prozessorsets allein gesteuert werden. Der FSS-Scheduler behandelt Prozessorsets als vollständig unabhängige Partitionen. Dabei wird jedes Prozessorset hinsichtlich der CPU-Zuweisungen vollständig unabhängig gesteuert.
Die Zuweisung von CPU-Ressourcen zu Projekten, die auf ein Prozessorset ausgeführt werden, wird weder von den CPU-Shares noch den Aktivitäten der Projekte beeinflusst, die auf einem anderen Prozessorset ausgeführt werden, da diese Projekte nicht um die gleichen Ressourcen konkurrieren. Projekte konkurrieren nur miteinander, wenn sie auf dem gleichen Prozessorset ausgeführt werden.
Die Anzahl der einem Projekt zugewiesenen Shares gilt systemweit. Unabhängig davon, auf welchem Prozessorset ein Projekt ausgeführt wird, erhält jeder Teil eines Projekts die gleiche Anzahl an Shares.
Wenn Prozessorsets verwendet werden, werden die CPU-Zuweisungen für ein Projekt nur für die aktiven Projekte berechnet, die auf einem Prozessorset ausgeführt werden.
Projektpartitionen, die auf anderen Prozessorsets ausgeführt werden, haben eventuell abweichende CPU-Zuweisungen. Die Zuweisung von CPU-Ressourcen für jede Projektpartition in einem Prozessorset hängt nur von den Zuweisungen anderer Projekte ab, die auf diesem Prozessorset ausgeführt werden.
Leistung und Verfügbarkeit von Anwendungen, die innerhalb der Grenzen ihrer Prozessorsets ausgeführt werden, werden von der Einführung neuer Prozessorsets nicht beeinflusst. Darüber hinaus wirken sich Änderungen, die an den Share-Zuweisungen zu Projekten in anderen Prozessorsets vorgenommen werden, nicht auf die Anwendungen aus.
Leere Prozessorsets (Sets ohne Prozessoren) oder Prozessoren ohne darin gebundene Prozesse haben keinen Einfluss auf das Verhalten des FSS-Scheduler.
Angenommen, ein Server mit acht CPUs führt mehrere CPU-gebundene Anwendungen in den Projekten A, B und C aus. Projekt A ist ein Share zugewiesen, Projekt B sind zwei Shares zugewiesen und Projekt C sind drei Shares zugewiesen.
Projekt A wird nur auf Prozessorset 1 ausgeführt. Projekt B wird auf den Prozessorsets 1 und 2 ausgeführt. Projekt C wird auf den Prozessorsets 1, 2 und 3 ausgeführt. Es wird davon ausgegangen, dass jedes Projekt über genügend Prozesse verfügt, um die gesamte verfügbare CPU-Leistung auszulasten. Daher konkurrieren alle Prozesse auf jedem Prozessorset um die verfügbaren CPU-Ressourcen.
Die gesamte systemweite CPU-Zuweisung für Projekte auf einem solchen System wird in der folgenden Tabelle gezeigt.
Projekt |
Zuweisung |
---|---|
Projekt A |
4% = (1/6 X 2/8)pset1 |
Projekt B |
28% = (2/6 X 2/8)pset1+ (2/5 * 4/8)pset2 |
Projekt C |
67% = (3/6 X 2/8)pset1+ (3/5 X 4/8)pset2+ (3/3 X 2/8)pset3 |
Diese Prozentwerte stimmen nicht der entsprechenden Anzahl an CPU-Shares überein, die den Projekten zugeordnet sind. Dennoch sind die zugewiesenen CPU-Ressourcen pro Projekt innerhalb jedes Prozessorsets proportional zu den jeweiligen Shares.
Auf dem gleichen System ohne Prozessorsets wäre die Verteilung der CPU-Ressourcen anders. Dies wird in der folgenden Tabelle gezeigt.
Projekt |
Zuweisung |
---|---|
Projekt A |
16.66% = (1/6) |
Projekt B |
33.33% = (2/6) |
Projekt C |
50% = (3/6) |
Standardmäßig nutzt die FSS-Scheduling-Klasse den gleichen Prioritätenbereich (0 bis 59) wie die Scheduling-Klassen Timesharing (TS), Interactive (IA) und Fixed Priority (FX). Aus diesem Grund sollten Sie vermeiden, dass Prozesse aus diesen Scheduling-Klassen das gleiche Prozessorset gemeinsam nutzen. Das Verbinden von Prozessen der Klassen FSS, TS, IA und FX könnte zu einem unerwarteten Scheduling-Verhalten führen.
Werden Prozessorsets verwendet, können Sie TS, IA und FX mit FSS in einem System verbinden. Alle Prozesse, die auf den Prozessorsets ausgeführt werden, müssen jedoch einer Scheduling-Klasse angehören, so dass sie nicht um die gleichen CPUs konkurrieren. Insbesondere sollte der FX-Scheduler nicht zusammen mit der FSS-Scheduling-Klasse verwendet werden, es sei denn, es werden Prozessorsets verwendet. Hierdurch wird verhindert, dass Anwendungen in der FX-Klasse so hohe Prioritäten verwenden, dass Anwendungen in der FSS-Klasse nicht mehr zum Zuge kommen.
Prozesse der Klassen TS und IA können auf dem gleichen Prozessorset oder auf dem gleichen System ohne Prozessorsets gemischt werden.
Für Benutzer mit Superuser-Berechtigungen bietet das Solaris-System darüber hinaus einen Realtime-Scheduler (RT). In der Standardeinstellung nutzt die RT-Scheduling-Klasse Systemprioritäten in einem anderen Bereich als der FSS (in der Regel von 100 bis 159). Da RT und FSS getrennte oder nicht-überlappende Prioritätenbereiche nutzen, kann FSS mit der RT-Scheduling-Klasse innerhalb des gleichen Prozessorsets koexistieren. Jedoch hat die FSS-Scheduling-Klasse keine Kontrolle über Prozesse, die in der RT-Klasse ausgeführt werden.
Bei einem Vier-Prozessor-System kann ein CPU-gebundener RT-Prozess mit einem Thread einen gesamten Prozessor verbrauchen. Wenn das System auch FSS ausführt, konkurrieren die Prozesse normaler Benutzer um die drei verbleibenden CPUs, die nicht vom RT-Prozess genutzt werden. Beachten Sie, dass der RT-Prozess die CPU eventuell nicht ständig nutzt. Wenn sich der RT-Prozess im Leerlauf befindet, lastet der FSS alle vier Prozessoren aus.
Mit dem folgenden Befehl können Sie herauszufinden, in welchen Scheduling-Klassen die Prozessorsets ausgeführt werden und sicherstellen, dass jedes Prozessorset zur Ausführung entweder von TS-, IA-, FX- oder FSS-Prozessen konfiguriert ist.
$ ps -ef -o pset,class | grep -v CLS | sort | uniq 1 FSS 1 SYS 2 TS 2 RT 3 FX |
Informationen zum Einstellen der standardmäßigen Scheduling-Klasse für das System finden Sie unter So legen Sie FSS als standardmäßige Scheduling-Klasse fest, Scheduling-Klasse in einer Zone und in der Manpage dispadmin(1M). Wie Sie laufende Prozesse in eine andere Scheduling-Klasse verschieben, können Sie unter Konfigurieren des FSS und in der Manpage priocntl(1) nachlesen.
Nicht-globale Zonen verwenden die standardmäßige Scheduling-Klasse des Systems. Wenn das System eine neue Standardeinstellung für die Scheduling-Klasse erhält, beziehen die nicht-globalen Zonen die neue Einstellung nach dem Booten bzw. einem Neustart.
Normalerweise wird der FSS in diesem Fall mit dem Befehl dispadmin auf die standardmäßige Scheduling-Klasse des Systems gesetzt. So erhalten alle Zonen einen gleich großen Anteil der CPU-Ressourcen des Systems. Weitere Informationen zu Scheduling-Klassen bei installierten Zonen finden Sie unter Scheduling-Klasse in einer Zone.
Informationen zum Verschieben von laufenden Prozessen in eine andere Scheduling-Klasse, ohne die standardmäßige Scheduling-Klasse zu ändern und einen Neustart durchzuführen, finden Sie in Tabelle 27–5 und in der Manpage priocntl(1).
Die in der folgenden Tabelle aufgeführten Befehle stellen die primäre administrative Schnittstelle zum Fair Share Scheduler dar.
Befehl |
Beschreibung |
---|---|
Zeigt die Scheduling-Parameter der angegebenen Prozesse an oder stellt sie ein, verschiebt laufende Prozesse in eine andere Scheduling-Klasse. |
|
Listet Informationen über laufende Prozesse auf, kennzeichnet, in welchen Scheduling-Klassen Prozessorsets ausgeführt werden. |
|
Legt den standardmäßigen Scheduler für das System fest. Dient darüber hinaus zum Prüfen und Einstellen des Zeit-Quantumwerts des FSS-Scheduler. |
|
Beschreibt den Fair Share Scheduler (FSS). |
In diesem Kapitel wird die Verwendung des Fair Share Scheduler (FSS) beschrieben.
Eine Einführung zum FSS finden Sie in Kapitel 8Einführung in den Fair Share Scheduler. Weitere Informationen zu Scheduling-Klassen bei installierten Zonen finden Sie unter Scheduling-Klasse in einer Zone.
Aufgabe |
Beschreibung |
Weitere Informationen |
---|---|---|
Überwachen der CPU-Nutzung. |
Überwachen der CPU-Nutzung durch Projekte und Projekten in Prozessorsets. | |
Festlegen der standardmäßigen Scheduler-Klasse. |
Festlegen eines Schedulers wie z. B. FSS als standardmäßigen Scheduler für das System. | |
Verschieben von laufenden Prozessen aus einer Scheduling-Klasse in eine andere Scheduling-Klasse, z. B. in die FSS-Klasse. |
Manuelles Verschieben von Prozessen aus einer Scheduling-Klasse in eine andere Scheduling-Klasse, ohne dabei die standardmäßige Scheduler-Klasse zu ändern oder das System neu zu booten. |
So verschieben Sie manuelle Prozesse aus der TS-Klasse in die FSS-Klasse |
Verschieben aller laufenden Prozesse aus allen Scheduling-Klassen in eine andere Scheduling-Klasse, z. B. in die FSS-Klasse. |
Manuelles Verschieben von Prozessen aus allen Scheduling-Klassen in eine andere Scheduling-Klasse, ohne dabei die standardmäßige Scheduling-Klasse zu ändern oder das System neu zu booten. |
So verschieben Sie Prozesse manuell aus allen Benutzerklassen in die FSS-Klasse |
Verschieben der Prozesse eines Projekts in eine andere Scheduling-Klasse, z. B. in die FSS-Klasse. |
Manuelles Verschieben der Prozesse eines Projekts aus der aktuellen Scheduling-Klasse in eine andere Scheduling-Klasse. |
So verschieben Sie die Prozesse eines Projekts manuell in die FSS-Klasse |
Untersuchen und Einstellen der FSS-Parameter. |
Einstellen des Quantum-Zeitwerts des Schedulers. Zeit-Quantum ist die Zeit, die ein Thread ausgeführt werden darf, bevor er die Kontrolle über den Prozessor abgeben muss. |
Mit dem in der Manpage prstat(1M) ausführlich beschriebenen Befehl prstat können Sie die CPU-Nutzung durch aktive Projekte überwachen.
Sie können die Extended Accounting-Daten für Aufgaben verwenden, um Statistiken der einzelnen Projekte zum Betrag der CPU-Ressourcen zu beziehen, die über einen längeren Zeitraum verbraucht werden. Weitere Informationen finden Sie in Kapitel 4Einführung in das Extended Accounting.
Zum Überwachen der CPU-Nutzung durch die auf einem System ausgeführten Projekte verwenden Sie den Befehl prstat mit der Option -J.
% prstat -J |
Zum Überwachen der CPU-Nutzung durch Projekte in einer Liste von Prozessorsets geben Sie Folgendes ein:
% prstat -J -C pset-list |
dabei steht pset-list für eine Liste der durch Kommata getrennten Prozessorset-IDs.
Die gleichen Befehle, die Sie für andere Scheduling-Klasse im Solaris-System verwenden, können auch für den FSS eingesetzt werden. Sie können die Scheduler-Klasse festlegen, die Parameter des Scheduler konfigurieren und die Eigenschaften bestimmter Prozesse einstellen.
Zum Neustarten des Scheduler-Service geben Sie den Befehl svcadm restart ein. Weitere Informationen finden Sie unter svcadm(1M).
Der FSS muss als standardmäßiger Scheduler auf dem System eingerichtet sein, damit die Zuweisung von CPU-Shares wirksam ist.
Mit einer Kombination der Befehle priocntl und dispadmin stellen Sie sicher, dass der FSS unmittelbar und auch nach einem Neustart der standardmäßige Scheduler wird.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Legen Sie FSS als standardmäßigen Scheduler für das System fest.
# dispadmin -d FSS |
Diese Änderung wirkt sich nach dem nächsten Neustart aus. Nach dem Neustart wird jeder Prozess auf dem System in der FSS-Scheduling-Klasse ausgeführt.
Die folgende Konfiguration wird unmittelbar und ohne einen Neustart wirksam.
# priocntl -s -c FSS -i all |
Sie können Prozesse manuell aus einer Scheduling-Klasse in eine andere Scheduling-Klasse verschieben, ohne die standardmäßige Scheduling-Klasse zu ändern oder das System neu zu booten. Dieses Verfahren zeigt, wie Sie Prozesse manuell aus der TS-Scheduling-Klasse in die FSS-Scheduling-Klasse verschieben.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Verschieben Sie den init-Prozess (pid 1) in die FSS-Scheduling-Klasse.
# priocntl -s -c FSS -i pid 1 |
Verschieben Sie alle Prozesse aus der TS-Scheduling-Klasse in die FSS-Scheduling-Klasse.
# priocntl -s -c FSS -i class TS |
Nach dem Neustart werden alle Prozesse wieder in der TS-Scheduling-Klasse ausgeführt.
Eventuell verwenden Sie eine andere Standard-Klasse als die TS-Scheduling-Klasse. Vielleicht wird das System in einer Fensterumgebung ausgeführt, die standardmäßig die IA-Klasse verwendet. Sie können alle Prozesse manuell in die FSS-Scheduling-Klasse verschieben, ohne die standardmäßige Scheduling-Klasse zu ändern oder das System neu zu booten.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Verschieben Sie den init-Prozess (pid 1) in die FSS-Scheduling-Klasse.
# priocntl -s -c FSS -i pid 1 |
Verschieben Sie alle Prozesse aus den aktuellen Scheduling-Klassen in die FSS-Scheduling-Klasse.
# priocntl -s -c FSS -i all |
Nach dem Neustart werden alle Prozesse wieder in der standardmäßigen Scheduling-Klasse ausgeführt.
Sie können die Prozesse eines Projekts manuell aus der aktuellen Scheduling-Klasse in die FSS-Scheduling-Klasse verschieben.
Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Verschieben Sie Prozesse, die in der Projekt-ID 10 ausgeführt werden, in die FSS-Scheduling-Klasse.
# priocntl -s -c FSS -i projid 10 |
Nach dem Neustart werden die Prozesse des Projekts wieder in der standardmäßigen Scheduling-Klasse ausgeführt.
Mit dem Befehl dispadmin können Sie die Parameter eines Prozess-Schedulers bei laufendem System anzeigen oder ändern. Beispielsweise können Sie den Befehl dispadmin eingeben, um den Zeit-Quantumwert des FSS-Schedulers zu prüfen und einzustellen. Zeit-Quantum ist die Zeit, die ein Thread ausgeführt werden darf, bevor er die Kontrolle über den Prozessor abgeben muss.
Zum Anzeigen des aktuellen Zeit-Quantums für den FSS-Scheduler bei laufendem System geben Sie Folgendes ein:
$ dispadmin -c FSS -g # # Fair Share Scheduler Configuration # RES=1000 # # Time Quantum # QUANTUM=110 |
Wenn Sie die Option -g verwenden, können Sie auch die Option -r angeben, um die Auflösung festzulegen, die beim Drucken der Zeit-Quantumswerte verwendet wird. Wenn keine Auflösung angegeben ist, werden die Zeit-Quantumswerte standardmäßig als Millisekunden angezeigt.
$ dispadmin -c FSS -g -r 100 # # Fair Share Scheduler Configuration # RES=100 # # Time Quantum # QUANTUM=11 |
Zum Einstellen der Scheduling-Parameter der FSS-Scheduling-Klasse geben Sie dispadmin -s ein. Die Werte in Datei müssen in dem Format vorliegen, das von der Option -g ausgegeben wird. Diese Werte überschreiben die aktuellen Werte im Kernel. Geben Sie Folgendes ein:
$ dispadmin -c FSS -s file |
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.
Informationen zu Verfahren, bei denen der rcapd eingesetzt wird, finden Sie in Kapitel 11Verwalten des Resource Capping Daemons (Vorgehen).
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.
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.
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.
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:
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 |
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.
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.
Vorgang |
Standardintervall in Sekunden |
Beschreibung |
---|---|---|
scan |
15 |
Anzahl der Sekunden zwischen Suchläufen nach Prozessen, die zur Arbeitslast eines Projekts hinzugekommen sind oder diese verlassen haben. Der Mindestwert beträgt 1 Sekunden. |
sample |
5 |
Anzahl der Sekunden zwischen Messungen der Resident Set-Größe und anschließenden Memory Cap-Durchsetzungen. Der Mindestwert beträgt 1 Sekunden. |
report |
5 |
Anzahl der Sekunden zwischen Aktualisierungen der Paging-Statistiken. Bei einem Wert von 0 werden die Statistiken nicht aktualisiert und die Ausgabe von rcapstat ist nicht auf dem aktuellen Stand. |
config |
60 |
Anzahl der Sekunden zwischen Neukonfigurationen. Bei einer Neukonfiguration prüft rcapadm die Konfigurationsdatei auf Aktualisierungen und sucht in der project-Datenbank nach neuen oder geänderten Memory Caps für das Projekt. Durch das Senden von SIGHUP an rcapd wird eine Neukonfiguration unmittelbar ausgeführt. |
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.
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.
Legt das Messintervall in Sekunden fest. Das Standardintervall ist 5 Sekunden.
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.
rcapstat-Spaltenüberschriften |
Beschreibung |
---|---|
id |
Die Projekt-ID des Projekts, für die eine Memory Cap eingerichtet wurde. |
project |
Der Projektname. |
nproc |
Die Anzahl der Prozesse im Projekt. |
vm |
Die Gesamtgröße des virtuellen Speichers der von den Projektprozessen verwendet wird, einschließlich aller zugeordneten Dateien und Geräte, in Kilobyte (K), Megabyte (M) oder Gigabyte (G). |
rss |
Die geschätzte Größe der gesamten Resident Set Size (RSS) der Projektprozesse, in Kilobyte (K), Megabyte (M) oder Gigabyte (G), ohne Berücksichtigung von gemeinsam genutzten Pages. |
cap |
Die für das Projekt definierte RSS Memory Cap. Weitere Informationen zum Festlegen von Memory Caps finden Sie unter Attribute zur Begrenzung der Nutzung des reellen Speichers für Projekte oder in der Manpage rcapd(1M). |
at |
Die Gesamtmenge an Speicher, den rcapd nach der letzten rcapstat-Messung auszulagern versuchte. |
avgat |
Die Gesamtmenge an Speicher, den rcapd während des letzten Messzyklus nach der letzten rcapstat-Messung auszulagern versuchte. Die Häufigkeit, mit der rcapd RSS-Daten sammelt, kann über rcapadm eingestellt werden. Lesen Sie dazu rcapd-Vorgangsintervalle. |
pg |
Die Gesamtmenge an Speicher, den rcapd seit der letzten rcapstat-Messung erfolgreich ausgelagert hat. |
avgpg |
Eine Schätzung der Gesamtmenge an Speicher, den rcapd während des letzten Messzyklus nach der letzten rcapstat-Messung erfolgreich ausgelagert hat. Die Häufigkeit, mit der rcapd RSS-Größen verarbeitet, kann über rcapadm eingestellt werden. Lesen Sie dazu rcapd-Vorgangsintervalle. |
Befehl |
Beschreibung |
---|---|
Überwacht die Ressourcenauslastung durch Projekte, für die eine Memory Cap eingerichtet wurde. |
|
Konfiguriert den Resource Capping Daemon, zeigt den aktuellen Status des Resource Capping Daemons an, sofern dieser konfiguriert wurde, und aktiviert oder deaktiviert das Resource Capping. |
|
Der Resource Capping Daemon. |
In diesem Kapitel werden die Verfahren zum Konfigurieren und Verwenden des Resource Capping Daemons rcapd beschrieben.
Eine Einführung in den rcapd finden Sie in Kapitel 10Einführung in die Steuerung des reellen Arbeitsspeichers mithilfe des Resource Capping Daemons.
Aufgabe |
Beschreibung |
Siehe |
---|---|---|
Einrichten eines Schwellenwerts für die Memory Cap-Durchsetzung. |
Konfigurieren einer Memory Cap, die durchgesetzt wird, wenn der für Prozesse verfügbare reelle Speicher zu gering wird. |
So richten Sie einen Schwellenwert für die Memory Cap-Durchsetzung ein |
Einrichten des Vorgangsintervalls. |
Das Ausführungsintervall für regelmäßige Vorgänge, die vom Resource Capping Daemon durchgeführt werden. | |
Aktivieren des Resource Cappings. |
Aktivieren des Resource Cappings auf dem System. | |
Deaktivieren des Resource Cappings. |
Deaktivieren des Resource Cappings auf dem System. | |
Erstellen von Berichten mit Cap- und Projektinformationen. |
Anzeigen von Beispielbefehlen für das Erstellen von Berichten. |
Erstellen von Berichten mit Memory Cap- und Projektinformationen |
Überwachen der Resident Set-Größe eines Projekts. |
Erstellen eines Berichts zur Resident Set-Größe eines Projekts. | |
Festlegen der Working Set-Größe eines Projekts. |
Erstellen eines Berichts zur Working Set-Größe eines Projekts. | |
Erstellen eines Berichts zur Speicherauslastung und Memory Caps. |
Drucken einer Zeile zur Speicherauslastung und Durchsetzung von Memory Caps für jedes Intervall am Ende des Berichts. |
In diesem Abschnitt werden die Verfahren zum Konfigurieren und Verwenden des Resource Capping Daemons mit dem Befehl rcapadm beschrieben. Weitere Informationen finden Sie in rcapd-Konfiguration und in der Manpage rcapadm(1M). Auch das Verwenden von rcapadm zum Festlegen einer temporären Resource Cap für eine Zone wird behandelt.
Erfolgt die Eingabe ohne Argumente, zeigt rcapadm den aktuellen Status des Resource Capping Daemons an, sofern dieser konfiguriert wurde.
Memory Caps können so konfiguriert werden, dass sie erst dann durchgesetzt werden, wenn der für Prozesse verfügbare reelle Speicher zu gering wird. Weitere Informationen finden Sie unter Schwellenwert für die Memory Cap-Durchsetzung.
Der Mindestwert (und die Standardeinstellung) ist 0; dies bedeutet, dass Memory Caps immer durchgesetzt werden. Zum Einrichten eines anderen Mindestwerts führen Sie das folgende Verfahren aus.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.
Geben Sie den Befehl rcapadm mit der Option -c ein, um einen anderen Wert für die Speicherauslastung einzurichten, ab dem eine Memory Cap durchgesetzt wird.
# rcapadm -c percent |
percent liegt im Bereich von 0 bis 100. Höhere Werte sind weniger einschränkend. Ein höherer Wert bedeutet, dass Projekt-Arbeitslasten mit Memory Caps ausgeführt werden können, ohne dass die Memory Caps durchgesetzt werden, bis die Systemspeicherauslastung diesen Schwellenwert überschreitet.
Wie die aktuelle Speicherauslastung und der Schwellenwert für die Memory Cap-Durchsetzung angezeigt werden, können Sie unter Erstellen von Berichten zur Speicherauslastung und dem Schwellenwert für die Durchsetzung der Memory Cap nachlesen.
rcapd-Vorgangsintervalle enthält Informationen über die Intervalle, in denen die regelmäßig von rcapd durchgeführten Vorgänge ausgeführt werden. Zum Einstellen der Vorgangsintervalle mit rcapadm führen Sie die folgenden Schritte aus.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.
Verwenden Sie die Option -i, um das Intervall einzurichten.
# rcapadm -i interval=value,...,interval=value |
Alle Intervallwerte werden in Sekunden angegeben.
Es gibt drei Möglichkeiten, das Resource Capping auf einem System zu aktivieren. Das Aktivieren des Resource Capping stellt auch die Standardwerte in der Datei /etc/rcap.conf ein.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.
Aktivieren Sie den Resource Capping Daemon mit einer der folgenden Methoden:
Aktivieren Sie das Resource Capping mit dem Befehl svcadm.
# svcadm enable rcap |
Um den Resource Capping Daemon so zu aktivieren, dass er unmittelbar und bei jedem Neustart des Systems gestartet wird, geben Sie Folgendes ein:
# rcapadm -E |
Um den Resource Capping Daemon bei einem Neustart zu starten, ohne dass er unmittelbar gestartet wird, geben Sie die Option -n an:
# rcapadm -n -E |
Es gibt drei Möglichkeiten, das Resource Capping auf einem System zu deaktivieren.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.
Deaktivieren Sie den Resource Capping Daemon auf eine der folgenden Arten:
Deaktivieren Sie das Resource Capping mit dem Befehl svcadm.
# svcadm disable rcap |
Um den Resource Capping Daemon so zu deaktivieren, dass er unmittelbar deaktiviert und bei einem Neustart des Systems nicht gestartet wird, geben Sie Folgendes ein:
# rcapadm -D |
Um den Resource Capping Daemon zu deaktivieren, ohne ihn unmittelbar zu stoppen, geben Sie die Option -n an:
# rcapadm -n -D |
Sicheres Deaktivieren des Resource Capping Daemons
Geben Sie den Befehl svcadm oder den Befehl rcapadm mit der Option -D ein, um den rcapd sicher zu deaktivieren. Wenn der Daemon beendet wird (siehe die Manpage kill(1)), könnten Prozesse mit dem Status „stopped“ zurückbleiben, die dann manuell neu gestartet werden müssen. Um einen Prozess weiter auszuführen, verwenden Sie den Befehl prun. Weitere Informationen finden Sie in der Manpage prun(1).
Mit dieser Vorgehensweise wird der Speicher begrenzt, der von einer angegebenen Zone maximal beansprucht werden kann. Dieser Wert gilt nur bis zum nächsten Neustart. Um eine dauerhafte Begrenzung festzulegen, verwenden Sie den Befehl zonecfg.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil.
Legen Sie eine Speichergrenze von 512 MB für die Zone my-zone fest.
# rcapadm -z testzone -m 512M |
Mit dem Befehl rcapstat erstellen Sie Berichte zu den Resource Capping-Statistiken. Überwachen der Ressourcenauslastung mit rcapstat beschreibt, wie Sie den Befehl rcapstat zum Erstellen von Berichten verwenden. Dieser Abschnitt enthält darüber hinaus Beschreibungen der Spaltenüberschriften in einem Bericht. Diese Informationen finden Sie auch in der Manpage rcapstat(1).
Die folgenden Unterabschnitte enthaltenen Beispiele, mit denen das Erstellen eines Berichts für einen bestimmten Zweck verdeutlicht wird.
In diesem Beispiel werden Memory Caps für zwei Projekte definiert, die zwei verschiedenen Benutzern zugeordnet sind. user1 hat eine Memory Cap von 50 MB, user2 eine Memory Cap von 10 MB.
Der folgende Befehl erzeugt fünf Berichte in einem Messintervall von 5 Sekunden.
user1machine% rcapstat 5 5 id project nproc vm rss cap at avgat pg avgpg 112270 user1 24 123M 35M 50M 50M 0K 3312K 0K 78194 user2 1 2368K 1856K 10M 0K 0K 0K 0K id project nproc vm rss cap at avgat pg avgpg 112270 user1 24 123M 35M 50M 0K 0K 0K 0K 78194 user2 1 2368K 1856K 10M 0K 0K 0K 0K id project nproc vm rss cap at avgat pg avgpg 112270 user1 24 123M 35M 50M 0K 0K 0K 0K 78194 user2 1 2368K 1928K 10M 0K 0K 0K 0K id project nproc vm rss cap at avgat pg avgpg 112270 user1 24 123M 35M 50M 0K 0K 0K 0K 78194 user2 1 2368K 1928K 10M 0K 0K 0K 0K id project nproc vm rss cap at avgat pg avgpg 112270 user1 24 123M 35M 50M 0K 0K 0K 0K 78194 user2 1 2368K 1928K 10M 0K 0K 0K 0K |
Die ersten drei Zeilen dieser Ausgabe bilden den ersten Bericht, der Memory Cap- und Projekt-Informationen für die zwei Projekte sowie Paging-Statistiken ab dem Start von rcapd enthält. Die Spalten at und pg enthalten Werte größer Null für user1 und Null für user2. Dies deutet darauf hin, dass user1 seinen Grenzwert für einen bestimmten Zeitraum im Verlauf des Daemons überschritten hat, user2 jedoch nicht.
Die nachfolgenden Berichte zeigen keine wichtige Aktivität.
Das folgende Beispiel zeigt das Projekt user1, in dem eine RSS über der zugehörigen RSS-Memory Cap vorliegt.
Der folgende Befehl erzeugt fünf Berichte in einem Messintervall von 5 Sekunden.
user1machine% rcapstat 5 5 |
id project nproc vm rss cap at avgat pg avgpg 376565 user1 3 6249M 6144M 6144M 690M 220M 5528K 2764K 376565 user1 3 6249M 6144M 6144M 0M 131M 4912K 1637K 376565 user1 3 6249M 6171M 6144M 27M 147M 6048K 2016K 376565 user1 3 6249M 6146M 6144M 4872M 174M 4368K 1456K 376565 user1 3 6249M 6156M 6144M 12M 161M 3376K 1125K |
Das Projekt user1 hat drei Prozesse, die aktiv reellen Speicher nutzen. Die positiven Werte in der Spalte pg weisen daraufhin, dass der rcapd ständig Speicher auslagert, während er versucht, die Memory Cap einzuhalten, indem die Speicherauslastung durch Projektprozesse gesenkt wird. rcapd ist jedoch nicht in der Lage, die RSS unter dem Memory Cap-Wert zu halten. Dies wird durch die wechselnden rss-Werte verdeutlicht, die keine entsprechende Reduzierung zeigen. Sobald Speicher ausgelagert wird, nutzt die Arbeitslast den Speicher neu und der RSS-Wert steigt wieder an. Dies bedeutet, dass der gesamte residente Speicher des Projekts aktiv genutzt wird und die Working Set-Größe (WSS) größer als die Memory Cap ist. Aus diesem Grund ist der rcapd gezwungen, einen Teil des Working Sets auszulagern, um die Memory Cap einzuhalten. In diesem Zustand treten weiterhin zahlreiche Page-Faults und somit erhöhtes E/A auf, bis eines der Folgenden eintritt:
Die WSS wird kleiner.
Die Memory Cap wird angehoben.
Die Anwendung ändert das Speicherzugriffsmuster.
In dieser Situation könnte ein kürzeres Messintervall die Diskrepanz zwischen dem RSS- und dem Cap-Wert reduzieren, da der rcapd gezwungen wäre, die Arbeitslast häufiger zu messen und Memory Caps häufiger durchzusetzen.
Ein Page-Fault tritt immer dann auf, wenn entweder eine neue Page erstellt oder von einem Swap-Gerät eingelesen werden muss.
Das folgende Beispiel schließt an das vorherige Beispiel an und verwendet das gleiche Projekt.
Das vorherige Beispiel zeigt, dass das Projekt user1 mehr reellen Speicher nutzt als seine Memory Cap gestattet. Dieses Beispiel zeigt, wie viel Speicher die Projekt-Arbeitslast benötigt.
user1machine% rcapstat 5 5 id project nproc vm rss cap at avgat pg avgpg 376565 user1 3 6249M 6144M 6144M 690M 0K 689M 0K 376565 user1 3 6249M 6144M 6144M 0K 0K 0K 0K 376565 user1 3 6249M 6171M 6144M 27M 0K 27M 0K 376565 user1 3 6249M 6146M 6144M 4872K 0K 4816K 0K 376565 user1 3 6249M 6156M 6144M 12M 0K 12M 0K 376565 user1 3 6249M 6150M 6144M 5848K 0K 5816K 0K 376565 user1 3 6249M 6155M 6144M 11M 0K 11M 0K 376565 user1 3 6249M 6150M 10G 32K 0K 32K 0K 376565 user1 3 6249M 6214M 10G 0K 0K 0K 0K 376565 user1 3 6249M 6247M 10G 0K 0K 0K 0K 376565 user1 3 6249M 6247M 10G 0K 0K 0K 0K 376565 user1 3 6249M 6247M 10G 0K 0K 0K 0K 376565 user1 3 6249M 6247M 10G 0K 0K 0K 0K 376565 user1 3 6249M 6247M 10G 0K 0K 0K 0K 376565 user1 3 6249M 6247M 10G 0K 0K 0K 0K |
Inmitten des Zyklus wurde die Memory Cap des Projekts user1 von 6 GB auf 10 GB erhöht. Dieser Anstieg stoppt die Durchsetzung der Memory Cap und gestattet ein Anwachsen der Resident Set-Größe, begrenzt nur durch andere Prozesse und der Größe des reellen Speichers in dem Computer. Die Spalte rss könnte sich stabilisieren, um die Working Set-Größe (WSS) des Projekts widerzuspiegeln, in diesem Beispiel 6247M. Dies ist der geringste Memory Cap-Wert, der eine Ausführung der Projektprozesse ohne ständig auftretende Page-Faults gestattet.
Während die Memory Cap für user1 bei 6 s liegt, sinkt die RSS bei einem 5-Sekunden-Messintervall. E/A steigt an, während der rcapd Speicher der Arbeitslast auslagert. Kurz nach Abschluss des Auslagerns werden die Pages von der Arbeitslast, die diese Pages benötigt, wieder eingelesen. Dieser Zyklus wiederholt sich, bis die Memory Cap auf 10 GB angestiegen ist, etwa in der Mitte des Beispiels. Dann stabilisiert sich die RSS bei 6,1 GB. Da die RSS jetzt unter der Memory Cap liegt, tritt kein weiteres Paging mehr auf. Die aufgrund des Pagings auftretenden E/A-Vorgänge stoppen ebenfalls. Somit benötigt das Projekt 6,1 GB zur Ausführung der im Überwachungszeitraum angefallenen Arbeiten.
Lesen Sie hierzu auch die Manpages vmstat(1M) und iostat(1M).
Mit der Option -g für den Befehl rcapstat erstellen Sie Berichte zu Folgendem:
Die aktuelle Speicherauslastung als Prozentwert des im System installierten reellen Speichers
Der mit rcapadm eingerichtete Schwellenwert für die Durchsetzung einer Memory Cap
Mit der Option -g wird am Ende des Berichts für jedes Intervall eine Zeile zur Speicherauslastung und Memory Cap-Durchsetzung gedruckt.
# rcapstat -g id project nproc vm rss cap at avgat pg avgpg 376565 rcap 0 0K 0K 10G 0K 0K 0K 0K physical memory utilization: 55% cap enforcement threshold: 0% id project nproc vm rss cap at avgat pg avgpg 376565 rcap 0 0K 0K 10G 0K 0K 0K 0K physical memory utilization: 55% cap enforcement threshold: 0% |
In diesem Kapitel werden die folgenden Themen behandelt:
Resource Pools, die zur Partitionierung von Computerressourcen verwendet werden
Dynamic Resource Pools (DRPs), mit denen die Ressourcenzuweisung von Resource Pools dynamisch eingestellt wird, um vorgegebene Systemziele zu erreichen
Ab Solaris-Release 10 11/06 sind Resource Pools und Dynamic Resource Pools Services der Solaris Service Management-Funktion (SMF). Jeder dieser Services wird separat aktiviert.
In diesem Kapitel werden folgende Themen behandelt:
Verfahren zur Nutzung dieser Funktionen finden Sie in Kapitel 13Erstellen und Verwalten von Resource Pools (Vorgehen).
Solaris 10: Resource Pools umfassen jetzt einen Mechanismus zum Einstellen der Ressourcenzuweisungen jedes Pools als Reaktion auf Systemereignisse und Änderungen bei den Arbeitslasten der Anwendungen. Dynamic Resource Pools vereinfachen und reduzieren die Anzahl der Entscheidungen, die ein Administrator treffen muss. Einstellungen werden automatisch vorgenommen, um die von einem Administrator festgelegten Leistungsziele des Systems einzuhalten.
Sie können jetzt den Befehl projmod verwenden, um das Attribut project.pool in der Datei /etc/project einzurichten.
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.
Solaris 10 11/06: Resource Pools und Dynamic Resource Pools sind jetzt SMF-Services.
Resource Pools ermöglichen Ihnen, bestimmte Arbeitslasten voneinander zu trennen, so dass sich der Arbeitslast-Verbrauch bestimmter Ressourcen nicht überschneidet. Diese Ressourcenreservierung hilft dabei, eine vorhersagbare Performance bei Systemen mit gemischten Arbeitslasten zu erreichen.
Resource Pools bieten einen persistenten Mechanismus für die Konfiguration eines Prozessorsets (pset) und optional für die Zuweisung einer Scheduling-Klasse.
Sie können sich einen Pool als eine besondere Art der Bindung von verschiedenen Ressourcensets vorstellen, die auf einem System zur Verfügung stehen. Sie können Pools erstellen, die verschiedene Arten von möglichen Ressourcenkombinationen darstellen:
pool1: pset_default |
pool2: pset1 |
pool3: pset1, pool.scheduler="FSS" |
Durch Gruppieren mehrerer Partitionen bieten Pools einen Handle, der bestimmten benannten Arbeitslasten zugewiesen werden kann. Jedem Projekteintrag in der Datei /etc/project kann ein bestimmter Pool zugewiesen sein. Dies wird mit dem Attribut project.pool angegeben.
Wenn Pools aktiviert sind, bilden ein Standard-Resource Pool und ein Standard-Prozessorset die Basiskonfiguration. Weitere benutzerdefinierte Pools und Prozessorsets können erstellt und der Konfiguration hinzugefügt werden. Eine CPU kann nur einem Prozessorset angehören. Benutzerdefinierte Pools und Prozessorsets können permanent gelöscht werden. Der Standard-Resource Pool und das Standard-Prozessorset können nicht permanent gelöscht werden.
Beim Standard-Resource Pool ist die Eigenschaft pool.default auf true gesetzt. Beim Standard-Prozessorset ist die Eigenschaft pset.default auf true gesetzt. Somit können der Standard-Resource Pool und das Standard-Prozessorset auch dann identifiziert werden, wenn ihre Namen geändert wurden.
Der Mechanismus der benutzerdefinierten Pools dient primär für große Computer mit mehr als vier CPUs. Jedoch können auch kleine Computer von dieser Funktion profitieren. Auf kleinen Computern können Sie Pools erstellen, die nicht-kritische Ressourcenpartitionen gemeinsam nutzen. Die Pools sind nur basierend auf kritischen Ressourcen getrennt.
Dynamic Resource Pools bieten einen Mechanismus zum Einstellen der Ressourcenzuweisungen jedes Pools als Reaktion auf Systemereignisse und Änderungen bei den Arbeitslasten der Anwendungen. DRPs vereinfachen und reduzieren die Anzahl der Entscheidungen, die ein Administrator treffen muss. Einstellungen werden automatisch vorgenommen, um die von einem Administrator festgelegten Leistungsziele des Systems einzuhalten. Änderungen an der Konfiguration werden protokolliert. Diese Funktionen werden primär über den Ressourcen-Controller poold ausgeführt, einem Systemdaemon, der immer dann aktiv sein sollte, wenn eine dynamische Ressourcenzuweisung erforderlich ist. poold ermittelt in regelmäßigen Abständen die Systemlast und stellt fest, ob eine Intervention erforderlich ist, damit das System die optimale Leistung hinsichtlich des Ressourcenverbrauchs beibehalten kann. Die poold-Konfiguration befindet sich in der libpool-Konfiguration. Weitere Informationen zu poold finden Sie in der Manpage poold(1M).
Wie Sie Resource Pools und Dynamic Resource Pools aktivieren bzw. deaktivieren, können Sie unter Aktivieren und Deaktivieren von Pools nachlesen.
Solaris 10 8/07: Alternativ zum Zuweisen einer Zone zu einem konfigurierten Resource Pool auf dem System können Sie den Befehl zonecfg eingeben, um einen temporären Pool zu erstellen, der nur über die Ausführung der Zone wirksam ist. Weitere Informationen finden Sie unter Solaris 10 8/07: dedicated-cpu-Ressource.
Auf einem System mit aktivierten Zonen kann eine nicht-globale Zone einem Resource Pool verbunden werden, obwohl der Pool nicht unbedingt exklusiv einer bestimmten Zone zugewiesen sein muss. Darüber hinaus können Sie einzelne Prozesse in nicht-globalen Zonen nicht mit dem Befehl poolbind aus der globalen Zone heraus an einen anderen Pool binden. Wie Sie eine nicht-globale Zone mit einem Pool verbinden, lesen Sie unter Konfigurieren, Prüfen und Übernehmen einer Zone.
Wenn Sie eine Scheduling-Klasse für einen Pool einrichten und dann eine nicht-globale Zone mit diesem Pool verbinden, verwendet die Zone standardmäßig diese Scheduling-Klasse.
Wenn Sie Dynamic Resource Pools verwenden, ist der Geltungsbereich einer ausführenden Instanz von poold auf die globale Zone beschränkt.
Das in einer nicht-globalen Zone ausgeführte Dienstprogramm poolstat zeigt nur Informationen zu dem Pool an, der mit der Zone verbunden ist. Wenn der Befehl pooladm ohne Argumente in einer nicht-globalen Zone ausgeführt wird, werden nur Informationen zu dem Pool angezeigt, der mit der Zone verbunden ist.
Weitere Informationen zu den Resource Pool-Befehlen finden Sie unter Mit Resource Pools verwendete Befehle.
Resource Pools stellen einen vielseitigen Mechanismus dar, der für viele verschiedene administrative Szenarios verwendet werden kann.
Nutzen Sie die Funktionen von Pools, um einen Server in zwei Pools aufzuteilen. Ein Pool dient für Anmeldesitzungen und interaktives Arbeiten durch das Timesharing von Benutzern. Der andere Pool dient für Jobs, die über das Stapelsystem übermittelt werden.
Partitionieren Sie die Ressourcen für interaktive Anwendungen gemäß den Anforderungen der Anwendungen.
Bestimmen Sie die Erwartungshaltung von Benutzern.
Sie können zunächst einen Computer bereitstellen, der nur einen Teil der Services ausführt, die dieser Computer letztlich bereitstellen soll. Wenn die auf Reservierungen basierenden Mechanismen der Ressourcenverwaltung beim online schalten des Computers nicht hergestellt sind, könnten sich Probleme bei den Benutzern einstellen.
Beispielsweise optimiert der Fair Share Scheduler die CPU-Auslastung. Die Reaktionszeiten eines Computers, der nur eine Anwendung ausführt, können fälschlich als sehr schnell interpretiert werden. Benutzer erfahren diese Reaktionszeiten nicht mehr, wenn mehrere Anwendungen geladen werden. Mit separaten Pools für jede Anwendung können Sie einen Grenzwert für die Anzahl der CPUs einrichten, die einer Anwendung zur Verfügung stehen, bevor Sie alle Anwendungen bereitstellen.
Partitionieren Sie einen Server, der große Benutzerzahlen unterstützt. Die Serverpartitionierung bietet einen Isolationsmechanismus, der zu einer besser vorhersehbaren Reaktionszeit für den einzelnen Benutzer führt.
Durch das Aufteilen von Benutzern in Gruppen, die an separate Pools gebunden sind, und das Verwenden des Fair Share Schedulers (FSS) können Sie CPU-Zuweisungen so anpassen, dass sie bestimmte Benutzergruppen mit einer höheren Priorität bevorzugen. Diese Zuweisung kann auf der Benutzerrolle, auf dem Accounting Chargeback oder anderen basieren.
Mit Resource Pools können Sie Anpassungen für einen sich ändernden Bedarf vornehmen.
Vielleicht treten am Standort vorhersagbare Änderungen des Arbeitslastbedarfs über längere Zeiten ein, z. B. monatlich, vierteljährlich oder jährlich. In diesem Fall können Sie durch Aufrufen von pooladm von einem cron-Job aus zwischen mehreren Pool-Konfigurationen wechseln. (Lesen Sie dazu Resource Pools-Framework.)
Erstellen Sie mithilfe des RT-Scheduler und zugewiesenen Prozessorressourcen einen Echtzeit-Pool.
Setzen Sie von Ihnen eingerichteten Systemziele durch.
Mit dem automatisierten Pools-Daemon können Sie die verfügbaren Ressourcen identifizieren und Arbeitslasten überwachen, um festzustellen, wenn die von Ihnen angegebenen Ziele nicht mehr eingehalten werden. Der Daemon führt, sofern möglich, korrigierende Maßnahmen durch. Andernfalls kann der Zustand protokolliert werden.
Die Konfigurationsdatei /etc/pooladm.conf enthält die Beschreibung der Static Pool-Konfiguration. Eine statische Konfiguration stellt dar, wie ein Administrator ein System unter Berücksichtigung der Resource Pools konfigurieren möchte. Es kann ein alternativer Dateiname verwendet werden.
Wenn die Service Management Facility (SMF) oder der Befehl pooladm - e zum Aktivieren des Resource Pools-Framework verwendet wird und die Datei /etc/pooladm.conf vorhanden ist, wird die in dieser Datei enthaltene Konfiguration für das System angewendet.
Der Kernel enthält Informationen zur Disposition von Ressourcen innerhalb des Resource Pools-Framework. Dies wird als dynamische Konfiguration bezeichnet. Sie repräsentiert die Resource Pools für ein bestimmtes System zu einem bestimmten Zeitpunkt. Die dynamische Konfiguration kann mit dem Befehl pooladm angezeigt werden. Beachten Sie, dass die Reihenfolge, in der die Eigenschaften für Pools und Ressourcensets angezeigt werden, variieren kann. Änderungen an der dynamischen Konfiguration können wie folgt vorgenommen werden:
Indirekt, durch Anwenden einer statischen Konfigurationsdatei
Direkt mit dem Befehl poolcfg und der Option -d
Es können mehrere Konfigurationsdateien für statische Pools vorhanden sein, die zu unterschiedlichen Zeiten aktiviert werden. Mit dem Befehl pooladm von einem cron-Job aus können Sie zwischen den verschiedenen Pool-Konfigurationen wechseln. Weitere Informationen zum Dienstprogramm cron finden Sie in der Manpage cron(1M).
In der Standardeinstellung ist das Resource Pools-Framework nicht aktiviert. Zum Erstellen oder Ändern einer dynamischen Konfiguration müssen Resource Pools aktiviert sein. Statische Konfigurationsdateien können auch dann mit dem Befehl poolcfg oder libpool bearbeitet werden, wenn das Resource Pools-Framework deaktiviert ist. Wenn keine Pools aktiv ist, können auch keine statischen Konfigurationsdateien erstellt werden. Weitere Informationen zur Konfigurationsdatei finden Sie unter Erstellen von Pool-Konfigurationen.
Die Befehle, die mit Resource Pools und dem Systemdaemon poold verwendet werden können, sind in den folgenden Manpages beschrieben:
Alle Resource Pool-Konfigurationen, einschließlich der dynamischen Konfiguration, können die folgenden Elemente enthalten.
Eigenschaften, die sich auf das Gesamtverhalten des Systems auswirken
Eine Resource Pool-Definition
Eine Prozessorset-Definition
Eine Prozessor-Definition
Alle diese Elemente besitzen Eigenschaften, die geändert werden können, um Status und Verhalten des Resource Pools-Frameworks zu manipulieren. Beispielsweise gibt die Pool-Eigenschaft pool.importance die relative Wichtigkeit eines bestimmten Pools an. Diese Eigenschaft wird zur Auflösung eines möglichen Konflikts um Ressourcen verwendet. Weitere Informationen finden Sie unter libpool(3LIB).
Die Funktion Pools unterstützt benannte, typisierte Eigenschaften, die für einen Pool, eine Ressource oder eine Komponente eingerichtet werden können. Administratoren können für verschiedene Pool-Elemente zusätzliche Eigenschaften speichern. Dabei wird der Namespace einer Eigenschaft ähnlich einem Projektattribut verwendet.
Beispielsweise kennzeichnet der folgende Kommentar, dass ein bestimmtes pset einer bestimmten Datatree-Datenbank zugewiesen wurde.
Datatree,pset.dbname=warehouse
Weitere Informationen zu Eigenschaftentypen finden Sie unter poold-Eigenschaften.
Eine Reihe von speziellen Eigenschaften ist für die interne Verwendung reserviert und kann nicht geändert oder entfernt werden. Weitere Informationen finden Sie in der Manpage libpool(3LIB).
Benutzerdefinierte Pools können mithilfe einer der folgenden Methoden auf einem System implementiert werden.
Beim Booten der Solaris-Software prüft das Skript init, ob die Datei /etc/pooladm.conf vorhanden ist. Wenn diese Datei gefunden wurde und Pools aktiviert sind, wird pooladm aufgerufen, um diese Konfigurationsdatei als aktive Pool-Konfiguration zu übernehmen. Das System erstellt eine dynamische Konfiguration, um die in der Datei /etc/pooladm.conf angeforderte Organisation widerzuspiegeln und partitioniert die Computerressourcen entsprechend.
Wenn das Solaris-System ausgeführt wird, kann eine Pool-Konfiguration entweder aktiviert werden (falls sie noch nicht vorhanden ist) oder mit dem Befehl pooladm geändert werden. In der Standardeinstellung wirkt sich der Befehl pooladm auf die Datei /etc/pooladm.conf aus. Sie können jedoch einen alternativen Speicherort und Dateinamen angeben, um eine andere Datei zum Aktualisieren der Pool-Konfiguration zu verwenden.
Weitere Informationen zum Aktivieren und Deaktivieren von Resource Pools finden Sie unter Aktivieren und Deaktivieren von Pools. Pools können nicht deaktiviert werden, wenn benutzerdefinierte Pools oder Ressourcen verwendet werden.
Zum Konfigurieren von Resource Pools müssen Sie als Superuser angemeldet sein oder über das Process Management-Profil verfügen. Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil.
Der Ressource-Controller poold wird mit den Dynamic Resource Pools gestartet.
Das Attribut project.pool kann einem Projekteintrag in der Datei /etc/project hinzugefügt werden, um diesem Eintrag einem bestimmten Pool zuzuweisen. Neue Arbeiten, die im Rahmen eines Projekts gestartet werden, sind dann an diesen Pool gebunden. Weitere Informationen finden Sie in Kapitel 2Einführung in Projekte und Aufgaben.
Beispielsweise können Sie den Befehl projmod eingeben, um das Attribut project.pool für das Projekt sales in der Datei /etc/project einzurichten:
# projmod -a -K project.pool=mypool sales |
Mit der Dynamic Reconfiguration (DR) können Sie Hardware bei laufendem System neu konfigurieren. Ein DR-Vorgang kann einen bestimmten Ressourcentyp vergrößern, verkleinern oder keine Auswirkungen zeigen. Da die DR verfügbaren Ressourcenmengen beeinflussen kann, müssen die Pools in diese Vorgänge mit einbezogen werden. Wenn ein DR-Vorgang initiiert wird, wird die Konfiguration vom Pools-Framework validiert.
Wenn der DR-Vorgang fortgesetzt werden kann, ohne dass die aktuelle Pool-Konfiguration ungültig wird, wird die private Konfigurationsdatei aktualisiert. Eine ungültige Konfiguration kann von den verfügbaren Ressourcen nicht unterstützt werden.
Wird die Pool-Konfiguration durch den DR-Vorgang ungültig, schlägt der Vorgang fehl und Sie werden über eine Nachricht an das Nachrichtenprotokoll informiert. Wenn Sie den Abschluss der Konfiguration erzwingen möchten, müssen Sie die DR-Durchsetzungsoption verwenden. Die Pool-Konfiguration wird dann so modifiziert, dass sie der neuen Ressourcenkonfiguration entspricht. Weitere Informationen zum DR-Prozess und der Durchsetzungsoption finden Sie im Benutzerhandbuch zur Dynamic Reconfiguration der Sun-Hardware.
Wenn Sie Dynamic Resource Pools verwenden, kann eine Partition die Resource Control poold bei aktivem Daemon verlassen. Weitere Informationen finden Sie unter Identifizieren eines Ressourcenmangels.
Die Konfigurationsdatei enthält eine Beschreibung der auf dem System zu erstellenden Pools. Die Datei beschreibt die Elemente, die manipuliert werden können.
system
pool
pset
cpu
Weitere Informationen zu den manipulierbaren Elementen finden Sie in der Manpage poolcfg(1M).
Wenn Pools aktiviert sind, können Sie auf zwei Arten eine strukturierte /etc/pooladm.conf-Datei erstellen.
Geben Sie den Befehl pooladm mit der Option -s ein, um die Ressourcen auf den aktuellen Systemen zu erfassen und die Ergebnisse in eine Konfigurationsdatei zu schreiben.
Dies ist die bevorzugte Methode. Hierbei werden alle aktiven Ressourcen und Komponenten auf dem System aufgezeichnet, die über die Pools-Funktionen manipuliert werden können. Zu diesen Ressourcen gehören auch bereits vorhandene Prozessorset-Konfigurationen. Anschließend können Sie die Konfiguration bearbeiten, um die Prozessorsets umzubenennen oder gegebenenfalls zusätzliche Pools zu erstellen.
Geben Sie den Befehl poolcfg mit der Option-c und die Unterbefehle discover oder create system name ein, um eine neue Pool-Konfiguration zu erstellen.
Diese Optionen wurden zur Abwärtskompatibilität mit früheren Versionen beibehalten.
Geben Sie den Befehl poolcfg oder libpool ein, um die Datei /etc/pooladm.conf zu bearbeiten. Bearbeiten Sie diese Dateien nicht direkt.
Sie können die CPU-Ressourcentypen in der dynamischen Konfiguration direkt bearbeiten, indem Sie den Befehl poolcfg mit der Option -d eingeben. Zur Übertragung von Ressourcen gibt es zwei Methoden.
Sie können eine allgemeine Anfrage erstellen, um alle verfügbaren identifizierten Ressourcen zwischen Sets zu übertragen.
Sie können Ressourcen mit bestimmten IDs an ein Ziel-Set übertragen. Beachten Sie, dass sich die System-IDs von Ressourcen ändern können, wenn die Ressourcenkonfiguration modifiziert oder ein System neu gebootet wird.
Ein Beispiel finden Sie unter Übertragen von Ressourcen.
Beachten Sie, dass die Übertragung einer Ressource eine Aktion vonpoold auslösen könnte. Weitere Informationen finden Sie unter poold – Übersicht.
Der Ressourcen-Controller für Pools, poold, verwendet die Systemziele und überwachbare Statistiken, um die von Ihnen angegebenen Ziele bei der Systemleistung einzuhalten. Dieser Systemdaemon muss stets aktiv sein, wenn eine dynamische Zuordnung von Ressourcen erforderlich ist.
Der Ressourcen-Controller poold identifiziert verfügbare Ressourcen und überwacht dann Arbeitslasten, um festzustellen, wenn die Systemauslastungsziele nicht mehr eingehalten werden. poold berücksichtigt in diesem Fall alternative Konfigurationen und leitet Korrekturmaßnahmen ein. Wenn möglich, werden die Ressourcen neu konfiguriert, so dass die Ziele eingehalten werden können. Ist dies nicht möglich, protokolliert der Daemon, dass die benutzerdefinierten Ziele nicht mehr eingehalten werden können. Nach einer Neukonfiguration setzt der Daemon die Überwachung der Arbeitslastziele fort.
poold verwaltet ein Protokoll über den Verlauf der Entscheidungen. Mithilfe dieses Verlaufsprotokolls werden mögliche Neukonfigurationen eliminiert, die in der Vergangenheit zu keinen Verbesserungen geführt haben.
Beachten Sie, dass eine Neukonfigurationen auch asynchron ausgelöst werden kann, wenn die Arbeitslastziele oder die auf dem System verfügbaren Ressourcen geändert wurden.
Der DRP-Service wird von der Service Management Facility (SMF) unter der Servicebezeichnung svc:/system/pools/dynamic verwaltet.
Administrative Maßnahmen an diesem Service, z. B. Aktivieren, Deaktivieren oder Anfordern eines Neustart können mithilfe des Befehlssvcadm vorgenommen werden. Der Status des Services kann mithilfe des Befehls svcs abgefragt werden. Weitere Informationen finden Sie in den Manpages svcs(1) und svcadm(1M).
Die SMF-Schnittstelle ist die bevorzugte Methode zur Steuerung der DRP, aus Gründen der Abwärtskompatibilität können aber auch die folgenden Methoden verwendet werden.
Wenn keine dynamische Ressourcenzuordnung erforderlich ist, kann poold mit dem Signal SIGQUIT oder SIGTERM gestoppt werden. Jedes dieser Signale führt zum ordnungsgemäßen Beenden von poold.
Obwohl poold Änderungen an den Ressourcen- oder Pool-Konfigurationen automatisch erfasst, können Sie mithilfe des Signals SIGHUP eine Neukonfiguration erzwingen.
Wenn Sie Änderungen an einer Konfiguration vornehmen, hält sich poold an Ihre Anweisungen. Sie geben diese Anweisungen als Einschränkungen und Ziele ein. poold ermittelt anhand Ihrer Angaben den relativen Wert verschiedener Konfigurationsmöglichkeiten in Relation zur vorhandenen Konfiguration. poold ändert dann die Ressourcenzuweisungen der aktuellen Konfiguration, und erstellt so neue Konfigurationen, die als Kandidaten zur Übernahme gelten.
Einschränkungen reduzieren die Anzahl möglicher Konfigurationen, indem sie einige potentielle Änderungen eliminieren, die an einer Konfiguration vorgenommen werden können. Die folgenden Einschränkungen stehen zur Verfügung. Sie werden in der libpool-Konfiguration angegeben.
Die maximalen und minimalen CPU-Zuweisungen
Fixierte Komponenten, die nicht aus einem Set verschoben werden können
Weitere Informationen zu den Pools-Eigenschaften finden Sie in der Manpage libpool(3LIB) und unter Eigenschaften von Pools.
Diese beiden Eigenschaften legen Grenzwerte (Maximum und Minimum) für die Anzahl der Prozessoren fest, die einem Prozessorset zugewiesen werden können. Weitere·Informationen zu diesen Eigenschaften finden Sie in Tabelle 12–1.
Im Rahmen dieser Einschränkungen können die Ressourcen einer Ressourcenpartition beliebigen anderen Ressourcenpartitionen in der gleichen Solaris-Instanz zugeordnet werden. Der Zugriff auf diese Ressourcen erfolgt durch das Binden an einen Pool, der dem Ressourcenset zugewiesen ist. Das Binden erfolgt entweder bei der Anmeldung oder manuell durch einen Administrator, der über die Berechtigung PRIV_SYS_RES_CONFIG verfügt.
Die Eigenschaft cpu-pinned kennzeichnet, dass eine bestimmte CPU nicht durch DRP aus dem aktuellen Prozessorset verschoben werden darf. Sie können diese libpool-Eigenschaft einrichten, um die Cache-Auslastung für eine bestimmte Anwendung zu maximieren, die innerhalb eines Prozessorsets ausgeführt wird.
Weitere Informationen zu dieser Eigenschaft finden Sie in Tabelle 12–1.
Die Eigenschaft pool.importance beschreibt die relative Wichtigkeit eines Pools gemäß der Definition durch den Administrator.
Ziele werden ähnlich wie Einschränkungen angegeben. Das vollständige Ziel-Set ist in Tabelle 12–1 dokumentiert.
Es gibt zwei Kategorien von Zielen.
Ein arbeitslastabhängiges Ziel ändert sich mit der Arbeitslast, die auf einem System ausgeführt wird. Ein Beispiel wäre das Ziel utilization. Der Wert für die Auslastung (utilization) eines Ressourcensets ändert sich je nach der im Set aktiven Arbeitslast.
Ein arbeitslastabhängiges Ziel ändert sich nicht mit der Arbeitslast, die auf einem System ausgeführt wird. Ein Beispiel wäre das CPU-Ziel locality. Die ausgewertete Messung der Lokalität (locality) eines Ressourcensets ändert sich nicht mit der Arbeitslast, die auf einem System ausgeführt wird.
Sie können drei Arten von Zielen definieren.
Name |
Gültige Elemente |
Operatoren |
Werte |
---|---|---|---|
wt-load |
system |
entf. |
entf. |
locality |
pset |
entf. |
loose | tight | none |
utilization |
pset |
< > ~ |
0–100% |
Ziele werden in den Eigenschaftenstrings der libpool-Konfiguration gespeichert. Die Eigenschaftennamen lauten wie folgt:
system.poold.objectives
pset.poold.objectives
Ziele haben die folgende Syntax:
objectives = objective [; objective]*
objective = [n:] keyword [op] [value]
Alle Ziele können ein optionales Präfix für die Wichtigkeit aufnehmen. Diese Wichtigkeit dient als ein Multiplikator für das Ziel und erhöht somit die Bedeutung des Beitrags zur Auswertung der Zielfunktion. Der Bereich erstreckt sich von 0 bis INT64_MAX (9223372036854775807). Wenn kein Wert angegeben ist, lautet der Standardwert für die Wichtigkeit 1.
Einige Elementtypen unterstützen mehrere Zieltypen. Ein Beispiel hierfür ist pset. Für diese Elemente können Sie mehrere Zieltypen angeben. Außerdem können Sie mehrere Auslastungsziele für ein einzelnespset-Element angeben.
Anwendungsbeispiele finden Sie unter So definieren Sie Konfigurationsziele.
Das Ziel wt-load begünstigt Konfigurationen, bei denen die Ressourcenzuordnungen mit den Ressourcenauslastungen übereinstimmen. Wenn dieses Ziel aktiv ist, erhält ein Ressourcenset, das mehr Ressourcen verwendet, mehr Ressourcen. wt-load bedeutet weighted load (gewichtete Last).
Verwenden Sie dieses Ziel, wenn Sie mit den Einschränkungen zufrieden sind, die Sie mithilfe der Minimum- und Maximum-Eigenschaften eingerichtet haben, und wenn der Daemon die Ressourcen innerhalb dieser Einschränkungen frei manipulieren soll.
Das Ziel locality wirkt sich auf den Einfluss aus, den die Lokalität (über die Daten der Locality Group (lgroup gemessen) auf die ausgewählte Konfiguration hat. Eine alternative Definition für Lokalität ist Latenz. Eine lgroup beschreibt CPU- und Speicherressourcen. Die lgroup wird vom Solaris-System verwendet, um den zeitlichen Abstand zwischen Ressourcen zu ermitteln. Weitere Informationen zur Locality Group-Abstraktion finden Sie unter Locality Groups Overview in Programming Interfaces Guide.
Dieses Ziel kann einen der folgenden drei Werte annehmen:
Bei dieser Einstellung werden Konfigurationen bevorzugt, bei denen die Resource Locality maximiert wird.
Bei dieser Einstellung werden Konfigurationen bevorzugt, bei denen die Resource Locality minimiert wird.
Bei dieser Einstellung hat die Resource Locality keinen Einfluss auf die bevorzugte Konfiguration. Dies ist der Standardwert für das Ziel locality.
Im Allgemeinen sollte das Ziel locality auf tight gesetzt sein. Um die Speicherbandbreite zu maximieren bzw. den Einfluss von DR-Vorgängen auf ein Ressourcenset zu minimieren, können Sie dieses Ziel auf loose setzen oder die Standardeinstellung von none beibehalten.
Das Ziel utilization begünstigt Konfigurationen, die den Partitionen Ressourcen zuordnen, die das angegebene Auslastungsziel nicht erreichen.
Dieses Ziel wird mithilfe von Operatoren und Werten angegeben. Folgende Operatoren stehen zur Verfügung:
Der „Kleiner-als“-Operator gekennzeichnet, dass der angegebene Wert den maximalen Zielwert darstellt.
Der „Größer-als“-Operator gekennzeichnet, dass der angegebene Wert den minimalen Zielwert darstellt.
Der „Circa“-Operator kennzeichnet, dass der angegebene Wert ein Zielwert ist, für den eine gewisse Schwankung akzeptabel ist.
Bei einem pset kann nur ein Auslastungsziel für jeden Operatortyp festgelegt werden.
Wenn der Operator ~ festgelegt ist, können die Operatoren < und > nicht verwendet werden.
Wenn die Operatoren < und > festgelegt sind, kann der Operator ~ nicht verwendet werden. Die Einstellungen des <-Operators und des >-Operators schließen sich gegenseitig nicht aus.
Sie können einen <- und einen >-Operator zusammen verwenden, um einen Bereich zu erstellen. Die Werte werden validiert, um sicherzustellen, dass sie einander nicht überschneiden.
In dem folgenden Beispiel wird poold zum Auswerten der folgenden Eigenschaften für das pset verwendet:
Die utilization muss zwischen 30 % und 80 % gehalten werden.
Die locality muss für jedes Prozessorset maximiert sein.
Die Ziele müssen die Standardwichtigkeit von 1 annehmen.
pset.poold.objectives "utilization > 30; utilization < 80; locality tight"
Weitere Nutzungsbeispiele finden Sie unter So definieren Sie Konfigurationsziele.
Es gibt vier Eigenschaftenkategorien:
Konfiguration
Einschränkung
Ziel
Zielparameter
Eigenschaft |
Typ |
Kategorie |
Beschreibung |
---|---|---|---|
system.poold.log-level |
string |
Konfiguration |
Protokollierungsebene |
system.poold.log-location |
string |
Konfiguration |
Speicherort des Protokolls |
system.poold.monitor-interval |
uint64 |
Konfiguration |
Messintervall bei der Überwachung |
system.poold.history-file |
string |
Konfiguration |
Speicherort des Entscheidungsverlaufs |
pset.max |
uint64 |
Einschränkung |
Maximale Anzahl der CPUs für dieses Prozessorset |
pset.min |
uint64 |
Einschränkung |
Minimale Anzahl der CPUs für dieses Prozessorset |
cpu.pinned |
boolesch |
Einschränkung |
An dieses Prozessorset fixierte CPUs |
system.poold.objectives |
string |
Ziel |
Formatierter String folgt der Syntax des poold-Zielausdrucks |
pset.poold.objectives |
string |
Ziel |
Formatierter String folgt der Syntax des poold-Ausdrucks |
pool.importance |
int64 |
Zielparameter |
Vom Benutzer zugewiesene Wichtigkeit |
Die folgenden Aspekte des Daemon-Verhaltens können konfiguriert werden.
Überwachungsintervall
Protokollierungsebene
Speicherort des Protokolls
Diese Optionen werden in der Pool-Konfiguration angegeben. Sie können die Protokollierungsebene auch mit dem Befehl poold von der Befehlszeile aus ändern.
Mit dem Eigenschaftennamen system.poold.monitor-interval geben Sie einen Wert in Millisekunden an.
Mit der Protokollierung werden drei Informationskategorien bereitgestellt. In den Protokollen werden die folgenden Kategorien aufgeführt:
Konfiguration
Überwachung
Optimierung
Mit dem Eigenschaftennamen system.poold.log-level geben Sie die Protokollierungsparameter an. Wenn diese Eigenschaft nicht angegeben ist, lautet die standardmäßige Protokollierungsebene NOTICE. Die Parameterebenen sind hierarchisch angeordnet. Bei der Protokollierungsebene DEBUG protokolliert poold alle definierten Meldungen. Die Ebene INFO stellt den meisten Administratoren alle wichtigen Informationen zur Verfügung.
Sie können den Befehl poold mit der Option -l an der Befehlszeile eingeben und einen Parameter hinzufügen, um die Ebene der erzeugten Protokollierungsinformationen festzulegen.
Die folgenden Parameter sind verfügbar:
ALERT
CRIT
ERR
WARNING
NOTICE
INFO
DEBUG
Die Parameterebenen entsprechend direkt ihren syslog-Äquivalenten. Weitere Informationen zur Verwendung von syslog finden Sie unter Speicherort des Protokolls.
Informationen zum Konfigurieren der poold--Protokollierung finden Sie unter So richten Sie die Protokollierungsebene für poold ein.
Die folgenden Meldungsarten können erzeugt werden:
Probleme beim Zugriff auf die libpool-Konfiguration oder ein anderer fundamentaler und unerwarteter Fehler bei der libpool-Funktion. Der Daemon wird beendet und es sind sofortige administrative Maßnahmen erforderlich.
Probleme aufgrund unerwarteter Fehler. Der Daemon wird beendet und es sind sofortige administrative Maßnahmen erforderlich.
Probleme mit benutzerdefinierten Parametern, die Vorgänge steuern, zum Beispiel nicht auflösbare, widersprüchliche Auslastungsziele für ein Ressourcenset. Erfordert administrative Maßnahmen zur Berichtigung der Ziele. poold versucht Korrekturmaßnahmen einzuleiten, indem widersprüchlichen Ziele ignoriert werden, aber bestimmte Fehler führen dazu, dass der Daemon beendet wird.
Warnungen hinsichtlich der Einstellungen von Konfigurationsparametern, die zwar technisch korrekt, für die vorgegebene Ausführungsumgebung jedoch ungeeignet sind. Ein Beispiel ist das Fixieren aller CPU-Ressourcen, so dass poold CPU-Ressourcen nicht zwischen Prozessorsets verschieben kann.
Es können Meldungen mit ausführlichen Informationen angezeigt werden, die zum Debuggen der Konfigurationsverarbeitung erforderlich sind. Diese Informationen werden von Administratoren nicht immer genutzt.
Die folgenden Meldungsarten können erzeugt werden:
Probleme aufgrund unerwarteter schwerwiegender Überwachungsfehler. Der Daemon wird beendet und es sind sofortige administrative Maßnahmen erforderlich.
Probleme aufgrund eines unerwarteten Überwachungsfehlers. Es sind eventuell Maßnahmen des Administrators erforderlich.
Meldungen über Wechsel der Resource Control-Region.
Meldungen zu den Ressourcen-Auslastungsstatistiken.
Es können Meldungen mit ausführlichen Informationen angezeigt werden, die beim Debuggen der Überwachungsverarbeitung erforderlich sind. Diese Informationen werden von Administratoren nicht immer genutzt.
Die folgenden Meldungsarten können erzeugt werden:
Es können Meldungen zu Problemen angezeigt werden, um optimale Entscheidungen zu treffen. Beispiele hierfür sind Ressourcensets, die durch vorgegebene Mindest- und Höchstwerte oder die Anzahl der fixierten Komponenten zu stark eingeschränkt sind.
Es können Meldungen bei Problemen angezeigt werden, wenn eine optimale Neuzuordnung aufgrund unvorhersehbarer Einschränkungen nicht durchgeführt werden kann. Beispiele hierfür sind das Entfernen des letzten Prozessors von einem Prozessorset, das einen gebundenen Ressourcenverbraucher enthält.
Es können Meldungen über nutzbare Konfigurationen oder Konfigurationen angezeigt werden, die durch das Überschreiben des Entscheidungsverlaufs nicht implementiert werden können.
Es können Meldungen über mögliche alternative Konfigurationen angezeigt werden.
Es können Meldungen mit ausführlichen Informationen angezeigt werden, die beim Debuggen der Optimierungsverarbeitung erforderlich sind. Diese Informationen werden von Administratoren nicht immer genutzt.
Mit der Eigenschaft system.poold.log-location können Sie den Speicherort der protokollierten Ausgabe von poold angeben. Sie können den Speicherort desSYSLOG für die poold-Ausgabe angeben (lesen Sie dazu syslog(3C)).
Wenn diese Eigenschaft nicht gesetzt ist, lautet der standardmäßige Speicherort der protokollierten Ausgabe von poold /var/log/pool/poold.
Erfolgt der Aufruf von poold von der Befehlszeile, wird diese Eigenschaft nicht verwendet. Protokolleinträge werden auf dem aufrufenden Terminal in stderr geschrieben.
Wenn poold aktiv ist, enthält die Datei logadm.conf einen Eintrag zur Verwaltung der Standarddatei /var/log/pool/poold. Dieser Eintrag lautet:
/var/log/pool/poold -N -s 512k
Weitere Informationen finden Sie in den Manpages logadm(1M) und logadm.conf(4).
In diesem Abschnitt werden der Prozess und die Faktoren beschrieben, die poold zum dynamischen Zuweisen von Ressourcen verwendet.
Verfügbaren Ressourcen sind alle Ressourcen, die innerhalb des Geltungsbereichs des poold-Prozesses zur Nutzung zur Verfügung stehen. Der Geltungsbereich einer Steuerung ist maximal eine einzelne Solaris-Instanz.
Auf einem System mit aktivierten Zonen ist der Geltungsbereich der ausgeführten poold-Instanz auf die globale Zone beschränkt.
Resource Pools umfassen alle Systemressourcen, die für den Verbrauch durch Anwendungen zur Verfügung stehen.
Bei einer ausgeführten Solaris-Instanz muss ein Ressourcentyp, z. B. eine CPU, einer einzelnen Partition zugeordnet sein. Es können eine oder mehrere Partitionen für jeden Ressourcentyp vorhanden sein. Jede Partition enthält ein einmaliges Ressourcenset.
Beispielsweise kann ein Computer mit vier CPUs und zwei Prozessorsets das folgende Setup haben:
pset 0: 0 1
pset 1: 2 3
dabei stellen 0, 1, 2 und 3 hinter dem Doppelpunkt die CPU-IDs dar. Beachten Sie, dass die zwei Prozessorsets alle vier CPUs aufnehmen.
Der gleiche Computer kann das folgende Setup nicht aufweisen:
pset 0: 0 1
pset 1: 1 2 3
Dieses Setup ist nicht möglich, da CPU 1 nur in einem pset erscheinen kann.
Ressourcen sind von anderen Partitionen als der, zu der sie gehören, nicht zugänglich.
Zum Erfassen der verfügbaren Ressourcen fragt poold die aktive Pool-Konfiguration ab, um Partitionen zu finden. Alle Ressourcen in allen Partitionen werden summiert, um die insgesamt zur Verfügung stehenden Ressourcen für jeden gesteuerten Ressourcentyp zu ermitteln.
Diese erfassten Ressourcen verwendet poold als Basiszahl für Berechnungen. Jedoch gelten bestimmte Einschränkungen für diese Zahl, die die Flexibilität von poold beim Erstellen der Zuweisungen beschränken. Informationen zu den verfügbaren Einschränkungen finden Sie unter Konfigurationseinschränkungen.
Der Steuerungsbereich von poold ist definiert als das verfügbare Ressourcenset, für das poold die primäre Verantwortung für effiziente Partitionierung und Verwaltung übernimmt. Es gibt jedoch noch weitere Mechanismen, die Ressourcen innerhalb dieses Steuerungsbereichs manipulieren können und sich so auf eine Konfiguration auswirken. Wenn eine Partition während poold aktiv ist, aus dem Steuerungsbereich entfernt wird, versucht poold die Steuerung durch eine vorsichtige Manipulation der verfügbaren Ressourcen wiederzustellen. Wenn poold keine zusätzlichen Ressourcen innerhalb des Geltungsbereichs lokalisieren kann, protokolliert der Daemon Informationen über den Ressourcenmangel.
poold wendet im Allgemeinen die meiste Zeit damit auf, die Ressourcenauslastung innerhalb des Steuerungsbereichs zu beobachten. Durch diese Überwachung wird sichergestellt, dass die arbeitslastabhängigen Ziele erreicht werden.
Beispielsweise werden bei Prozessorsets alle Messungen über alle Prozessoren in einem Set durchgeführt. Die Ressourcenauslastung zeigt den Anteil der Zeit, den die Ressource über das Messintervall genutzt wurde. Die Ressourcenauslastung wird als ein Prozentwert zwischen 0 und 100 angezeigt.
Die unter Konfigurationseinschränkungen und -ziele beschriebenen Direktiven dienen zum Erfassen einer bevorstehenden Situation, bei der das System die vorgegebenen Ziele nicht mehr erreicht. Diese Ziele stehen in einem direkten Zusammenhang mit der Arbeitslast.
Eine Partition, die benutzerdefinierte Ziele nicht erreicht, wird als eine Steuerungsverletzung bezeichnet. Es gibt zwei Arten von Steuerungsverletzungen: synchrone und asynchrone.
Eine synchrone Ziel-Verletzung wird vom Daemon während der Arbeitslastüberwachung festgestellt.
Eine asynchrone Ziel-Verletzung erfolgt unabhängig von der Überwachungsaktion des Daemons.
Die folgenden Ereignisse können asynchrone Ziel-Verletzungen auslösen:
Ressourcen, die einem Steuerungsbereich hinzugefügt oder daraus entfernt werden.
Der Steuerungsbereich wird neu konfiguriert.
Der Ressourcen-Controller poold wird neu gestartet.
Die Beiträge von Zielen, die in keiner Beziehung zur Arbeitslast stehen, werden zwischen einzelnen Auswertungen von Zielen als gleichbleibend konstant betrachtet. Ziele, die in keiner Beziehung zur Arbeitslast stehen, werden nur dann neu ausgewertet, wenn aufgrund einer asynchronen Verletzung eine neue Auswertung ausgelöst wird.
Stellt der Ressourcen-Controller fest, dass es einem Ressourcenverbraucher an Ressourcen mangelt, werden zunächst die Ressourcen erhöht, um die Leistung zu verbessern.
Alternative Konfigurationen, mit denen sich die in der Konfiguration für den Steuerungsbereich angegebenen Ziele erreichen lassen, werden geprüft und ausgewertet.
Dieser Prozess wird über die Zeit weiter angepasst, da die Ergebnisse der Ressourcenänderungen überwacht und jede Ressourcenpartition auf deren Reaktionsfähigkeit geprüft wird. Mithilfe des Entscheidungsverlaufs können Neukonfigurationen eliminiert werden, die in der Vergangenheit zu keinen Verbesserungen geführt haben. Andere Informationen, z. B. Prozessnamen und Mengen, werden zur weiteren Auswertung der Verlaufsdaten herangezogen.
Wenn der Daemon keine Korrekturmaßnahmen ausführen kann, wird der Zustand protokolliert. Weitere Informationen finden Sie unter poold-Protokollierungsinformationen.
Mit dem Dienstprogramm poolstat wird die Ressourcenauslastung überwacht, wenn Pools auf dem System aktiviert sind. Dieses Dienstprogramm prüft wiederholt alle aktiven Pools auf dem System und zeichnet Statistiken basierend auf dem ausgewählten Ausgabemodus auf. Mithilfe der poolstat-Statistiken können Sie feststellen, welche Ressourcenpartitionen stark ausgelastet sind. Sie können diese Statistiken analysieren, um Entscheidungen über neue Ressourcenzuordnungen zu treffen, wenn das System mehr Ressourcen bereitstellen muss.
Das Dienstprogramm poolstat enthält Optionen, mit denen bestimmte Pools untersucht und Ressourcenset-spezifische Statistiken erstellt werden können.
Wenn Zonen auf dem System implementiert sind und Sie poolstat in einer nicht-globalen Zone verwenden, werden Informationen zu den Ressourcen angezeigt, die dem Pool der Zone zugeordnet sind.
Weitere Informationen zum Dienstprogramm poolstat finden Sie in der Manpage poolstat(1M) poolstat-Aufgaben- und Nutzungsinformationen finden Sie unter Verwenden von poolstat zum Erstellen von Statistiken über Pool-bezogene Ressourcen.
In der Standardeinstellung umfass die Ausgabe von poolstat eine Überschrift und eine Zeile für jeden Pool. Eine Pool-Zeile beginnt mit der Pool-ID und dem Namen des Pools, gefolgt von einer Spalte mit statistischen Daten zu dem Prozessorset, das an den Pool angehängt ist. Ressourcensets, die an mehrere Pools angehängt sind, werden mehrmals aufgeführt, jeweils einmal für jeden Pool.
Die Spaltenüberschriften lauten wie folgt:
Pool-ID.
Pool-Name.
Ressourcenset-ID.
Ressourcenset-Name.
Ressourcenset-Typ.
Minimale Ressourcenset-Größe.
Maximale Ressourcenset-Größe.
Aktuelle Ressourcenset-Größe.
Eine Messung, wie viel des Ressourcensets derzeit verwendet wird.
Diese Nutzung wird als Prozentsatz der Ressourcensetauslastung multipliziert mit der Größe des Ressourcensets berechnet. Falls ein Ressourcenset während des letzten Messintervalls neu konfiguriert wurde, wird dieser Wert nicht aufgeführt. Ein nicht aufgeführter Wert erscheint als Strich (-).
Die absolute Darstellung der Last, die auf dem Ressourcenset liegt.
Weitere Informationen zu dieser Eigenschaft finden Sie in der Manpage libpool(3LIB).
Die Ausgabe von poolstat kann wie folgt angepasst werden:
Die Reihenfolge der Spalten
Die angezeigten Überschriften
Sie können Einstellen, wie häufig die von poolstat durchgeführten Vorgänge ausgeführt werden. Sie können das Messintervall für den Bericht und die Häufigkeit festlegen, wie oft Statistiken wiederholt werden:
Sie können die Intervalle für die regelmäßig von poolstat ausgeführten Vorgänge einstellen. Alle Intervalle werden in Sekunden angegeben.
Legt die Häufigkeit fest, wie oft Statistiken wiederholt werden. Standardmäßig erfasst poolstat Statistiken nur einmal.
Wenn Intervall und Zählung nicht angegeben sind, werden die Statistiken nur einmal erfasst. Wenn Intervall angegeben und Zählung nicht angegeben ist, werden die Statistiken unendlich erfasst.
Die in der folgenden Tabelle aufgeführten Befehle stellen die primäre administrative Schnittstelle zu den Pools dar. Informationen zum Verwenden dieser Befehle auf einem System mit aktivierten Zonen finden Sie unter In Zonen verwendete Resource Pools.
Manpage |
Beschreibung |
---|---|
Aktiviert oder deaktiviert die Pools auf dem System. Aktiviert eine bestimmte Konfiguration oder entfernt die aktuelle Konfiguration und setzt die zugehörigen Ressourcen auf deren Standardstatus zurück. Bei Ausführung ohne Optionen druckt pooladm die aktuelle Konfiguration der dynamischen Pools. |
|
Aktiviert die manuelle Bindung von Projekten, Aufgaben und Prozessen an einen Resource Pool. |
|
Bietet Konfigurationsvorgänge für Pools und Sets. Mit diesem Tool erstellte Konfigurationen werden mithilfe von pooladm auf einem Zielhost instanziiert. Bei Ausführung mit dem Unterbefehl info für die Option -c zeigt poolcfg Informationen zur statischen Konfiguration in /etc/pooladm.conf an. Wird ein Dateiname als Argument hinzugefügt, zeigt dieser Befehl Informationen zur statischen Konfiguration in der angegebenen Datei an. Beispielsweise zeigt poolcfg -c info /tmp/newconfig Informationen zur statischen Konfiguration in der Datei /tmp/newconfig an. |
|
Der System-Daemon der Pools. Der Daemon verwendet Systemziele und überwachbare Statistiken, um die vom Administrator angegebenen Ziele hinsichtlich der Systemleistung zu erreichen. Wenn der Daemon bei nicht erreichten Zielen keine Korrekturmaßnahmen ausführen kann, erfasst poold diesen Zustand in einem Protokoll. |
|
Zeigt Statistiken über Pool-bezogene Ressourcen an. Vereinfacht die Leistungsanalyse und stellt Informationen bereit, die Systemadministratoren bei der Ressourcenpartitionierung und Neupartitionierung unterstützen. Optionen helfen bei der Untersuchung der angegebenen Tools und der Zusammenstellung von Ressourcenset-spezifischen Statistiken. |
Eine Bibliothek-API wird für libpool bereitgestellt (lesen Sie dazu die Manpage libpool(3LIB) Die Bibliothek kann von Programmen zur Bearbeitung von Pool-Konfigurationen verwendet werden.
In diesem Kapitel wird das Einrichten und Verwalten von Resource Pools auf einem System beschrieben.
Eine Einführung in das Thema der Resource Pools finden Sie in Kapitel 12Einführung in Resource Pools.
Aufgabe |
Beschreibung |
Siehe |
---|---|---|
Aktivieren oder Deaktivieren von Resource Pools. |
Aktivieren oder Deaktivieren von Resource Pools auf einem System. | |
Aktivieren oder Deaktivieren von Dynamic Resource Pools. |
Aktivieren oder Deaktivieren von Dynamic Resource Pools auf einem System. | |
Erstellen einer statischen Resource Pool-Konfiguration. |
Erstellen einer statischen Konfigurationsdatei, die der aktuellen dynamischen Konfiguration entspricht. Weitere Informationen finden Sie unter Resource Pools-Framework. | |
Bearbeiten einer Resource Pool-Konfiguration. |
Überarbeiten einer Pool-Konfiguration auf dem System, beispielsweise durch das Erstellen von zusätzlichem Pools. | |
Zuordnen eines Resource Pools zu einer Scheduling-Klasse. |
Zuordnen eines Pool zu einer Scheduler-Klasse, so dass alle an den Pool gebundenen Prozesse den angegebenen Scheduler verwenden. | |
Einrichten von Konfigurationseinschränkungen und Definieren von Konfigurationszielen. |
Angabe der Ziele für poold, um festzulegen, wann Korrekturmaßnahmen eingeleitet werden sollen. Weitere Informationen zu den Konfigurationszielen finden Sie unter poold – Übersicht. |
So richten Sie Konfigurationseinschränkungen ein und So definieren Sie Konfigurationsziele |
Einstellen der Protokollierungsebene. |
Einstellen der Ebene, auf der poold Protokollinformationen erzeugen soll. | |
Verwenden einer Textdatei mit dem Befehl poolcfg. |
Der Befehl poolcfg kann um den Namen eine Textdatei erweitert werden. | |
Übertragen von Ressourcen im Kernel. |
Übertragen von Ressourcen im Kernel. Beispielsweise können Sie Ressourcen mit bestimmten IDs an ein Ziel-Set übertragen. | |
Aktivieren einer Pool-Konfiguration. |
Aktivieren der Konfiguration in der standardmäßigen Konfigurationsdatei. | |
Validieren einer Pool-Konfiguration, bevor sie übernommen wird. |
Validieren einer Pool-Konfiguration, um zu testen, was bei einer Validierung geschieht. | |
Löschen einer Pool-Konfiguration von dem System. |
Alle zugewiesenen Ressourcen wie z. B. Prozessorsets werden auf den Standardstatus zurückgesetzt. | |
Binden von Prozessen an einen Pool. |
Manuelles Zuweisen eines laufenden Prozesses auf dem System zu einem Resource Pool. | |
Binden von Aufgaben oder Projekten an einen Pool. |
Zuweisen von Aufgaben oder Projekten zu einem Resource Pool. | |
Binden von neuen Prozessen an einen Resource Pool. |
Um neue Prozesse in einem Prozess automatisch an einen bestimmten Pool zu binden, fügen Sie jedem Eintrag in der project-Datenbank ein Attribut hinzu. |
So richten Sie das Attribute project.pool für ein Projekt ein |
Verwenden von project-Attributen, um einen Prozess an einen anderen Pool zu binden. |
Ändern der Pool-Bindung für neu gestartete Prozesse. |
So verwenden Sie project-Attribute zum Binden eines Projekts an einen anderen Pool |
Verwenden des poolstat-Dienstprogramms zum Erzeugen von Berichten. |
Erzeugen von mehreren Berichten in angegebenen Intervallen. | |
Erzeugen von Ressourcenset-Statistiken. |
Verwenden des Dienstprogramms poolstat zum Erzeugen von Statistiken für ein pset-Ressourcenset. |
Ab Solaris-Release 10 11/06 können Sie die Resource Pools- und Dynamic Resource Pools-Services auf dem System mit dem Befehl svcadm aktivieren bzw. deaktivieren. Eine Beschreibung dieses Befehls finden Sie in der Manpage svcadm(1M).
Mit dem in der Manpage pooladm(1M) ausführlich beschriebenen Befehl pooladm können Sie:
Pools aktivieren, so dass sie bearbeitet werden können
Pools deaktivieren, so dass sie nicht bearbeitet werden können
Wenn ein System aufgerüstet wird und das Resource Pools-Framework aktiviert und die Datei /etc/pooladm.conf vorhanden ist, wird der Pools-Service aktiviert und die in der Datei enthaltene Konfiguration für das System übernommen.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Aktivieren Sie den Resource Pools-Service.
# svcadm enable system/pools:default |
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Deaktivieren Sie den Resource Pools-Service.
# svcadm disable system/pools:default |
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter Configuring RBAC (Task Map) in System Administration Guide: Security Services „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.
Aktivieren Sie den Dynamic Resource Pools-Service.
# svcadm enable system/pools/dynamic:default |
In diesem Beispiel wird gezeigt, dass Sie zunächst die Resource Pools aktivieren müssen, wenn Sie DRP ausführen möchten.
Es besteht eine Abhängigkeit zwischen Resource Pools und Dynamic Resource Pools. DRP ist jetzt ein von den Resource Pools abhängiger Service. DRP kann unabhängig vom Resource Pools-Service aktiviert und deaktiviert werden.
Im Folgenden wird gezeigt, dass sowohl Resource Pools als auch Dynamic Resource Pools derzeit deaktiviert sind:
# svcs *pool* STATE STIME FMRI disabled 10:32:26 svc:/system/pools/dynamic:default disabled 10:32:26 svc:/system/pools:default |
Aktivieren Sie die Dynamic Resource Pools:
# svcadm enable svc:/system/pools/dynamic:default # svcs -a | grep pool disabled 10:39:00 svc:/system/pools:default offline 10:39:12 svc:/system/pools/dynamic:default |
Der DRP-Service ist noch immer offline.
Geben Sie die Option -x des Befehls svcs ein, um festzustellen, warum der DRP-Service offline ist:
# svcs -x *pool* svc:/system/pools:default (resource pools framework) State: disabled since Wed 25 Jan 2006 10:39:00 AM GMT Reason: Disabled by an administrator. See: http://sun.com/msg/SMF-8000-05 See: libpool(3LIB) See: pooladm(1M) See: poolbind(1M) See: poolcfg(1M) See: poolstat(1M) See: /var/svc/log/system-pools:default.log Impact: 1 dependent service is not running. (Use -v for list.) svc:/system/pools/dynamic:default (dynamic resource pools) State: offline since Wed 25 Jan 2006 10:39:12 AM GMT Reason: Service svc:/system/pools:default is disabled. See: http://sun.com/msg/SMF-8000-GE See: poold(1M) See: /var/svc/log/system-pools-dynamic:default.log Impact: This service is not running. |
Aktivieren Sie den Resource Pools-Service, so dass der DRP-Service ausgeführt werden kann:
# svcadm enable svc:/system/pools:default |
Wenn der Befehl svcs *pool* verwendet wird, zeigt das System Folgendes an:
# svcs *pool* STATE STIME FMRI online 10:40:27 svc:/system/pools:default online 10:40:27 svc:/system/pools/dynamic:default |
Wenn beide Services online sind und Sie den Resource Pools-Service deaktivieren:
# svcadm disable svc:/system/pools:default |
Wenn der Befehl svcs *pool* verwendet wird, zeigt das System Folgendes an:
# svcs *pool* STATE STIME FMRI disabled 10:41:05 svc:/system/pools:default online 10:40:27 svc:/system/pools/dynamic:default # svcs *pool* STATE STIME FMRI disabled 10:41:05 svc:/system/pools:default online 10:40:27 svc:/system/pools/dynamic:default |
Schließlich wird der DRP-Service offline geschaltet, weil der Resource Pools-Service deaktiviert wurde:
# svcs *pool* STATE STIME FMRI disabled 10:41:05 svc:/system/pools:default offline 10:41:12 svc:/system/pools/dynamic:default |
Ermitteln Sie, warum der DRP-Service offline ist:
# svcs -x *pool* svc:/system/pools:default (resource pools framework) State: disabled since Wed 25 Jan 2006 10:41:05 AM GMT Reason: Disabled by an administrator. See: http://sun.com/msg/SMF-8000-05 See: libpool(3LIB) See: pooladm(1M) See: poolbind(1M) See: poolcfg(1M) See: poolstat(1M) See: /var/svc/log/system-pools:default.log Impact: 1 dependent service is not running. (Use -v for list.) svc:/system/pools/dynamic:default (dynamic resource pools) State: offline since Wed 25 Jan 2006 10:41:12 AM GMT Reason: Service svc:/system/pools:default is disabled. See: http://sun.com/msg/SMF-8000-GE See: poold(1M) See: /var/svc/log/system-pools-dynamic:default.log Impact: This service is not running. |
Resource Pools müssen gestartet sein, damit DRP ausgeführt werden können. Beispielsweise können Resource Pools mit dem Befehl pooladm und der Option -e gestartet werden:
# pooladm -e |
Jetzt zeigt der Befehl svcs *pool* Folgendes an:
# svcs *pool* STATE STIME FMRI online 10:42:23 svc:/system/pools:default online 10:42:24 svc:/system/pools/dynamic:default |
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Deaktivieren Sie den Dynamic Resource Pools-Service.
# svcadm disable system/pools/dynamic:default |
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Aktivieren Sie die Pools.
# pooladm -e |
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Deaktivieren Sie die Pools.
# pooladm -d |
Geben Sie die Option -s für /usr/sbin/pooladm ein, um eine statische Konfigurationsdatei zu erstellen, die der aktuellen dynamischen Konfiguration entspricht. Sofern kein anderer Dateiname angegeben wurde, wird der standardmäßige Speicherort /etc/pooladm.conf verwendet.
Übernehmen Sie die Konfiguration mit dem Befehl pooladm und der Option -c. Dann geben Sie den Befehl pooladm mit der Option -s ein, um die statische Konfiguration so zu aktualisieren, dass sie dem Status der dynamischen Konfiguration entspricht.
Das neue Funktionsmerkmal pooladm -s sollte dem älteren Befehl poolcfg -c discover zum Erstellen einer neuen Konfiguration, die der dynamischen Konfiguration entspricht, vorgezogen werden.
Aktivieren Sie die Pools auf dem System.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Aktualisieren Sie die statische Konfigurationsdatei so, dass sie der aktuellen dynamischen Konfiguration entspricht.
# pooladm -s |
Zeigen Sie den Inhalt der Konfigurationsdatei in lesbarer Form an.
Beachten Sie, dass die Konfiguration vom System erstellte Standardelemente enthält.
# poolcfg -c info system tester string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line |
Übernehmen Sie die Konfiguration unter /etc/pooladm.conf.
# pooladm -c |
(Optional) Um die dynamische Konfiguration in die statische Konfigurationsdatei namens /tmp/backup zu kopieren, geben Sie Folgendes ein:
# pooladm -s /tmp/backup |
Um die Konfiguration zu verbessern, erstellen Sie ein Prozessorset namens pset_batch und einen Pool namens pool_batch. Dann verbinden Sie Pool und Prozessorset über eine Zuordnung.
Denken Sie daran, dass Sie Unterbefehlsargumente mit Leerzeichen in Anführungszeichen stellen müssen.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Erstellen Sie das Prozessorset pset_batch.
# poolcfg -c 'create pset pset_batch (uint pset.min = 2; uint pset.max = 10)' |
Erstellen Sie den Pool pool_batch.
# poolcfg -c 'create pool pool_batch' |
Verbinden Sie Pool und Prozessorset über eine Zuordnung.
# poolcfg -c 'associate pool pool_batch (pset pset_batch)' |
Zeigen Sie die bearbeitete Konfiguration an.
# poolcfg -c info system tester string system.comment kernel state int system.version 1 boolean system.bind-default true int system.poold.pid 177916 pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line pool pool_batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment pset pset_batch pset pset_batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line |
Übernehmen Sie die Konfiguration unter /etc/pooladm.conf.
# pooladm -c |
(Optional) Um die dynamische Konfiguration in die statische Konfigurationsdatei namens /tmp/backup zu kopieren, geben Sie Folgendes ein:
# pooladm -s /tmp/backup |
Sie können einen Pool einer Scheduling-Klasse zuordnen, so dass alle an den Pool gebundenen Prozesse diesen Scheduler verwenden. Dazu setzen Sie die Eigenschaft pool.scheduler auf den Namen des Schedulers. Im folgenden Beispiel wird der Pool pool_batch dem Fair Share Scheduler (FSS) zugeordnet.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.
Bearbeiten Sie den Pool pool_batch, um ihm dem FSS zuzuordnen.
# poolcfg -c 'modify pool pool_batch (string pool.scheduler="FSS")' |
Zeigen Sie die bearbeitete Konfiguration an.
# poolcfg -c info system tester string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line pool pool_batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler FSS pset batch pset pset_batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line |
Übernehmen Sie die Konfiguration unter /etc/pooladm.conf :
# pooladm -c |
(Optional) Um die dynamische Konfiguration in die statische Konfigurationsdatei namens /tmp/backup zu kopieren, geben Sie Folgendes ein:
# pooladm -s /tmp/backup |
Einschränkungen reduzieren die Anzahl möglicher Konfigurationen, indem sie einige potentielle Änderungen eliminieren, die an einer Konfiguration vorgenommen werden können. Im folgenden Verfahren wird gezeigt, wie Sie die Eigenschaft cpu.pinned einrichten.
In den folgenden Beispielen ist cpuid eine ganze Zahl.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Ändern Sie die Eigenschaft cpu.pinned in der statischen oder dynamischen Konfiguration:
Sie können Ziele für poold angeben, die beim Durchführen von Korrekturmaßnahmen berücksichtigt werden sollen.
Im folgenden Verfahren ist das Ziel wt-load so gesetzt, dass poold versucht, die Ressourcenzuordnung an die Ressourcenauslastung anzupassen. Das Ziel locality ist deaktiviert, um das Erreichen dieses Konfigurationsziels zu unterstützen.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Ändern Sie das System tester, um das Ziel wt-load zu bevorzugen.
# poolcfg -c 'modify system tester (string system.poold.objectives="wt-load")' |
Deaktivieren Sie das Ziel locality für das standardmäßige Prozessorset.
# poolcfg -c 'modify pset pset_default (string pset.poold.objectives="locality none")' |
Deaktivieren Sie das Ziel locality für das Prozessorset pset_batch.
# poolcfg -c 'modify pset pset_batch (string pset.poold.objectives="locality none")' |
Zeigen Sie die bearbeitete Konfiguration an.
# poolcfg -c info system tester string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 string system.poold.objectives wt-load pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true string pset.poold.objectives locality none cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line pool pool_batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler FSS pset batch pset pset_batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 string pset.poold.objectives locality none cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line |
Übernehmen Sie die Konfiguration unter /etc/pooladm.conf.
# pooladm -c |
(Optional) Um die dynamische Konfiguration in die statische Konfigurationsdatei namens /tmp/backup zu kopieren, geben Sie Folgendes ein:
# pooladm -s /tmp/backup |
Zum Festlegen der Protokollierungsebene für poold richten Sie die Eigenschaft system.poold.log-level in der poold-Konfiguration ein. Die poold-Konfiguration befindet sich in der libpool-Konfiguration. Weitere Informationen finden Sie unter poold-Protokollierungsinformationen und in den Manpages poolcfg(1M) und libpool(3LIB).
Sie können den Befehl poold auch an der Befehlszeile eingeben, um die Protokollierungsebene für poold festzulegen.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Legen Sie die Protokollierungsebene mit dem Befehl poold und der Option -l sowie einem Parameter, z. B. INFO fest.
# /usr/lib/pool/poold -l INFO |
Informationen zu den verfügbaren Parametern finden Sie unter poold-Protokollierungsinformationen. Die standardmäßige Protokollierungsebene ist NOTICE.
Der Befehl poolcfg mit der Option -f kann eine Textdatei aufnehmen, die poolcfg-Unterbefehlsargumente für die Option -c enthält. Diese Methode eignet sich insbesondere dann, wenn Sie die durchzuführenden Vorgänge einrichten möchten. Bei der Verarbeitung von mehreren Befehlen wird die Konfiguration nur dann aktualisiert, wenn alle Befehle erfolgreich ausgeführt wurden. Bei großen oder komplexen Konfigurationen ist diese Technik eventuell besser geeignet als das Aufrufen einzelner Unterbefehle.
In Befehlsdateien kennzeichnet das #-Zeichen den Rest der Zeile als Kommentar.
Erstellen Sie die Eingabedatei poolcmds.txt.
$ cat > poolcmds.txt create system tester create pset pset_batch (uint pset.min = 2; uint pset.max = 10) create pool pool_batch associate pool pool_batch (pset pset_batch) |
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.
Führen Sie den folgenden Befehl aus:
# /usr/sbin/poolcfg -f poolcmds.txt |
Geben Sie das Unterbefehlsargument transfer für die Option -c des Befehls poolcfg mit der Option -d ein, um Ressourcen im Kernel zu übertragen. Die Option -d gibt an, dass der Befehl direkt am Kernel ausgeführt wird und keine Eingabe aus einer Datei erhält.
Im folgenden Verfahren werden zwei CPUs aus dem Prozessorset pset1 in das Prozessorset pset2 im Kernel verschoben.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Verschieben Sie zwei CPUs von pset1 nach pset2.
Die Unterklauseln from und to können in beliebiger Reihenfolge verwendet werden. Für jeden Befehl wird nur jeweils eine Unterklausel to und from unterstützt.
# poolcfg -dc 'transfer 2 from pset pset1 to pset2' |
Wenn bestimmte bekannte IDs eines Ressourcentyps übertragen werden, kann auch eine alternative Syntax verwendet werden. Beispielsweise weist der folgende Befehl die zwei CPUs mit den IDs 0 und 2 dem Prozessorset pset_large zu:
# poolcfg -dc "transfer to pset pset_large (cpu 0; cpu 2)" |
Falls eine Übertragung fehlschlägt, weil nicht genügend Ressourcen verfügbar sind, um die Anforderung zu erfüllen oder die angegebenen IDs nicht gefunden werden können, zeigt das System eine Fehlermeldung an.
Mit dem Befehl pooladm können Sie eine bestimmte Pool-Konfiguration aktivieren oder die aktuelle aktive Pool-Konfiguration entfernen. Weitere Informationen zu diesem Befehl finden Sie in der Manpage pooladm(1M).
Zum Aktivieren der Konfiguration in der standardmäßigen Konfigurationsdatei /etc/pooladm.conf geben Sie den Befehl pooladm mit der Option -c für „Konfiguration übernehmen“ ein.”
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Übernehmen Sie die Konfiguration unter /etc/pooladm.conf.
# pooladm -c |
(Optional) Kopieren Sie die dynamische Konfiguration in eine statische Konfigurationsdatei, z. B. /tmp/backup.
# pooladm -s /tmp/backup |
Mit der Option -n und der Option -c können Sie prüfen, was bei einer Validierung geschieht. Die Konfiguration wird dabei nicht tatsächlich übernommen.
Der folgende Befehl versucht, die Konfiguration unter /home/admin/newconfig zu validieren. Alle erfassten Fehler werden angezeigt, die Konfiguration selbst wird jedoch nicht modifiziert.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Validieren Sie die Konfiguration, bevor Sie sie übernehmen.
# pooladm -n -c /home/admin/newconfig |
Zum Entfernen der aktuellen, aktiven Konfiguration und Wiederherstellen des Standardzustands aller zugeordneten Ressourcen, z. B. Prozessorsets, geben Sie die Option -x für „Konfiguration entfernen“ ein.”
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Entfernen Sie die aktuelle aktive Konfiguration.
# pooladm -x |
Mit der Option -x für den Befehl pooladm werden alle benutzerdefinierten Elemente aus der dynamischen Konfiguration entfernt. Alle Ressourcen nehmen wieder den Standardstatus an, und alle Pool-Bindungen werden durch eine Bindung mit dem Standard-Pool ersetzt.
Prozesse in den Klassen TS und IA können im gleichen Prozessorset gemischt werden. Das Mischen anderer Scheduling-Klassen innerhalb eines Prozessorsets kann zu unerwarteten Ergebnissen führen. Wenn der Befehl pooladm -x dazu führt, dass Scheduling-Klassen innerhalb eines Prozessorsets gemischt werden, verwenden Sie den Befehl priocntl ein, um laufende Prozesse in eine andere Scheduling-Klasse zu verschieben. Lesen Sie dazu So verschieben Sie manuelle Prozesse aus der TS-Klasse in die FSS-Klasse. Lesen Sie auch die Manpage priocntl(1).
Durch Einrichten eines project.pool-Attributs können Sie einen Resource Pool einem Projekt zuordnen.
Sie können einen laufenden Prozess auf zwei Arten an einen Pool binden:
Verwenden Sie den unter poolbind(1M) beschriebenen Befehl poolbind, um einen bestimmten Prozess an einen benannten Resource Pool zu binden.
Geben Sie das Attribut project.pool in die project-Datenbank ein, um die Pool-Bindung für eine neue Anmeldesitzung oder eine Aufgabe zu identifizieren, die über den Befehl newtask gestartet wird. Lesen Sie auch die Manpages newtask(1), projmod(1M) und project(4).
Im folgenden Verfahren wird der Befehl poolbind mit der Option -p verwendet, um einen Prozess (in diesem Fall die aktuelle Shell) manuell an einen Pool namens ohare zu binden.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Binden Sie manuell einen Prozess an einen Pool:
# poolbind -p ohare $$ |
Überprüfen Sie die Pool-Bindung des Prozesses mit dem Befehl poolbind und der Option -q.
$ poolbind -q $$ 155509 ohare |
Das System zeigt die Prozess-ID und die Pool-Bindung an.
Zum Binden von Aufgaben oder Projekten an einen Pool verwenden Sie den Befehl poolbind mit der Option -i. Im folgenden Beispiel werden alle Prozesse im Projekt airmiles an den Pool laguardia gebunden.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Binden Sie alle Prozesse im Projekt airmiles an den Pool laguardia.
# poolbind -i project -p laguardia airmiles |
Mit dem Attribut project.pool können Sie die Prozesse eines Projekts an einen Resource Pool binden.
Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.
Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Fügen Sie jedem Eintrag in der project-Datenbank das Attribut project.pool hinzu.
# projmod -a -K project.pool=poolname project |
Angenommen, Sie haben eine Konfiguration mit zwei Pools, studio und backstage. Die Datei /etc/project enthält Folgendes:
user.paul:1024::::project.pool=studio user.george:1024::::project.pool=studio user.ringo:1024::::project.pool=backstage passes:1027::paul::project.pool=backstage |
Bei dieser Konfiguration werden Prozesse, die von dem Benutzer paul gestartet werden, standardmäßig an den Pool studio gebunden.
Der Benutzer paul kann die Pool-Bindung für von ihm gestartete Prozesse ändern. paul kann den Befehl newtask verwenden, um Arbeiten auch an den Pool backstage zu binden, indem sie im Projekt passes gestartet werden.
Starten Sie einen Prozess im Projekt passes.
$ newtask -l -p passes |
Verwenden Sie den Befehl poolbind mit der Option -q, um die Pool-Bindung des Prozesses zu überprüfen. Verwenden Sie darüber hinaus ein doppeltes Dollarzeichen ($$), um die Prozessnummer der übergeordneten Shell an den Befehl zu übergeben.
$ poolbind -q $$ 6384 pool backstage |
Das System zeigt die Prozess-ID und die Pool-Bindung an.
Mit dem Befehl poolstat können Sie Statistiken über Pool-bezogene Ressourcen anzeigen. Weitere Informationen finden Sie unter Verwenden von poolstat zur Überwachung der Pools und der Ressourcenauslastung und in der Manpage poolstat(1M).
Die folgenden Unterabschnitte enthaltenen Beispiele, mit denen das Erstellen eines Berichts für einen bestimmten Zweck verdeutlicht wird.
Geben Sie den Befehl poolstat ohne Argumente ein, um nur eine Kopfzeile sowie eine Zeile mit Informationen zu jedem Pool auszugeben. Die Informationszeile enthält die Pool-ID, den Pool-Namen und die Ressourcenstatistiken für das an den Pool angehängte Prozessorset.
machine% poolstat pset id pool size used load 0 pool_default 4 3.6 6.2 1 pool_sales 4 3.3 8.4 |
Mit dem folgenden Befehl erstellen Sie drei Berichte in einem 5-Sekunden-Messintervall.
machine% poolstat 5 3 pset id pool size used load 46 pool_sales 2 1.2 8.3 0 pool_default 2 0.4 5.2 pset id pool size used load 46 pool_sales 2 1.4 8.4 0 pool_default 2 1.9 2.0 pset id pool size used load 46 pool_sales 2 1.1 8.0 0 pool_default 2 0.3 5.0 |
Im folgenden Beispiel wird der Befehl poolstat mit der Option -r verwendet, um Statistiken für das Prozessorset-Ressourcenset zu erstellen. Beachten Sie, dass das Ressourcenset pset_default an mehrere Pools angehängt ist, daher wird dieses Prozessorset einmal für jede Pool-Mitgliedschaft aufgeführt.
machine% poolstat -r pset id pool type rid rset min max size used load 0 pool_default pset -1 pset_default 1 65K 2 1.2 8.3 6 pool_sales pset 1 pset_sales 1 65K 2 1.2 8.3 2 pool_other pset -1 pset_default 1 10K 2 0.4 5.2 |
In diesem Kapitel werden die Grundstruktur der Ressourcenverwaltung erklärt und ein hypothetisches Server-Konsolidierungsprojekt beschrieben.
In diesem Kapitel werden folgende Themen behandelt:
In diesem Beispiel werden fünf Anwendungen auf einem einzigen System konsolidiert. Die Zielanwendungen haben unterschiedliche Ressourcenanforderungen, unterschiedlich hohe Benutzerzahlen und unterschiedliche Architekturen. Derzeit befindet sich jede Anwendung auf einem dedizierte Server, der so ausgelegt ist, dass er die Anforderungen der Anwendung erfüllt. Die Anwendungen und ihrer Eigenschaften sind in der folgenden Tabelle aufgeführt.
Beschreibung der Anwendung |
Eigenschaften |
---|---|
Anwendungsserver |
Zeigt eine negative Skalierbarkeit über zwei CPUs hinaus |
Datenbankinstanz für den Anwendungsserver |
Ressourcenintensive Transaktionsverarbeitung |
Anwendungsserver in der Test- und Entwicklungsumgebung |
GUI-basiert, mit nicht getesteter Codeausführung |
Transaktionen verarbeitender Server |
Oberste Priorität hat die Reaktionszeit |
Eigenständige Datenbankinstanz |
Verarbeitet zahlreiche Transaktionen und dient mehreren Zeitzonen |
Die folgende Konfiguration dient zur Konsolidierung der Anwendungen auf einem System.
Der Anwendungsserver ist mit zwei CPU-Prozessorsets ausgestattet.
Die Datenbankinstanz für den Anwendungsserver und die eigenständige Datenbankinstanz werden auf ein einzelnes Prozessorset mit mindestens vier CPUs konsolidiert. Der eigenständigen Datenbankinstanz werden 75 % dieser Ressource garantiert.
Der Anwendungsserver für die Test- und Entwicklungsumgebung benötigt die Scheduling-Klasse IA, um die UI-Reaktionsfähigkeit sicherzustellen. Speichereinschränkungen wurden eingerichtet, um die Auswirkungen von Programmen mit fehlerhaften Codes zu reduzieren.
Dem Server für die Transaktionsverarbeitung ist ein dediziertes Prozessorset mit mindestens zwei CPUs zugewiesen, um die Latenzzeit bei der Reaktion zu minimieren.
Diese Konfiguration deckt bekannte Anwendungen ab, die Prozessorzyklen in einem Ressourcenset ausführen und verbrauchen. Das heißt, es können Einschränkungen eingerichtet werden, mit denen die Prozessorressource zu den Sets übertragen werden, wo die Ressource benötigt wird.
Das Ziel wt-load ist so eingerichtet, dass stark ausgelastete Ressourcensets größere Ressourcenzuweisungen erhalten als Sets, die nur eine geringe Auslastung aufweisen.
Das Ziel locality ist auf tight eingestellt. Bei dieser Einstellung wird die Prozessorlokalität maximiert.
Eine zusätzliche Einschränkung verhindert, dass die Auslastung eines beliebigen Ressourcensets 80 % übersteigt. Diese Einschränkung stellt sicher, dass Anwendungen Zugriff auf die angeforderten Ressourcen erhalten. Weiterhin ist das Ziel, die Auslastung unter 80 % zu halten, für das Transaktions-Prozessorset doppelt so wichtig wie alle anderen angegebenen Ziele. Diese Wichtigkeit ist in der Konfiguration definiert.
Bearbeiten Sie die Datenbankdatei /etc/project. Fügen Sie Einträge hinzu, um die erforderlichen Resource Controls zu implementieren und ordnen Sie Benutzer zu den Resource Pools zu. Dann zeigen Sie die Datei an.
# cat /etc/project . . . user.app_server:2001:Production Application Server:::project.pool=appserver_pool user.app_db:2002:App Server DB:::project.pool=db_pool;project.cpu-shares=(privileged,1,deny) development:2003:Test and development::staff:project.pool=dev_pool; process.max-address-space=(privileged,536870912,deny)keep with previous line user.tp_engine:2004:Transaction Engine:::project.pool=tp_pool user.geo_db:2005:EDI DB:::project.pool=db_pool;project.cpu-shares=(privileged,3,deny) . . . |
Das Entwicklungssystem muss Aufgaben im Entwicklungsprojekt ausführen, da der Zugriff auf dieses Projekt auf Benutzergruppen-IDs (GIDs) basiert.
Erstellen Sie eine Eingabedatei namens pool.host zur Konfiguration der erforderlichen Resource Pools. Zeigen Sie die Datei an.
# cat pool.host create system host create pset dev_pset (uint pset.min = 0; uint pset.max = 2) create pset tp_pset (uint pset.min = 2; uint pset.max=8) create pset db_pset (uint pset.min = 4; uint pset.max = 6) create pset app_pset (uint pset.min = 1; uint pset.max = 2) create pool dev_pool (string pool.scheduler="IA") create pool appserver_pool (string pool.scheduler="TS") create pool db_pool (string pool.scheduler="FSS") create pool tp_pool (string pool.scheduler="TS") associate pool dev_pool (pset dev_pset) associate pool appserver_pool (pset app_pset) associate pool db_pool (pset db_pset) associate pool tp_pool (pset tp_pset) modify system tester (string system.poold.objectives="wt-load") modify pset dev_pset (string pset.poold.objectives="locality tight; utilization < 80") modify pset tp_pset (string pset.poold.objectives="locality tight; 2: utilization < 80") modify pset db_pset (string pset.poold.objectives="locality tight;utilization < 80") modify pset app_pset (string pset.poold.objectives="locality tight; utilization < 80") |
Aktualisieren Sie die Konfiguration mit der Eingabedatei pool.host.
# poolcfg -f pool.host |
Aktivieren Sie die Konfiguration.
# pooladm -c |
Die Grundstruktur der Konfiguration ist jetzt auf dem System betriebsfähig.
Zum Anzeigen der Grundstruktur der Konfiguration, in der auch vom das System erstellte Standardelemente enthalten sind, geben Sie Folgendes ein:
# pooladm system host string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 string system.poold.objectives wt-load pool dev_pool int pool.sys_id 125 boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler IA pset dev_pset pool appserver_pool int pool.sys_id 124 boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler TS pset app_pset pool db_pool int pool.sys_id 123 boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler FSS pset db_pset pool tp_pool int pool.sys_id 122 boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler TS pset tp_pset pool pool_default int pool.sys_id 0 boolean pool.default true boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler TS pset pset_default pset dev_pset int pset.sys_id 4 string pset.units population boolean pset.default false uint pset.min 0 uint pset.max 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 string pset.poold.objectives locality tight; utilization < 80 pset tp_pset int pset.sys_id 3 string pset.units population boolean pset.default false uint pset.min 2 uint pset.max 8 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 string pset.poold.objectives locality tight; 2: utilization < 80 cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line pset db_pset int pset.sys_id 2 string pset.units population boolean pset.default false uint pset.min 4 uint pset.max 6 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 string pset.poold.objectives locality tight; utilization < 80 cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 6 string cpu.comment string cpu.status on-line pset app_pset int pset.sys_id 1 string pset.units population boolean pset.default false uint pset.min 1 uint pset.max 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 string pset.poold.objectives locality tight; utilization < 80 cpu int cpu.sys_id 7 string cpu.comment string cpu.status on-line pset pset_default int pset.sys_id -1 string pset.units population boolean pset.default true uint pset.min 1 uint pset.max 4294967295 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line |
Im Folgenden finden Sie eine grafische Darstellung der Grundstruktur der Konfiguration.
Mit dem Pool db_pool werden der eigenständigen Datenbankinstanz 75 % der CPU-Ressource garantiert.
In diesem Kapitel werden die Funktionen zur Steuerung und Überwachung von Ressourcen in der Solaris Management-Konsole beschrieben. Nur ein Teil der Funktionen zur Ressourcenverwaltung können über die Konsole gesteuert werden.
Mit der Konsole können Sie die Systemleistung überwachen und die in Tabelle 15–1 aufgeführten Resource Control-Werte für Projekte, Aufgaben und Prozesse eingeben. Die Konsole ist eine bequeme und sichere Alternative zur Befehlszeilenschnittstelle (CLI), um die zahlreichen, über viele Systeme verteilten Konfigurationsparameter zu verwalten. Jedes System wird individuell verwaltet. Die grafische Oberfläche der Konsole unterstützt alle Benutzer, vom Anfänger bis zum Experten.
In diesem Kapitel werden folgende Themen behandelt.
Aufgabe |
Beschreibung |
Siehe |
---|---|---|
Verwenden der Konsole |
Starten der Solaris Management-Konsole in einer lokalen Umgebung, in einem Namen-Service oder in einer Verzeichnisdienstumgebung. Das Leistungswerkzeug ist in einer Namen-Service-Umgebung nicht verfügbar. |
Starting the Solaris Management Console in System Administration Guide: Basic Administration und Using the Solaris Management Tools in a Name Service Environment (Task Map) in System Administration Guide: Basic Administration |
Überwachen der Systemleistung |
Greifen Sie unter „Systemstatus“ auf das „Leistungswerkzeug“ zu. | |
Hinzufügen von Resource Controls zu Projekten |
Greifen Sie unter „Systemkonfiguration“ auf die Registerkarte „Resource Controls“ zu. |
Die Ressourcenverwaltung ist eine Komponente der Solaris Management-Konsole. Die Konsole ist ein Container für GUI-basierte Administrationswerkzeuge, die in Sammlungen gespeichert werden, die als Toolboxes bezeichnet werden. Weitere Informationen zur Konsole und ihrer Verwendungsweise finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.
Bei der Arbeit mit der Konsole und den darin enthaltenen Werkzeugen ist die Onlinehilfe der Konsole Ihre wichtigste Informationsquelle. Eine Beschreibung der Dokumentation in der Onlinehilfe finden Sie unter Solaris Management Console (Overview) in System Administration Guide: Basic Administration.
Der Begriff Managementbereich bezieht sich auf die Namen-Service-Umgebung, die Sie zur Verwendung mit dem ausgewählten Verwaltungswerkzeug gewählt haben. Der Managementbereich für die Resource Control- und Leistungswerkzeuge ist die lokale Datei /etc/project oder NIS.
Der von Ihnen während einer Konsolensitzung gewählte Managementbereich muss dem primären Namen-Service entsprechen, der in der Datei /etc/nsswitch.conf gekennzeichnet ist.
Das Leistungswerkzeug dient zur Überwachung der Ressourcenauslastung. Die Ressourcenauslastung kann als Zusammenfassung für das System, nach Projekt oder nach einzelnen Benutzern angezeigt werden.
Das Leistungswerkzeug befindet sich unter „Systemstatus“ im Bereich „Navigation“. Um auf das Leistungswerkzeug zuzugreifen, führen Sie die folgenden Schritte aus:
Klicken Sie auf das Steuerelement „Systemstatus“ im Bereich „Navigation“.
Das Steuerelement dient zum Erweitern der Menübefehle im Bereich „Navigation“.
Klicken Sie auf das Steuerelement „Leistung“.
Klicken Sie auf das Steuerelement „System“.
Doppelklicken Sie auf „Zusammenfassung“, „Projekte“ oder „Benutzer“.
Ihre Auswahl hängt von der Nutzung ab, die Sie überwachen möchten.
Es werden für die folgenden Attributwerte angezeigt.
Attribut |
Beschreibung |
---|---|
Aktive Prozesse |
Anzahl der auf dem System aktiven Prozesse |
Belegter virtueller Speicher |
Größe des belegten Systemspeichers |
Freier physischer Speicher |
Größe des verfügbaren Systemspeichers |
Belegter Swap-Speicher |
Größe des belegten Swap-Speichers |
Freier Swap-Speicher |
Größe des verfügbaren Swap-Speichers |
Seitenrate |
Rate der Paging-Aktivität des Systems |
Systemaufrufe |
Anzahl der Systemaufrufe pro Sekunde |
Netzwerkpakete |
Anzahl der Netzwerkpakete, die pro Sekunde übertragen werden |
CPU-Auslastung |
Prozentsatz der CPU, der derzeit genutzt wird |
Belastungsmittelwert |
Anzahl der Prozesse in der System-Ausführungswarteschlange als Mittelwert über die letzten 1, 5 und 15 Minuten |
Es werden für die folgenden Attributwerte angezeigt.
Attribut |
Kurzname |
Beschreibung |
---|---|---|
Eingabeblöcke |
inblk |
Anzahl der gelesenen Blöcke |
Geschriebene Blöcke |
oublk |
Anzahl der geschriebenen Blöcke |
Gelesene/Geschriebene Zeichen |
ioch |
Anzahl der gelesenen und geschriebenen Zeichen |
Passivzeit bei Datenseitenfehlern |
dftime |
Für die Verarbeitung von Datenseitenfehlern aufgewendete Zeit |
Unbeabsichtigte Kontextübergänge |
ictx |
Anzahl der unwillkürlichen Kontextübergänge |
Zeit Systemmodus |
stime |
Im Kernel-Modus verbrachte Zeit |
Schwerwiegende Seitenfehler |
majfl |
Anzahl der wesentlichen Seitenfehler |
Empfangene Meldungen |
mrcv |
Anzahl der empfangenen Meldungen |
Gesendete Meldungen |
msend |
Anzahl der gesendeten Meldungen |
Geringfügige Seitenfehler |
minf |
Anzahl der geringfügigen Seitenfehler |
Prozessanzahl |
nprocs |
Anzahl an Prozessen mit dem Benutzer oder dem Projekt als Eigentümer |
LWP-Anzahl |
count |
Anzahl an Lightweight-Prozessen |
Weitere Passivzeit |
slptime |
Eine andere Passivzeit als tftime, dftime, kftime und ltime |
CPU-Zeit |
pctcpu |
Prozentsatz der zuletzt vom Prozess, vom Benutzer oder vom Projekt genutzten CPU-Zeit |
Belegter Speicher |
pctmem |
Prozentsatz des zuletzt vom Prozess, vom Benutzer oder vom Projekt genutzten Systemspeichers |
Heap-Größe |
brksize |
Größe des Speichers, der für einen Prozessdatensegment reserviert ist |
Resident Set-Größe |
rsssize |
Aktuelle Speichergröße, die vom Prozess beansprucht wird |
Größe des Prozessabbildes |
size |
Größe des Prozessabbilds in KB |
Empfangene Signale |
sigs |
Anzahl der empfangenen Signale |
Gestoppte Zeit |
stoptime |
Zeit, die im Status „stopped“ verbracht wurde |
Swap-Operationen |
swaps |
Anzahl der derzeit stattfindenden Swap-Vorgänge |
Getätigte Systemaufrufe |
sysc |
Anzahl der Systemaufrufe über das letzte Zeitintervall |
Passivzeit bei Systemseitenfehlern |
kftime |
Zeit, die für die Verarbeitung von Seitenfehlern aufgewendet wurde |
Trap-Zeit des Systems |
ttime |
Zeit, die für die Verarbeitung von System Traps aufgewendet wurde |
Passivzeit bei Textseitenfehlern |
tftime |
Zeit, die für die Verarbeitung von Textseitenfehlern aufgewendet wurde |
Benutzersperrzeit |
ltime |
Zeit, die für das Warten auf Benutzersperren aufgewendet wurde |
Zeit Benutzermodus |
utime |
Zeit, die im Benutzermodus verbracht wurde |
Zeit Benutzer- und Systemmodus |
time |
Die gesamte CPU-Ausführungszeit |
Beabsichtigte Kontextübergänge |
vctx |
Anzahl der beabsichtigten Kontextübergänge |
Wait-Zeit CPU |
wtime |
Zeit, die für das Warten auf die CPU (Latenz) aufgewendet wurde |
Mit Resource Controls weisen Sie einem Projekt ein Set mit Ressourceneinschränkungen zu. Diese Einschränkungen bestimmen die zulässige Ressourcennutzung durch Aufgaben und Prozesse, die im Projektkontext ausgeführt werden.
Die Registerkarte „Resource Controls“ befindet sich unter „Systemkonfiguration“ im Bereich „Navigation“. Um auf die Registerkarte „Resource Controls“ zuzugreifen, führen Sie die folgenden Schritte aus:
Klicken Sie auf das Steuerelement „Systemkonfiguration“ im Bereich „Navigation“.
Doppelklicken Sie auf „Projekte“.
Klicken Sie auf ein Projekt im Hauptfenster der Konsole, um es auszuwählen.
Wählen Sie im Menü „Aktion“ die Option „Eigenschaften“.
Klicken Sie auf die Registerkarte "Resource Controls".
Zeigen Sie die Werte der Resource Controls für Prozesse, Projekte oder Aufgaben an, fügen Sie Werte hinzu oder bearbeiten oder löschen Sie sie.
In der folgenden Tabelle sind die Resource Controls aufgeführt, die Sie in der Konsole einstellen können. Dabei wird die Ressource beschrieben, die von einer Resource Control eingeschränkt wird. Darüber hinaus sind die Standardeinheiten in der Tabelle aufgeführt, die von der project-Datenbank für diese Ressourcen verwendet werden. Es gibt zwei Arten von Standardeinheiten:
Mengen stellen eine begrenzte Anzahl dar.
Indizes stellen einen maximal gültigen Bezeichner dar.
Somit gibt project.cpu-shares die Anzahl der Shares an, auf die das Projekt Anrecht hat. process.max-file-descriptor gibt die maximale Anzahl an Dateien an, die einem Prozess vom Systemaufruf open(2) zugewiesen werden können.
Tabelle 15–1 In der Solaris Management-Konsole standardmäßig verfügbare Resource Controls
Name der Resource Control |
Beschreibung |
Standardeinheit |
---|---|---|
project.cpu-shares |
Die Anzahl der CPU-Shares, die diesem Projekt zur Nutzung mit dem Fair Share Scheduler (FSS) zugeteilt sind (lesen Sie dazu auch die Manpage FSS(7)) |
Menge (Shares) |
task.max-cpu-time |
Maximale CPU-Zeit, die für die Prozesse der Aufgabe verfügbar ist |
Zeit (Sekunden) |
task.max-lwps |
Höchstzahl der LWPs, die gleichzeitig für die Prozesse der Aufgabe zur Verfügung stehen |
Menge (LWPs) |
process.max-cpu-time |
Maximale CPU-Zeit, die für diesen Prozess zur Verfügung steht |
Zeit (Sekunden) |
process.max-file-descriptor |
Maximaler Dateideskriptorindex, der für diesen Prozess zur Verfügung steht |
Index (maximaler Dateideskriptor) |
process.max-file-size |
Maximaler Datei-Offset, der für das Schreiben durch diesen Prozess zur Verfügung steht |
Größe (Byte) |
process.max-core-size |
Maximale Größe einer Kerndatei, die von diesem Prozess erstellt wird |
Größe (Byte) |
process.max-data-size |
Maximaler Heap-Speicher, der für diesen Prozess zur Verfügung steht |
Größe (Byte) |
process.max-stack-size |
Maximales Stack-Speichersegment, das für diesen Prozess zur Verfügung steht |
Größe (Byte) |
process.max-address-space |
Maximale Größe des Adressraums, als Summe aller Segmentgrößen, der für diesen Prozess zur Verfügung steht |
Größe (Byte) |
Sie können Resource Control-Werte für Prozesse, Projekte und Aufgaben anzeigen, hinzufügen, bearbeiten oder löschen. Diese Vorgänge werden über Dialogfelder in der Konsole durchgeführt.
Resource Controls und Werte werden in Tabellenform in der Konsole angezeigt. Die Spalte „Resource Control“ führt die Resource Controls auf, die eingestellt werden können. Die Spalte „Wert“ zeigt die jeder Resource Control zugeordneten Eigenschaften an. Die Werte sind in der Tabelle in Klammern eingeschlossen, und erscheinen als durch Kommata getrennter Klartext. Die Werte in Klammern bilden eine „Aktionsklausel“. Jede Aktionsklausel setzt sich aus einem Schwellenwert, einer Berechtigungsebene, einem Signal und einer lokalen Aktion zusammen, die einen bestimmten Schwellenwert zugeordnet ist. Jede Resource Control kann mehrere Aktionsklauseln enthalten, die ebenfalls durch Kommata voneinander getrennt sind.
Bei einem laufenden System wirken sich Werte, die über die Konsole in der project-Datenbank geändert werden, nur auf neue Aufgaben aus, die in einem Projekt gestartet werden.
Informationen zu Projekten und Aufgaben finden Sie in Kapitel 2Einführung in Projekte und Aufgaben. Informationen zu Resource Controls finden Sie in Kapitel 6Einführung in die Resource Controls. Informationen zum Fair Share Scheduler (FSS) finden Sie in Kapitel 8Einführung in den Fair Share Scheduler.
Nicht alle Resource Controls können in der Konsole eingestellt werden. Eine Liste der Resource Controls , die in der Konsole eingestellt werden können, finden Sie in Tabelle 15–1.