Will auch ohne Anführungszeichen nicht ... 
pihole checkout ftl fix/getClientsOverTime_only_active geht auch nicht...
Komisch, hier funktioniert es...
nanopi@nanopi:~$ pihole checkout ftl fix/MASTER_getClientsOverTime_only_active
[sudo] password for nanopi:
Please note that changing branches severely alters your Pi-hole subsystems
Features that work on the master branch, may not on a development branch
This feature is NOT supported unless a Pi-hole developer explicitly asks!
Have you read and understood this? [y/N] y
[✓] Branch fix/MASTER_getClientsOverTime_only_active exists
[✓] Downloading and Installing FTL
[✓] Restarting pihole-FTL service...
[✓] Enabling pihole-FTL service to start on reboot...
Gerade nochmals probiert. Funktioniert nicht.
master und release/v5.2 nimmt er anstandslos.
Bei mir geht die Befehl auch einwandfrei und die Version wird geladen.
Ach ja, wir sprechen ja hier über master ... der Build-Prozess hat sich verändert. @yubiuser benötigt vermutlich x86_64 (was derzeit geht), @guineapig braucht aber ARM(hf) was derzeit nicht geht.
@guineapig Bitte noch einmal versuchen. Hoffentlich funktioniert es jetzt.
Läuft 
Er nimmt sich immer noch etwas Zeit, aber die Verzögerung ist deutlich geringer.
Hattest du überhaupt die Lösung von @Bucking_Horn ausprobiert.
Bei mir wurde damit die Verzögerung gelöst und ich habe keine Verzögerung mehr.
Was hast du jetzt gemacht das es bei dir läuft, bzw welcher "Befeh" lief nun bei dir?
Ich würde die von mir genannten Schritte höchstens als Workaround bezeichen wollen. Daten aus der DB zu löschen, damit sie die Anzeuge nicht stören, ist ein ziemlich grobes Vorgehen.
Die SQL-Anweisungen waren zudem spezifisch für Deine Situation (in Bezug auf das Datum und die im WHERE...IN verwendeten IDs) und müssten bei wiederholter oder alternativer Verwendung jeweils vor Ausführung angepasst werden.
Der Fix von DL6ER kürzt die Anzahl der Clients für die graphische Aufbereitung um solche Einträge, die in den letzten 24 Stunden ohne Anfragen geblieben sind, ohne Informationen aus der DB zu löschen.
Wenn Du das testen möchtest, kannst Du das über den beschriebenen Checkout tun.
Oh ok verstanden danke
Ich habe eine allgemeine Frage zu dem Thema.
Das Verhalten in den beiden hier beschrienen Fällen scheint ja nicht typisch zu sein. Ist pi-hole für Anwender, bei denen etwas mehr im Netzwerk los ist, deswegen nicht optimal geeignet dafür? Ist es das erstemal, dass dieses Verhalten von pi-hole nun auffällt?
Gibt es von den Entwicklern Empfehlungen, wieviele Clients und Anfragen mit pi-hole genutzt werden kann?
Diese Frage lässt sich pauschal nicht seriös beantworten, sondern nur im Kontext der jeweils für Pi-hole verwendeten Hardware und des tatsächlichen Einsatzszenarios.
Sie ist außerdem zweigeteilt:
Die eigentliche DNS-Auflösung ist überhaupt nicht von der Anzahl der Clients abhängig, sondern allein von der absoluten Anzahl der Anfragen. Hier verfügt bereits ein RPi Zero über ausreichend Leistung, um tausende von Anfragen pro Minute zu behandeln - für ein durchschnitliches Heimnetz ist das auf jeden Fall ausreichend.
Die Darstellung der Weboberfläche ist ein separates Thema.
Hier geht es um die Aufbereitung von über einen bestimmten Zeitraum angesammelten Daten (für das Dashboard sind das 24 Stunden), und das kann je nach Datenmenge schon etwas Rechenaufwand erzeugen.
Durch Dein Topic haben wir gelernt, dass die von Pi-holes Weboberfläche für die graphische Aufbereitung verwendeten Ausgabe-Bibliotheken offensichtlich empfindlich für eine grössere (aber immer noch relatv überschaubare) Anzahl an Clients zu sein scheint. Der Flaschenhals ist also nicht Pi-holes DNS-Filterung oder die Datenbereitstellung, sondern die Darstellung.
Wenn der Fix hier einwandfrei greift, wäre dieser Engpass im Regelfall beseitigt, und dann würde das bestimmt mit einer der nächsten Pi-hole-Versionen ausgeliefert.
Danke und habe den Fix nun auch eingespielt und werde testen
Hallo,
habe ich ein Problem mit dem Fix?.
Wenn ich mir im Query-Log -show all- anzeigen lassen möchte, hängt sich das Webinterface auf. Es ist keine Bedienung mehr möglich.
Öffne ich dann ein zweites Browserfenster läuft wieder alles.
Der Effekt tritt bei mir auch auf! Aber nur bei "show all" aus der Überschrift.
Es dauert beim ersten Mal über 30 Sekunden, bis die Tabelle erscheint.
Weitere Versuche sind dann etwas schneller.
Die CPU-Auslastung des Pi ist nur anfangs hoch.
Der Fix hat diese Funktion gar nicht angefasst. Könnt ihr ausschließen, dass das Problem nicht auch schon vorher da war? Bei sehr aktiven Pi-holes ist es zu erwarten, dass das "show all" bis zu einer Ewigkeit brauchen kann. Da haben wir für Pi-hole v6.0 eine Lösung für (komplettes Redesign), aber das dauert noch ein paar Monate.
Nein das kann ich nicht ausschließen, da ich jetzt mehr als sonst getestet habe. Vermutlich ist es dann ein dummer Zufall. Klasse das es dafür auch bald eine Lösung geben wird.
Ich kann es auch nicht ausschliessen.
Rückmeldung
Mit dem Fix läuft alles perfekt und superschnell
1 Like
Das ist so nun auch schon in der regulären Version von Pi-hole enthalten, ich bitte um ein
pihole checkout master
sodass Ihr wieder mit allem auf den jeweils aktuellsten Versionen seid.
done 
Current Pi-hole version is v5.2.
Current AdminLTE version is v5.2.
Current FTL version is v5.3.1.
Danke für die tolle Hilfe hier und die schnelle Problemlösung! Klasse Projekt
Ein weiteres Update steht ins Haus, das die Performance noch ein bisschen verbessert.
2 Likes