Mailcow auf "RS 1000 G9 a1 12M" (8GB Ram) - Memory Problem?

  • Hallo,

    ich habe Mailcow nach offiziellem Howto auf dem vServer installiert, funktioniert auch alles wie gewünscht.

    Im Moment 2 Domains und ca 15 Postfächer, Konfiguartion von Mailcow eigentlich default (clamd, solr sind aktiv)

    Keine anderen Services/Daemons außer Docker/Mailcow.


    Jedoch hatte ich nun 2 Tage hintereinander das Problem das der vServer von aussen plötzlich nicht mehr erreichbar war (ICMP PING fehlgeschlagen).

    Ich konnte mich jedoch noch über das Netcup Panel am System anmelden, und witzigerweisse nach außen pingen.

    /var/log/* habe ich durchforstet doch nicht wirklich etwas von einem Problem gefunden.


    Was ich leider nicht kontrolliert habe war die Memory Auslastung auf dem vServer selbst.

    Mein PRTG Monitor schlägt jedoch nach ein paar Stunden Laufzeit Alarm.

    pasted-from-clipboard.png



    Code
    root@mail ~ > free -m
                  total        used        free      shared  buff/cache   available
    Mem:           7978        3923         114          64        3940        4202
    Swap:             0           0           0


    Ich frage mich nun:

    1. was Ihr für Erfahrungen damit gemacht habt

    2. da kein Swap auf dieser VM aktiv ist, ob ich mal vorsichtshalber ein Swapfile konfigurieren soll


    :)

  • Bei mir läuft Mailcow mit 4GB RAM und 4GB Swap problemlos. Du könntest evtl. mal den Heap vom Solr etwas runternehmen, wenn das Mailaufkommen es hergibt.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • In der Dokusteht das dieser schon eingeschränkt ist, ist bei mir auch der Fall:

    Code
    SOLR_HEAP=1024


    In diesem Fall haben wir jedoch auch den Unterschied das dein vServer ein SWAP hat, mein vServer jedoch nicht.

    Ja, du hast aber doppelt so viel RAM. Also dürfte sich das nichts nehmen. Und ich fahre mein Solr glaube auf 256MB.


    Wie viele Mailuser, Domains, parallele SOGo Sessions usw. hast du über den Server laufen?

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Mal Danke für Antwort überhaupt :)


    Domains=2

    Mailboxen=~15

    SOGo=Denke das die meisten einen Mailclient verwenden, jedoch fast jede Mailbox nutzt EAS


    Ich habe nun trotzdem mal vorsorglich SWAP per File aktiviert. Berichte hier ob das Problem auch mit Swap noch auftritt.


  • Du hast doch noch fast 4GB Speicher verfügbar laut "free -m".

    Nur weil RAM als buffer/cache in Benutzung ist, heißt das lange noch nicht, dass du diesen nicht nutzen kannst.

    Schau dir dazu das hier mal an:

    https://www.linuxatemyram.com/


    Ich würde vor allem mal in die Logs schauen, ob da nicht doch mehr drin steht als nur hoher Speicherverbrauch.

  • Hallo x1lor,

    mir ist die Linux Speichernutzung schon bekannt, bzw. das dies auch so sein soll.

    Jedoch ist es so das in keinem LOG des Wirtsystems etwas darüber zu finden ist, was auf ein Problem hinweist.

    Zugegeben, mit Docker selbst und den mailcow-containern bin ich noch nicht vertraut, diese LOGS habe ich nicht kontrolliert,

    wobei ich denke wenn eth0 nicht mehr erreichbar ist, etwas sehen zu müssen.

    Nun egal, ich schau ob das Problem nach ca. 24h Laufzeit wieder auftritt.


    Zusätzlich habe ich soeben die /etc/network/interfaces konfiguriert so wie ich es von Debian kenne,

    und die /etc/network/interfaces.d/50-cloud-init.irgendwas gelöscht


    mfg

  • Versprochene Rückmeldung.

    Das Problem ist nun nicht mehr aufgetreten.


  • Sehr schön.


    Tipp am Rande: direkter root Login, speziell nur mit Passwort, ist unsicher wie die Hölle. Bitte nur Login per Keyfile als unpriveligierter User erlauben und dann per su - mit Passwort zum root User wechseln.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Sehr schön.


    Bitte nur Login per Keyfile als unpriveligierter User erlauben und dann per su - mit Passwort zum root User wechseln.

    Keyfile ist nicht immer möglich. z.B. wenn man oft von unterwegs, von fremden Geräten aus auf den Server zugreifen muss.

    Ich habe dafür dann immer zwei user. Einen "normalen" mit ausreichend langem Passwort und einen su zu dem man dann wechseln muss und für den das ssh-Login gesperrt ist. Das ist durchaus ausreichend. Keyfile muss nicht notwendigerweise sein. (Meine Passwörter sind in der, dem Universum noch verbliebenen Zeit nicht zu knacken ;))

  • Keyfile ist nicht immer möglich. z.B. wenn man oft von unterwegs, von fremden Geräten aus auf den Server zugreifen muss.

    Ich habe dafür dann immer zwei user. Einen "normalen" mit ausreichend langem Passwort und einen su zu dem man dann wechseln muss und für den das ssh-Login gesperrt ist. Das ist durchaus ausreichend. Keyfile muss nicht notwendigerweise sein. (Meine Passwörter sind in der, dem Universum noch verbliebenen Zeit nicht zu knacken ;))

    Dann vielleicht doch 2fa umsetzen? Das Handy hat man doch immer dabei.

  • Keyfile ist nicht immer möglich. z.B. wenn man oft von unterwegs, von fremden Geräten aus auf den Server zugreifen muss.

    Ich habe dafür dann immer zwei user. Einen "normalen" mit ausreichend langem Passwort und einen su zu dem man dann wechseln muss und für den das ssh-Login gesperrt ist. Das ist durchaus ausreichend. Keyfile muss nicht notwendigerweise sein. (Meine Passwörter sind in der, dem Universum noch verbliebenen Zeit nicht zu knacken ;))

    Für sowas kann man doch super einen Jumphost benutzen. So muss man nicht auf allen Systemen PW-basierte Authentifizierung aktivieren.