CPU-Last steigt unaufhörlich nach Starten des mailcowdockerized-Stacks

stackHollow

Hallo zusammen,

an mailcow verzweifle ich gerade.Der Stack startet mit meinen Configs problemlos, ich kann auch eine Domain anlegen, E-Mails versenden, soweit alles wie erwartet. Allerdings geht meine CPU nach kurzer Zeit durch die Decke. Der CPU-Load steigt unaufhörlich, nach einer knappen Minute fangen sich diverse Jobs an zu stapeln, ohne zu beenden.

PID PPID USER %MEM %CPU CMD 1331220 1331204 root 0.0 48.8 /usr/local/bin/gosu nobody /usr/local/bin/imapsync_runner.pl 1331226 1331170 root 0.0 48.8 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1333080 1333011 root 0.0 46.7 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1334565 1334551 root 0.0 46.5 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1336365 1336345 root 0.0 44.4 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1338817 1328001 root 0.0 42.8 /usr/local/bin/gosu vmail /usr/local/bin/repl_health.sh 1338867 1338824 root 0.0 42.2 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1340513 1340426 root 0.0 41.8 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1342158 1342127 root 0.0 40.3 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1343993 1343957 root 0.0 37.9 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1331217 1331171 root 0.0 37.6 /usr/local/bin/gosu sogo /usr/sbin/sogo-tool -v expire-sessions 480 1331225 1331205 root 0.0 37.1 /usr/local/bin/gosu sogo /usr/sbin/sogo-ealarms-notify -p /etc/sogo/cron.creds 1345727 1345709 root 0.0 37.1 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1333067 1333048 root 0.0 36.2 /usr/local/bin/gosu sogo /usr/sbin/sogo-ealarms-notify -p /etc/sogo/cron.creds 1333068 1333060 root 0.0 35.5 /usr/local/bin/gosu sogo /usr/sbin/sogo-tool -v expire-sessions 480 1349307 1349218 root 0.0 35.1 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1347515 1328001 root 0.0 34.6 /usr/local/bin/gosu vmail /usr/local/bin/repl_health.sh 1347621 1347588 root 0.0 34.5 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1334558 1334524 root 0.0 34.1 /usr/local/bin/gosu sogo /usr/sbin/sogo-tool -v expire-sessions 480 1336352 1336306 root 0.0 34.0 /usr/local/bin/gosu sogo /usr/sbin/sogo-ealarms-notify -p /etc/sogo/cron.creds 1334564 1334518 root 0.0 33.6 /usr/local/bin/gosu sogo /usr/sbin/sogo-ealarms-notify -p /etc/sogo/cron.creds 1352604 1352541 root 0.0 32.7 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1336351 1336308 root 0.0 32.2 /usr/local/bin/gosu sogo /usr/sbin/sogo-tool -v expire-sessions 480 1354187 1354130 root 0.0 31.3 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1355858 1355786 root 0.0 30.9 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1357431 1328001 root 0.0 30.6 /usr/local/bin/gosu vmail /usr/local/bin/repl_health.sh 1338872 1338808 root 0.0 30.5 /usr/local/bin/gosu sogo /usr/sbin/sogo-ealarms-notify -p /etc/sogo/cron.creds 1357469 1357451 root 0.0 30.4 /usr/local/bin/gosu vmail /usr/local/bin/trim_logs.sh 1338866 1338849 root 0.0 30.2 /usr/local/bin/gosu sogo /usr/sbin/sogo-tool update-autoreply -p /etc/sogo/cron.creds

Dovecot und SOGo scheinen mir hier was krumm zu nehmen.

An den Systemvoraussetzungen scheitere ich nicht, die reichen hier aus. Die einzigen Anpassungen in der Config habe ich an den Volumes sowie den HTTP(S)-Ports und dem Redirect auf HTTPS vorgenommen und natürlich an meine Traefik-Gegebenheiten angepasst.

Ich vermute hier stark, dass ich das Problem bin, aber ich finde einfach nicht heraus, an welcher Stelle. Die Logs machen mich hier leider auch nicht schlauer, weil augenscheinlich alles zu funktionieren scheint. Hat diese Erfahrung schon einmal jemand gemacht oder eine Idee, wo ich hier suchen sollte?

Vielen Dank vorab

Ganzjahresgriller

Was ist das denn für ein Server? CPU, RAM, HDD. Was läuft noch auf dem Server?

stackHollow

Hi @Ganzjahresgriller,
das ist mein privater Server mit Tunnel zu einem Hetzner VPS als Gateway.

CPU: i7-12700K
RAM: 32GB DDR5
OS-Platte: NVMe
diverse Daten-HDDs
OS: Ubuntu 25.10

Und hier noch die docker-compose.override.yml:

---
services:
  certdumper:
    image: ghcr.io/kereis/traefik-certs-dumper:latest
    restart: unless-stopped
    network_mode: none
    command: --restart-containers mailcowdockerized-postfix-mailcow-1,mailcowdockerized-dovecot-mailcow-1
    volumes:
      - /path/to/certs/domain:/traefik:ro
      - /path/to/mailcow/data/assets/ssl:/output:rw
    environment:
      DOMAIN: ${MAILCOW_HOSTNAME}
      ACME_FILE_PATH: "/traefik/acme.json"
    healthcheck:
      test: ["CMD", "/usr/bin/healthcheck"]
      interval: 30s
      timeout: 10s
      retries: 5

  nginx-mailcow:
    ports: !reset
    networks:
      traefik_network:
    volumes:
      - /path/to/mailcow/sogo/web:/usr/lib/GNUstep/SOGo/
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=traefik_network"
      - "traefik.http.routers.mailcow-https.entrypoints=https"
      - "traefik.http.routers.mailcow-https.rule=Host(`mail.domain.de`) || Host(`autodiscover.domain.de`)"
      - "traefik.http.routers.mailcow-https.tls.certresolver=cloudflare"
      - "traefik.http.services.mailcow.loadbalancer.server.port=80"
      - "traefik.http.services.mailcow.loadbalancer.server.scheme=http"

  mysql-mailcow:
    volumes:
      - /path/to/mailcow/mysql/data:/var/lib/mysql/
      - /path/to/mailcow/mysql/socket:/var/run/mysqld/:z

  redis-mailcow:
    volumes:
      - /path/to/mailcow/redis:/data/

  clamd-mailcow:
    volumes:
      - /path/to/mailcow/clamav:/var/lib/clamav

  rspamd-mailcow:
    volumes:
      - /path/to/mailcow/rspamd:/var/lib/rspamd

  php-fpm-mailcow:
    volumes:
      - /path/to/mailcow/rspamd:/var/lib/rspamd
      - /path/to/mailcow/mysql/socket:/var/run/mysqld/:z

  sogo-mailcow:
    volumes:
      - /path/to/mailcow/mysql/socket:/var/run/mysqld/:z
      - /path/to/mailcow/sogo/web:/sogo_web
      - /path/to/mailcow/sogo/backup:/sogo_backup

  dovecot-mailcow:
    volumes:
      - /path/to/mailcow/dovecot/data:/var/vmail
      - /path/to/mailcow/dovecot/index:/var/vmail_index
      - /path/to/mailcow/mailcrypt:/mail_crypt/
      - /path/to/mailcow/rspamd:/var/lib/rspamd
      - /path/to/mailcow/mysql/socket:/var/run/mysqld/:z

  postfix-mailcow:
    volumes:
      - /path/to/mailcow/postfix:/var/spool/postfix
      - /path/to/mailcow/mailcrypt:/var/lib/zeyple
      - /path/to/mailcow/rspamd:/var/lib/rspamd
      - /path/to/mailcow/mysql/socket:/var/run/mysqld/:z

  postfix-tlspol-mailcow:
    volumes:
      - /path/to/mailcow/postfix/tlspool:/var/lib/postfix-tlspol

  acme-mailcow:
    volumes:
      - /path/to/mailcow/mysql/socket:/var/run/mysqld/:z

  watchdog-mailcow:
    volumes:
      - /path/to/mailcow/rspamd:/var/lib/rspamd
      - /path/to/mailcow/mysql/socket:/var/run/mysqld/:z
      - /path/to/mailcow/postfix:/var/spool/postfix

networks:
  proxy:
    external: true

Auf dem Server laufen noch diverse intern gehostete Dienste, wie Omada, Paperless-ngx und eine Nextcloud-Instanz.

D4niel

Willst du vielleicht kurz die Hintergründe deiner Anpassungen erläutern? Bis auf die Traefik-Anpassungen (die nicht den Docs zu entsprechen scheinen) ist daran meiner Meinung nach fast alles unnötiges Fehlerpotential 🤔.
Das proxy network unten wird auch irgendwie nirgendwo verwendet?

stackHollow

Na klar. Das proxy-network war ein Typo. Das beim Anonymisieren habe ich wohl das traefik_network im nginx-mailcow-Container vergessen anzupassen. Dabei handelt es sich um mein Traefik-Network.

Beim übrigen Rest war ich der Überzeugung, ich könnte die Named Volumes aus der docker-compose.yml mit diesen Config in meiner Override-Datei stumpf überschreiben, was nach meinen Erfahrungen auch geklappt hat.

Losgelöst davon habe ich aber auch genügend Testläufe mit der grundkonfigurierten docker-compose.yml durchgeführt und die gleichen Erfahrungen gemacht.

Ganzjahresgriller

Also ich sehe auf die Schnelle nicht, mit den Infos, was das Problem ist, aber ich kann Dir sagen das es immer eine gute Idee ist eine Mailcow auf einer eigenen dedizierten Maschine laufen zu lassen. Da reicht ja ein kleiner ARM Server. Ich mach das nun schon eine ganze Zeit lang genau so und fahre damit sehr gut. Mag sein das man das in Deinem Szenario auch hinbekommt aber da bin ich erst mal raus.

CK_beats

Ich bin auch der Meinung von Ganzjahresgriller .
In Zeiten von Virualisierung lasse Mailcow separat laufen. So bekommst Du keine Konflikte und kannst vor allen Dingen sauber auf Fehler prüfen. Ohne irgendwelche Abhängigkeiten / doppelte Portverwendung etc. befürchten zu müssen.

Außerdem geht im Wartungsfall nicht das komplette System down.