Der Satz steht da, allein das Token fehlt. 
Grundsätzlich schon, wobei die Konfigurationsmöglichkeiten wiederum vom BS abhängen würden.
Es ist aber noch nicht klar, ob das in Deinem Fall etwas beitragen würde.
Pi-hole verbraucht während eines Gravity-Updates potentiell an zwei zusätzlichen Stellen RAM: Zum einen beim Aufbau des Suchbaums (Building tree), und zum anderen beim temporären Erstellen der bereinigten Domänenliste, für die der Suchbaum erstellt wird.
Ersteres läuft komplett im Hauptspeicher, während letzteres /tmp beansprucht, was nur dann RAM belegt, wenn /tmp (wie unter Armbian) als tmpfs eingebunden ist. Deine df- h-Ausgabe legt nahe, dass Debian Bullseye das nicht tut.
Bei einem laufenden Pi-hole wird außerdem /dev/shm von pihole-FTL genutzt, was als tmpfs ebenfalls RAM belegt. Der tatsächliche Bedarf dafür würde insbesondere von der Aktivität Deines Netzwerks abhängen: Viele Anfragen von vielen Clients würden in diesem Bereich zu höherem RAM-Bedarf führen.
Eine Anpassung von tmpfs würde nur Sinn machen, wenn Du während eines Gravity-Updates einen deutlich steigenden Verbrauch feststellst (dazu z.B. währenddessen wiederholt df -h -t tmpfs --total ausführen).
Wieviel RAM hat denn Dein Pi-hole Rechner?
Bei einer so massiv großen Anzahl von Blocklist-Domänen wie bei Dir kann RAM zum Engpaß werden, insbesondere auf RAM-limitierten Systemen wie RPis. Der Sinn der "Alles-Blocken"-Strategie wäre ein deutlich reduzierter RAM-Verbrauch, ohne dafür die Zahl der geblockten Domänen senken zu müssen.
Alternativ könntest Du auch yubiusers adlists tool laufen lassen, um mit den daraus gewonnenen Erkenntnissen Deine Blocklisten auf die für Dich sinnvollsten zu trimmen.