Prozesse unter Linux adressieren keine einzelnen Bytes, sondern sprechen immer Speicherseiten (page frames) an. Die Größe einer solchen Speicherseite beträgt auf x86- und x86_64-Systemen üblicherweise 4 KiByte. Allerdings lässt sich dieser Wert auch ändern. Die verwendete Größe auf einem System fragen Sie mittels ab.
Ebenfalls erwähnenswert ist die Tatsache, dass Prozesse keinen physikalischen Speicher adressieren, sondern stattdessen einen virtuellen Adressraum zugewiesen bekommen. Wie groß dieser ist, hängt von der Prozessor-Architektur ab. Auf 32 Bit-Systemen stehen maximal 4 GByte zur Verfügung, während auf 64 Bit-Systemen das Limit wesentlich höher liegt – bei 16 ExaByte. Physikalische Speicherseiten müssen also in den virtuellen Adressraum eines Prozesses gemappt werden, wobei lange nicht der komplette Speicher verwendet wird. Startet ein neuer Prozess, so wird diesem ein virtueller Adressraum zugewiesen, allerdings werden erst dann physikalische Seiten gemappt, wenn diese tatsächlich benötigt werden.
Andere Speicherseiten wiederum können zwischen mehreren Prozessen geteilt werden. Dies ist beispielsweise bei Bibliotheken der Fall, die von mehreren Anwendungen verwendet werden (shared Libraries). Wie viel Speicher ein Prozess in Anspruch nimmt, zeigen beispielsweise Tools wie ps oder top an (siehe Kasten “Speicherverbrauch mit ps ermittelt”).
Die Werte VSZ und RSS geben jeweils die Größe des virtuellen und des gemappten physikalischen Speichers in KByte an. Wie sich der virtuelle Speicher genau zusammensetzt, zeigt der Aufruf von "pmap 6392". Wobei 6393 in diesem Beispiel die Prozess-ID des FTP-Servers ist.
Für das Mapping zwischen physikalischen und virtuellen Adressen kommt eine sogenannte Page Table zum Einsatz. Hier ist definiert, welche physikalische Speicherseite welcher virtuellen Seite entspricht. Da das Mapping und die Abfrage dieser Tabelle recht teuer und Performance-intensiv ist, existiert als Teil der CPU eine Memory Management Unit (MMU), die für die Umsetzung der Speicherseiten verantwortlich ist und das Ergebnis in einem eigenen Cache speichert – dem sogenannten Translation Lookaside Buffer (TLB). Die Größe des Caches und die Anzahl der Mappings zeigt das Tool "x86info -c" an. Wie Sie sehen können, ist dieser Cache recht klein. Um eine effiziente Nutzung zu gewährleisten, kommen auf manchen Systemen sogenannte Huge-Pages zum Einsatz, die 2 MByte oder größer sein können. Der Vorteil ist, dass bei deren Einsatz weniger Mappings durchgeführt werden müssen. Auf der anderen Seite wird allerdings mehr physikalischer Speicher verwendet, da die kleinste Einheit an physikalischen Speicherseiten, die gemappt werden kann, nun beispielsweise 2 MByte beträgt. Bei manchen Workloads, beispielsweise auf großen Datenbank-Systemen, ist der Einsatz von Huge-Pages jedoch zu empfehlen. Wieviel Speicher Sie als Huge Pages verwenden möchten, legen Sie mittels
sysctl -w vm.nr_hugetables=Anzahl
fest. Über das Kommando
cat /proc/meminfo|grep -i huge"
erhalten Sie dann das Ergebnis.
Zum Schluss sei noch die Anmerkung erlaubt, dass das Thema Performance-Tuning viel Zeit in Anspruch nimmt und Sie nur dann optimale Ergebnisse erzielen, wenn Sie viele unterschiedliche Einstellungen auf einem System probieren. Dieser Artikel soll erste Anregungen hierfür liefern. Als weitere Quelle für Anregungen empfehlen wir die Installation des Paketes "tuned" auf einem Red Hat Enterprise Linux-System. Es enthält unter anderem das Tool "tuned-adm", mit dem sich vordefinierte Perfomance-Profile aktivieren lassen. Die Profile sind dabei als Ausgangspunkt für erste Tests gedacht und können nach Belieben geändert werden.
(jp)
Link-Codes
[1] EPEL-Software Repository: : https://fedoraproject.org/wiki/EPEL/
[2] Bonnie++: : http://www.coker.com.au/bonnie++/
[3] IOzone:: http://www.iozone.org/
[4] Iperf:: http://iperf.sourceforge.net/