moin,
ich freu mich bei solchen problemen bei euch zu sein. sowas lernt man anscheint nur hier.
wir hatte grade ein problem mit srv01 tail /var/log/syslog [...] systemd[1]: Looping too fast. Throttling execution a little. [...] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789796#40 die lösung war systemctl daemon-reexec
hmm da hat systemd mit jounald anscheint einen bug!?
dannach habe ich noch php5-fpm neu getartet. meinen test nach geht alels wieder.
Zitat von picard freifunk@fr32k.de:
dannach habe ich noch php5-fpm neu getartet.
ich muss mich berichtigen bjo war auch zur gleichen zeit auf dem srv01 und schrieb mir eine mail auf dem srv das er auch neustartete.
btw: das ist auch ein riesen vorteil von user verwaltung: mails auf den srv ;-)
moin,
heute war es wieder soweit reboot von srv01 einige services kommen nicht hoch sudo systemctl restart php5-fpm.service sudo systemctl restart zerobin.service sudo systemctl restart spamassassin.service
immer noch keine lösung in sicht?
Am Mittwoch, den 06.01.2016, 08:39 +0100 schrieb picard via Admin:
moin,
heute war es wieder soweit reboot von srv01 einige services kommen nicht hoch sudo systemctl restart php5-fpm.service sudo systemctl restart zerobin.service sudo systemctl restart spamassassin.service
immer noch keine lösung in sicht?
Wie wäre es, wenn du eine Lösung suchst? ;)
Am 6. Januar 2016 10:44:25 MEZ, schrieb picard freifunk@fr32k.de:
Am 06.01.2016 um 09:43 schrieb Bjoern Franke via Admin:
Wie wäre es, wenn du eine Lösung suchst? ;)
waren meine ML emails in den letzten wochen zu dem thema spam?
Du hast öfters festgestellt, dass die Dienste Probleme bereiten.
Wie wäre eine temporäre Lösung, nach dem Systemstart die Dienste einfach neustarten zu lassen?
Am 6. Januar 2016 10:48:38 MEZ, schrieb Bjoern Franke via Admin admin@lists.ffnw.de:
Am 6. Januar 2016 10:44:25 MEZ, schrieb picard freifunk@fr32k.de:
Am 06.01.2016 um 09:43 schrieb Bjoern Franke via Admin:
Wie wäre es, wenn du eine Lösung suchst? ;)
waren meine ML emails in den letzten wochen zu dem thema spam?
Du hast öfters festgestellt, dass die Dienste Probleme bereiten.
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Zitat von picard freifunk@fr32k.de:
dannach habe ich noch php5-fpm neu getartet. meinen test nach geht alels wieder.
nicht ganz, nginx ist noch ganz schön langsam. den habe ich auch noch neu gestartet mit php5-fpm zusammen.
aber ihrgendwas läuft da immer noch nicht ganz rund. lassen wir der maschine noch mal paar minuten... so langsam wird es wieder normal.
Zitat von picard freifunk@fr32k.de:
aber ihrgendwas läuft da immer noch nicht ganz rund. lassen wir der maschine noch mal paar minuten... so langsam wird es wieder normal.
systemctl --failed hat mir gezeigt das ein paar services nicht gestartet wurden. diese habe ich von hand gestartet, aber immer noch läuft srv01 bescheiden (nginx).
journalctl -b zeigte mir das wie immer php5-fpm und einige andere dingen icht hoch bekommen sind nach dem reboot heute nacht.
wieso eigendlich ein reboot? wurde der manuell gemacht oder der srv01 alleine?
/lib/systemd/system/php5-fpm.service habe ich bearbeitet, wasi ch gemacht habe steht kommentiert drin,
ich mache mal einen (kontrollierten) reboot um zu sehen ob jetzt alles hoch kommt. ich bin weiter dran.
Zitat von picard freifunk@fr32k.de:
systemctl --failed
auch nach dem reboot kammen einige servies nicht hoch. die mussten von hand gestartet werden. php5-fpm, zerobin, spamassassin
journalctl -b
Dez 23 13:52:14 srv01.ffnw.de cron[836]: Error: bad username; while reading /etc/cron.d/partkeepr
Dez 23 13:52:15 srv01.ffnw.de smartd[821]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices Dez 23 13:52:15 srv01.ffnw.de smartd[821]: Problem creating device name scan list Dez 23 13:52:15 srv01.ffnw.de smartd[821]: In the system's table of devices NO devices found to scan
Dez 23 13:52:21 srv01.ffnw.de rc.local[838]: sh: 0: Can't open /etc/fastd/ffol/up.sh
Dez 23 13:52:21 srv01.ffnw.de systemd[1]: rc-local.service: control process exited, code=exited status=127 Dez 23 13:52:21 srv01.ffnw.de systemd[1]: Failed to start /etc/rc.local Compatibility. Dez 23 13:52:21 srv01.ffnw.de systemd[1]: Unit rc-local.service entered failed state.
Dez 23 13:52:27 srv01.ffnw.de spamass-milter[1014]: spamass-milter 0.3.2 starting
Dez 23 13:53:34 srv01.ffnw.de systemd[1]: php5-fpm.service start operation timed out. Terminating. Dez 23 13:53:39 srv01.ffnw.de sshd[1365]: Connection closed by 62.75.151.93 [preauth] Dez 23 13:53:46 srv01.ffnw.de systemd[1]: spamassassin.service start operation timed out. Terminating. Dez 23 13:53:46 srv01.ffnw.de systemd[1]: Failed to start Perl-based spam filter using text analysis. Dez 23 13:53:46 srv01.ffnw.de systemd[1]: Unit spamassassin.service entered failed state.
Dez 23 13:55:04 srv01.ffnw.de systemd[1]: php5-fpm.service stop-final-sigterm timed out. Killing. Dez 23 13:55:05 srv01.ffnw.de systemd[1]: php5-fpm.service: main process exited, code=killed, status=9/KILL Dez 23 13:55:05 srv01.ffnw.de systemd[1]: Failed to start The PHP FastCGI Process Manager. Dez 23 13:55:05 srv01.ffnw.de systemd[1]: Unit php5-fpm.service entered failed state.
das müssen wir uns unbedingt anschauen!
Zitat von picard freifunk@fr32k.de:
journalctl -b
Dez 23 13:52:14 srv01.ffnw.de cron[836]: Error: bad username; while reading /etc/cron.d/partkeepr
habe erstmal "root" eingetragen. es sollte einen eigenen user geben, root hat zu viel rechte.
Dez 23 13:52:15 srv01.ffnw.de smartd[821]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices Dez 23 13:52:15 srv01.ffnw.de smartd[821]: Problem creating device name scan list Dez 23 13:52:15 srv01.ffnw.de smartd[821]: In the system's table of devices NO devices found to scan
sudo systemctl disable smartd.service
Dez 23 13:52:21 srv01.ffnw.de rc.local[838]: sh: 0: Can't open > /etc/fastd/ffol/up.sh
den path /etc/fastd/ffol gibt es nicht mehr! aber /etc/fastd/ffnw/up.sh
habe /etc/ff/ffolgate.sh abgeändert auf /etc/fastd/ffnw/up.sh
Dez 23 13:52:27 srv01.ffnw.de spamass-milter[1014]: spamass-milter 0.3.2 starting
Dez 23 13:53:34 srv01.ffnw.de systemd[1]: php5-fpm.service start operation timed out. Terminating. Dez 23 13:53:46 srv01.ffnw.de systemd[1]: spamassassin.service start operation timed out. Terminating. Dez 23 13:53:46 srv01.ffnw.de systemd[1]: Failed to start Perl-based spam filter using text analysis. Dez 23 13:53:46 srv01.ffnw.de systemd[1]: Unit spamassassin.service entered failed state.
Dez 23 13:55:04 srv01.ffnw.de systemd[1]: php5-fpm.service stop-final-sigterm timed out. Killing. Dez 23 13:55:05 srv01.ffnw.de systemd[1]: php5-fpm.service: main process exited, code=killed, status=9/KILL Dez 23 13:55:05 srv01.ffnw.de systemd[1]: Failed to start The PHP FastCGI Process Manager. Dez 23 13:55:05 srv01.ffnw.de systemd[1]: Unit php5-fpm.service entered failed state.
hierzu bitte hilfe
Am 23.12.2015 um 16:29 schrieb picard:
journalctl -b
/etc/rc.local das GW zeugs habe ich auskommentiert
habe erneut noch mal rebootet es wird immer besser
aber
php5-fpm.service start operation timed out. Terminating. spamassassin.service start operation timed out. Terminating.
die beiden services wollen nicht beim booten hoch kommen.
dann gibt es aktuell noch ein problem der ping auf den srv01 ist schlecht.
dann gibt es aktuell noch ein problem der ping auf den srv01 ist schlecht.
Ist er?
bjo@ostrea ~ % mtr -r srv01.ffnw.de Start: Wed Dec 23 21:23:02 2015 HOST: ostrea Loss% Snt Last Avg Best Wrst StDev 1.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 2.|-- 10.96.89.154 0.0% 10 62.8 73.2 45.9 146.2 30.1 3.|-- 89.15.232.17 0.0% 10 82.7 57.1 42.2 93.1 18.0 4.|-- 89.15.232.3 0.0% 10 80.6 54.5 42.1 80.6 14.4 5.|-- 213.20.91.225 0.0% 10 89.8 62.1 39.7 89.8 16.0 6.|-- et-7-1-0- 0.0001.prrx.13.f 0.0% 10 59.7 67.0 49.9 93.1 16.3 7.|-- et-7-1-0-0.0001.prrx.13.f 0.0% 10 56.2 85.0 50.1 139.6 27.9 8.|-- gw-decix.ffm.netcup.net 0.0% 10 53.8 85.1 53.8 178.5 36.3 9.|-- srv01.ffnw.de 0.0% 10 65.6 84.9 52.6 187.9 43.6
Am 23.12.2015 um 21:24 schrieb Bjoern Franke:
dann gibt es aktuell noch ein problem der ping auf den srv01 ist schlecht.
Ist er?
war er, bei 1k pings war der Avg bei ~200ms. deswegen auch im anderen tread hilkos odoo sei kapput
viel wichtiger ist aber was machen wir mit den services die nicht hoch kommen? php5-fpm.service start operation timed out. Terminating. spamassassin.service start operation timed out. Terminating.
Zitat von Bjoern Franke bjo@nord-west.org:
dann gibt es aktuell noch ein problem der ping auf den srv01 ist schlecht.
Ist er?
heute ist der ping zu srv01 und von srv01 weg soweit normal, aber packet verluste nahe 10% in beide richtungen.
Zitat von picard freifunk@fr32k.de:
heute ist der ping zu srv01 und von srv01 weg soweit normal, aber packet verluste nahe 10% in beide richtungen.
(h)top, iftop, nmon CPU/RAM, DiskIO und Netzwerk nichts zeigt wieso der Vserver so langsam ist.
aus meiner sicht zum srv01 pic@nas:~$ mtr -c 100 -r srv01.ffnw.de HOST: nas Loss% Snt Last Avg Best Wrst StDev 1.|-- openwrt.lan 0.0% 100 0.4 0.3 0.3 0.4 0.0 2.|-- firewall.lan 0.0% 100 0.4 0.5 0.4 0.8 0.1 3.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 4.|-- 83-169-159-134.static.sup 0.0% 100 8.1 9.6 7.4 35.1 3.4 5.|-- ip5886c327.dynamic.kabel- 0.0% 100 19.2 13.1 8.0 75.4 10.0 6.|-- ip5886c329.dynamic.kabel- 0.0% 100 16.2 17.2 15.5 22.6 1.4 7.|-- ip5886ee15.dynamic.kabel- 0.0% 100 21.7 22.8 19.4 28.3 1.7 8.|-- ip5886ca34.dynamic.kabel- 0.0% 100 25.0 25.0 23.6 27.5 0.8 9.|-- ip5886eacf.dynamic.kabel- 0.0% 100 22.5 22.8 21.4 27.7 0.9 10.|-- ae0-429.fra20.core-backbo 0.0% 100 24.1 24.0 19.1 45.5 4.1 11.|-- ae3-2003.nbg40.core-backb 0.0% 100 30.3 31.3 27.8 63.8 4.1 12.|-- gw-cb40.nbg.netcup.net 0.0% 100 30.6 27.2 23.7 58.0 4.8 13.|-- srv01.ffnw.de 0.0% 100 30.4 32.4 28.9 63.9 6.1
vom srv01 ins internet picard@srv01 ~ % mtr -c 100 -r google.de Start: Mon Dec 28 21:21:26 2015 HOST: srv01.ffnw.de Loss% Snt Last Avg Best Wrst StDev 1.|-- 2a03:4000:6:8000::2 0.0% 100 0.4 19.0 0.3 509.9 75.3 2.|-- 100ge7-2.core1.fra1.he.ne 1.0% 100 4.0 42.1 4.0 492.2 74.6 3.|-- de-cix20.net.google.com 0.0% 100 4.3 28.6 3.9 617.1 77.7 4.|-- 2001:4860::1:0:abf5 0.0% 100 4.6 22.5 4.3 470.6 58.5 5.|-- 2001:4860:0:1::6eb 0.0% 100 130.2 23.6 4.6 318.1 54.5 6.|-- 2a00:1450:4001:806::2003 1.0% 100 4.9 22.1 4.4 666.7 74.4
wieso ist der srv01 so langsam? hat der KVM wo der srv drauf läuft ein problem? wie kann ich probleme weiter eingränzen?
Am Montag, 28. Dezember 2015, 21:24:29 CET schrieb picard:
(h)top, iftop, nmon CPU/RAM, DiskIO und Netzwerk nichts zeigt wieso der Vserver so langsam ist.
Hi,
das Problem kann ich nachvollziehen. Ein paar Ideen: * Ist die Maschine auf der die VM läuft überlastet? CPU Steal in Munin anschauen. Sieht normal bzw. quasi nicht vorhanden aus. Da dürfte alles ok sein. * Problem fühlt sich nach disk io an. In Munin mal die disk io der Server vergleichen. Srv01 hat eine 2-3x höhere IO als andere Server. Sieht für mich noch nicht kritisch aus, könnte aber ein Grund sein. ** Netmon läuft wieder soweit ich weiß. Ich weiß aber nicht wo, ich sehe nur die DB-Requests auf srv07. Netmon generiert RRDs, die massiv disk io erzeugen. Ich hatte das mal mit rrdcached gelöst, weiß aber nicht wie da der Stand ist. ** Munin selbst generiert ja auch einiges an rrds. Wird hier rrdcached verwendet? Wenn nein, ist das auch eine Quelle für hohes disk io * Andere Möglichkeiten: ** Es sieht so aus als würde der Server HTTP Anfragen nur einzeln beantworten. Gibts im nginx Probleme mit irgendeiner Einstellung a la MaxConnections oder MaxParallelRequests?
Das ist erstmal nur ins Blaue geraten, weil ich einen konkreten Verursacher gestern auch nicht direkt ausmachen konnte.
LG Clemens
Hi,
ich denke auch, dass es am Netcup Host liegt. Am 29.12.2015 um 12:19 schrieb Clemens John:
Netmon läuft wieder soweit ich weiß. Ich weiß aber nicht wo, ich sehe nur die DB-Requests auf srv07. Netmon generiert RRDs, die massiv disk io erzeugen. Ich hatte das mal mit rrdcached gelöst, weiß aber nicht wie da der Stand ist.
Netmon läuft auf srv18.
Wollen wir hier bei Netcup mal ein Supportticket aufmachen bzgl. der IO´ s?
Vg,
Stefan
Am Dienstag, 29. Dezember 2015, 13:02:13 CET schrieb Stefan:
Wollen wir hier bei Netcup mal ein Supportticket aufmachen bzgl. der IO´
So, nach fünf Stunden Debugging bin ich mit meinem Latein dann auch am Ende...
Anfrage ist gerade raus: +++ Sehr geehrte Damen und Herren,
seit einiger Zeit haben wir Probleme mit der Performance des Systems v22015021996422995. Mehrere Administratoren haben unsererseits bereits versucht dem Problem auf den Grund zu gehen, bisher ohne Erfolg.
Auf dem System laufen verschiedene Web-Anwendungen (Wordpress, MoinMoin, Etherpad...) unter einem nginx mit php-fpm. Normalerweise performt diese Kombination sehr gut, derzeit haben wir jedoch große Probleme damit. Obwohl das System nahezu nicht belastet wird. Die Zugriffszahlen belaufen sich auf <1/Sekunde.
Konkret äußert sich das Problem in langen Antwortzeiten. Jedoch nicht nur bei Web-Anwendungen sondern auch beim Zugriff per SSH. In unserem Monitoring sind mir keine kritischen Werte aufgefallen. Ich hatte erst auf Disk-IO getippt, aber der Wert verhält sich völlig normal - auch beim direkten Messen mit ioping.
Bei der Beobachtung des Systems per top ist mir jedoch der Softirq-Wert aufgefallen. Dieser liegt zeitweise bei konstant 5-10% mit Spitzen bis 25%. Insbesondere wenn ein Zugriff erfolgt, entstehen diese Spitzen. Wir haben nun einen Großteil der Webanwendungen heruntergfahren, jedoch liegt der Wert weiterhin bei 3%. Das können wir uns nicht erklären und würden daher gerne einmal nachfragen ob es ein Problem mit dem Hostsystem gibt und wenn ja, ob Sie diesen Server auf ein anderes Hostsystem umziehen können.
Viele Grüße Clemens John +++
Viele Grüße Clemens
Zitat von Clemens John clemens.john@floh1111.de:
erstmal vielen dank das du dich beteiligst! hier zeigen sich mir probleme die ich bis dato noch nie gesehen habe bei linux auf einer art nett, aber auf der anderen art hilf los.
- Problem fühlt sich nach disk io an. In Munin mal die disk io der Server
vergleichen. Srv01 hat eine 2-3x höhere IO als andere Server. Sieht für mich noch nicht kritisch aus, könnte aber ein Grund sein.
das vermute ich auch. können wir auf der VM ihrgendwie das problem weiter eingrenzen? "nmon" hilft sonst immer sehr gut, weil es alles auf einen blick zeigt.
** Munin selbst generiert ja auch einiges an rrds. Wird hier rrdcached verwendet? Wenn nein, ist das auch eine Quelle für hohes disk io
gute idee, aber das problem hatten wir ja vor monaten gelöst.
picard@srv01 ~ % systemctl status rrdcached.service ? rrdcached.service - LSB: start the RRDtool data caching daemon Loaded: loaded (/etc/init.d/rrdcached) Active: active (running) since Mi 2015-12-23 19:26:15 CET; 5 days ago CGroup: /system.slice/rrdcached.service ??1155 /usr/bin/rrdcached -s munin -B -b /var/lib/munin/ -F -j /va...
picard@srv01 ~ % sudo systemctl restart rrdcached.service
picard@srv01 ~ % systemctl status rrdcached.service ? rrdcached.service - LSB: start the RRDtool data caching daemon Loaded: loaded (/etc/init.d/rrdcached) Active: active (running) since Di 2015-12-29 13:52:29 CET; 2s ago
und arbeitet immer noch.
- Andere Möglichkeiten:
** Es sieht so aus als würde der Server HTTP Anfragen nur einzeln beantworten. Gibts im nginx Probleme mit irgendeiner Einstellung a la MaxConnections oder MaxParallelRequests?
hast du an der nginx.conf was geändert? dort ist eine änderung drin, von wann ist die?
ich habe heute den hebel worker_connections 2048; geändert. aber das scheint auch nichts zu bewirken.
können wir gemeinsam noch mal überlegen ob oder was haben wir vor dem 23 o. 22.12 geändert? nicht das wir beim support als deppen da stehen.
-
Bjoern Franke -
Clemens John -
picard -
Stefan