Adguard LXC 100% Auslastung auf Proxmox

R

Ronny1978

Member
Mar 13, 2023
68
16
8
Hallo Zusammen,

leider ist es mir jetzt innerhalb 2 Wochen schon 3x passiert, dass mein DNS nicht mehr funktioniert. Nach kurzer Suche habe ich gemerkt, dass der Adguard im LCX Container auf 100% Auslastung war. Ich habe den Container neu gestartet und dann ging es wieder. Aber das ist ja keine Lösung. Habt jemand auch schon einmal das Problem bemerkt?

Gibt es eine Fehlerursache oder noch schöner, eine Lösung?

Folgendes ist mir im Syslog aufgefallen:

Code: 
Jul 01 11:21:01 pve audit[3760945]: AVC apparmor="STATUS" operation="profile_load" profile="/usr/bin/lxc-start" name="lxc-102_</var/lib/lxc>" pid=3760945 comm="apparmor_parser"
Jul 01 11:21:01 pve kernel: audit: type=1400 audit(1688203261.403:47): apparmor="STATUS" operation="profile_load" profile="/usr/bin/lxc-start" name="lxc-102_</var/lib/lxc>" pid=3760945 comm="apparmor_parser"
Jul 01 11:21:01 pve systemd-udevd[3760738]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jul 01 11:21:01 pve systemd-udevd[3760738]: Using default interface naming scheme 'v247'.
Jul 01 11:21:01 pve systemd-udevd[3760738]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jul 01 11:21:01 pve systemd-udevd[3760738]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jul 01 11:21:01 pve systemd-udevd[3760977]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jul 01 11:21:01 pve systemd-udevd[3760977]: Using default interface naming scheme 'v247'.
Jul 01 11:21:01 pve kernel: vmbr1: port 3(fwpr102p0) entered blocking state
Jul 01 11:21:01 pve kernel: vmbr1: port 3(fwpr102p0) entered disabled state
Jul 01 11:21:01 pve kernel: device fwpr102p0 entered promiscuous mode
Jul 01 11:21:01 pve kernel: vmbr1: port 3(fwpr102p0) entered blocking state
Jul 01 11:21:01 pve kernel: vmbr1: port 3(fwpr102p0) entered forwarding state
Jul 01 11:21:01 pve kernel: fwbr102i0: port 1(fwln102i0) entered blocking state
Jul 01 11:21:01 pve kernel: fwbr102i0: port 1(fwln102i0) entered disabled state
Jul 01 11:21:01 pve kernel: device fwln102i0 entered promiscuous mode
Jul 01 11:21:01 pve kernel: fwbr102i0: port 1(fwln102i0) entered blocking state
Jul 01 11:21:01 pve kernel: fwbr102i0: port 1(fwln102i0) entered forwarding state
Jul 01 11:21:01 pve kernel: fwbr102i0: port 2(veth102i0) entered blocking state
Jul 01 11:21:01 pve kernel: fwbr102i0: port 2(veth102i0) entered disabled state
Jul 01 11:21:01 pve kernel: device veth102i0 entered promiscuous mode
Jul 01 11:21:01 pve kernel: eth0: renamed from vethtKcPLb

Code: 
Jul 01 11:20:16 pve systemd-udevd[3758882]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jul 01 11:20:16 pve systemd-udevd[3758882]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jul 01 11:20:16 pve systemd-udevd[3758905]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jul 01 11:20:16 pve systemd-udevd[3758905]: Using default interface naming scheme 'v247'.

Mache ich hier etwas falsch?

Danke für eure Hilfe.

Ronny

P.S. Ich habe jetzt auch den Unifi Controller mal neu gestartet, aber dort eigentlich keine Auffälligkeiten entdeckt.

Virtual Environment 7.4-15
 
Hat jemand eine Idee? Gestern Abend 19.04 Uhr war es wieder soweit. Adguard war bei 100% CPU Auslastung und beim DNS ging nix mehr. :oops:

Danke für eure Hilfe.
 
Kannst du mal die Container Config postern? (cat /etc/pve/lxc/102.conf)
 
Code: 
arch: amd64
cores: 1
features: keyctl=1,nesting=1
hostname: Adguard
memory: 1024
nameserver: 10.0.80.1
net0: name=eth0,bridge=vmbr1,firewall=1,gw=10.0.80.1,hwaddr=7E:EE:B5:3A:5D:29,ip=10.0.80.2/24,tag=80,type=veth
onboot: 1
ostype: debian
parent: Update-2023-06-08
rootfs: local-zfs:subvol-102-disk-0,size=4G
searchdomain: 10.0.80.1
startup: order=3
swap: 1024
tags: adguard
unprivileged: 1

[Erstinstallation]
arch: amd64
cores: 1
features: nesting=1
hostname: Adguard
memory: 1024
nameserver: 10.0.80.1
net0: name=eth0,bridge=vmbr1,firewall=1,gw=10.0.80.1,hwaddr=7E:EE:B5:3A:5D:29,ip=10.0.80.2/24,tag=80,type=veth
ostype: debian
rootfs: local-zfs:subvol-102-disk-0,size=4G
searchdomain: 10.0.80.1
snaptime: 1682848972
swap: 1024
tags: adguard
unprivileged: 1

[Update-2023-06-08]
#vor dem Update
arch: amd64
cores: 1
features: keyctl=1,nesting=1
hostname: Adguard
memory: 1024
nameserver: 10.0.80.1
net0: name=eth0,bridge=vmbr1,firewall=1,gw=10.0.80.1,hwaddr=7E:EE:B5:3A:5D:29,ip=10.0.80.2/24,tag=80,type=veth
onboot: 1
ostype: debian
parent: Erstinstallation
rootfs: local-zfs:subvol-102-disk-0,size=4G
searchdomain: 10.0.80.1
snaptime: 1686247015
startup: order=3
swap: 1024
tags: adguard
unprivileged: 1
 
Hmm... du hast da nur 1 Core eingestellt. Ich weiß nicht wie hungrig Adguard ist aber kann es sein das es einfach zu wenig CPU bekommt? Hast du mal versucht 2 cores bereitzustellen?
 
Hallo Philipp,

kann ich machen. Aber die Empfehlung von Adguard Home sagt 1 Core und 512 MB RAM. Im Normalfall bewegt sich die Auslastung bei 1% oder unter 1%.

Ich denke daran liegt es nicht. Die Auslastung steigt irgendwann sprunghaft auf 100% und dann geht nichts mehr. Mehrere Tage läuft es aber normal.

Danke weiterhin für eure Tipps.

Adguard.png
 
hmm... versuch mal wenn es das nächste mal hängt

Code: 
journalctl --since=YYYY-MM-DD HH:MM:SS

mit einen Zeitpunkt vor den aufhängen
 
Hallo Philipp,

danke für deinen Tipp ;). Das werde ich tun. Da Adguard, die Windows VM, Home Assistant, RustDesk und die MariaDB über eine 2. LAN Schnittstelle laufen, habe ich diese LAN jetzt im PVE fest auf die 172.16.1.200 eingestellt. Den Haken bei Firewall im Adguard LXC habe ich zusätzlich deaktiviert. VLAN aware ist bei dieser LAN angehakt.

Ich schaue beim nächsten Mal, ob auch erhöhter Traffic auf den Adguard "knallt" und ihn in die Knie zwingt. Was für mich noch ein Rätsel ist, ist, dass Adguard durchgehend läuft, obwohl nicht mehr Netzwerkgeräte vorhanden sind. Die Auslastung liegt immer zwischen 0-2% beim Core und ca. 100 MB RAM.

Ich halte dich/euch auf dem Laufenden. Und nochmals danke für die Unterstützung.

Ronny

P.S. Und natürlich eine wunderschöne und gesunde Woche.
 
Code: 
AdGuard Home v0.107.34 Neueste
Diese Version verbessert die Sicherheit von AdGuard Home und behebt einige größere Probleme.

Sicheres Surfen und CPU-Spitzen
Bereits im Juni haben wir ein Sicherheitsupdate für AdGuard Home mit einigen Bugfixes veröffentlicht. Ironischerweise verursachte es einen weiteren Fehler. Safe Browsing und Kindersicherung funktionierten seitdem nicht mehr richtig, was in einigen Fällen zu Leistungseinbußen, zufälligen Abstürzen und enormen CPU-Spitzen führte.

Vielleicht hat sich damit mein Problem erübrigt. Das würde auch erklären, warum der Fehler erst seit ein paar Wochen aufgefallen ist. ;) Ich bleibe hier dran und werde weiter berichten, ob der Fehler damit weg ist.
 
Hallo,

ich hatte in den vergangenen 5 Tagen ein ähnliches Verhalten: Ram voll und CPU des LXCs auch auf 100%.

@Ronny1978: Hast Du es final fixen können?

Mein LXC ist geupdatet, aber das Problem bleibt bestehen.
 
Hallo @nitrosont,

poste bitte mal:
  • Deine AdGuard Home Version (AdGuardHome --version im Container)
  • Die Container-Config (cat /etc/pve/lxc/<CTID>.conf)
  • Ob Safe Browsing und/oder Kindersicherung in AdGuard aktiviert sind
Wenn es das nächste Mal passiert, bevor du den Container neustartest:
Code: 
# Im Container schauen, was die CPU frisst:
top -b -n1 | head -20

# AdGuard-Logs prüfen:
journalctl -u AdGuardHome --since "1 hour ago" --no-pager | tail -100

# Query-Log auf Auffälligkeiten prüfen (DNS-Loop? Ein Client mit extrem vielen Queries?):
# → AdGuard Web-UI → Query Log → nach Zeitraum filtern
Häufigste Ursachen neben dem Safe-Browsing-Bug aus v0.107.34:
  • DNS-Loop — wenn der Container sich selbst als DNS nutzt oder der Upstream-DNS zurück auf AdGuard zeigt. Prüfe cat /etc/resolv.conf im Container und die Upstream-DNS-Einstellungen in der AdGuard-UI.
  • Ein Gerät im Netz, das massenhaft DNS-Queries erzeugt (IoT, defektes Smart-Home-Gerät etc.) — das Query-Log zeigt das sofort.
@Ronny1978 — hat das Update auf v0.107.34 das Problem bei dir dauerhaft gelöst?
 
Vielen Dank für die konkreten Tipps!

Meine Rückmeldungen dazu:
  • Deine AdGuard Home Version (AdGuardHome --version im Container)
Click to expand...
Code: 
Version: v0.107.72

  • Die Container-Config (cat /etc/pve/lxc/<CTID>.conf)
Click to expand...

Code: 
root@pve0:~$cat /etc/pve/lxc/231.conf 
#<div align='center'>AdGuard LXC
#</div>
arch: amd64
cores: 1
features: keyctl=1,nesting=1
hostname: adguard
memory: 256
net0: name=eth0,bridge=vmbr0,gw=192.168.101.244,hwaddr=bc:24:22:bc:23:13,ip=192.168.101.231/24,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-231-disk-0,size=10G
swap: 256
tags: system
unprivileged: 1

  • Ob Safe Browsing und/oder Kindersicherung in AdGuard aktiviert sind
Click to expand...
Safe Browsing und/oder Kindersicherung: sind beide nicht aktiv.

Im Container schauen, was die CPU frisst
Click to expand...

Code: 
root@adguard:~#top -b -n1 | head -20
top - 21:04:03 up 1 day, 12 min,  1 user,  load average: 3.31, 2.20, 1.59
Tasks:  17 total,   1 running,  16 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.1 us, 82.3 sy,  0.0 ni,  0.0 id, 14.8 wa,  0.0 hi,  0.1 si,  0.0 st 
MiB Mem :    256.0 total,      1.2 free,    253.3 used,      1.5 buff/cache     
MiB Swap:    256.0 total,      0.1 free,    255.9 used.      2.7 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    137 root      20   0 1739964 234276    128 S  44.7  89.4   8:46.51 AdGuard+
   4056 root      20   0    8448   2016    132 R  31.2   0.8   0:10.24 top
      1 root      20   0  167972    844      4 S   2.5   0.3   0:08.30 systemd
   1916 root      20   0   32976    132      4 S   0.3   0.1   0:00.64 systemd+
    105 root      20   0    3612     92      4 S   0.0   0.0   0:00.30 cron
    107 message+  20   0    9380    340      8 S   0.0   0.1   0:00.33 dbus-da+
    112 root      20   0   16592    136      4 S   0.0   0.1   0:00.41 systemd+
    129 root      20   0    2528    104      4 S   0.0   0.0   0:00.00 agetty
    130 root      20   0    6136     12      4 S   0.0   0.0   0:00.01 login
    131 root      20   0    2528     88      4 S   0.0   0.0   0:00.00 agetty
    285 root      20   0   42676    104      4 S   0.0   0.0   0:00.51 master
    287 postfix   20   0   43104     80      4 S   0.0   0.0   0:00.11 qmgr
    302 root      20   0    6400    312      4 S   0.0   0.1   0:00.11 bash


zu diesen Punkten:
# AdGuard-Logs prüfen:
journalctl -u AdGuardHome --since "1 hour ago" --no-pager | tail -100
# Query-Log auf Auffälligkeiten prüfen (DNS-Loop? Ein Client mit extrem vielen Queries?):
# → AdGuard Web-UI → Query Log → nach Zeitraum filtern
Click to expand...
  • die journalctl-Einträge lassen sich nicht mehr aufrufen, wenn der LXC so extrem ausgelastet ist
  • Entweder bin ich blind, oder aber, ich kann das Query-Log nicht filtern. Bei mir ist es nur eine lange Liste. Auffälligkeiten sehe ich nicht wirklich.


Ich habe folgendes jetzt mal geändert - mal schauen, ob das Abhilfe bringt:
  • RAM & Swap: jeweils 1024MB
  • Log-Retention: von 30d auf 7d gesetzt
 
nitrosont said:
cores: 1
memory: 256
swap: 256
Click to expand...
Pihole kommt (kam) mit so etwas klar aber für AGH kann das zu wenig sein. Das kann je nach Listen beim Updaten dieser durchaus mal erheblich mehr Resourcen brauchen. Da es ein CT ist (Eine VM würde alles für Cache nutzen), ist eine RAM Überbuchung auch üblicherweise nicht schlimm. Du kannst ja mal die maximum Werte der letzten Woche oder so in CT > Summary prüfen. Nur damit du ein Beispiel hast
1772246277536.png
 
Last edited:
  • Like
Reactions: nitrosont
Ja, ich weiß ehrlich gesagt gar nicht, warum ich mit dem Ram sooo sparsam war bei dem Container. Ich werde es nun mal beobachten. Meine Vermutung war, dass beim Update der Filterlisten der Ram einfach nicht ausgereicht hat und daher der Container abgeschmiert ist.
 
Nur eine Idee: Hatte ihn zuvor ebenfalls auf 256 MB stehen gehabt. Bin weit durch die Logs gescrollt und weg war der Container. CT Abschaltung wegen RAM Überfüllung (oder so öhnlich war der Log von PVE zu entnehmen).
Habe den Speicherzeitraum der Logs von 90 auf 30 Tage verringert.
Diese Änderung habe ich erst vor 4 Tagen vorgenommen.
 
@nitrosont, dein top-Output zeigt das Problem ziemlich eindeutig — es ist kein CPU-Problem, sondern Speicher:

  • MiB Mem: 256.0 total, 1.2 free, 253.3 used — RAM praktisch voll
  • MiB Swap: 256.0 total, 0.1 free, 255.9 used — Swap ebenfalls voll
  • AdGuardHome allein: 234 MB RES (89.4%)
  • 82.3% sy, 14.8% wa — der Kernel verbringt die gesamte CPU-Zeit mit Swap-I/O

Das ist klassisches Swap-Thrashing: RAM und Swap sind komplett erschöpft, der Kernel schiebt nur noch Speicherseiten hin und her. Deshalb geht auch journalctl nicht mehr — das System ist so beschäftigt mit Swapping, dass kein Prozess mehr vernünftig laufen kann.

Die Erhöhung auf 1024 MB RAM war der richtige Schritt. Zusätzlich prüfe in der AdGuard-UI unter Einstellungen → Allgemein → Query-Log, ob das Query-Log im Speicher gehalten wird. Bei 30 Tagen Retention auf 256 MB wächst das unweigerlich über den verfügbaren RAM hinaus. Die Reduzierung auf 7 Tage hilft, aber schau auch, ob du die Speicherung auf Festplatte erzwingen kannst — in der AdGuardHome.yaml:

Code: 
querylog:
  dir_path: ""      # Default = Arbeitsverzeichnis
  file_enabled: true
  interval: 168h    # 7 Tage
  size_memory: 1000 # Anzahl Einträge im RAM-Buffer — niedrig halten

Gib Bescheid, ob das Problem mit 1024 MB + reduzierter Retention stabil bleibt.
 
  • Like
Reactions: nitrosont and Johannes S
@Bu66as : Danke für Deine zusätzlichen Tipps/Anregungen! Ich werde den LXC in der kommenden Zeit im Auge behalten und hier Feedback geben.

Ich kann aber jetzt - nach knapp einer Woche mit den geänderten Einstellungen (RAM) - schon sage, dass der LXC bisher stabil läuft.
 
Last edited:
  • Like
Reactions: Bu66as
You must log in or register to reply here.
Top Bottom
Back