Huge Pages für schnelleres Blocknet-Mining

Mit reservierten Huge Pages kann seine den Speicher jedes Mining-Threads mit wenigen großen Pages statt mit Hunderttausenden kleinen abdecken. Diese Anleitung erklärt, warum das den Argon2id-Proof-of-Work von Blocknet beschleunigt, wie viele Pages du reservieren solltest und welche Befehle du unter Linux, WSL2 und Windows genau brauchst.

Warum beschleunigen Huge Pages das Blocknet-Mining?

Jeder Speicherzugriff beginnt mit einer virtuellen Adresse, die die CPU in eine physische übersetzen muss. Die letzten Übersetzungen liegen im Translation Lookaside Buffer (TLB), den die Dokumentation des Linux-Kernels als „Cache für Übersetzungen von virtuellen in physische Adressen“ und als „sehr knappe Ressource im Prozessor“ beschreibt. Steht eine Adresse nicht im TLB, durchläuft die CPU erst die Seitentabellen im Speicher, bevor sie überhaupt mit dem Laden der Daten beginnen kann.

Der Proof of Work von Blocknet macht dieses Durchlaufen häufig. Jeder Hash füllt einen 2-GiB-Speicherbereich mit 1-KiB-Blöcken, und in der zweiten Hälfte des Durchgangs liest jeder neue Block einen früheren Block, dessen Position von Daten abhängt, die einen Moment zuvor berechnet wurden. Wie die Argon2id-Erklärung zeigt, kommen so pro Hash etwa 2 GiB verstreute Lesezugriffe zusammen. Die Page-Größe entscheidet, wie viele Übersetzungen diese Zugriffe brauchen:

Mit Huge Pages deckt ein TLB-Eintrag 512- oder 262.144-mal so viel Speicher ab. Dadurch bleibt ein viel größerer Teil des Speicherbereichs in Reichweite des TLB, und jeder Thread verbringt mehr Zeit mit Hashen.

Wie viel schneller ist Mining mit Huge Pages?

Die Huge-Pages-Anleitung von seine nennt sie die wichtigste einzelne Stellschraube für CPU-Mining unter Linux. Auf dem Validierungsrechner brachten reservierte 2-MiB-Pages etwa 4–6 %, und 1-GiB-Pages legten noch einmal rund 2 % drauf. Die Anleitung hält außerdem fest, dass bei vielen laufenden Threads die Abdeckung mit Huge Pages meist mehr ausmacht als die Optimierung auf einen bestimmten Befehlssatz.

Die Server-Ergebnisse im Leistungsdiagramm von seine wurden mit explizit reservierten 2-MiB-Huge-Pages gemessen. Die 49,4 H/s eines AMD EPYC Zen 5 (EPYC 9R45) mit 32 Threads, gemessen im Oktober 2026, liefen mit 34.407 reservierten Pages, derselben Zahl wie in der Zeile für 32 Threads in der Tabelle unten. Der Leitfaden zur Mining-Hardware enthält alle Ergebnisse nach Generation.

Auch ohne Reservierung fordert seine unter Linux beim Kernel Transparent Huge Pages an. Ein reservierter Pool geht weiter, weil die Pages vorab zurückgelegt werden, sodass jeder Thread sie bekommt, egal wie fragmentiert der Speicher inzwischen ist.

Wie viele Huge Pages braucht seine?

Die Thread-Anzahl ist der Wert Threads im Dashboard von seine. seine wählt ihn anhand deines RAMs und deiner Kernanzahl, also starte seine einmal ohne Huge Pages und notiere ihn dir. Ist die Reservierung zu klein, gibt das Startprotokoll von seine eine Zeile hugepages | mit den benötigten Pages und dem sysctl-Befehl zum Reservieren aus.

Reservierte Pages sind für Programme zurückgelegt, die Huge Pages anfordern, also richte die Reservierung nach der Thread-Anzahl aus, mit der du tatsächlich minst. seine zählt den reservierten Pool beim Festlegen der Threads als verfügbaren Speicher, sodass deine Thread-Anzahl durch die Reservierung gleich bleibt.

Wie richtest du 2-MiB-Huge-Pages unter Linux ein?

Reserviere die Pages für deine Thread-Anzahl. Dieses Beispiel gilt für 4 Threads:

sudo sysctl -w vm.nr_hugepages=4301

Prüfe, ob der Kernel alle bereitstellen konnte:

grep -E 'HugePages_Total|HugePages_Free|Hugepagesize' /proc/meminfo

Ist HugePages_Total niedriger als angefordert, ist der Speicher fragmentiert. Leere die Caches, komprimiere den Speicher und versuche es erneut:

echo 3 | sudo tee /proc/sys/vm/drop_caches
echo 1 | sudo tee /proc/sys/vm/compact_memory
sudo sysctl -w vm.nr_hugepages=4301

Mache die Reservierung dauerhaft:

echo 'vm.nr_hugepages=4301' | sudo tee /etc/sysctl.d/99-seine-hugepages.conf
sudo sysctl --system

Bei großen Reservierungen ist die dauerhafte Einstellung plus Neustart der zuverlässigste Weg, weil der Kernel die Pages früh beim Booten reserviert, bevor der Speicher fragmentiert. Starte seine danach wie gewohnt. Der Standardmodus auto bildet den Speicherbereich jedes Threads ohne zusätzliche Flags aus dem reservierten Pool ab.

Wie fügst du 1-GiB-Pages hinzu?

1-GiB-Pages brauchen etwas mehr Einrichtung und bringen etwa 2 % zusätzlich zu 2-MiB-Pages. Jeder 2-GiB-Speicherbereich braucht genau zwei davon, eine Reserve musst du also nicht berechnen. Sie funktionieren unter x86_64-Linux und WSL.

Reserviere sie beim Booten mit Kernel-Parametern, denn so bekommst du Pages dieser Größe am zuverlässigsten. Für 9 Threads:

hugepagesz=1G hugepages=18

Auf einem frisch gebooteten Rechner kannst du auch eine Reservierung zur Laufzeit versuchen und dann die Zahl der freien Pages prüfen:

echo 18 | sudo tee /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
cat /sys/kernel/mm/hugepages/hugepages-1048576kB/free_hugepages

Die Zeilen HugePages_* in /proc/meminfo gelten nur für die Standardgröße von 2 MiB, also liest du den 1-GiB-Pool aus /sys. Starte seine dann im 1-GiB-Modus:

./seine --cpu-page-mode large-1g

In diesem Modus bildet jeder Thread seinen Speicherbereich aus dem 1-GiB-Pool ab, sodass du weißt, dass der ganze Lauf 1-GiB-Pages genutzt hat.

Wie reservierst du Huge Pages unter WSL2?

WSL2 läuft mit einem echten Linux-Kernel, also funktionieren die Linux-Befehle oben auch darin. Für 1-GiB-Pages übergibst du die Boot-Parameter auf der Windows-Seite über %UserProfile%\.wslconfig. Die VM braucht außerdem genug Speicher für die Reservierung plus die Dienste von Windows und WSL. Der validierte 64-GiB-Rechner von seine nutzte diese Einstellungen:

[wsl2]
memory=48GB
processors=32
swap=8GB
kernelCommandLine = hugepagesz=1G hugepages=18

Speichere die Datei, führe unter Windows wsl --shutdown aus und öffne deine Distribution erneut. Prüfe, ob die Zahl der freien Pages für alle Threads reicht, bevor du mit dem Mining beginnst.

Wie aktivierst du Large Pages unter Windows?

Natives Mining unter Windows ist auf derselben Hardware meist schneller als unter WSL, und seine nutzt dort die Large Pages von Windows. Dafür braucht es ein einziges Recht, Sperren von Seiten im Speicher (Lock pages in memory):

1. Öffne secpol.msc und dann Lokale Richtlinien → Zuweisen von Benutzerrechten.
2. Füge deinen Benutzer zu Sperren von Seiten im Speicher hinzu.
3. Melde dich ab und wieder an, da das Recht für neue Sitzungen gilt.

secpol.msc ist in Windows Pro, Enterprise und Education enthalten. Bei Home-Editionen vergibst du dasselbe Recht mit einem Tool wie ntrights.

Mehr Einrichtung ist nicht nötig. Beim Start aktiviert seine das Recht für sich selbst und legt den 2-GiB-Speicherbereich jedes Threads mit VirtualAlloc und MEM_LARGE_PAGES an, der Methode, die Microsoft für Large-Page-Speicher dokumentiert. Stehen keine Large Pages zur Verfügung, mint seine mit normalen Pages und protokolliert den Grund samt genauer Lösung. seine ändert nie selbst Kontorechte und meldet dich nie ab.

Welchen Page-Modus solltest du verwenden?

Der Standard passt für fast alle. Die anderen Modi sind für 1-GiB-Pages und für Messungen gedacht:

Um den Gewinn auf deinem eigenen Rechner zu messen, mine eine Weile mit --cpu-page-mode regular, dann mit auto oder large-1g, und vergleiche die Hashrate im Dashboard. Auf Servern mit mehreren NUMA-Nodes müssen die reservierten Pages außerdem auf den Nodes liegen, auf denen deine Threads laufen; die Anleitung zum Mining auf Servern erklärt das.