Docker Performance verbessern?

Taobyebye

Hallo,

habt ihr Tipps, mit denen man die Performance von unRAID an sich steigern kann ?

Ich habe des öfteres Probleme mit der Geschwindigkeit. Wenn ich eine Seite in meinem Wiki bearbeite, kommt es des öfteren vor dass es ewig lädt bis ich editieren kann. Das kommt und geht in Schüben. Mal ist es sehr fix und dann wieder sehr langsam. Das selbe passiert auch bei meiner Nextcloud. Deswegen vermute ich es liegt nicht nur am einzelnen Dockercontainer.
Ich weiß aber nicht wie ich an die Sache rangehen soll. Was sollte ich überprüfen ?

monarc99

Lass mal sowas wie htop in der Konsole auf dem Server mitlaufen, wenn du etwas machst. Ob ihm z.B. der Speicher ausgeht oder ähnliches.

b0mb

Htop halte ich auch für eine gute Idee, da das Problem kein unRAID Problem ist.

darkside40

Liegen die Docker auf einer SSD oder einer HDD?

BigChris

Welches Wiki nehmt ihr denn so?

Taobyebye

Hallo,

ich habe das System damit im Auge behalten und währenddessen einiges am Server gemacht und versucht das Problem nachzustellen, jedoch ist es bisher nicht aufgetaucht und htop zeigt mir an dass allesim grünen Bereich ist.
Bei der CPU wurde es bisher nie mehr als bis zur Hälfte kurz gefüllt.

Die Docker liegen auf der Cache-SSD wenn ich es richtig verstanden habe. Da das Appdata-Share auf Prefer steht, müsste ich da richtig liegen oder ?
Für das Wiki nehme ich Dokuwiki.

BigChris

Zitat von Taobyebye

Für das Wiki nehme ich Dokuwiki.

Der Container wird aber nicht mehr gepflegt.

Taobyebye

Zitat von BigChris

Der Container wird aber nicht mehr gepflegt.

Verdammt, ist mir noch nicht aufgefallen
Habe es bisher mit apt get update und upgrade aktuell gehalten.
Und ein Umzug in ein anderes Wiki wird wohl schwierig..

SLiX

Mit docker stats kannst du dir auch mal ansehen, was er der einzelne Container nun verbraucht

hordesprime

Zitat von Taobyebye

Hallo,
habt ihr Tipps, mit denen man die Performance von unRAID an sich steigern kann ?
Ich habe des öfteres Probleme mit der Geschwindigkeit. Wenn ich eine Seite in meinem Wiki bearbeite, kommt es des öfteren vor dass es ewig lädt bis ich editieren kann. Das kommt und geht in Schüben. Mal ist es sehr fix und dann wieder sehr langsam. Das selbe passiert auch bei meiner Nextcloud. Deswegen vermute ich es liegt nicht nur am einzelnen Dockercontainer.
Ich weiß aber nicht wie ich an die Sache rangehen soll. Was sollte ich überprüfen ?

Kann es sein dass du die Daten von Nextcloud in einem Share auf einer HDD liegen hast, ich meine nicht die AppData Daten von Nextcloud. Wenn es mal länger dauert bis du etwas ändern kannst würde ich sonst sagen kann es daran liegen dass die Platten in dem Moment vielleicht erst aufwachen müssen weil Spindown.

TC

Taobyebye

Mir ist bisher nicht aufgefallen dass etwas voll läuft.
Die eigentlichen Daten wie Dokumente in Nextcloud liegen auf den HDDs aber das Problem kommt nicht nur wenn ich die Dateien durchstöbere sondern auch wenn ich in den Einstellungen bin.

Adromir

Ich könnte mir vorstellen, wenn man etwas Ahnung von docker hat, man sozusagen den "Overhead" optimieren könnte.

Also z. B. Hat man 10 docker mit webanwendungen, dann hätte man quasi 10x ein Betriebssystem mit 10 Webservern laufen. Dies könnte man rein theoretisch in einen docker zusammen fassen.. Der entstandene Docker wäre dafür leider etwas schwieriger zu managen, ausser man mapped den htdocs Ordner z. B. von außen. Dann könnte man auf die Installation der webapps im Docker verzichten und die Installationen halt händisch managen

PvD

Zitat von Taobyebye

Mir ist bisher nicht aufgefallen dass etwas voll läuft.

Davon war auch nicht die Rede. Eher läuft bei Dir nichts , die HDDs z.B., auf denen die Daten liegen und die im Idle sein können und daher runtergefahren sind (Spindown). Das von Dir beschriebene Verhalten ist typisch dafür. Die Platten müssen erst wieder anlaufen, bevor Du auf die Daten zugreifen kannst. Was hast Du denn unter Settings -> Disk Settings unter "Default Spin Down Delay" stehen?

Zitat von Taobyebye

Da das Appdata-Share auf Prefer steht, müsste ich da richtig liegen oder ?

Nö, prefer steht für "bevorzugt". Das schliesst nicht aus (abhängig von den darüberliegenden Einstellungen), daß die Daten eben doch auf die HDDs verteilt werden. Richtig wäre IHMO "use cache disk only", zumindest für Daten, die einem ständigen Änderungsprozeß unterliegen.

Taobyebye

Default Spin Down Delay ist bei 15min.
Okay dann Stelle ich AppData bei der Cache-Einstellung auf only, müsste es dann ja gewesen sein ? Wenn AppData jetzt auf only ist, müsste das mit dem Spindown doch auch egal sein ?

justray2k

Zitat von Taobyebye

Wenn AppData jetzt auf only ist, müsste das mit dem Spindown doch auch egal sein ?

Jap. Nach umstellen auf Only aber nochmal den Mover anstoßen.

Taobyebye

Ich habe es nun eine Weile beobachtet. Leider immer noch recht langsam, vor allem Nextcloud :-/
Woran könnte es noch liegen ?

monarc99

Ohne Anhaltspunkt schwierig.

Wenn das Problem auftritt, gib mal den Befehl "dmesg" in die Konsole ein. Ob der Kernel irgendwelche Probleme (z.B. mit der Platte) ausspuckt.

Taobyebye

Bisher kommt mit dmesg folgendes:

Code

[1466724.845862] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1466724.845906] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1466771.893860] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1466771.893899] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1466806.189634] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1466806.189674] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1466842.349694] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1466842.349759] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1466884.557854] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1466884.557891] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1466919.149358] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1466919.149425] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1466963.757305] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1466963.757366] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1467010.861231] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1467010.861272] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1467061.901104] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1467061.901146] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1467093.484863] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1467093.484904] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1467126.556928] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1467126.556995] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1467168.556657] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1467168.556698] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1467226.028594] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1467226.028656] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1467258.156575] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1467258.156626] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1467316.415880] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1467316.415921] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!
[1467374.684120] br0: received packet on eth0 with own address as source address (addr:1c:1b:0d:ad:b3:f0, vlan:0)
[1467374.684159] IPv6: eth1: IPv6 duplicate address 2003:c8:872a:2849:1e1b:dff:fead:b2f0 used by 1c:1b:0d:ad:b3:f0 detected!

Alles anzeigen

Taobyebye

Zitat von Justray2k

Jap. Nach umstellen auf Only aber nochmal den Mover anstoßen.

Das Plugin FileActivity zeigt mir dass appdata-Daten noch auf einer Disk liegen, ich habe AppData auf Only, den Mover angestoßen gehabt

und Nextclouds Config sollte auch im AppData liegen

reey

Bei dem output von FileActivity handelt es sich nicht um deinen AppData share sondern um deinen nextcloud share
Müsstest du dann für diesen auch umstellen, falls dein cache Drive groß genug ist.

Docker Performance verbessern?

Jetzt mitmachen!

Benutzer online in diesem Thema