Nach längerer Nutzung des PI-Hole läuft die Speichernutzung langsam Voll!

Das sieht aus, als sei die Seite in Google Chrome vom Browser in Deutsch übersetzt worden. Sieht bei mir auch so aus wenn ich das anklicke.

Ich verwende keine Dritt-Patei-Modi es ist eine Darstellungsform die von Google Chrome angeboten wird. Rechte Maustaste „Auf deutsch übersetzen“ ist aber nur eine Darstellungsanzeige tippe ich auf englisch ist die Seite wieder in Original auf dem Monitor zu sehen. Mit dem Tool Generate Debug Log muss ich erst mit befassen (wie schon gesagt Anfänger in Sachen Linux)

Mfg WilDam48

Screenshot 2021-05-22 10.44.35.png

Ich denke, dein Fettdruck soll kein Geschrei sein, sondern ist versehentlich passiert. :wink:
Das Debug-Log erzeugst du unter Settings/Einstellungen -> Erzeuge / Geneate debug Log.
Das Log wird automatisch hochgeladen; die LOG-ID, die dir angezeigt wird, postest du hier.
Das Log wird später automatisch gelöscht.

Eine Idee habe ich: Kann es sein, dass das Übersetzen langsam den Speicher füllt?
Wenn du nur das OS und nur pihole am Laufen hast, fällt mir sonst nichts mehr ein. Aber dafür gibt es hier ja die Entwickler :slight_smile:

Hallo Gert_Chlupaty,

sorry der Fettdruck kam von copy + pase.

Probleme beim Debug-Log erzeugen „Settings“ finde ich ja noch aber „Einstellungen“ ? fehlt.

Wie du in dem Screenshot siehst habe ich nicht auf deutsch Anzeige umgestellt sieht genauso aus ,

außerdem habe ich den PC auch nicht immer an, und Pi-Hole mit der Anzeige auch nicht, nur mal zur Kontrolle.

Der Raspi steht im Keller (schön kühl) und ich schaue über den PC Browser ab und zu mal drauf.

Ich hoffe du kannst mir bei der Debug-Log noch helfen

Mfg WilDam48

6 posts were split to a new topic: Raspberry Pi Temperatures

Sorry, ich meinte Tools, dort der vorletzte Punkt -generate debug log-.
Mein Pi 3 hat im Wohnzimmer in einem Fach 47,2° Temperatur.

Debug-log wurde gestarten schauen wir mal morgen.

Mein Pi 3b hat keine passiven oder aktive Kühler.

Hilfe

Wie geht es jetzt weiter?

Ich habe die LOG-Datei gestartet aber es tut sich nichts!

Wie beende ich die Aufzeichnung und wo steht dann die LOG-Datei

Die ich schicken soll.

Wer kann mir helfen?

Mfg WilDam48

Lesen hilft! Dort steht doch, dass du das Log generieren kannst. Einfach draufklicken!!
Danach bekommst du die Log-ID, die du dann hier postest.

1 Like

Der Übersetzer läuft ja nur im Browser, hat also keinen Einfluss auf die Speichernutzung des Servers.

Da es sich nicht um ein Netzwerkproblem handelt, liefert der debug upload möglichweise nicht die passenden Infos, aber trotzdem sollte da mal jemand drüber schauen.

Aber die Idee mit htop war gut: Starte mal htop von einer console ist SSH, mache ein screenshot von der Anzeige und poste es hier (nachdem du ggf. identifizieren Inhalte unkenntlich gemacht hast). Da sollten wir sehen können welcher Prozess viel RAM nutzt.

Äußerem kann ein tmpfs verantwortlich sein. Führe mal den folgenden Befehle aus und poste dessen Ausgabe hier:

df | grep tmpfs

Welches OS nutzt du eigentlich? Raspberry Pi OS? Mit Desktop oder Lite?

Sorry hatte übersehen den Harken zusetzen.

Hier ist der Debug-Token ich hoffe er hilft weiter.

Mfg WilDam48

Hey

Anbei eine 1 Screenshot ausgabe von htop.

2 Screenshot ausgabe von df | grep tmpfs.

Zu der Frage welches OS ich benutze Ich habe die Lite Version installiert da hier nur der Pi-Hole

Darauf läuft und ich Linux Anfänger bin.

Ich hoffe ich konnte euch weiter helfen.

Mfg WilDam48

Du musst nicht nur den Haken setzen, sondern danach auf die große Schaltfläche "Generate debug log" klicken. Am Ende wird dir dann ein Link mit einem Token (Zahlen/Buchstabenkombi) angezeigt, diesen musst du hier posten.

Habe ich so gemacht und euch zu gesendet.

Von meinem/meiner Galaxy gesendet

Dann poste bitte hier den debug Token der dir angezeigt wurde, damit der zugehörige upload auch gefunden werden kann.

Zum htop:
Das schaut doch alles sehr normal aus, passt auch zu den ~20% die ja jetzt in Pi-hole angezeigt werden ("RES" Spalte und grüner Teil des Balkens sind relevant). Du sagtest Raspberry Pi OS Lite, aber ein Desktop ist ja installiert und läuft auch, so wie wenn gerade aktiv jemand eingeloggt ist. Ohne autologin wären das vielleicht 50 MiB weniger, ohne Desktop (man kann ja auch den Login-Manager und damit den X Server Start komplett deaktivierten, oder deinstallieren) über 100 MiB weniger. Aber bisher ist es ja alles andere als knapp.

tmpfs RAM Speicher sind ebenfalls keine unerwarteten.

Sollte das nun weiter ansteigen, kannst du ja bei 50% oder so noch einmal beides checken und ggf posten, dann sollte man denn verantwortlichen Prozess/tmpfs sehen.

Sorry hatte übersehen den Harken zusetzen.

Hier ist der Debug-Token ich hoffe er hilft weiter.

Mfg WilDam48

image001.jpg

Die Nummer des Tokens fehlt!

Nummer ? Ich habe keine Nummer

Aber ich sende dir die LOG-Datei als TXT Datei.

Vielleicht reicht das ja.

Oder du musst mir die Nummer sagen wo sie steht.

Mfg WilDam48

Generate-debug-log.txt (42.9 KB)



image001.jpg

|

Gert_Chlupaty
May 25

|

  • | - |

Die Nummer des Tokens fehlt!

Nummer ? Ich habe keine Nummer

Aber ich sende dir die LOG-Datei als TXT Datei.

Vielleicht reicht das ja.

Oder du musst mir die Nummer sagen wo sie steht.

Mfg WilDam48

Generate-debug-log.txt (42.9 KB)

The idea behind the debug upload is that you don't need to make it readable to everyone but only to authorised people from the Pi-hole team. When you hit the "Generate debug log" button, you should be shown a random string, to post here. Pi-hole team guys can then find and read the full log, but not users like me that might be able to use the info to hack into your system or so :wink:. But so far I couldn't see some problematic info (public IP address or hostname).

Here is the debug token (from the end of the log): r8cft8cigk
So you may want to remove the files again from here, just to be sure :wink:.


PIHOLE_DNS_1=127.0.0.1#5353

Does it mean you have Unbound or another local DNS server running which Pi-hole uses as upstream? Ah lol, the htop screenshot shows Unbound. 16 MiB RAM usage, that is okay.

Aside of two failures which seem like bugs in the debug script itself (resolving IPv6 hostname via upstream DNS and blocking page X header), everything looks pretty fine. As said, now RAM usage is perfectly fine as well, but when it raises over time, check htop and df again whether you can identify the process or tmpfs that uses that unexpected large amount of memory.