Virtual Memory Manager VMM

VMM Einstellungen in der Zeit von AIX 4.1 bis 5.2 TL 6

Mit welchen Limits läuft ein aktiver Prozess?

Wieviel 4K / 16K / 64K pages nutzt mein Server?

VMM Einstellungen in der Zeit von AIX 4.1 bis 5.2 TL 4 bzw. bis 5.3 ML 1

Bei den AIX Versionen ab 5.2 TL 5 bzw 5.3 TL 2 hat sich die Behandlung von permanent und computational memory sowie die eingestellten Grenzen geändert. Die u.g. Werte und Formeln sind damit hinfällig. Seit AIX V6 sind diese geänderten Einstellungen schon default und die alten Werte sollten nicht ohne sehr guten Grund verwendet werden.

Bestimmung VMM Einstellungen
minperm

Minimum>= 5%, defaults to 20%

Berechnet mit

minperm=(RAM-4MB) * 0,2 oder

minperm= (# of memory frames - 1024) * 0,2

maxperm -P

Minimum >= 5%, defaults to 80%

Berechnet mit

maxperm =(RAM - 4MB)*0,8 oder

maxperm =(# of memory frames - 1024) * 0,8 oder

maxperm = 100% - [(100*avm/size)-5%] oder

maxperm = 100% - [( ( work(in use) + work(pin) ) * 100 /

size(memory) ) - 5%] oder

maxperm = 100% - [( ( virtual(memory) + pin(memory)) * 100 /

size(memory) ) - 5%]

Bestimmung der Werte über svmon -G die Daten in Spalte "work" und Zeile "Memory". Ausgabe liefert 4K Pages

# bootinfo -r

14155776

# svmon -G

size inuse free pin virtual

memory 3538941 3415500 123441 342456 1359246

pg space 1572864 511526

work pers clnt lpage

pin 342456 0 0 0

in use 905132 2496986 13382 0

# bc

342456+905132

1247588

1247588*100

124758800

124758800/3538941

35

35-5

30

Beispiel

Script rc.vmtune (Owner root:system ; Rechte: 754)

#!/usr/bin/ksh

# Tuning VMM Options for DB2EEE Server

if [ $(/usr/sbin/bootinfo -K) -eq 32 ]; then

if [ -x /usr/samples/kernel/vmtune ]; then

/usr/samples/kernel/vmtune -R64 -f360 -F552 -s1 -p10 -P60 -t60

fi

elif [ $(/usr/sbin/bootinfo -K) -eq 64 ]; then

if [ -x /usr/samples/kernel/vmtune64 ]; then

/usr/samples/kernel/vmtune64 -R64 -f360 -F552 -s1 -p10 -P60 -t60

fi

fi

Top

Mit welchen Limits läuft ein aktiver Prozess?

a) Um herauszufinden, mit welchen Limits ein Prozess gestartet wurde, gibt es verschiedene Möglichkeiten. Die einfachste Möglichkeit ist mit dem ps Kommando indem man die "v" Option aus dem Berkeley Standard mitgibt. Diese einfache Methode hat jedoch den Nachteil, daß die zurückgelieferte Information nicht besonders aussagekräftig ist.

(0)aserver:/home/root 19# ps v

PID TTY STAT TIME PGIN SIZE RSS LIM TSIZ TRS %CPU %MEM COMMAND

11692 0 A 0:00 24 432 496 32768 49 64 0.0 0.0 /usr/sbin

13510 pts/0 A 0:00 107 884 1348 32768 399 464 0.0 0.0 -ksh93

15044 pts/0 A 0:00 0 544 640 32768 72 96 0.0 0.0 ps v

16338 pts/0 A 0:00 14 548 784 32768 200 236 0.0 0.0 -ksh

(0)aserver:/home/root 20# ulimit -a

time(seconds) unlimited

file(blocks) unlimited

data(kbytes) 131072

stack(kbytes) 32768

memory(kbytes) 32768

coredump(blocks) 2097151

nofiles(descriptors) 2000

(0)aserver:/home/root 21#

b) Man kann dann den AIX dbx aus dem bos.adt.debug fileset benutzen um eine Abfrage nach proc rlimit machen. Damit lassen sich die eingestellten Limits erforschen. Allerdings muß man beim beenden der debugging Sitzung daran denken, daß man den dbx mit detach verläßt und nicht mit quit. Ein quit beendete den untersuchten Prozess gleich mit und das kann auf einem lfd. System schon mal Ärger geben.

c) Um also viele Informationen zu bekommen und trotzdem ein geringes Risiko einzugehen bleibt als dritte Möglichkeit der AIX Kerneldebugger kdb. Mit seinen vielen Möglichkeiten ist er ein sehr komplexes Werkzeug und wer sich nicht intensiv mit ihm auseinandersetzt wird wenig mit ihm anfangen können. Es gibt aber einen einfachen Weg, mit dem man Informationen über einen Prozess aus ihm abgreifen kann.

Da der kdb intern mit Hexadezimalzahlen arbeitet muß man zunächst die PID des betroffenen Prozesses von Dezimal in Hexadezimal übertragen. Im Beispiel untersuchen wir einen Java Prozess, der die PID 14194 hat. Der Basic Calculator rechnet für uns um:

(0)aserver:/home/root 23# ps -ef | grep -i java

root 14194 5464 0 23:33:12 - 1:36 /usr/java5/bin/java -Xbootclass.....

(0)aserver:/home/root 24# bc

obase=16

14194

3772

Als nächstes muß man die zum Prozess gehörenden Threads identifizieren.

(0)aserver:/home/root 37# pstat -A | head -3 ;pstat -A | awk '{if ($4 ~ "772$") {print $0}}' | head

THREAD TABLE:

SLT ST TID PID CPUID POLICY PRI CPU EVENT PROCNAME FLAGS

41 s 2975 3772 unbound other 3c 0 31f2e88c java

67 s 438b 3772 unbound other 52 0 ea0021a0 java

86 s 56b1 3772 unbound other 52 0 ea002b20 java

92 s 5ced 3772 unbound other 52 0 70f1291c java

97 s 61e9 3772 unbound other 3c 0 ea0030a0 java

99 s 63e1 3772 unbound other 3c 0 ea0031a0 java

123 z 7bff 3772 unbound other 60 0 java

125 s 7d05 3772 unbound other 52 0 70f1411c java

140 s 8c21 3772 unbound other 52 0 33dd00d8 java

141 s 8d1b 3772 unbound other 46 0 ea0046a0 java

(0)aserver:/home/root 38#

Der Java Prozess hat also eine ganze Reihe von Threads(, mit head wurde im Beispiel ein Teil der Ausgabe abgeschnitten). Die Limits stehen in der User Area. Um die Limits aus der User Area auszulesen brauchen wir (für kdb) dabei den sog. Slot des Threads (und nicht des Prozesses). Diese Slot-ID ist die SLT Spalte. Für harte bzw. softe Speicherlimits fragen wir FSIZE  aus dem kdb mit einfachsten Mitteln ab:

(0)aserver:/home/root 43# print "user 41" | kdb | grep FSIZE

rlimit[FSIZE].........cur 7FFFFFFF max 7FFFFFFF

saved_rlimit[FSIZE].. cur 7FFFFFFFFFFFFFFF max 7FFFFFFFFFFFFFFF

rlimit_flag[FSIZE]... cur INF max INF

(0)aserver:/home/root 44#

Aus der /usr/include/sys/resource.h sieht man "cur" steht für das Softlimit des Prozesses, "max" für das Hardlimit.

typedef unsigned long rlim_t;

struct rlimit {

rlim_t rlim_cur; /* current (soft) limit */

rlim_t rlim_max; /* maximum value for rlim_cur */

};

Im obigen Beispiel handelt es sich um einen 32-Bit Prozess. Bei der Rückgabe der o.g. Abfrage findet man auch

In der /usr/include/sys/user.h findet man die Bedeutung von INF. Wie schon vermutet steht das Kürzel für Unendlich:

(0)cserver:/home/root/ 14# grep INF /usr/include/sys/user.h

* RLFLAG_INF => limit is infinite

(0)cserver:/home/root/ 15#

Abschließend muß man das hexadezimale Ergebnis in ein dezimales umrechnen und mit den Werten in der globalen oder user limits vergleichen:

(0)aserver:/home/root 46# bc

ibase=16

7FFFFFFF

2147483647

2147483647/1024*2

69181914

(0)aserver:/home/root 47#

Das Ergebnis ist Byte, geteilt durch 1024 erhält man KB, multipliziert mit 2 erhält man 512 Byte Blöcke.

Top

Wieviel 4K / 16K / 64K pages nutzt mein Server?

Informationen über die Speichernutzung eines AIX Servers kann man ebenfalls wie oben gesehen aus dem kdb abfragen. Dies ist nur ein Nutzungsbeispiel für kdb, das im Beispiel zurückgegebene Ergebnis entspricht weitgehend den Informationen, die man ansonsten mit vmstat -v abfragt.

(0)cserver:/home/root/ 18# print vmstat | kdb | egrep '4K|16K|64K'

Total available memory (4K frames) : 00200000 8.0GB

4K number of frames : 001E7292 7.7GB

4K frames pinned : 00017EDB 382.9MB

4K system pinnable frames remaining: 0016DCCD 5.8GB

4K user pinnable frames remaining : 0017A7F0 6.0GB

Free paging space (in 4K blocks) : 00011C29 284.2MB

(0)cserver:/home/root/ 19#

Top