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.