task ... blocked for more than 120 seconds

Re(8): task ... blocked for more than 120 seconds

zeddicus — Tue, 03 Nov 2015 05:56:10 GMT

jo werd ich noch testen. Es deutet eh immer mehr auf die disk, da der server bei deaktiviertem journaling jetzt zum ersten mal seit langem 24h läuft

Re(8): task ... blocked for more than 120 seconds

zeddicus — Tue, 03 Nov 2015 05:56:10 GMT

jo werd ich noch testen. Es deutet eh immer mehr auf die disk, da der server bei deaktiviertem journaling jetzt zum ersten mal seit langem 24h läuft

Edit:
Jetzt sinds schon 48h

Re(7): task ... blocked for more than 120 seconds

MrT2004 — Mon, 02 Nov 2015 21:17:49 GMT

Dann würd ich das auch mal ohne Kompression probieren, ums einfach auszuschließen.

Was auch sein könnte, ist, dass die SSD darunter Probleme bei zu vielen Writes hat und/oder einfach Müll ist. Wobei die Schreibrate jetzt nicht arg hoch ist. Dennoch: Aussagekräftigen Schreibtest fahren (und sequentielle Nullbytes sind nicht aussagekräftig)! Kostet ein paar Minuten, das zu installieren und einen brauchbaren Benchmark zu starten...

Re(3): task ... blocked for more than 120 seconds

zeddicus — Mon, 02 Nov 2015 20:47:00 GMT

Caches, Buffers und dergleichen in der mysqld-config angepasst?

Tabellen-Indices passen? Slow Queries in MySQL
vorhanden?

Würde sich imho völlig anders auswirken

Re(3): task ... blocked for more than 120 seconds

zeddicus — Mon, 02 Nov 2015 20:47:00 GMT

Caches, Buffers und dergleichen in der mysqld-config angepasst?

Tabellen-Indices passen? Slow Queries in MySQL
vorhanden?

Würde sich völlig anders auswirken

Re(6): task ... blocked for more than 120 seconds

zeddicus — Mon, 02 Nov 2015 20:46:11 GMT

Da die Kompression lediglich die Datenbank betrifft, und es darum ging möglichst viele Disk I/O zu produzieren sollte das keinen Unterschied machen.

Re(5): task ... blocked for more than 120 seconds

MrT2004 — Mon, 02 Nov 2015 17:16:09 GMT

Wen du irgendeine Dateisystemkompression am Laufen hast, und so interpretiere ich

Als nächsten Versuch stell ich mal von zlib compression auf lzma,

dann bringt dir ein Test wie

dd if=/dev/zero of=./testfile bs=1G count=30 oflag=direct

höchstwahrscheinlich gar nix. Würde mal zB mit

https://wiki.ubuntuusers.de/bonnie%2B%2B

repräsentative Benchmarks fahren und mit SSD-üblichen Werten vergleichen.

Re(2): task ... blocked for more than 120 seconds

MrT2004 — Mon, 02 Nov 2015 17:05:43 GMT

Caches, Buffers und dergleichen in der mysqld-config angepasst? Tabellen-Indices passen? Slow Queries in MySQL vorhanden?

Re: task ... blocked for more than 120 seconds

zeddicus — Mon, 02 Nov 2015 08:44:17 GMT

Es zipft mich an. Schon alles mögliche probiert, aber es bessert sich nix.

Als letzten Strohhalm teste ich heute mal, das journaling zu deaktivieren, da das für 70% der I/O Operationen sorgt. Ja, ich bin mir der Gefahr durchaus bewußt, aber im Momentanzustand ist der Server auch unbrauchbar...

Re(4): task ... blocked for more than 120 seconds

zeddicus — Fri, 30 Oct 2015 20:48:09 GMT

bin jetzt mal gespannt, ich fahr die DB jetzt mal mittels directio, das sorgt zwar dafür dass die disk immer busy ist, allerdings erwarte ich mir dadurch nicht so starke bursts als wenn der cache gesyncht wird.

Als nächsten Versuch stell ich mal von zlib compression auf lzma, das sollte die disk usage verringern, die cpu usage ist ja derzeit noch relativ gering, das heißt da hätt ich eigentlich relativ viel reserve, somit sollt sich die stärkere compression nicht zu viel auf die db performance auswirken.

Re(3): task ... blocked for more than 120 seconds

DerPropagandaMinister — Fri, 30 Oct 2015 19:44:06 GMT

Uhm, also wenn du wirklich OOM gehst dann siehst du das auch eindeutig im Log. Wie gesagt, genau solche Fehler sind der Grund warum ich von vServer die Finger lass für mehr als nur Spielerei. Du weisst eben nie was der Hoster draussen aufführt und wer noch so aller auf dem Server liegt und eventuell Ressourcen frisst. Hilft dir halt leider auch nicht weiter, ich weiss. Ich würd halt nochmal syslog etc. durchforsten ob nicht doch was auf deiner Kiste schuld ist. Eventuell auch atop installieren und dann nachsehen was da zum Zeitpunkt des abschmierens gelaufen ist und wie die Auslastung war. Wie du ja sagst kannst du es recht gut reproduzieren, dh. das Problem einzugrenzen wenns wirklich an dir liegt sollt recht flott gehen.

Re(2): task ... blocked for more than 120 seconds

zeddicus — Fri, 30 Oct 2015 16:20:14 GMT

Dem hab ich schon geschrieben. Heute dann nochmal.

Antwort:

Wir haben das Wirtsystem soeben nochmals untersucht. Dieses arbeitet korrekt und Störungsfrei. Die Meldungen, die Sie erhalten lassen darauf schließen, dass Ihre VM "Out Of Memory" läuft. Darauf haben wir keinerlei Einfluss. Ebenso kennen wir die Konfiguration Ihres Systems nicht.

Unsere Wirtsysteme sind darüber hinaus nicht overcommited. Jedem vServer stehen die Ressourcen fest zu, die gebucht wurden.

Ich kann mir nicht vorstellen, daß mir der RAM ausgeht, da von den 24GB eigentlich nur ~15 reserviert sind und der Rest für cache / apache spawns zur Verfügung steht. Hab auch extra noch ein 16G swapfile zur Reserve angelegt.

Naja, hab jetzt noch ein 2. swapfile dazugepackt, jetzt steh ich bei 24G physikalisch + 48G swap. Glaub zwar nicht dran, aber probiern kann mans.

Re(2): task ... blocked for more than 120 seconds

MrT2004 — Thu, 29 Oct 2015 20:16:51 GMT

Richtig, und das wird der Fredersteller nur schwierig selbst feststellen können. Eine Möglichkeit wäre, auf die "steal" time, in top o.ä. mal zu beobachten, dass sind die cpu time slices, die der Kernel der VM vom hypervisor anfordert, aber aufgrund mangelnder resourcen nicht bekommt.

weiters kann es sein, dass die VM grade live-migriert wird, wenn das problem auftritt. dazu fällt mir aber keine möglichkeit ein, das aus dem gast heraus feststellen zu können.

Re: task ... blocked for more than 120 seconds

DerPropagandaMinister — Thu, 29 Oct 2015 15:32:18 GMT

Nachdems ein VServer ist kanns auch leicht sein das deine Nachbarn einfach zuviel ressourcen ziehen und sich daher die Kiste aufhängt weil sie keine Ressourcen bekommt. Mein erster Ansatz wär daher mal dem Provider zu schreiben mit der Problembeschreibung. VServer sind halt generell die Cash Cow der Provider da man da overcomitten ohne ende kann und meistens fällt es niemandem auf.

Re(4): task ... blocked for more than 120 seconds

zeddicus — Thu, 29 Oct 2015 13:42:30 GMT

Jo, werd ich mal machen, weil schön langsam ist es echt zum Kotzen. Ich kämpfe wochenlang mir eine Userbase aufzubauen, und vergraul sie dann mit Unerreichbarkeit mehrmals am Tag bis ichs bemerk.

Re(3): task ... blocked for more than 120 seconds

MG — Thu, 29 Oct 2015 13:33:59 GMT

Da hast was mit dem Hypervisor sag ich dir.
Mach Druck, dass die den mal rebooten.

Re(2): task ... blocked for more than 120 seconds

zeddicus — Thu, 29 Oct 2015 12:11:13 GMT

wieder nur 3h. hab jetzt auch acpi deaktiviert und den io schedulet auf deadline umgestellt. langsam wirds echt schlimm

Re(2): task ... blocked for more than 120 seconds

zeddicus — Wed, 28 Oct 2015 22:31:26 GMT

mit 3.16 und 3.20 hab ich das Problem auf jeden Fall.

Hab nachdems grad wieder passiert ist mit noapic gebootet. mal schaun obs was hilft

Re(2): task ... blocked for more than 120 seconds

zeddicus — Wed, 28 Oct 2015 22:31:26 GMT

mit 3.16 und 3.20 hab ich das Problem auf jeden Fall.

Hab nachdems grad wieder passiert ist mit noapic gebootet. mal schaun obs was hilft

Edit: hat nix gebracht. Diesmal hat der Server sogar nur 2h durchgehalten. Ich werd das Teil heut mal neu aufsetzen. Ev hab ich da ja mal irgendwas zrennt.

Re: task ... blocked for more than 120 seconds

MG — Wed, 28 Oct 2015 21:38:24 GMT

Schon mal anderen Kernel probiert?
Oder APIC deaktiviert?

Re(10): task ... blocked for more than 120 seconds

zeddicus — Wed, 28 Oct 2015 14:52:04 GMT

ah ok, wieviele Cores hast da drin eigentlich (würd mich nur interessieren bei
einer Load von 2.8)

Re(9): task ... blocked for more than 120 seconds

A national Acrobat — Wed, 28 Oct 2015 14:47:13 GMT

ah ok, wieviele Cores hast da drin eigentlich (würd mich nur interessieren bei einer Load von 2.8)

Sehr gut, die "Standard"-Checks sind eh gleich beim Cacti dabei, ggf. noch die /proc/meminfo und /proc/interrupts ins rrd einpflegen..

Zu den ersten (Eingangsposting) Errors kann auchmal mit "irqbalance" arbeiten um die irqs besser auf die CPUs aufzuteilen.. aber da muß ich sagen hab ich 0 Erfahrung damit welche Werte interessant sind zu ändern.

lg.

Re(8): task ... blocked for more than 120 seconds

zeddicus — Wed, 28 Oct 2015 14:13:38 GMT

Da der mysql Server relativ viel CPU/RAm brauch, hast da schonmal in die Logs
geguckt ob da ein error auftritt ?

Der macht wirklich viel, der darf das schon. Die DB ist auf der disk so um die 16GB und läuft unter der TokuDB engine. Da laufen schon so 1k-1k5 queries/sec.

So RRDTools (Cacti ?) oder ähnliches hast Du vielleicht auch - für Ram/CPU/IO
Überwachung

er guggt mal

Re(7): task ... blocked for more than 120 seconds

A national Acrobat — Wed, 28 Oct 2015 13:53:30 GMT

Da der mysql Server relativ viel CPU/RAm brauch, hast da schonmal in die Logs geguckt ob da ein error auftritt ?

Bis jetzt ist es ja eher ein Rumgerate als echte Hilfe

Re(7): task ... blocked for more than 120 seconds

A national Acrobat — Wed, 28 Oct 2015 13:53:30 GMT

Da der mysql Server relativ viel CPU/RAm brauch, hast da schonmal in die Logs geguckt ob da ein error auftritt ?

Bis jetzt ist es ja eher ein Rumgerate als echte Hilfe

Edit: So RRDTools (Cacti ?) oder ähnliches hast Du vielleicht auch - für Ram/CPU/IO Überwachung ?

Re(6): task ... blocked for more than 120 seconds

zeddicus — Wed, 28 Oct 2015 12:48:44 GMT

iotop:

htop:

free:

nebenbei:
danke für deine Hilfe!

Re(6): task ... blocked for more than 120 seconds

zeddicus — Wed, 28 Oct 2015 12:48:44 GMT

iotop:

htop:

free:

nebenbei:
danke für deine Hilfe!

Re(5): task ... blocked for more than 120 seconds

A national Acrobat — Wed, 28 Oct 2015 10:45:28 GMT

Ich hab jetzt mal per crontab regelmäßig ein "sync" gescheduled, damit der
cache ev. früher auf die disk geschrieben wird (net dass da was net
automatisch tut). Mal schaun, ob das was hilft.

Es muß nicht umbedingt an den HDDs liegen, ist halt oft so wenn was IO mässiges passiert, das die Dinge betroffen sind die den meisten IO haben, das wären eben Platten.

Was Du noch checken könntest ist das Du via "iotop" oder "top" nachsiehst wie hoch die Load bei "IO/Waits" ist (bei "top"). Da sollte dann auch der Process "hochwandern" der die Load verursacht.

Re(4): task ... blocked for more than 120 seconds

zeddicus — Wed, 28 Oct 2015 08:43:56 GMT

Bekommst Du den Fehler auch wenn Du selbst massiv Daten liest/schreibst, oder
sonstige "stärkere" IO-Operationen machst ?

Re(4): task ... blocked for more than 120 seconds

zeddicus — Wed, 28 Oct 2015 08:43:56 GMT

Bekommst Du den Fehler auch wenn Du selbst massiv Daten liest/schreibst, oder
sonstige "stärkere" IO-Operationen machst ?

grad 15 mal
dd if=/dev/zero of=./testfile bs=1G count=30 oflag=direct

getestet, da kommt die Meldung nicht. Schreibt mit 300-450MB/s, drum irritierts mich dass er zu einem anderen Zeitpunkt nicht zusammenkommt.

Ich hab jetzt mal per crontab regelmäßig ein "sync" gescheduled, damit der cache ev. früher auf die disk geschrieben wird (net dass da was net automatisch tut). Mal schaun, ob das was hilft.

Re(3): task ... blocked for more than 120 seconds

A national Acrobat — Wed, 28 Oct 2015 08:19:43 GMT

Bin jetzt ein paar Reboot Zeitpunkte durchgegangen. Bei manchen ist davor gar
nix im kern.log seit dem letzten Bootvorgang, bei ein paar gibts solche
Meldungen:
Oct 27 16:15:02 v22015103066628590 kernel: [ 537.119885] perf interrupt took
too long (2585 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
Oct 27 16:22:00 v22015103066628590 kernel: [ 955.391757] perf interrupt took
too long (5088 > 5000), lowering kernel.perf_event_max_sample_rate to 25000

Das ist schon sehr interessant, das die kernel-interne Performancemessung hier in Probleme läuft. Soviel ich von der x86 Platform versteh, sagt der Kernel das das Handling der IRQs/NMI zuviel Zeit in Anspruch nimmt, bzw. der Kernel nicht mehr x IRQs per Sekunde abarbeiten kann (oder es werden zuviele IRQs/NMI abgefeuert und das beeinträchtigt den Scheduler).
(https://lkml.org/lkml/2013/5/29/640 )

Seh ich leider nicht, da eine vda. Generell sollten es SSD sein (nur als
Nebeninfo)

Hab netcup geschrieben, die meinen sie sehen am Wirtssystem nichts. Ich
bezweifle allerdings dass die wirklich nachgeschaut haben.

Bekommst Du den Fehler auch wenn Du selbst massiv Daten liest/schreibst, oder sonstige "stärkere" IO-Operationen machst ?

Re(3): task ... blocked for more than 120 seconds

A national Acrobat — Wed, 28 Oct 2015 08:19:43 GMT

Bin jetzt ein paar Reboot Zeitpunkte durchgegangen. Bei manchen ist davor gar
nix im kern.log seit dem letzten Bootvorgang, bei ein paar gibts solche
Meldungen:
Oct 27 16:15:02 v22015103066628590 kernel: [ 537.119885] perf interrupt took
too long (2585 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
Oct 27 16:22:00 v22015103066628590 kernel: [ 955.391757] perf interrupt took
too long (5088 > 5000), lowering kernel.perf_event_max_sample_rate to 25000

Seh ich leider nicht, da eine vda. Generell sollten es SSD sein (nur als
Nebeninfo)

Hab netcup geschrieben, die meinen sie sehen am Wirtssystem nichts. Ich
bezweifle allerdings dass die wirklich nachgeschaut haben.

Bekommst Du den Fehler auch wenn Du selbst massiv Daten liest/schreibst, oder sonstige "stärkere" IO-Optionen machst ?

Re(2): task ... blocked for more than 120 seconds

zeddicus — Wed, 28 Oct 2015 07:20:05 GMT

Was spuckt denn dmesg bzw. /var/log/kern.log aus was zu dem Zeitpunkt aus
Kernelsicht passiert ist ?

Bin jetzt ein paar Reboot Zeitpunkte durchgegangen. Bei manchen ist davor gar nix im kern.log seit dem letzten Bootvorgang, bei ein paar gibts solche Meldungen:
Oct 27 16:15:02 v22015103066628590 kernel: [ 537.119885] perf interrupt took too long (2585 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
Oct 27 16:22:00 v22015103066628590 kernel: [ 955.391757] perf interrupt took too long (5088 > 5000), lowering kernel.perf_event_max_sample_rate to 25000

Ich tät mal schaun ob das System allgemein swapped

Nope

ob die Disks die darunter liegen auch ok sind (smartctl ?)

Seh ich leider nicht, da eine vda. Generell sollten es SSD sein (nur als Nebeninfo)

Hab netcup geschrieben, die meinen sie sehen am Wirtssystem nichts. Ich bezweifle allerdings dass die wirklich nachgeschaut haben.

Re: task ... blocked for more than 120 seconds

A national Acrobat — Wed, 28 Oct 2015 06:38:07 GMT

Irgendjemand Tipps für mich auf was ich schauen soll?

Das kann mehrere Gründe haben, der wahrscheinlichste ist das der Process etwas lesen/schreiben will, aber von dem zuständigen Gerät (Disk?) 120 Sekunden geblocked wurde bzw. der Scheduler den Task nicht für 120 Sekunden schedulen konnte.

Ich tät mal schaun ob das System allgemein swapped, ob die Disks die darunter liegen auch ok sind (smartctl ?) bzw. halt andere IO Devices die die Tasks benötigen.

Was spuckt denn dmesg bzw. /var/log/kern.log aus was zu dem Zeitpunkt aus Kernelsicht passiert ist ?

task ... blocked for more than 120 seconds

zeddicus — Tue, 27 Oct 2015 23:12:30 GMT

Servus,

ich bekomm auf meinem netcup server (debian jessie vserver) immer häufiger eine Fehlermeldung wie:
INFO: task kworker/1:1:17535 blocked for more than 120 seconds.

(der task ist variabel, mal mysqld, mal ists der apache)

Danach ist das System quasi tot. Man kann nicht mal mehr tools wie top oder was ausführen, und es geht auch kein reboot mehr, nur mehr hart aus und ein.

Google Recherchen haben bislang nur den Tipp ergeben die dirty_ratio und die dirty_background_ratio runterzustellen, damit weniger auf einmal aus dem file system cache auf die disk geschrieben werden muss. Das hat aber bislang Nüsse geholfen.

Irgendjemand Tipps für mich auf was ich schauen soll?