Surfen (vor allem Suchen) langsam. Was kann ich tun?

FastJimmy75 · March 28, 2023, 8:58am

Hallo liebe Community

Seit einiger Zeit nervt mich, dass surfen z.T. unschön langsam geworden ist. Vor allem fällt es mir bei Suchanfragen bei duckduckgo auf. Leider habe ich keine genaueren Zeitangaben, als gefühlt wurde es in den letzten 3 Monaten schlechter.

Ich habe also häufig geschaut ob es ein Update gibt in der Hoffnung, das Problem löst sich von selbst. Seit zwei drei Wochen schaue ich immer wieder mal ins Query Log, wenn es sehr mühsam langsam ist und sehe die Reply Zeiten von 500, 600, 700+ ist das normal?

Heute habe ich ausprobiert: DNS Upstream Server, Open DNS entfernt und nur Cloudflare – wurde nicht merklich besser, also hab ich den Open DNS wieder aktiviert.

Das pi-hole läut seit mehreren Jahren bestens auf einem Raspberry 3B v1.2, 1GB Ram, 32GB Speicherkarte. Raspbian GNU/Linux 10 (buster). Es ist zudem ein Plex-Server installiert, das hat bis jetzt aber problemlos geklappt, wird nur sporadisch im Heimnetzwerk genutzt.

Wie ihr bereits merkt, kenn ich mich mit dem RasPi, Linux und Pi-hole leider zu wenig aus und hoffe deshalb, dass ihr mir weiterhelfen könnt. Oder zumindest ein wenig die Richtung weisen, wo ich suchen muss.

Auf was achtet ihr z.B. beim checken des Debug-Logs?

Hier der Debug-Token:
https://tricorder.pi-hole.net/iVSQXUUe/

Vielen Dank fürs Zeit nehmen.
herzlich Mimir

Bucking_Horn · March 29, 2023, 6:31am

Das lässt sich nicht seriös beantworten, da die Latenz primär von Deiner Internetanbindung abhängt (und nachrangig ggf. von der Art der DNS-Auflösung).
Subjektiv scheinen die Zeiten schon sehr hoch, bei meiner DSL-Verbindung sind es im Durchschnitt ~42ms.

Das sollte sich objektiv mit Hilfe von Pi-holes Langzeit-Datenbank nachvollziehen lassen, z.B.
für die durchschnittliche Antwortzeit je Upstream-DNS-Server im letzten Monat:

pihole-FTL sqlite3 -header -column /etc/pihole/pihole-FTL.db "SELECT forward AS 'DNS Server', \
count(reply_time) AS 'Anzahl', round(avg(reply_time)*1000,1) AS 'Antwortzeit' \
FROM queries WHERE timestamp > strftime('%s', DATETIME('now','-1 month')) AND status==2 \
GROUP BY forward;"

im Vergleich zur durchschnittlichen Antwortzeit davor:

pihole-FTL sqlite3 -header -column /etc/pihole/pihole-FTL.db "SELECT forward AS 'DNS Server', \
count(reply_time) AS 'Anzahl', round(avg(reply_time)*1000,1) AS 'Antwortzeit' \
FROM queries WHERE timestamp <= strftime('%s', DATETIME('now','-1 month')) AND status==2 \
GROUP BY forward;"

Damit sollte sich herausfinden lassen, ob die Antwortzeiten der in Pi-hole konfigurierten Upstream-DNS-Server tatsächlich signifkant langsamer geworden sind.

Allerdings wäre durchaus fraglich, ob Deine DNS-Anfragen überhaupt über Pi-hole gehen.
Dein Debug Log zeigt, dass Dein Router zwei öffentliche IP-Adressen (UPC/Cablecom?) als DNS-Server verteilt:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 312 bytes from eth0:192.168.0.1
     Offered IP address: 192.168.0.83
     DHCP options:
      Message type: DHCPOFFER (2)
      router: 192.168.0.1
      dns-server: 62.2.17.60
      dns-server: 62.2.24.162
      --- end of options ---

Damit würden DHCP-Clients in Deinem Netzwerk weder Pi-hole noch Deinen Router für DNS-Anfragen verwenden. Deren DNS-Anfragen würden somit komplett an Pi-hole vorbeigehen.

Wie stellst Du sicher, dass Dein Netzwerk Pi-hole als DNS-Server verwendet?

wd9895 · March 29, 2023, 6:57am

Richtig konfiguriert sollte das Netzwerk schon sein.

Zum Testen der DNS Server kannst du GRC's | DNS Nameserver Performance Benchmark nutzen.
Trag deinen DNS des Provider dazu und dann hast du einen schnellen Vergleich.

Bucking_Horn · March 29, 2023, 7:12am

Das ist ein interessantes Tool, aber allgemeine synthetische Tests liefern nur eine Momentaufnahme und sind in diesem Fall gegenüber der echten Historie aus Pi-holes Langzeit-Datenbank klar im Nachteil.

Wenn geklärt ist, dass sich die Antwortzeiten tatsächlich verändert haben, kann es im zweiten Schritt bei der Auswahl eines alternativen DNS-Servers helfen, oder dabei, eine generell hohe Latenz der Internetverbindung festzustellen.

FastJimmy75 · March 29, 2023, 1:15pm

Zuerst, DANKE euch beiden Bucking_Horn und wd9895 fürs Zeitnehmen!

Zu meinem Setup: Ich habe den Pi am Router (Standard UPC/Cablecom Modem) und auf allen Geräten, die das Pi-hole nutzen sollen, trage ich es als DNS-Server ein. Und ich meine, dass es so auch ordentlich funktioniert (hat), seit mehreren Jahren – da viel weniger Werbung, wenn es an ist, und ich ja auch die geblockten Anfragen im Query-Log sehen kann.

Bucking_Horns Input – Langzeit-Datenbank Test:

wd9895s Input bzgl. Nameserver Benchmark:

Ich glaube ihr habt mir einen super Input gegeben und ich habe am falschen Ort gesucht.

Wenn ich es richtig verstehe, läuft das Pi-Hole korrekt und macht was es soll. Und entweder das Modem oder die Verkabelung bis zum iMac haben ein Problem. Was mich noch stutzig macht ist, wieso es immer wieder Messungen beim DNS-Benchmark hat, die normal sind 22ms, 46ms usw. und dann wieder die langsamen.

Oder was denkt ihr?

Beste Grüsse, M

Bucking_Horn · March 30, 2023, 5:55am

Pi-holes Langzeit-Datenbank zeigt, dass es im letzten Monat im Vergleich zu früheren Zeiten zumindest keine signifikante Verschlechterung bei der Antwortzeit gegeben hat. Im Schnitt liegt diese bei Dir zwischen 450 und 500ms. Die Anzahl (~300.000 für den letzten Monat vs. 26.000 restliche Zeit) lässt allerdings vermuten, dass in Pi-holes DB auch nicht viel mehr als ein Monat gespeichert ist.

Die Auswertung zeigt außerdem, dass die Antwortzeit über alle verwendeten Upstream-DNS-Server vergleichbar lahm ist. Das spricht generell für eine hohe Latenz der Internetanbindung Deiner Pi-hole-Maschine.

Die wohl ebenfalls auf dem RPi ausgeführten DNS-Benchmarks bestätigen das.
Sie zeigen außerdem, dass Pi-holes Caching (192.168.0.100) die hohen Latenzen innerhalb Deines Netzwerks deutlich auf etwa ~120ms reduziert.
Auf Dein ping hat Pi-holes Caching kaum einen Einfluss, da Pi-hole nur (und nur u.U.) an der Namensauflösung beteiligt ist. Bei einem ping auf eine IP-Adresse wäre Pi-hole überhaupt nicht beteiligt.

Generell ist ping kein geeignetes Tool für die DNS-Analyse (da sind dig oder nslookup die Mittel der Wahl).

In diesem Fall haben wir es aber mit hohen Latenzen zu tun, und da passt ping:
Braucht ein ping zu den IPs der Pi-hole-Upstream-Resolver von anderen Rechnern in Deinem Netzwerk aus (z.B. vom Mac-Rechner) auch um die 500ms?

Falls ja, sitzt Du wohl an einem hochlatenten Internet-Zugang.
Wie bist Du ans Internet angebunden (DSL, LTE, Satellit)?

Falls nein, solltest Du die Netzwerkanbindung Deines Pi-hole überprüfen.
Ich würde dabei zunächst die Router-/Firewall-Einstellungen unter die Lupe nehmen, selbiges gälte für eventuell vorhandene Switches.
Ein defektes Kabel halte ich eher für unwahrscheinlich, da die lokalen Latenzen vom Mac zu Pi-hole mit <1ms erwartet niedrig ausfallen.
Vielleicht schickst Du Deinen öffentlichen Netzwerk-Verkehr aber auch über ein VPN?
Das könnte durchaus einen Einfluss haben.

Alles in allem sieht das aber nicht nach einem Pi-hole-Problem aus.
Für weitergehende Hilfe solltest Du daher auch andere einschlägige Foren in Betracht ziehen.

Und noch eine Anmerkung zu Deiner Router-Konfiguration (klicken für mehr)

Laut Debug Log verfügt Dein Netzwerk zumindest über link-lokale IPv6-Anbindung.
Falls Dein Router seine link-lokale IPv6-Adresse als lokalen DNS-Server offeriert (über SLAAC/NDP/RA/RNDSS oder Stateless DHCPv6)), könnten IPv6-fähige Clients Pi-hole zeitweise oder komplett über diese IPv6 umgehen - auch solche, auf denen Du manuell Pi-holes IPv4-Adresse eingetragen hast.

Das solltest Du in Deinem Router überprüfen, auch wenn das in Deinem Fall nichts mit der hohen Latenz zu tun hat.

FastJimmy75 · March 30, 2023, 5:06pm

Nein nicht ganz. Alle DNS-Benchmarks habe ich vom Mac aus, entweder mit oder ohne pi-hole dazwischen gmacht.

Danke. Good to know.

Die Pings waren alle vom Mac aus. (Und weil die Pings ab der 2. Messung jeweils "normal" schnell waren, dachte ich, dies sei wegen dem Pi-hole-cache...)

hier zwei neue von gerade eben:
Mac zu Quad9

@iMacM ~ % ping -c 5 9.9.9.9
PING 9.9.9.9 (9.9.9.9): 56 data bytes
64 bytes from 9.9.9.9: icmp_seq=0 ttl=58 time=594.635 ms
64 bytes from 9.9.9.9: icmp_seq=1 ttl=58 time=23.100 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=58 time=10.789 ms
64 bytes from 9.9.9.9: icmp_seq=3 ttl=58 time=10.547 ms
64 bytes from 9.9.9.9: icmp_seq=4 ttl=58 time=13.119 ms

--- 9.9.9.9 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.547/130.438/594.635/232.144 ms

Raspi zu Quad9

pi@raspberrypi:~ $ ping -c 5 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
64 bytes from 9.9.9.9: icmp_seq=1 ttl=58 time=546 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=58 time=25.7 ms
64 bytes from 9.9.9.9: icmp_seq=3 ttl=58 time=10.4 ms
64 bytes from 9.9.9.9: icmp_seq=4 ttl=58 time=10.7 ms
64 bytes from 9.9.9.9: icmp_seq=5 ttl=58 time=12.8 ms

--- 9.9.9.9 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 11ms
rtt min/avg/max/mdev = 10.389/121.052/545.598/212.348 ms

Kabelanschluss, war bis anhin eigentlich immer ganz flott

Mach ich. Danke für den Tipp.

Und danke für diesen Tipp. Hab ich eben gemacht, aber ich sehe in meinem Router nicht eine Erwähnung zu IPv6... und nur IPv4 Adressen. Könnte es auch mit dieser Pi-hole Einstellungen zu tun haben? Ich hab sie drin gehabt und rausgenommen, weil ich dachte, dass ich kein IPv6 habe... und jetzt wieder eingeschaltet.

Auf jeden Fall. Vielen Dank für deine Hilfe! Als nächstes werd ich wohl mal mit dem Provider reden.

herzlich M

Bucking_Horn · March 30, 2023, 5:20pm

Deine Screenshots zeigen für dnsperftest ein Mac-Terminal für pi@raspberrypi.
Der ausführende Rechner wäre demnach raspberrypi.
Ist raspberrypi nicht der Rechner, auf dem Pi-hole läuft?

Hmm, das sollte normalerweise keinen Einfluss haben, könnte in Deinem Fall aber vielleicht nützlich sein.

Du könntest prüfen, ob für Deinen ISP die Verbindung über IPv6 vielleicht besser läuft.

Das sollte sich mit einem ping auf die entsprechenden IPv6-Adressen überprüfen lassen.
Diese werden als Hover angezeigt, wenn Du den Mauszeiger eine Weile über dem entsprechenden Kontrollkästchen hältst.

FastJimmy75 · March 31, 2023, 9:21am

Nein es stimmt schon, es sind alle Test vom Mac aus gemacht die nicht explizit pi@raspberrypi im Bild haben. Ich war davor per SSH verbunden und nach dem Ausloggen wechselt der Fenstername nicht zurück. Das ist vermutlich ein kleiner Bug vom Mac Terminal.

pi@raspberrypi:~ $ ping6 2606:4700:4700::1111
connect: Das Netzwerk ist nicht erreichbar
pi@raspberrypi:~ $ ping 2606:4700:4700::1111
connect: Das Netzwerk ist nicht erreichbar

Auch auf dem Mac kann ich kein ping zu einer IPv6 Adresse durchführen

@iMac ~ % ping6 2606:4700:4700::1111
ping6: UDP connect: No route to host

Heisst das, dass ich kein IPv6 habe?

Ich habe gestern auch noch im Forum des Providers einen Thread entdeckt, wo jemand ein ähnlich Problem zu haben scheint, da wurde dann ein neues Modem verschickt. Das werde ich wohl auch mal versuchen...

Bucking_Horn · March 31, 2023, 9:50am

Ja, Dein ISP bietet Dir kein IPv6.
Das hat das Debug Log auch schon angedeutet.

Ah, dann wäre es sinnvoll, dass zukünftig jeweils klar zu machen (damit zumindest ich nichts falsch interpretiere).
Noch lieber sind uns textuelle Ausgaben - die nehmen weniger Platz weg und erlauben uns, schnell Teile daraus zu kopieren und sofort in der Antwort zu verwenden. Ist jetzt hier egal, aber für eventuelle zukünftige Posts wäre das nützlich.

Bandbreite und Latenz sind verschiedene Dinge.
Du kannst 250Mbit/s im Download haben - mit Deiner Latenz von 500ms werden Dir trotzdem Verzögerungen auffallen.

Es ist schon sehr auffällig, dass das erste ping immer eine sehr hohe Latenz hat und 20- bis 50-fach über den folgenden Zeiten liegt.

Wenn Du Dich an Deinen Provider wendest, dann verwende als Diagnosebeispiel diese direkten pings auf IPs - dann kann der erst gar nicht auf die Idee kommen, es läge an Deinem DNS, und Dich damit abzuwimmeln versuchen.

system · April 21, 2023, 9:50am

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.