Da viele Server-Applikationen (wie Apache Web Server, FTP- und Mail-Server) für jeden Client eine eigene Prozessinstanz starten, ist die Anzahl der Clients,
die die Applikation gleichzeitig bedienen kann, durch das Limit für die Anzahl der Prozesse begrenzt.
Allerdings wird durch die Anzahl der Prozesse weder das “Gewicht” der Anwendung noch die Fähigkeit des Servers begrenzt, gewichtige Anfragen von Clients zu bedienen.

Beim Konfigurieren des Systems zur Ressourcensteuerung ist es wichtig, sowohl die maximale Anzahl der Prozesse als auch die durchschnittliche Anzahl der
Prozesse zu bestimmen. Andere abhängige Parameter der Ressourcensteuerung hängen möglicherweise sowohl vom Limit als auch von der durchschnittlichen Anzahl ab.

Die Schwelle (barrier) von numproc bietet keine zusätzliche Kontrolle und sollte auf denselben Wert wie das Limit gesetzt werden.

Die Gesamtzahl der Prozesse im System unterliegt einer Einschränkung.
Ab ungefähr 16.000 Prozessen beginnt sich die Reaktionsgeschwindigkeit des Systems zu verschlechtern, was mit steigender Prozessanzahl noch zunimmt.
Eine Gesamtzahl der Prozesse über 32.000 führt höchstwahrscheinlich zu einem Hängen des Systems.
In der Praxis ist die Anzahl der Prozesse gewöhnlich niedriger.
Jeder Prozess verbraucht eine gewisse Menge Speicher, und der verfügbare Speicher und der untere Speicherbereich begrenzen die Anzahl der Prozesse auf niedrigere Werte.
Bei typischen Prozessen können normalerweise maximal 8.000 Prozesse in einem System ausgeführt werden.

Dieser Parameter begrenzt die Anzahl der TCP-Verbindungen und somit die Anzahl der Clients, die die Serverapplikation gleichzeitig bedienen kann.
Die Schwelle dieses Parameters sollte auf denselben Wert wie das Limit gesetzt werden.

Da jeder Container über einen eigenen Satz IP-Adressen verfügt, besteht keine direkte Einschränkung der Gesamtzahl der TCP-Sockets im System.
Die Anzahl der Sockets muss kontrolliert werden, da jeder Socket eine gewisse Menge Speicher für seine Puffer zum Empfangen und Senden benötigt und Speicher eine begrenzte Ressource ist.

Für die Kommunikation innerhalb des Systems werden lokale (UNIX-Domain) Sockets verwendet.
Mehrschichtige Applikationen (z. B. eine Webapplikation mit einem Datenbankserver als Backend) können für die Versorgung jedes Clients einen oder mehrere lokale Sockets benötigen.
Einfache Applikationen, wie die meisten Mailserver (mit Ausnahme von Postfix) verwenden keine lokalen Sockets.

Für Domain Name Service (DNS)-Abfragen werden UDP-Sockets verwendet.
Allerdings wird nur eine geringe Anzahl solcher Sockets gleichzeitig geöffnet.
UDP- und andere Sockets können auch in einigen sehr speziellen Applikationen (SNMP-Agenten usw.) verwendet werden.

Die Schwelle (barrier) dieses Parameters sollte auf denselben Wert wie das Limit gesetzt werden.
Die Anzahl der lokalen Sockets in einem System ist nicht eingeschränkt.
Die Anzahl der UDP-Sockets in einem System ist, ähnlich wie die der TCP-Sockets, bei Virtuozzo-Systemen nicht eingeschränkt.

Wie beim Parameter numtcpsock muss die Anzahl der Nicht-TCP-Sockets kontrolliert werden, da jeder Socket eine gewisse Menge
Speicher für seine Puffer benötigt und Speicher eine begrenzte Ressource ist.

Dieser Parameter bestimmt, wie viel Speicher der virtuellen Umgebung zur Verfügung steht (d. h. wie viel Speicher seine Applikationen mit malloc(3)
oder anderen Linux-Standardmechanismen zur Speicherzuordnung zuweisen können).
Je mehr Clients eine Applikation bedient, oder je “gewichtiger” sie ist, desto mehr Speicher benötigt sie.

Die Speichermenge, die Applikationen des Containers garantiert zuordnen können, ist definiert als die Schwelle (barrier) des Parameters vmguarpages.
Die aktuell zugeordnete Speichermenge wird im Parameter privvmpages festgehalten.
Der Parameter vmguarpages weist selbst keinen eigenen Zähler auf.
Die Schwelle (barrier) und das Limit des Parameters privvmpages legen eine Obergrenze für die Speicherzuordnungen fest.
Die Bedeutung des Limits für den Parameter vmguarpages ist in der aktuellen Version nicht spezifiziert und sollte auf den maximal zulässigen Wert LONG_MAX gesetzt werden.

Wenn die aktuell zugeordnete Speichermenge nicht die garantierte Speichermenge (die Schwelle (barrier) von vmguarpages) überschreitet,
sind die Speicherzuordnungen der Applikationen des Containers immer erfolgreich.
Wenn die aktuell zugeordnete Speichermenge die garantierte Speichermenge überschreitet, aber unterhalb der Schwelle von privvmpages bleibt, können die Zuordnungen,
abhängig von der gesamten verfügbaren Speichermenge im System, erfolgreich sein oder nicht.

Ab der Schwelle (barrier) von privvmpages schlagen Speicherzuordnungen mit normaler Priorität und ab dem Limit von privvmpages alle von den
Applikationen vorgenommenen Speicherzuordnungen fehl.
Die Speicherzuordnungsgarantie ist eines der Haupt-Tools zur Kontrolle des für Container verfügbaren Speichers, weil sie Administratoren ermöglicht, Service-Level-Agreements anzugeben.
Diese Agreements garantieren eine bestimmte Dienstqualität (QoS), eine bestimmte Menge von Ressourcen und die allgemeine Verfügbarkeit des Dienstes.
Die Maßeinheit der Werte von vmguarpages ist Speicherseiten (4 KB auf x86- und x86_64-Prozessoren).
Die gesamten den Containern gewährten Speicherzuordnungsgarantien sind durch die physischen Ressourcen des Computers begrenzt – die Größe des RAM und des Swap-Speichers.

Der Parameter beinhaltet alle den Containerprozessen zugeordneten internen Datenstrukturen des Kernels, mit Ausnahme der unten besprochenen Netzwerkpuffer.
Diese Datenstrukturen befinden sich im ersten Gigabyte des Server-RAM, dem so genannten “unteren” Speicherbereich.

Der Parameter kmemsize hängt mit der Anzahl der Prozesse zusammen.
Jeder Prozess verbraucht eine bestimmte Menge an Kernelspeicher, mindestens jedoch 24 KB und typischerweise 30-60 KB. Sehr große Prozesse können auch noch mehr Kernelspeicher verbrauchen.
Es ist wichtig, einen bestimmten Sicherheitspuffer zwischen der Schwelle (barrier) und dem Limit des Parameters kmemsizeeinzurichten (z. B. 10 %). Wenn die Schwelle (barrier) und das Limit des Parameters kmemsize identisch sind, kann die Situation eintreten, dass der Kernel die Applikationen des Containers beenden muss, um die Nutzung von kmemsize unter dem Limit zu halten.

Das Limit für kmemsize kann nicht willkürlich hoch festgelegt werden.
Die Gesamtmenge aus im Parameter kmemsize festgehaltener Speichermenge plus Socket-Pufferspeicher ist durch die Hardwareressourcen des Systems begrenzt.

Der Parameter tcpsndbuf hängt von der Anzahl der TCP-Sockets (numtcpsock) ab und sollte die Zuordnung eines minimalen Pufferspeichers für jeden Socket ermöglichen:

Wenn diese Vorgabe nicht erfüllt ist, können sich Netzwerkverbindungen unter Umständen ohne Fehlermeldung aufhängen, sodass keine Daten gesendet werden können.

Das Festlegen hoher Werte für den Parameter tcpsndbuf kann, muss aber nicht, die Leistung der Netzwerkkommunikation steigern.
Anders als bei den meisten anderen Parametern wirken sich das Erreichen der tcpsndbuf-Limits und fehlgeschlagene Socket-Puffer-Zuordnungen nicht besonders negativ
auf die Applikationen aus, sondern verringern lediglich die Leistung der Netzwerkkommunikation.

Bei Verwendung von “rtorrent” in einem Container kann ein niedriger Wert für tcpsndbuf dazu führen, dass “rtorrent” eine ungewöhnlich große Menge von CPU-Ressourcen beansprucht.
In diesem Fall müssen Sie einen höheren Wert festlegen.
Achten Sie auch auf den Wert für failcnt in /proc/user_beancounters.

Das Limit für tcpsndbuf kann nicht willkürlich hoch festgelegt werden.
Die Gesamtmenge aus für alle Container im System verfügbarem tcpsndbuf-Speicher plus Speicher von kmemsize und anderen Socket-Puffern ist durch die Hardwareressourcen des Systems begrenzt.

Diese Socket-Puffer befinden sich ebenfalls im “unteren Speicherbereich”.

Der Parameter tcprcvbuf hängt von der Anzahl der TCP-Sockets ab und sollte die Zuordnung eines minimalen Pufferspeichers für jeden Socket ermöglichen:

Wenn diese Vorgabe nicht erfüllt ist, können sich Netzwerkverbindungen unter Umständen aufhängen, sodass keine Daten empfangen werden können und die
Verbindung nach einigen Minuten abgebrochen wird.

Ähnlich wie für den Parameter tcpsndbuf gilt auch für den Parameter tcprcvbuf, dass das Festlegen hoher Werte die Leistung der Netzwerkkommunikation steigern kann, aber nicht muss.
Das Erreichen der tcprcvbuf-Limits und fehlgeschlagene Socket-Puffer-Zuordnungen wirken sich nicht besonders negativ auf die Applikationen aus,
sondern verringern lediglich die Leistung der Netzwerkkommunikation.
Allerdings kann es beim Parameter tcprcvbuf riskanter als beim Parameter tcpsndbuf sein, längere Zeit über der Schwelle (barrier) zu bleiben.
Längere Zeiträume bei überschrittener Schwelle können dazu führen, dass einige Verbindungen abgebrochen werden.

Das Limit für tcprcvbuf kann nicht willkürlich hoch festgelegt werden.
Die Gesamtmenge aus für alle Container im System verfügbarem tcprcvbuf-Speicher plus Speicher von kmemsize und anderen Socket-Puffern ist durch die Hardwareressourcen des Systems begrenzt.

Der Parameter othersockbuf hängt von der Anzahl der Nicht-TCP-Sockets ab. Die Konfiguration von othersockbuf muss gemäß der folgenden Formel durchgeführt werden:
Für besonders hohe Anforderungen an die Kommunikation über lokale (UNIX-Domain) Sockets muss das Limit für othersockbufheraufgesetzt werden.
Allerdings wirkt sich, wie beim Parameter tcpsndbuf, das Erreichen des othersockbuf-Limits nur auf die Kommunikationsleistung und nicht auf die Funktionalität aus.
Das Limit für othersockbuf kann nicht willkürlich hoch festgelegt werden.
Die Gesamtmenge aus für alle Container im System verfügbarem othersockbuf-Speicher plus Speicher von kmemsize und anderen Socket-Puffern ist durch die
Hardwareressourcen des Systems begrenzt.

Der Parameter dgramrcvbuf hängt von der Anzahl der Nicht-TCP-Sockets ab.
Die Limits für dgramrcvbuf müssen in der Regel nicht hoch sein.
Nur wenn die Container sehr große Datagramme senden und empfangen müssen, sollten die Schwellen für die Parameter othersockbuf und dgramrcvbuf heraufgesetzt werden.

Bei Erreichen des dgramrcvbuf-Limits gehen einige Datagramme verloren, die unter Umständen für die Funktion der Applikation von Bedeutung sind.
Da das UDP-Protokoll keine garantierte Zustellung bietet, können die Datagramme selbst bei ausreichenden Puffern noch in einem späteren Stadium der
Verarbeitung verloren gehen, und die Applikationen sollten darauf vorbereitet sein.

Anders als bei anderen Socket-Puffer-Parametern sollte die Schwelle für dgramrcvbuf auf denselben Wert wie das Limit gesetzt werden.

Das Limit für dgramrcvbuf kann nicht willkürlich hoch festgelegt werden.
Die Gesamtmenge aus für alle Container im System verfügbarem dgramrcvbuf-Speicher plus Speicher von kmemsize und anderen Socket-Puffern ist durch die Hardwareressourcen des Systems begrenzt.

Der Parameter oomguarpages hängt mit dem Parameter vmguarpages zusammen.
Wenn die Applikationen mehr Speicher verbrauchen als der Computer aufweist, kommt es zur Speicherüberlastung des Systems.
In diesem Fall wird das Betriebssystem die Prozesse des Containers einen nach dem anderen beenden, um so viel Speicher freizugeben, dass das Überleben des Systems gewährleistet ist.
Auch wenn es bei typischer Systemauslastung sehr selten vorkommt, ist das Beenden von Prozessen in Situationen mit Speicherüberlastung eine normale Reaktion des Systems,
die in jeden Linux-Kernel integriert ist.
Der Parameter oomguarpages berücksichtigt die Gesamtmenge des Arbeitsspeichers und Swap-Speichers, die von Prozessen eines bestimmten Containers genutzt wird.
Die Schwelle des Parameters oomguarpages ist die Speicherüberlastungsgarantie.

Wenn die aktuelle Nutzung des Arbeitsspeichers und Swap-Speichers (der Wert von oomguarpages) plus die Menge des genutzten Kernelspeichers (kmemsize)
und des Socket-Pufferspeichers unter der Schwelle (barrier) liegen, werden Prozesse in diesem Container in Situationen mit Speicherüberlastung garantiert nicht beendet.
Wenn auf dem System eine Situation mit Speicherüberlastung eintritt und es mehrere Container mit zu hohem oomguarpages-Wert gibt, werden die Applikationen
in dem Container mit dem höchsten Wert als erste beendet.
Der Zähler failcnt des Parameters oomguarpages wird erhöht, wenn ein Prozess in diesem Container aufgrund einer Überlastungssituation beendet wird.

Wenn der Administrator sicherstellen möchte, dass das Beenden einer Applikation ungeachtet des Applikationsverhaltens nicht erzwungen wird,
kann er die Wahrscheinlichkeit der Beendigung deutlich verringern, indem er das Limit für den Parameter privvmpages auf einen Wert setzt, der nicht höher als die oomguarpages-Garantie ist.
Setzt er das Limit auf die Hälfte der oomguarpages-Garantie, ist eine Beendigung vollkommen ausgeschlossen.
Solche Konfigurationen sind jedoch nicht sehr verbreitet, weil sie die Auslastung der Hardware erheblich verringern.

Die Bedeutung des Limits für den Parameter oomguarpages ist in der aktuellen Version nicht spezifiziert.

Die gesamten den Containern gewährten Überlastungsgarantien sollten die physische Kapazität des Computers nicht überschreiten.
Wenn höhere Garantien gewährt werden als das System zur Verfügung hat, kann es in Überlastungssituationen vorkommen, dass Applikationen in Containern mit garantiertem Service-Level und System-Daemons abgebrochen werden.

Der Parameter privvmpages ermöglicht das Steuern der von Applikationen zugewiesenen Speichermenge.

Die Schwelle (barrier) und das Limit des Parameters privvmpages bestimmen die Obergrenze der insgesamt zugewiesenen Speichermenge.
Diese Obergrenze ist keine Garantie dafür, dass der Container tatsächlich in der Lage ist, die angegebene Speichermenge zuzuordnen, oder dass andere Container ihren
jeweiligen Speicheranteil zuordnen können.
Der Hauptmechanismus zur Steuerung der Speicherzuordnung ist die vmguarpages-Garantie.
Im Parameter privvmpages wird der zugewiesene (aber möglicherweise noch nicht genutzte) Speicher festgehalten.
Der festgehaltene Wert stellt eine Schätzung der Speichermenge dar, die tatsächlich verbraucht wird, wenn die Applikationen des Containers beginnen, den zugeordneten Speicher zu nutzen.
Verbrauchter Speicher wird im Parameter oomguarpages festgehalten.

Da der im Parameter privvmpages festgehaltene Speicher möglicherweise nicht tatsächlich genutzt wird, kann die Summe der aktuellen privvmpages-Werte für
alle Container die Größe des RAM und Swap-Speichers des Computers übersteigen.

Zwischen der Schwelle (barrier) und dem Limit des Parameters privvmpages sollte ein Sicherheitspuffer bestehen, um die Anzahl der Speicherzuordnungsfehler
zu verringern, die die Applikation nicht handhaben kann.
Dieser Puffer wird für Speicherzuordnungen mit “hoher Priorität” (wie z. B. Prozess-Stapelerweiterungen) genutzt.
Zuordnungen mit normaler Priorität schlagen bei Erreichen der Schwelle von privvmpages fehl.

Die privvmpages-Gesamtmenge muss mit den physischen Ressourcen des Computers korrelieren.
Um schwerwiegende Beeinträchtigungen der Service-Levels für andere Container zu vermeiden, sollte es zudem keinem Container gestattet werden, einen beträchtlichen
Teil des gesamten System-RAM zuzuordnen.

Die Größe dieser Seiten wird auch im Parameter kmemsize festgehalten.
Die Schwelle (barrier) kann auf denselben Wert wie das Limitgesetzt werden, oder es kann ein gewisser Puffer zwischen Schwelle (barrier) und Limit eingerichtet werden.
Dies ist abhängig von der Beschaffenheit der Applikationen, die Speichersperrfunktionen verwenden.

Beachten Sie, dass typische Serverapplikationen wie Web-, FTP- und Mailserver keine Speichersperrfunktionen verwenden.

Die Konfiguration dieses Parameters hat keinen Einfluss auf die Sicherheit und Stabilität des Gesamtsystems oder die Isolierung der einzelnen Container.
Seine Konfiguration wirkt sich nur im jeweiligen Container auf die Funktionalität von Applikationen und ihr Verhalten bei mangelnden Ressourcen aus.

Diese Seiten werden auch im Parameter privvmpages festgehalten.

Die Schwelle (barrier) dieses Parameters sollte auf denselben Wert wie das Limit gesetzt werden.
Die Konfiguration dieses Parameters hat keinen Einfluss auf die Sicherheit und Stabilität des Gesamtsystems oder die Isolierung der einzelnen Container.
Seine Konfiguration wirkt sich nur im jeweiligen Container auf die Funktionalität von Applikationen und ihr Verhalten bei mangelnden Ressourcen aus.

Bei Speicherseiten, die von mehreren verschiedenen Containern (z. B. Mappings gemeinsam genutzter Bibliotheken) genutzt werden, wird jedem Container nur ein Bruchteil einer Seite zugeteilt.
Die Summe der physpages-Nutzung für alle Container entspricht der Gesamtzahl der von allen Containern im System genutzten Seiten.

Bei vSwap-fähigen Kernels sollte die Schwelle (barrier) auf 0 gesetzt werden, während das Limit die gesamte von einem Container verwendete RAM-Größe begrenzt.
Bei älteren Kernels dient der Parameter physpages lediglich zur Zählung.
Die Schwelle (barrier) sollte auf 0 und das Limit auf unbegrenzt (unlimited) gesetzt werden.

Die Schwelle (barrier) dieses Parameters sollte auf denselben Wert wie das Limit gesetzt werden.
Die Konfiguration dieses Parameters hat keinen Einfluss auf die Sicherheit und Stabilität des Gesamtsystems oder die Isolierung der einzelnen Container.
Seine Konfiguration wirkt sich nur im jeweiligen Container auf die Funktionalität von Applikationen und ihr Verhalten bei mangelnden Ressourcen aus.

Hinweis: Wenn Sie derzeit die Schwelle (barrier) anpassen, ändert sich das Kernel-Verhalten bezüglich der “Vorauszuteilung” der numfile-Ressource.
Wenn Sie eine Änderung vornehmen, werden Sie wahrscheinlich überhaupt keine Änderungen beim Containerverhalten feststellen.
Diese Fähigkeit wurde zu reinen Forschungszwecken hinzugefügt.

Bei der Konfiguration dieses Parameters sollte ein Puffer zwischen der Schwelle (barrier) und dem Limit eingerichtet werden.
Sehr hohe Limits bei numflock-Parametern und die große Anzahl von Dateisperren im System können eine gewisse (aber nicht schwerwiegende) Verlangsamung des gesamten Systems verursachen.
Daher sollten für diesen Parameter Limits gewählt werden, die den tatsächlichen Anforderungen der Applikationen angemessen sind.

Dieser Parameter wird in der Regel verwendet, um die Anzahl gleichzeitiger Shell-Sitzungen zu begrenzen.
Die Schwelle (barrier) dieses Parameters sollte auf denselben Wert wie das Limit gesetzt werden.
Die Konfiguration dieses Parameters hat keinen Einfluss auf die Sicherheit und Stabilität des Gesamtsystems oder die Isolierung der einzelnen Container.
Seine Konfiguration wirkt sich nur im jeweiligen Container auf die Funktionalität von Applikationen und ihr Verhalten bei mangelnden Ressourcen aus.
Allerdings ist in Virtuozzo-Systemen die tatsächliche Anzahl von Pseudoterminals auf 256 Pseudoterminals im BSD-Stil plus 256 Pseudoterminals im UNIX98-Stil begrenzt.

Die Größe der Struktur wird auch im Parameter kmemsize festgehalten.
Die Standardinstallationen eigenständiger Linux-Systeme begrenzen diese Zahl auf 1.024 für das gesamte System.
In Virtuozzo-Installationen gilt das numsiginfo-Limit jeweils für einen einzelnen Container.

Die Schwelle (barrier) dieses Parameters sollte auf denselben Wert wie das Limit gesetzt werden.
Sehr hohe Limit-Einstellungen für diesen Parameter können die Reaktionsgeschwindigkeit des Systems beeinträchtigen.
Es ist unwahrscheinlich, dass ein Container ein höheres als das von Linux vorgegebene Standardlimit (1.024) benötigt.

Der Parameter dcachesize steuert dateisystembezogene Caches wie Verzeichniseintrags- (dentry) und inode-Caches. Der im Parameter dcachesize festgehaltene Wert wird auch in den Parameter kmemsize aufgenommen. dcachesize ist ein eigenständiger Parameter, der einen Grenzwert festlegt, mit dessen Hilfe Dateioperationen Speicherengpässe
erkennen und eine entsprechende Fehlermeldung an Applikationen zurückgeben können.
Dies schützt Applikationen vor Speicherengpässen während kritischer Operationen, die nicht fehlschlagen sollten.

Bei der Konfiguration dieses Parameters sollte ein Puffer zwischen der Schwelle (barrier) und dem Limit (ungefähr 10 %) eingerichtet werden.
Die Konfiguration dieses Parameters hat keinen Einfluss auf die Sicherheit und Stabilität des Gesamtsystems oder die Isolierung der einzelnen Container.
Seine Konfiguration wirkt sich nur im jeweiligen Container auf die Funktionalität von Applikationen und ihr Verhalten bei mangelnden Ressourcen aus.

Die Schwelle (barrier) dieses Parameters sollte auf denselben Wert wie das Limit gesetzt werden.
Die numiptent-Gesamtzahl unterliegt einer Einschränkung.
Sie ist abhängig von der Anzahl weiterer Zuordnungen im so genannten vmalloc-Speicherbereich und beläuft sich auf etwa 250.000 Einträge.
Eine Verletzung dieser Einschränkung kann dazu führen, dass Operationen mit IP-Paketfiltertabellen (Ausführung von iptables(8)) in einem
Container oder dem Hostsystem fehlschlagen oder dass Container-Starts fehlschlagen.

Außerdem führt eine hohe numiptent-Einstellung dazu, dass die Verarbeitung von Netzwerkpaketen sich erheblich verlangsamt.
Es wird nicht empfohlen, Containern zu erlauben, mehr als 200-300 numiptent zu erstellen.

Die Konfiguration dieses Parameters hat keinen Einfluss auf die Sicherheit und Stabilität des Gesamtsystems oder die Isolierung der einzelnen Container.
Seine Konfiguration wirkt sich nur auf die Art und Weise aus, wie der Virtuozzo-Kernel den verfügbaren Swap-Speicher in einem Container meldet.
Dies wird für einige Applikationen benötigt, die nur in einem Container ausgeführt werden, wenn der Kernel meldet, dass mindestens eine gewisse Menge an Swap-Speicher verfügbar ist.
Wenn das Limit festgelegt wird, wird sein Wert als Gesamtmenge des Swap-Speichers in einem Container gemeldet.
Wird das Limit auf LONG_MAX gesetzt (der Kernel-interne Standardwert für diesen Parameter), werden alle Parameter für Swap-Speicherwerte (gesamt, genutzt, frei) als 0 gemeldet.
Der Wert der Schwelle (barrier) für diesen Beancounter wird ignoriert.
Der Wert für gehalten (held) zeigt, wie viel Swap-Speicher aktuell für diesen Container verwendet wird.