wir haben mehrere Server im Cluster und möchten wissen, in welchen Fällen wir generell große Seiten konfigurieren müssen?
Ich habe auch ein paar Fragen
- Ist die „Speicherseitengröße“ gleich „Große Seiten“?
In meinem Linux-Server habe ich den folgenden Befehl eingegeben, um die Standardgröße der Speicherseite zu überprüfen
grep Hugepagesize /proc/meminfo
Hugepagesize: 2048 kB
getconf PAGESIZE
4096
aber wie wir hier alle sehen, erhalten wir unterschiedliche Ergebnisse. Warum?
welche Risiken bestehen bei der Verwendung sehr großer Seiten?
Dosis: Transparente große Seite deaktivieren – bedeutet, die Option „RIESIGE SEITEN“ zu deaktivieren?
Antwort1
Hugepages sind interessant, wenn Anwendungen große Mappings benötigen, auf die sie wahlfrei zugreifen, da dies der schlimmstmögliche Fall für den Translation Lookaside Buffer (TLB) ist. Sie tauschen Mappinggranularität gegen TLB-Einträge ein.
Seiten, einschließlich Hugepages, können nur einem physischen Speicherblock derselben Größe zugeordnet und an dieser Größe ausgerichtet werden. Eine 2 MB große Hugepage muss also einer 2 MB-Grenze im physischen RAM zugeordnet werden und eine 1 GB große Hugepage muss einer 1 GB-Grenze zugeordnet werden, da die unteren Bits Daten innerhalb der Seite adressieren und hier kein Offset hinzugefügt werden kann.
Das bedeutet, dass Hugepages normalerweise beim Systemstart reserviert werden, wenn der physische Speicher noch nicht fragmentiert ist. Anwendungen, die Hugepages unterstützen, können hugetlbfs
sie zur Zuweisung verwenden.
Ob Hugepages 2MB oder 1GB groß sein sollen, muss per Kernel-Parameter entschieden werden, eine Mischung ist nicht möglich. Normale 4kB-Seiten sind immer verfügbar.
Der häufigste Anwendungsfall sind virtuelle Maschinen (qemu/kvm können Hugepages verwenden), bei denen dies ermöglicht, die gesamte Speicherzuordnung der VM in einer kleinen Anzahl von TLB-Einträgen zu halten, die daher nie gelöscht werden, sodass Speicherzugriffe innerhalb der VM nur im Gastkontext eine Seitentabellensuche erfordern.
Einige Datenbanksysteme unterstützen auch Hugepages, aber dies ist im Allgemeinen nur nützlich, wenn Sie mit großen Datensätzen und Indizes arbeiten.
Die Fragen:
Es gibt normale (4 kB) Seiten und riesige (2 MB oder 1 GB) Seiten. Wenn Sie die Seitengröße abfragen, erhalten Sie die Größe für normale Seiten, wenn Sie die riesige Seitengröße abfragen, erhalten Sie die Einstellung für riesige Seiten. Sowohl normale als auch riesige Seiten können parallel verwendet werden, aber Sie können nicht verschiedene riesige Seitengrößen mischen.
Sie erhalten unterschiedliche Ergebnisse, da dies zwei verschiedene Dinge sind. Die Größe normaler Seiten ist hardwareseitig festgelegt, es handelt sich also nicht um eine Einstellung.
Große Seiten müssen frühzeitig zugewiesen werden, und obwohl der Speicher technisch gesehen „frei“ ist, kann er nur für Anwendungen verwendet werden, die große Seiten unterstützen. Daher steht allen Anwendungen außer diesen weniger Speicher zur Verfügung. Das ist normalerweise kein Problem, da Sie große Seiten auf Maschinen verwenden, die für speicherhungrige Anwendungen wie VMs oder Datenbanken vorgesehen sind.
Transparente Hugepages versuchen, den Speicher als Puffer und Caches verfügbar zu machen (im Gegensatz zu Nr. 3) und Hugepages an Anwendungen zu vergeben, die große Speicherblöcke zuordnen, sodass Anwendungen, die Hugepages nicht verstehen, trotzdem davon profitieren können – im Grunde wird einer Anwendung, die einen Speicherblock von 2 MB/1 GB anfordert, wenn möglich eine Hugepage zugewiesen. Ob dies die Leistung verbessert oder verschlechtert, hängt von Ihren Anwendungen ab. Wenn Sie eine Hugepage-verstehende Anwendung haben und den Speicher manuell zuweisen möchten, müssen Sie THP deaktivieren, während ein System mit einer Datenbankanwendung, die Hugepages nicht versteht, wahrscheinlich davon profitieren würde.
Antwort2
Offensichtliche Anwendungsfälle für riesige Seiten sind, wenn PageTables (sichtbar in /proc/meminfo) Dutzende GB groß werden. Das bedeutet großen Speicher- und CPU-Overhead allein durch die Überwachung Ihres Speichers. Dies passiert bei riesigen Speicherblöcken, einer großen Anzahl von Prozessen oder beidem. Häufig in Datenbankanwendungen.
Riesige Seiten reduzieren diesen Aufwand erheblich, da ein einzelner Seitentabelleneintrag nun viel mehr Speicher adressiert, beispielsweise 2.048 KB statt 4 KB. (Auf anderen Plattformen gibt es andere Größen, AIX unter POWER unterstützt beispielsweise 16 MB große Seiten.)
Riesige Seiten können unter Linux nicht für die Dateizwischenspeicherung verwendet werden und sind für ein paar MB an malloc() für nicht gemeinsam genutzten Speicher ärgerlich und ineffizient. Der Administrator muss also riesige Seitenpools zuweisen, die nur für bestimmte Zwecke verwendet werden können. Dies ist ein Nachteil bei der Verwendung riesiger Seiten.
Transparent Huge Pages (THP) versuchen, die Verwaltung weniger lästig zu machen, indem sie zusammenhängenden Speicher automatisch in Huge Pages „defragmentieren“. Die Idee war, dass dies vorab zugewiesene Huge Pages optional macht. Die Vorteile sind sehr arbeitslastabhängig, es kann sein, dass zu viel CPU verbraucht wird, als dass es sich lohnt. Wenn Sie THP deaktivieren, können Sie Huge Pages immer noch manuell zuweisen. Manchmal lohnt es sich, THP auszuschalten und nur die gemeinsam genutzten Speichersegmente der Datenbank in Huge Pages zu packen.
Eine letzte Beschwerde zu den riesigen Seiten unter Linux: Ich finde die Verwaltung nervig.
- Der gemeinsam genutzte Speicher verwendet eine Schnittstelle, für die anderen verwenden Sie jedoch eine Hugetlbfs-Bibliothek und ein Hugetlbfs-Dateisystem.
- Sie können Speicher „verschwenden“, indem Sie zu große Seiten zuweisen und Ihre Anwendung nicht für die Verwendung dieses Speichers konfigurieren.
- Diese Seitenzahl muss auf die jeweilige Hostgröße skaliert werden, da es sich um die Anzahl der Seiten und nicht um einen Prozentsatz des Speichers handelt.
- Oft ist die Möglichkeit, große Seiten zuzuordnen, auf die Zugehörigkeit zu einer Gruppe beschränkt. Ein Wechsel des Datenbankbenutzers kann zu überraschender Speicherverschwendung führen.