Ja, ich habe das jetzt alles deaktiviert (brauche ich auch nicht wirklich). Gleichzeitig habe ich hier im Forum die Anleitung für reverse proxy gefunden und die unterscheidet sich etwas von dem o.g. Vorgehen, ich habe das jetzt mal angepasst, ich denke inzwischen nicht mehr, das es an traefik liegt … der kümmert sich ja eigentlich nur um die Ports 80 und 443, d.h. den nginx (der jetzt auf 10080 und 10443 läuft), ohne reverse proxy müßte ich die halt durchschleifen, habe aber dann das Problem, das das Zertifikatsupdate nicht mehr geht, weil das offensichtlich zwingend einen http-Server an Port 80 braucht.
Lustigerweise läuft das System tagsüber inzwischen sehr ruhig, d.h. ich kann diese Lastspitzen auch nie direkt beobachten, die treten immer erst nachts auf. Da läuft dann mein backup, unter Umständen müßte ich mein Skript modifizieren, das er die docker container vor dem Backup kurz herunterfährt und danach wieder startet (eigentlich generell eine gute Idee 😇), um Interferenzen hier auszuschließen, ich kann mir im Moment nicht erklären, warum ich immer morgens eine komplett zerfahrene Situation vorfinde und es tagsüber alles super smooth läuft.
Ich habe auch den watchdog deaktiviert, der marodiert nach diesen Anfällen immer im System herum und versucht verzweifelt, alles neu zu starten und hat gleichzeitig arge Netzwerkprobleme, was zu üblen timeouts in der Kommunikation zwischen den Komponenten führt. Im Zweifel ist dann ein simples “docker compose down && docker compose up -d” zielführender als den watchdog versuchen zu lassen, einzelne Prozesse neu zu starten.
Zu den ganzen anderen parallelen Services, die sind alle chronisch unterbeschäftigt und idlen meist so vor sich hin, der Server ist halt für meinen Privatgebrauch und zum austesten von coolen neuen Sachen wie z.B. mailcow …. ich habe die auch schon alle heruntergefahren, d.h. ich kann eigentlich ausschließen, das es daran liegt, das ich dem Server einfach zuviel zumute