vorweg, ich bin beeindruckt von v6.x und ziehe meinen Hut vor dieser ganzen Arbeit.
Respekt.
Ich habe an mehreren Orten in der Verwandschaft jeweils 1-2 Raspberrys mit Pi-hole (v5).
Gestern habe ich zwecks Test das Pi-hole meines Raspberry Zero2 (4-Core m. 512MB RAM) auf v6.x upgedatet.
Ergebnis war, dass die WeboberflĂ€che nur sehr, sehr zĂ€h, wenn ĂŒberhaupt, erreichbar war. Ein Blick in die Konsole (top) zeigte, dass der pihole-FTL bei rund 50-60% lief. Load Average ging auf 2-3 hoch. Lt. htop war aber die CPU nicht voll beschĂ€ftigt. Auch RAM war noch genug da. Auf der Konsole spĂŒrte man eine Verzögerung bei Eingaben, ca. eine Antwortzeit von 500 bis 1000ms.
Ich vermutete die hohe Anzahl an Blockdomains (18 Mio.).
Erster Versuch:
Ich deinstallierte das Pi-hole und installierte es neu. Dann fĂŒgte ich Blocklisten fĂŒr 12 Mio. Domains ein und machte ein Gravity. Am Ende das gleiche Spiel, RAM war ok, CPU lief bei 30-40%, der Dienst pihole-FTL zeigte fĂŒr sich alleine 50-60% und die WeboberflĂ€che war schlecht erreichbar.
Zweiter Versuch:
Gleiches Spiel noch mal, Pi-hole runter, wieder rauf und Blocklisten fĂŒr ca. 8 Mio. Domains rein. Nun lĂ€uft das System rund, sprich kaum CPU-Last, pihole-FTL unauffĂ€llig (0,7 bis 1,3% CPU-Last) und die WeboberflĂ€che lĂ€uft einwandfrei.
RĂŒckblick zur v5:
Hier lief das Pi-hole auf dem gleichen System mit bis zu 22 Mio. Blockdomains einwandfrei.
Irgendwelche Ideen woran es liegt?
Gerne kann ich auch noch mal 12 Mio. einwerfen und versuchen einen Token zu erstellen. Aber wie gesagt, die WeboberflÀche ist da recht zickig.
Ich scheine dem Problem auf die Spur gekommen zu sein.
Das waren die Voraussetzungen:
RAM => 512MB
Swap => 500MB
Beim Gravity, genau beim "Building tree" wird der RAM stĂŒckweise immer mehr belastet. Wenn der RAM voll ist, beginnt sich der Swap zu fĂŒllen. Wenn der voll ist, bricht das Gravity inkl. Fehlermeldung ab.
Ich hÀtte nun erwartet, dass das Pi-hole wieder die alte DB verwendet und alle bis zu diesem Punkt generierten Daten verwirft.
Dem scheint aber nicht so, da die Anzahl der geblockten Domains sich Ă€ndert. Ab diesem Zeitpunkt spielt dann der FTL verrĂŒckt (CPU-Last) und verursacht die Probleme.
Meine laienhafte Annahme: Die Daten in der DB sind nicht schlĂŒssig und der FTL dreht sich irgendwo im Kreis.
Folgendes habe ich nun gemacht:
Ich habe den Swap auf 2000MB erhöht und Gravity wieder angestoĂen. Und siehe da, er lĂ€uft ohne Fehlermeldung durch. WĂ€hrend dieses Durchlaufs nimmt er sich wieder den gesamten RAM und ca. 1200MB Swap. Nach dem Durchlauf ist der Swap und der RAM wieder frei.
Pi-hole lÀuft mit 20 Mio. Blockdomains, nimmt kaum RAM und macht keine CPU-Last mehr.
Ich nutze Pi-hole nicht nur fĂŒr das Blocken von Werbung und Tracking, sondern auch fĂŒr Porno, wovon es eine Menge gibt.
By the way: In einem anderen Thread ist einer mit 50 Mio. Blockdomains. Und das funktioniert auch.
Unter Pi-hole v5 lief das seit wirklich langer Zeit problemlos. Gravity hat das System 1x Woche gemacht und das lief auch recht zĂŒgig durch.
Musste ebenso bei einem LXC Container Ram auf 2GB und SWAP erhöhen.
Gravity lÀuft jetzt ohne Problem durch, aber nach kurzer Zeit wird ein 1 CPU Kern permanent mit 100% ausgelastet und die WeboberflÀche sehr zÀh.
In TOP werden mir 8 FTL Prozesse angezeigt, wovon einer zu 100% ausgelastet ist. Bei einem Pi4 der anstandslos mit derselben Config lĂ€uft sehe ich dort nur 2 FTL Prozesse mit der ĂŒblichen niedrigen Auslastung.
webserver.threads auf 3 zu erhöhen bringt nur am Anfang etwas ...
Bist du dir da sicher?
Das sah bei mir auch so aus, aber da sind Fehlermeldungen am Ende vom Gravity (Konsole).
Ich habe daher eine Konsole mit dem Gravity laufen lassen, gleichzeitig eine Konsole mit htop bzw. top. Da sieht man, wenn der Swap volllaufen sollte. Wenn er volllÀuft, hatte ich das Problem mit der CPU-Last. Wenn der Swap nicht volllÀuft, habe ich kein Problem mit der CPU-Last.
Meine laienhafte Vermutung:
Der Fehler wird nicht abgefangen und die kompromittierte Datenbank wird ĂŒbernommen.
