Docker netwerk lijkt traag?

[Oon]

Voor een situatieschets is het misschien handig om even naar Rendabiliteit vervangen server te kijken (waar input ook welkom is overigens ), maar in het kort:
Ik heb een server met 2x24 cores, 196GB geheugen, 10x10TB aan hardeschijven. Het primaire doel van deze server is docker en PVE, waarbij PVE eigenlijk alleen maar een kleine VM en Home Assistant heeft draaien (dus docker overheerst).

Ik heb sinds een tijdje pi-hole (en om te testen nu even AdGuard Home) draaien, en ik merk nu de laatste paar weken dat mijn DNS echt absurd traag is.
Om dit te debuggen heb ik allerlei dingen geprobeerd, maar uiteindelijk komt het erop neer dat de verbinding naar de container toe heel traag lijkt te zijn. Dat inclusief directe IP+poort verbindingen naar andere containers.

Of het op de heenweg of terugweg is weet ik niet, en ik heb ook echt totaal geen idee hoe ik dat zou kunnen testen. Mijn ping naar de server is zo'n 0,3ms gemiddeld, vanaf iedere container naar het internet en naar mijn interne netwerk gaat prima, andere DNS servers (ook vanuit pi-hole of AGH) zijn snel. Om het nog even ingewikkelder te maken; het is niet constant.
Ik heb steeds ergens tussen een paar minuten en een paar uur perfecte verbindingen, alles laadt snel en geen gedoe met DNS die niet wil resolven oid, en dan ineens is het even enorm traag. DNS blijft dan timeouts geven (en sommige sites willen dus niet laden) en ook mijn Home Assistant heeft ineens allemaal sensoren die unavailable worden omdat ze data van het internet moeten trekken.

Als voorbereiding heb ik alvast in Grafana een dashboard met statistieken van het aantal packets en het aantal MB per container, en ook grafieken van het totaal + de gemiddelden over de afgelopen 6 uur:


Je ziet dat er flink wat verkeer is, maar geen enorme schommelingen die dit gedrag kunnen verklaren. De pieken komen niet overeen met wanneer ik de problemen ervaar.
CPU load e.d. zijn allemaal prima, en als ik de lokale DNS omzeil zijn de problemen op mijn client weg, dus ik kan andere internetapparatuur in huis ook uitsluiten.

Ik heb ook Smokeping draaien, en die laat in de DNS tests naar bijv. Google niks vreemds zien, en ook andere tests zijn prima. Ik zal jullie de screenshots even besparen, maar de hoogste latency intern is heel soms 24ms, inclusief slimme stekkers in de garage (waar slecht bereik is).

Even opgesomd wat ik al kan uitsluiten:
- CPU/geheugen zijn normaal
- AGH/pi-hole zelf , want verse installatie is even langzaam
- Netwerk in huis, want omzeilen lost het probleem op
- Bufferbloat test is prima
- Speedtest is prima
- Ligt niet aan mijn client, want omzeilen lost het probleem op
- Upstream DNS is niet het probleem

Praktisch is mijn vraagstuk dus; hoe ga ik dit in hemelsnaam troubleshooten?
Ik zal op de één of andere manier moeten bevestigen waar het probleem zit door 'iets' te testen op het moment dat het gebeurt, maar het is soms enkele seconden en totaal niet voorspelbaar.
Zijn er tools die ik over het hoofd zie, of een logische verklaring voor dit gedrag?

[The Realone]

Als je een dig doet naar een cached vs non-cached domain op het moment dat je de traagheid merkt, wat is het verschil in query time?

Als test kun je ook zolang je DNS ergens anders op draaien. PC'tje waar je docker op zet of op een VM in je PVE omgeving.

[Oon]

The Realone schreef op dinsdag 5 september 2023 @ 19:22:
Als je een dig doet naar een cached vs non-cached domain op het moment dat je de traagheid merkt, wat is het verschil in query time?

Als test kun je ook zolang je DNS ergens anders op draaien. PC'tje waar je docker op zet of op een VM in je PVE omgeving.

20-24 milliseconden naar een uncached domeinnaam, 0-4 seconden naar een cached domeinnaam vanaf de host zelf, en vanaf mijn Mac Mini naar de server toe (waar alleen een switch tussen zit) scheelt het soms nog 1 milliseconde extra. Nagenoeg niks, dus, zelfs uncached is gewoon prima.

Is natuurlijk een optie om die even ergens anders op te gooien, maar ik heb helaas op het moment geen extra apparaat om dat mee te doen (behalve een hele oude Synology DS1511+ en een Raspberry Pi 2, maar die lijken me niet echt realistisch als vergelijking). Daarnaast is het niet alleen pihole/AGH waar ik problemen mee heb, maar alle containers. Ook bijv. Frigate, NextCloud, Grafana etc. Of ik nou via een (interne) hostnaam ga (hostnamen proxy ik via NginxProxyManager) of direct IP + poort maakt geen verschil op het moment dat hij langzaam is.

[The Realone]

Dan begrijp ik het even niet. Je zegt in je OP dat, wanneer je lokale DNS niet gebruikt, het snel is. Maar nu zeg je ook dat direct naar een IP traag is?

[Oon]

The Realone schreef op dinsdag 5 september 2023 @ 19:44:
Dan begrijp ik het even niet. Je zegt in je OP dat, wanneer je lokale DNS niet gebruikt, het snel is. Maar nu zeg je ook dat direct naar een IP traag is?

Excuses, ik had je vorige reactie fout gelezen. De tijden die ik nu noemde is wanneer het wel gewoon meewerkt.

Als het probleem niet speelt is zowel IP+poort als hostname als alle DNS die via de server hier thuis loopt snel, maar wanneer het probleem wel speelt dan zijn die alledrie langzaam, en is de lokale DNS omzeilen en direct naar bijv. T.net gewoon snel.

Wat ik nog niet absoluut heb kunnen bevestigen maar wel het geval lijkt te zijn is dat Home Assistant, die op diezelfde server maar in een gewone VM (dus buiten Docker en Docker routing) draait wel gewoon responsive blijft. Ik weet niet zo goed hoe ik dat zou moeten bevestigen, ik zou nog een ping tester als Smokeping op mijn Mac Mini kunnen draaien en die zowel Home Assistant als een willekeurige Docker container kunnen laten pingen..

Edit: Zojuist nog kunnen bevestigen dat Home Assistant prima bereikbaar is terwijl DNS dat niet is, daarmee dus bevestigd dat het probleem echt binnen Docker zit

[ Voor 7% gewijzigd door Oon op 05-09-2023 20:42 ]

[GekkeFriet]

Probeer de container eens met

code:

--net "host"

te starten om bridge issues uit te sluiten

[Oon]

GekkeFriet schreef op woensdag 6 september 2023 @ 01:01:
Probeer de container eens met

code:

--net "host"

te starten om bridge issues uit te sluiten

Dat is helaas al zo, dit is de docker-compose van de Swarm stack:

YAML:

version: '3.7'
services:
    agh:
        image: adguard/adguardhome:v0.108.0-b.44
        deploy:
            replicas: 1
        volumes:
            - /vmdata/services/adguard_agh/work:/opt/adguardhome/work
            - /vmdata/services/adguard_agh/conf:/opt/adguardhome/conf
            - /vmdata:/vmdata
        ports:
            - target: 53
              published: 53
              protocol: tcp
              mode: host
            - target: 53
              published: 53
              protocol: udp
              mode: host
            - target: 6979
              published: 6979
              protocol: tcp
              mode: host
        networks:
            - common
            - nginxpm
networks:
    common:
        external: true
    nginxpm:
        external: true

[The Realone]

Wordt een kwestie van vanalles proberen denk ik. Je kunt bijvoorbeeld eens met iperf tussen 2 containers over het docker netwerk meten wat je performance is op de verschillende momenten.

Daarbij, hoewel het prima kan zijn dat het niet in DNS zit, is het wel zo dat DNS problemen door kunnen werken in verschillende scenarios. Sommige applicaties zijn bijvoorbeeld niet/nauwelijks responsive als de applicatie zelf DNS resolving issues heeft. Andere applicaties hebben daar mogelijk weer geen last van. Ik zou toch overwegen om even een DNS server op PVE op te spinnen om dit te testen, of voor mijn part even je router gebruiken. Het is maar tijdelijk.

Want vergeet niet:

[Oon]

The Realone schreef op woensdag 6 september 2023 @ 15:33:
Wordt een kwestie van vanalles proberen denk ik. Je kunt bijvoorbeeld eens met iperf tussen 2 containers over het docker netwerk meten wat je performance is op de verschillende momenten.

Daarbij, hoewel het prima kan zijn dat het niet in DNS zit, is het wel zo dat DNS problemen door kunnen werken in verschillende scenarios. Sommige applicaties zijn bijvoorbeeld niet/nauwelijks responsive als de applicatie zelf DNS resolving issues heeft. Andere applicaties hebben daar mogelijk weer geen last van. Ik zou toch overwegen om even een DNS server op PVE op te spinnen om dit te testen, of voor mijn part even je router gebruiken. Het is maar tijdelijk.

Want vergeet niet:

[Afbeelding]

Ik zou inderdaad eens twee containers met iperf op kunnen zetten, dat is geen verkeerd idee.

Vwb DNS specifiek maak ik me niet heel druk, maar ik ga dan wel ook meteen testen met en zonder AGH draaiend, kijken of dat nog verschil maakt. Het stukje lokaal DNS is niet kritiek gelukkig