Plesk Dovecot wird "angegriffen" geht down

docb

docb

New Member
Grüß Euch, ich habe seit zwei Wochen einen VServer mit Plesk und bin eigentlich sehr zufrieden. Ich habe mich auch einigermaßen durch Plesk durchgewurstelt und die Steuerung des Servers klappt schon ganz gut. Aber ich habe ein Problem mit dem Mailserver und keine Ahnung, wie ich das in den Griff bekommen soll. Der Server geht mehrmals täglich in die Knie, weil der Mailserver (Dovecot) so unter Last ist. Watchdog schickt mir ca. 20 Mails am Tag mit "The Dovecot IMAP and POP3 server service on host xyz.stratoserver.net is down". Jedes 10te mal davon geht kurz danach der Apache und dann der Plesk Service in die Knie, so dass ich teilweise sogar nicht mal mehr über ssh reinkomme, sondern über Strato neu booten muss. Nach viel Foren lesen, habe ich eine Postausgangskontrolle eingerichtet (10 Mails pro Stunde) und das Relaying auf geschlossen gestellt, aber auch das hilft nichts. Ich bekomme nur dauernd Warnungen, z.B. gerade eben wieder:
Grenze: 10 Nachrichten pro Stunde
13 Versuch(e), die Grenzen zu überschreiten von Apr/09/2020 13:12 bis jetzt
74 Versuch(e), die Grenzen zu überschreiten von Apr/09/2020 12:31 bis Apr/09/2020 13:11
Als Mailserver ist postfix, als IMAP/POP3-Server Dovecot eingerichtet.
Ich hoste da eigentlich nur 1 Website mit Wordpress und bräuchte auch nur funktionierende Weiterleiter (xy@domain.de -> xy@gmail.com) sowie natürlich die Mails vom System aus, z.B. Watchdog. Gibt es eine Möglichkeit, das so schlank wie möglich einzurichten, am besten ohne eine große Mailserver-Angriffsfläche zu bieten? Ich habe schon länger einen Linux-Server zu Hause, aber ohne Mailserver, daher bin ich was Mails anbelangt extrem blank. Ich kapiere schon gar nicht, wie da irgendjemand, offensichtlich ohne Authentifizierung, überhaupt was schicken kann.
Ich habe auch Fail2Ban bei Plesk eingerichtet, aber das Dovecot Jail ist leer. Wäre super, wenn mir jemand auf die Sprünge helfen könnte...
Besten Dank im Voraus, viele Grüße
doc
 
Du musst erst mal klären, ob da überhaupt Versand ohne Authentsierung stattfindet oder es nicht evtl. ein bekanntgewordenes Passwort ist. Das kannst du in den Logs sehen. Dort solltest du auch Hinweise sehen, warum eine so hohe Last auf dem Server vorhanden ist.
Es kann natürlich auch bei einem kleinen Server sein, dass der RAM einfach zu knapp bemessen ist und daher der OOM-Killer zuschlägt. Sind alles nur Vermutungen, da meine Glaskugel gerade zur Wartung ist...
 
docb said:
Ich hoste da eigentlich nur 1 Website mit Wordpress und bräuchte auch nur funktionierende Weiterleiter (xy@domain.de -> xy@gmail.com) sowie natürlich die Mails vom System aus, z.B. Watchdog. Gibt es eine Möglichkeit, das so schlank wie möglich einzurichten, am besten ohne eine große Mailserver-Angriffsfläche zu bieten?
Click to expand...
Hol dir ein Webspacepaket und betreibe deine Webseite darüber.
Dann fällt für dich der administrative Aufwand weg und du kannst dich einzig auf den Betrieb deiner Seite konzentrieren.
 
:)Wow, das ging ja schnell, danke schon mal!
@nexus: naja, irgendwie wäre das ja wie aufgeben. Zwar deutlich weniger Arbeit, aber naja, ich will es lernen.
@danton: 8GB Ram müssten eigentlich reichen, oder? Jedenfalls habe ich mal geschaut, ob der OOM-Killer zugeschlagen hat, weder mit
dmesg | egrep -i 'killed process' noch mit grep -i 'killed process' /var/log/syslog wird mir etwas angezeigt.
Aus dem Dovecot log (/usr/sbin/dovecot) werde ich überhaupt nicht schlau und auch aus dem Syslog werde ich nicht wirklich schlau, da das voll mit postfix Messages ist. Ich google mich gerade durch und versuche mal, das zu verstehen.
Eine konkrete Frage hätte ich dazu: den Relay kann ich auslassen, da der Server ja (zumindest über die Weiterleitung) für die Mails zuständig ist, richtig? Soweit zumindest meine Schlussfolgerung nach dem ersten Einlesen...
 
Warum schaust du nicht ins maillog? Das siehst du doch ob Dovecot was per Login (oder auch ohne) bekommt zu der Zeit, von welchem User und von welcher IP.
 
Jo, da wurstel ich mich gerade durch... aber ich kapiere nicht, warum er abschmiert. Hier die letzten Einträge vor dem letzten Shutdown, die Mailasdress und den Server habe ich verändert (nicht, dass noch mehr Angreifer kommen :confused:). Suspekt ist das connect von 45.125.65.35, das bin sicher nicht ich... Ich schaue mal, was vor den anderen Shutdowns los war.

Code: 
Apr  9 14:19:15 h2873307 postfix/qmgr[23036]: 2300B20A2B: removed
Apr  9 14:19:15 h2xx postfix/qmgr[23036]: 43F7A2090C: removed
Apr  9 14:19:15 h2xxpostfix/qmgr[23036]: 4A474202DB: removed
Apr  9 14:19:15 h2xx postfix/qmgr[23036]: B3A9620937: removed
Apr  9 14:19:15 h2xxpostfix/pipe[24705]: 5BE3720938: to=<xx@xxs.com>, relay=plesk_virtual, delay=747, delays=488/26/0/232, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
Apr  9 14:19:15 h2xx psa-pc-remote[22986]: handlers_stderr: SKIP
Apr  9 14:19:15 h2xx psa-pc-remote[22986]: SKIP during call 'limit-out' handler
Apr  9 14:19:15 h2xx check-quota[25116]: Starting the check-quota filter...
Apr  9 14:19:15 h2xx psa-pc-remote[22986]: handlers_stderr: SKIP
Apr  9 14:19:15 h2xx psa-pc-remote[22986]: SKIP during call 'check-quota' handler
Apr  9 14:19:15 h2xx spf[25117]: Starting the spf filter...
Apr  9 14:19:15 h2xx spf[25117]: SPF result: pass
Apr  9 14:19:15 h2xx postfix/smtpd[24742]: connect from unknown[45.125.65.35]
Apr  9 14:19:15 h2xx postfix/smtpd[24742]: disconnect from unknown[45.125.65.35] ehlo=1 auth=0/1 quit=1 commands=2/3
Apr  9 14:19:15 h2xx postfix/qmgr[23036]: 5BE3720938: removed
Apr  9 14:19:15 h2xx postfix-local[25125]: postfix-local: from=watchdog@h2xx.stratoserver.net, to=xx@xxs.com, dirname=/var/qmail/mailnames
Apr  9 14:19:15 h2xx postfix-local[25122]: postfix-local: from=watchdog@h2xx.stratoserver.net, to=xx@xxs.com, dirname=/var/qmail/mailnames
Apr  9 14:19:33 h2xx postfix-local[25124]: postfix-local: from=watchdog@h2xx.stratoserver.net, to=xx@xxs.com, dirname=/var/qmail/mailnames
Apr  9 14:19:33 h2xx postfix-local[25111]: postfix-local: from=watchdog@h2xx.stratoserver.net, to=xx@xxs.com, dirname=/var/qmail/mailnames
Apr  9 14:19:33 h2xx postfix-local[25112]: postfix-local: from=watchdog@h2xx.stratoserver.net, to=xx@xxs.com, dirname=/var/qmail/mailnames
Apr  9 14:19:33 h2xx postfix-local[25127]: postfix-local: from=watchdog@h2xx.stratoserver.net, to=xx@xxs.com, dirname=/var/qmail/mailnames
 
Last edited:
Hm, na schau an,
bei den Abstürzen davor habe ich folgendes im Maillog gefunden - hat jemand eine Idee, wo ich weiterschauen könnte?
Code: 
Apr  9 12:29:58 h2xx check-quota[12573]: Starting the check-quota filter...

Apr  9 12:29:58 h2xx psa-pc-remote[22986]: handlers_stderr: SKIP
Apr  9 12:29:58 h2xx psa-pc-remote[22986]: SKIP during call 'check-quota' handler
Apr  9 12:29:58 h2xxdovecot: master: Warning: Killed with signal 15 (by pid=12572 uid=0 code=kill)
Apr  9 12:29:58 h2xx spf[12574]: Starting the spf filter...
Apr  9 12:29:58 h2xx spf[12574]: SPF result: pass
Apr  9 12:29:58 h2xx spf[12574]: SPF status: PASS
Apr  9 12:29:58 h2xx psa-pc-remote[22986]: handlers_stderr: PASS
Apr  9 12:29:59 h2xx psa-pc-remote[22986]: PASS during call 'spf' handler

Apr  9 12:56:18 h2xx dovecot: master: Warning: Killed with signal 15 (by pid=14969 uid=0 code=kill)

Apr  9 13:43:33 h2xx dovecot: master: Warning: Killed with signal 15 (by pid=20684 uid=0 code=kill)
Apr  9 13:43:42 h2xx dovecot: anvil: Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)
Apr  9 13:43:47 h2xx dovecot: config: Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)
Apr  9 13:44:00 h2xx dovecot: log(15171): Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)
Apr  9 13:44:00 h2xx dovecot: log(15171): Warning: Shutting down logging for 'anvil: ' with 1 clients
Apr  9 13:44:00 h2xxdovecot: log(15171): Warning: Shutting down logging for 'config: ' with 1 clients

Und hier ist auch gleich der Apache mit abgetreten - das war im syslog:
Code: 
Apr  9 16:08:03 h2xx postfix/anvil[13495]: statistics: max connection rate 1/60s for (smtp:45.125.65.42) at Apr  9 15:50:11
Apr  9 16:08:03 h2xx postfix/anvil[13495]: statistics: max connection count 1 for (smtp:45.125.65.42) at Apr  9 15:50:11
Apr  9 16:08:03 h2xx postfix/anvil[13495]: statistics: max cache size 3 at Apr  9 15:51:00
Apr  9 16:08:30 h2xxpostfix/master[1987]: warning: unix_trigger_event: read timeout for service private/tlsmgr
Apr  9 16:08:48 h2xx CRON[13798]: (root) CMD ([ -x /opt/psa/admin/sbin/backupmng ] && /opt/psa/admin/sbin/backupmng >/dev/null 2>&1)
Apr  9 16:08:48 h2xx postfix/qmgr[23036]: B0B6420729: from=<watchdog@h2xx.stratoserver.net>, size=751, nrcpt=1 (queue active)
Apr  9 16:09:41 h2xx systemd[1]: Starting Clean php session files...
Apr  9 16:10:44 h2xx CRON[13801]: (psaadm) CMD (/opt/psa/admin/bin/php -dauto_prepend_file=sdk.php '/opt/psa/admin/plib/modules/nextcloud/scripts/refresh-instances-slow.php')
Apr  9 16:10:44 h2xx systemd[1]: Started Clean php session files.
Apr  9 16:10:51 h2xxCRON[13800]: (psaadm) CMD (/opt/psa/admin/bin/php -dauto_prepend_file=sdk.php '/opt/psa/admin/plib/modules/nextcloud/scripts/refresh-instances-fast.php')
Apr  9 16:11:10 h2xx CRON[13804]: (psaadm) CMD (/opt/psa/admin/bin/php -dauto_prepend_file=sdk.php '/opt/psa/admin/plib/modules/nextcloud/scripts/refresh-instances-fast.php')
Apr  9 16:11:44 h2xx monit[551]: GENERIC: error receiving data -- Resource temporarily unavailable
Apr  9 16:11:48 h2xx monit[551]: 'apache' failed protocol test [generic] at INET[127.0.0.1:7080].
Apr  9 16:11:48 h2xx monit[551]: 'apache' trying to restart
Apr  9 16:11:48 h2xx monit[551]: 'apache' stop: /opt/psa/admin/bin/websrvmng
Apr  9 16:11:48 h2xx CRON[13806]: (psaadm) CMD (/opt/psa/admin/bin/php -dauto_prepend_file=sdk.php '/opt/psa/admin/plib/modules/diskspace-usage-viewer/scripts/files.php')
Apr  9 16:11:49 h2xx CRON[13805]: (psaadm) CMD (/opt/psa/admin/bin/php -dauto_prepend_file=sdk.php '/opt/psa/admin/plib/modules/nextcloud/scripts/nextcloud-cron.php')
Apr  9 16:11:49 h2xx systemd[1]: Stopping The Apache HTTP Server...
Apr  9 16:12:07 h2xx postfix/smtpd[13786]: connect from unknown[45.125.65.35]
Apr  9 16:12:20 h2xx monit[551]: 'apache' start: /opt/psa/admin/bin/websrvmng
Apr  9 16:12:54 h2xx systemd[1]: Stopped The Apache HTTP Server.
Apr  9 16:12:57 h2xx postfix/smtpd[13786]: lost connection after CONNECT from unknown[45.125.65.35]
Apr  9 16:13:13 h2xx wdcollect[2233]: Connection to server has been established.
Apr  9 16:13:13 h2xx monit[551]: monit: embed_ssl_socket(): Openssl read timeout error!
Apr  9 16:13:13 h2xx monit[551]: 'dovecot' failed, cannot open a connection to INET[localhost:995]
Apr  9 16:13:13 h2xx monit[551]: 'dovecot' trying to restart
Apr  9 16:13:13 h2xx monit[551]: 'dovecot' stop: /opt/psa/admin/bin/mailmng-service
Apr  9 16:13:13 h2xx monit[551]: 'dovecot' start: /opt/psa/admin/bin/mailmng-service
Apr  9 16:13:13 h2xx monit[551]: 'dovecot' failed, cannot open a connection to INET[localhost:110]
Apr  9 16:13:13 h2xx monit[551]: 'dovecot' trying to restart
Apr  9 16:13:13 h2xx monit[551]: 'dovecot' failed, cannot open a connection to INET[localhost:993]
Apr  9 16:13:13 h2xx monit[551]: 'dovecot' trying to restart
Apr  9 16:13:13 h2xx monit[551]: 'dovecot' failed, cannot open a connection to INET[localhost:143]
Apr  9 16:13:13 h2xx monit[551]: 'dovecot' trying to restart
Apr  9 16:13:13 h2xx systemd[1]: Stopping Dovecot IMAP/POP3 email server...
Apr  9 16:13:13 h2x postfix/smtpd[13786]: disconnect from unknown[45.125.65.35] commands=0/0
 
Warum monit meint Dovecot sei neu zu starten, weiß ich auch nicht, weil ich mein System anders überwache. Plesks Advanced Monitoring ist nicht so der Hit. Und falls du Plesks Grafana installiert hast, schmeiß das raus. Das frisst über die Zeit massiv Ressourcen bei lokalen Verbindungen.

Ich seh’ da nix bei dir von Angriffen.
Du solltest mal über watch "netstat -Wtp" schauen was da passiert.

Und auch was da so and TCP und UDP-Paketen anlandet, dann siehst eher ob irgendjemand dich mit Netzerk-Paketen zumüllen will.
Weißt du wie man sowas überwacht?
 
Last edited:
Es hilft relativ wenig, wenn du nur einzelne Log-Zeilen hier rein kopierst und dazwischen immer wieder welche weg lässt. Manchmal sieht man im Mail-Log nur die Auswirkungen (z.B. Dovecot wird beendet), die Ursache steht aber in einem anderen Log (wenn sie überhaupt mitgelogt wird). Auch Logzeilen, die gar nichts mit dem Mailserver zu tun haben, können wichtig sein. Irgendwas scheint auf deinem System ja dem Dovecot die Anweisung zu geben, sich zu beenden.
Die in den oben aufgeführten Log-Snippseln zu findende IP-Adresse würde ich jetzt erst mal nicht überbewerten, solche Logzeilen mit diveren IPs dürfte jeder regelmäßig auf seinem Server finden, dass ist ein geiwsses Grundrauschen (automatische Scans, etc.)
 
Super, vielen Dank für die Tipps - ich habe mir gestern die Nacht um die Ohren geschlagen und auch heute alles mögliche umgestellt, z.B. alle Emailpostfächer (die eigentlich nur Weiterleiter waren) mit Passwörtern versehen (das war vorher nicht so, weil ich dachte als Weiterleiter wäre das egal). Und ich habe das Admin-Postfach nicht mehr als Weiterleiter, sondern als Postfach, das ich per Pop3 anrufe. Da sollten nämlich zwischen 15 und 40 Mails pro Stunde weitergeleitet werden, warum auch immer.
Seitdem war es stabil - bis gerade eben, dann ist der Dovecot wieder abgeschmiert.
Ich habe Grafana jetzt mal deaktiviert. Den Tipp mit watch "netstat -WtP" habe ich mal getestet - hier das Ergebnis anonymisiert:

Code: 
tcp        0      0 hxx.stratoserver.net:ftp 84.17.xxxx:3118       SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp 48.cust-C00.xxxx:11820 SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp x5f76xx.dyn.telefxxxx:57942 SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp 30.128-17-84.wxxx.net:28858 SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp 84.17.xxx:41932      SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp 84.17.xxx:48031      SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp 238.cust-B32.wxxx.net:2927 SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp 242.cust-B32.wxxx.net:42605 SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp 84.17.xxx:29303     SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp 248.cust-C00.wxxx.net:5992 SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp 84.17.xxx:32874     SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp 84.17.1xxx:23056     SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp 212.cust-C00.wxxx.net:60246 SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp 84.17.xxx:17763     SYN_RECV    -

tcp        0      0 hxx.stratoserver.net:ftp 84.17.xxx:39379     SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:ftp 84.17.xxx:476345     SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:https 84.17.xxx:48703     SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:https 134.cust-D00.wxxx.net:16410 SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:https 84.17xxx:20315     SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:https 152.cust-B32.wxxx.net:32116 SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:https smtp.parlemexxxx.be:6148 SYN_RECV    -
tcp        0      0 hxx.stratoserver.net:https 84.17.xxx:61844     SYN_RECV    -V    -
tcp        0      0 hxx.stratoserver.net:https 61.cust-D00.wxxx.net:33679 SYN_RECV
Die Ftp-Dinger müssten 1x mein Server zu Hause sein und 8 IP-Kameras. Die restlichen 5 Verbindungen kann ich mir nicht erklären.
Und auch was da so andTCP und UDP-Paketen anlandet, dann siehst eher ob irgendjemand dich mit Netzerk-Paketen zumüllen will.
Weißt du wie man sowas überwacht?
Click to expand...
Ich habe mal mit Wireshark lokal herumexperementiert, aber das bringt mir auf dem Server wohl eher nichts - über einen Tipp wäre ich dankbar.

Morgen schaue ich die anderen Logfiles noch nach Auffälligkeiten durch. Herzlichen Dank nochmal für alle Tipps!
 
docb said:
Die Ftp-Dinger müssten 1x mein Server zu Hause sein und 8 IP-Kameras. Die restlichen 5 Verbindungen kann ich mir nicht erklären.
Click to expand...
Die IP bei dir zushaue solltest du kennen, damit kannst du deine Verbindungen identifizieren. Bezüglich Rests: Dein Server ist auch für alle anderen im Internet erreichbar und es gibt immer welche, die eine Verbindung aufbauen, nicht nur per FTP, sondern auch über diverse andere Ports.
Manchmal hilft es auch, dass der Syslog-Daemon alles ungefiltert in eine einzelnen Logdatei schreibt - bei rsyslog geht das z.B. mit
Code: 
*.*       /var/log/allmessages
in der Konfiguration - die Datei kann aber schnell sehr groß werden, daher nur bei Bedarf aktivieren und regelmäßig wegrotieren lassen. Dann fehlen dir in der Datei nur noch die Logs von Programmen, die nicht über den Syslog-Daemon loggen.
 
Top, danke für den Tipp mit dem Syslog-Daemon. Die Mailgeschichte scheint sich beruhigt zu haben, allerdings geht der Server trotzdem dauernd in die Knie - das ist echt komisch, denn der sollte schon was können (ist von Strato ein Virtueller Server Linux V10, Traffic Unlimited,4 vCores, 8 GB RAM, 100 GB SSD, 100 Mbit/s Anbindung). Ich habe über den Support mal ein Upgrade auf einen iV30 beantragt (6 vCores, 6 GB RAM, 300 GB SSD, 500 Mbit/s Anbindung), dass sollte doch für ein bisschen Wordpress, FTP-Empfang und Mini-Nextcloud dicke reichen.
Ich habe ja jetzt dank Eurem Tipp das Advanced Monitoring runtergeschmissen (da war aber - bis auf den Mailserver - überall immer noch gut Luft). Wenn ich mir jetzt den Ressourcenverbrauch über Watchdog Statistiken oder über die Konsole mit top anschaue, sehe ich immer noch nichts Auffälliges - in der Regel 80% CPU ungenutzt, 2 GB RAM frei. Hat jemand eine Idee, wie ich rausfinden kann, warum der Server jetzt so in die Knie geht. Der Seitenaufbau der Wordpressseite ist teilweise ein Graus und ich habe oft nginx 504 Gateway Time-outs.

Die einzig auffälligen bei Top sind imemr mal wieder die hier, aber da ist ja immer noch genug Luft:
PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
23368 serveru+ 20 0 575084 90776 56632 S 10,1 1,1 0:01.91 php-fpm7.2
23356 serveru+ 20 0 572460 67388 37576 S 7,1 0,8 0:01.15 php-fpm7.2
23367 serveru+ 20 0 495784 73232 45852 S 2,9 0,9 0:01.23 php-fpm7.2

PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
386 root 20 0 1203264 28876 13016 S 1,7 0,3 16:22.37 containerd
23357 serveru+ 20 0 75520 6348 4528 R 1,0 0,1 0:00.63 in.proftpd
23358 serveru+ 20 0 75516 6348 4528 S 1,0 0,1 0:00.42 in.proftpd
 
Eigentlich sollte dein jetziger Server schon recht gut klar kommen. Du solltest dir auch mal anschauen, wie sich die CPU-Last verteilt - ob System, User, Wait usw. - zeigt dir top ja an. Wenn immer wieder bei, wait Last steht, kann es sein, dass das IO-System deines Servers nicht nachkommt. Da kann dann z.B. iotop helfen, den Übeltäter zu finden. Du kannst natürlich auch auf einem Hostsystem bei Strato gelandet sein, was von anderen Kunden schon gut ausgelastet ist - du hast ja keine dedizierten Resourcen wie bei einem Hardware-Server. Und mit den Webcams wil ja schon ein recht konstanter Datenstrom weggeschrieben werden - das erzeugt natürlich schon einiges an Last, auch bei geringer Auslösung.
 
Mann, es ist zum Haare raufen. Jede dritte Anfrage wird mit einem nginx 504 Gateway Time-out beantwortet. Bis die Seiten geladen wurden, dauert es ewig. Vermutlich ist das Hostsystem tatsächlich am Limit, denn bei mir schaut es doch echt gemütlich aus:
top - 14:05:01 up 19:17, 1 user, load average: 0,18, 0,15, 0,17
Tasks: 109 gesamt, 1 laufend, 108 schlafend, 0 gestoppt, 0 Zombie
%CPU(s): 1,2 be, 1,3 sy, 0,0 ni, 97,4 un, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Spch : 8388608 gesamt, 67508 frei, 898148 belegt, 7422952 Puff/Cache
KiB Swap: 0 gesamt, 0 frei, 0 belegt. 7354480 verfü Spch

Wobei gerade, wenn die Seite wieder einen timeout produziert schaut es telweise so aus:
PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
24173 serveru+ 20 0 491596 66308 40252 S 15,6 0,8 0:00.56 php-fpm7.2
24147 serveru+ 20 0 493644 68688 42268 S 14,6 0,8 0:00.71 php-fpm7.2
24353 serveru+ 20 0 485492 49428 30060 S 11,3 0,6 0:00.34 php-fpm7.2
24170 serveru+ 20 0 491404 52052 28124 S 8,0 0,6 0:00.48 php-fpm7.2
24171 serveru+ 20 0 485324 53988 34328 S 8,0 0,6 0:00.35 php-fpm7.2
640 mysql 20 0 799864 179068 7320 S 3,3 2,1 3:50.55 mysqld
8129 www-data 20 0 2209220 36652 2840 S 3,3 0,4 0:17.64 apache2
24148 serveru+ 20 0 75516 6348 4528 S 1,7 0,1 0:00.38 in.proftpd
293 root 20 0 470904 8320 5692 S 1,3 0,1 1:03.10 php-fpm7.2
386 root 20 0 1203264 28864 13004 S 1,3 0,3 16:33.91 containerd
8101 www-data 20 0 2209360 36480 2716 S 1,3 0,4 0:12.34 apache2
24135 serveru+ 20 0 75520 6352 4528 S 1,0 0,1 0:00.34 in.proftpd
24150 psaadm 20 0 446356 17708 11684 S 1,0 0,2 0:00.10 sw-engine-fpm
17848 nginx 20 0 35304 4684 1704 S 0,7 0,1 0:07.57 nginx
22396 root 20 0 38820 1844 1264 R 0,7 0,0 0:04.17 top

Was meinst du denn mit
wie sich die CPU-Last verteilt - ob System, User, Wait usw. - zeigt dir top ja an. Wenn immer wieder bei, wait Last steht, kann es sein, dass das IO-System deines Servers nicht nachkommt.
Click to expand...
? Woran sehe ich das denn?

iotop wenn ich auf der Konsole eingebe, passiert übrigens gar nichts... aber aktuell habe ich auch nur timeouts. Befürchte irgendwas stimmt da ganz und gar nicht... aber ich tippe aufs Hostsystem.
 
So, jetzt klappt iotop. Ich befürchte, das ging vorher nicht, weil die Maschine so am Limit war, da wird auch die Verbindung über die Konsole zur Hölle und saulangsam. Ist da irgendwas auffällig? Weil da so oft popuser und postfix sehe - es gibt eigentlich nur ein einziges Postfach. Hat jemand eine Idee?
Viele Grüße


7695 be/4 rootl 154.22 K/s 0.00 B/s 0.00 % 74.66 % find / -maxdepth 7 -path /proc -prune -o -path /sys -prune -o -type f -size +50 -printf %s t%Tc t%p
17848 be/4 nginx 3.92 K/s 0.00 B/s 0.00 % 3.88 % nginx: worker process
7178 be/4 mysql 3.92 K/s 3.92 K/s 0.00 % 2.88 % mysqldadd/287330]
7152 be/4 mysql 0.00 B/s 0.00 B/s 0.00 % 0.00 % mysqlder]
7650 be/4 mysql 0.00 B/s 0.00 B/s 0.00 % 0.00 % mysqldd-udevd
7652 be/4 mysqlgd- 23.53 K/s 0.00 B/s 0.00 % 0.00 % mysqldgd -n [rs:main Q:Reg]
7658 be/4 mysql 0.00 B/s 0.00 B/s 0.00 % 0.00 % mysqldf
7546 be/4 serverus 54.89 K/s 0.00 B/s 0.00 % 0.00 % php-fpm: pool xxr.de
7643 be/4 serverus 160.76 K/s 0.00 B/s 0.00 % 0.00 % php-fpm: pool xx.de (/etc/sw-engine/sw-engine-fpm.conf)
292 be/4 rootfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd/287330]inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
363 be/4 rootfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % [khelper]mote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
370 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
371 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
372 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
373 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
374 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
372 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
373 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
374 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
329 be/4 syslog 0.00 B/s 0.00 B/s 0.00 % 0.00 % rsyslogd -n [rs:main Q:Reg]tc/php/7.2/fpm/php-fpm.conf)
309 be/4 messageb 0.00 B/s 0.00 B/s 0.00 % 0.00 % dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
339 be/4 rootogeb 0.00 B/s 0.00 B/s 0.00 % 0.00 % sw-collectd -fn:imuxsock]dress=systemd: --nofork --nopidfile --systemd-activation --syslog-only

KiB Spch : 8388608 gesamt, 204092 frei, 841548 belegt, 7342968 Puff/Cache
KiB Swap: 0 gesamt, 0 frei, 0 belegt. 7411120 verfü Spch

PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
top - 16:00:23 up 21:12, 1 user, load average: 0,35, 0,37, 0,24
Tasks: 72 gesamt, 1 laufend, 68 schlafend, 2 gestoppt, 1 Zombie
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
7548 be/4 mysql 0.00 B/s 0.00 B/s 0.00 % 0.00 % mysqldz
7658 be/4 mysql 0.00 B/s 0.00 B/s 0.00 % 0.00 % mysqldadd/287330]7 -path /proc -prune -o -path /sys -prune -o -type f -size +50 -printf %s t%Tc t%p
8888 be/4 mysqlix 0.00 B/s 0.00 B/s 0.00 % 0.00 % mysqlder]
71 be/4 mysql 0.00 B/s 3.92 K/s 0.00 % 39.73 % systemd-journald
3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [khelper]
128 be/4 root 23.53 K/s 0.00 B/s 0.00 % 0.00 % systemd-udevd
136 be/4 systemd- 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd-networkd
275 be/4 root 54.89 K/s 0.00 B/s 0.00 % 0.00 % cron -f
276 be/4 serverus 160.76 K/s 0.00 B/s 0.00 % 0.00 % systemd-logind
284 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % sw-engine-fpm: master process (/etc/sw-engine/sw-engine-fpm.conf)
290 be/4 rostfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
369 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
370 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
371 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
372 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
373 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
374 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
293 be/4 root x 0.00 B/s 0.00 B/s 0.00 % 0.00 % php-fpm: master process (/etc/php/7.2/fpm/php-fpm.conf)
295 be/4 syslog 0.00 B/s 0.00 B/s 0.00 % 0.00 % rsyslogd -n
329 be/4 syslog 0.00 B/s 0.00 B/s 0.00 % 0.00 % rsyslogd -n [rs:main Q:Reg]
309 be/4 messageb 0.00 B/s 0.00 B/s 0.00 % 0.00 % dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
339 be/4 rootageb 0.00 B/s 0.00 B/s 0.00 % 0.00 % sw-collectd -fsystem --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
 
Ach und ich habe jetzt übrigens alle Cams abgestellt, also es werden nicht dauern parallel 8 FTP Ströme verarbeitet - jetzt muss der Server eigentlich nur noch Wordpress und Nextcloud bedienen. Na und Plesk natürlich. Aber er ist unendlich lahm, ich habe immer noch dauernd 504 Gateway Time-outs. Horror.
 
Wenn ich eine Seite aufrufe, dauert das Laden der Seite locker über 20 Sekunden, in der Regel tritt dann der Gateway Timeout auf. Da schauts dann übrigens so bei iotop aus:

PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL
top - 16:00:23 up 21:12, 1 user, load average: 0,35, 0,37, 0,24
Tasks: 72 gesamt, 1 laufend, 68 schlafend, 2 gestoppt, 1 Zombie
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
936 be/4 rooterus 35.38 K/s 1910.29 K/s 0.00 % 99.99 % sw-collectd -fxx.de
9025 be/4 psaadmus 3.93 K/s 0.00 B/s 0.00 % 99.99 % sw-engine -c /opt/psa/admin/conf/php.ini -dauto_prepend_file=sdk.php /opt/psa/admin/plib/modules/nextcloud/scripts/refresh-instances-fast.php
1610 be/4 root 10.00 B/s 0.00 B/s 0.00 % 99.99 % master -wournald
71 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd-journald
1612 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 99.99 % qmgr -l -t fifo -u
8142 be/4 www-data 0.00 B/s 0.00 B/s 0.00 % 99.99 % apache2 -k start
8127 be/4 www-data 0.00 B/s 0.00 B/s 0.00 % 99.99 % apache2 -k start
329 be/4 syslog 0.00 B/s 11.79 K/s 0.00 % 0.00 % rsyslogd -n [rs:main Q:Reg]
9024 be/4 mysql - 10.00 B/s 0.00 B/s 0.00 % 0.00 % mysqld
291 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % init -z
362 postfix 0.00 B psthreadd/287330]inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
3 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % [khelper]
371 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
372 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
373 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n
374 be/4 postfix 0.00 B/s 0.00 B/s 0.00 % 0.00 % psa-pc-remote -p inet:12768@127.0.0.1 -t 7210 -P /run/psa-pc-remote.pid -u postfix -g popuser -n

Übrigens das Einzige, das ich jemals manuell auf dem Server installiert habe, waren die PHP-Module intl und gmp. Kann es damit was zu tun haben? Denn der php-prozess scheint schon ganz schön viel IOs zu produzieren.
7695 be/4 root 207.05 K/s 0.00 B/s 0.00 % 29.59 % find / -maxdepth 7 -path /proc -prune -o -path /sys -prune -o -type f -size +50 -printf %s t%Tc t%p
8963 be/4 serverus 19.41 K/s 0.00 B/s 0.00 % 60.90 % php-fpm: pool xx.de
8973 be/4 serverus 0.00 B/s 0.00 B/s 0.00 % 50.78 % php-fpm: pool xx.de
8975 be/4 serverus 3.88 K/s 0.00 B/s 0.00 % 0.17 % php-fpm: pool xx.de
 
wie sich die CPU-Last verteilt - ob System, User, Wait usw. - zeigt dir top ja an. Wenn immer wieder bei, wait Last steht, kann es sein, dass das IO-System deines Servers nicht nachkommt.

Woran sehe ich das denn?
Click to expand...

Schau in top (nicht iotop) nach in den Kopfzeilen:

# top

top - 16:17:23 up 21 min, 2 users, load average: 0,71, 0,57, 0,44
Tasks: 176 total, 1 running, 175 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5,4 us, 1,2 sy, 0,0 ni, 93,3 id, 0,2 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem : 2578488 total, 968516 free, 993528 used, 616444 buff/cache
KiB Swap: 4317180 total, 4317180 free, 0 used. 1201208 avail Mem

Wenn der rot gekennzeichnete I/O-wait-Wert dauerhaft über 5-10 % ist, dann wartet der Server auf Resourcen(wahrscheinlich auf die Festplatte weniger wahrscheinlich aber auch möglich: Netzwerk).
 
greystone said:
Wenn der rot gekennzeichnete I/O-wait-Wert dauerhaft über 5-10 % ist, dann wartet der Server auf Resourcen(wahrscheinlich auf die Festplatte weniger wahrscheinlich aber auch möglich: Netzwerk).
Click to expand...
Ne, isser nicht.zeigt immer 0,0. Echk nervig. Auffällig ist aktuell eigentlich nur sw-enginge-fpm und php-fpm, die kommen immer mal wieder in die Top 3 der top-charts. An meiner Installation der PHP-Module intl und gmp mit apt-get install php7.3-gmp und apt-get install php-intl kann es nicht liegen? Nicht, dass ich da selber Mist gebaut habe - nicht auszuschließen ;-)
 
You must log in or register to reply here.
Back
Top