Ja, sehe ich auch so... es wird ja pausiert, nur die GUI bekommt es nicht mit. Komisch nur, dass der MySQL Check beim "Fehlverhalten" ueber eine Minute braucht, beim korrekten Verhalten aber nur (wie vermutlich beabsichtigt) aber nur 10s.
-
-
Das ist in der Tat merkwürdig... 97 DBs sollten in ein paar Sekunden zu schaffen sein. Darauf habe ich allerdings keinen direkten Einfluss - das macht logischerweise mySql. Bist Du Dir denn sicher, dass nicht irgendein EXEC-LBS im Hintergrund noch weiterläuft und das System "auslastet"?EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)Kommentar
-
-
Zumindest laufen 2 zusätzliche "PHP-Prozesse" - was machen die denn so? Wenn Du die entsprechenden LBS mal rausnimmst...?EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)Kommentar
-
Sind es nicht eigentlich sogar 3?
Es ist ein experimenteller UDP-Listener, der Squeeze-Server-LBS (beides Daemons) und dann vermutlich ein periodischer Aufruf eines EXEC-Dingens, ne Wetterabfrage oder so. Ich hab die beiden Daemons deaktiviert, das Problem tritt immer noch auf.
In den meisten Faellen passiert es (gemaess Logfile) hier:
Normal dauert der Schritt so ziemlich genau 12s, oder nen Hauch mehr oder weniger. Im Fehlerfall aber irgendwie immer exakt 60s mehr - so wie oben zu sehen.Code:2017-02-24 22:51:48 285782 MAIN 20650 Check: 64-Bit-System? Ok 2017-02-24 22:51:48 286335 MAIN 20650 PHP-Zeitzone: Europe/Berlin (Winterzeit) Ok 2017-02-24 22:51:48 292777 MAIN 20650 mySQL: Connect Ok ----- 2017-02-24 22:52:56 748168 MAIN 20650 Check: 97 Datenbanken überprüft (0 Fehler) Ok 2017-02-24 22:52:56 748986 MAIN 20650 mySQL: RAM reservieren (100 MB pro RAM-DB) Ok 2017-02-24 22:52:56 847214 MAIN 20650 db.edomiLive erstellen Ok
Jetzt hatte ich beim Testen aber nochmal an anderer Stelle einen Verursacher, diesmal wars hier:
und kurz danach nochmal hier:Code:2017-02-24 22:54:37 553276 MAIN 20872 Prozess MAIN beenden... (Modus 10) Ok 2017-02-24 22:54:37 553977 MAIN 20872 EDOMI beenden... Ok ----- 2017-02-24 22:55:18 076312 SYSINFO 20880 MAIN-SIGNAL erhalten -> Beenden... Ok 2017-02-24 22:55:18 158859 SYSINFO 20880 Prozess SYSINFO beenden... Ok 2017-02-24 22:55:18 159539 SYSINFO 20880 mySQL disconnect Ok
An den Stellen wo in den Logs die 5 Striche auftauchen hat die GUI dann jeweils ein "konnte nicht pausiert werden" gemeldet.Code:2017-02-24 23:01:30 464797 MAIN 22202 Prozess MAIN beenden... (Modus 10) Ok 2017-02-24 23:01:30 465456 MAIN 22202 EDOMI beenden... Ok ----- 2017-02-24 23:02:05 256861 SYSINFO 22211 MAIN-SIGNAL erhalten -> Beenden... Ok 2017-02-24 23:02:05 260298 SYSINFO 22211 Prozess SYSINFO beenden... Ok 2017-02-24 23:02:05 261965 SYSINFO 22211 mySQL disconnect Ok
Kommentar
-
Ok - der Nebel lichtet sich ein wenig! Die GUI wartet max. 30s (so aus'm Kopf) auf die Rückmeldung "Ok, bin pausiert" - ansonsten Timeout und die entsprechende Meldung. Natürlich könnte man den Timeout entsprechend verlängern, aber das löst das mySql-Problem ja nicht - und dies scheint in diesem Fall das eigentliche Problem zu sein.
Beim Beenden werden auch diverse DB-Operationen durchgeführt - offenbar stimmt irgendwas mit Deinem mySql nicht?! Merkwürdig, dass es manchmal mit normaler Geschwindigkeit funktioniert und manchmal nicht - daher würde ich auf irgendeine Art von Auslastung tippen (andere Prozesse auf Deinem System, etc.)?!EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)Kommentar
-
Wie schon geschrieben ist das (nach meinem Empfinden) eigentlich alles sehr entspannt:
auslastung.pngKommentar
-
Sind die DBs denn irgendwie besonders "riesig" (Archive o.d.G.)? Obwohl, kann ja auch nicht sein, denn manchmal geht's ja offenbar schnell...
Wie gesagt: Allein der DB-Check (97 DBs) dauert normaler Weise höchstens ein paar Sekunden. Vielleicht ist Deine SSD "kaputt", so dass der Zugriff je nach "Sektor" ewig dauert?!EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)Kommentar
-
Hast du mal versucht das Projekt in eine Vanilla-EDOMI-1.49-VM zu importieren, um zu testen ob es sich dort genauso verhält? Dann könntest du zumindest mal ausschließen, dass es irgendetwas mit der HW und sonstigen Einflüssen zu tun hat.Kommentar
-
Ich hab grad leider keine Vanilla-VM zur Hand o\
MySQL Datenbanken sind eher uebersichtlich, finde ich:
Code:[root@edomi log]# du -sh /var/lib/mysql 222M /var/lib/mysql
Kommentar
-
Bei mir siehts so aus - als Hausnummer:Zitat von wintermute Beitrag anzeigen
Ich hatte aber auch mal einen "Pausen-Hänger". Das lag an einem Timer der in einer Schleife hing. Die Cpu-Last war ebenso unauffällig.Code:[root@edomi ~]# du -sh /var/lib/mysql 11M /var/lib/mysql
2017-02-25 13_39_50-EDOMI · Administration.pngZuletzt geändert von WagoKlemme; 25.02.2017, 13:40.Kommentar
-
Die Groesse kommt durch Archive - nehm ich die raus bin ich auch irgendwo um 10MB. Trotzdem ist das ja nu keine Groesse fuer eine Datenbank - und waer das der Grund, dann waers ja auch immer... sonderbar finde ich weiterhin die Zeiten wenn es am DB-Check liegt. Es sind quasi IMMER entweder 12 oder 72s - so als ob irgendeine Komponente sagt: "ich warte jetzt erstmal genau 1 Minute ab und mach derweil garnix".
Das der Fehler beim "Beenden von Edomi" auftritt (die letzten beiden Beispiele von oben) ist eine Ausnahme, das hatte ich vorher noch nie - und da kann ich mir auch durchaus vorstellen, dass zB irgendein Loop der Grund sein koennte - wenngleich das nach meinem Verstaendnis abgefangen werden muesste. Die GUI sollte solange warten bis eine Rueckmeldung kommt und bleibt die aus, dann eben mit mehr Nachdruck arbeiten
Was MySQL und die SSD angeht, im Normalbetrieb sieht das auf dem System so aus (4x30s):
Wie man sehen kann ist da nix mit iowait oder so...Code:Linux 2.6.32-573.26.1.el6.x86_64 (edomi.localnet) 25.02.2017 _x86_64_ (4 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 4,23 0,00 2,06 0,04 0,00 93,66 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,24 15,93 2,48 3,46 226,73 155,15 64,25 0,13 21,52 0,38 0,23 avg-cpu: %user %nice %system %iowait %steal %idle 3,03 0,00 1,22 0,00 0,00 95,74 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 4,17 0,00 3,20 0,00 58,93 18,42 0,00 0,14 0,07 0,02 avg-cpu: %user %nice %system %iowait %steal %idle 2,89 0,00 1,14 0,00 0,00 95,97 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 3,67 0,00 2,27 0,00 47,47 20,94 0,00 0,12 0,06 0,01 avg-cpu: %user %nice %system %iowait %steal %idle 3,18 0,00 1,29 0,00 0,00 95,53 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 4,13 0,00 2,97 0,00 56,80 19,15 0,00 0,03 0,03 0,01
Hier nochmal dasselbe, allerdings zweisekuendlich aufgeloest, zum Zeitpunkt des (MySQL-)Fehlers, also von kurz vorher bis kurz danach. Auch da ist weder was von I/O-waitstates noch von CPU-Anschlag zu sehen, es ist alles ganz enstpannt...
Logfile:
I/O Statistiken dazu:Code:2017-02-25 15:19:08 846035 MAIN 15055 mySQL: Connect Ok 2017-02-25 15:20:18 987222 MAIN 15055 Check: 97 Datenbanken überprüft (0 Fehler) Ok
Code:avg-cpu: %user %nice %system %iowait %steal %idle 13,64 0,00 7,58 0,00 0,00 78,79 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 5,37 0,00 1,75 0,00 0,00 92,88 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 22,78 0,00 2,38 0,00 0,00 74,84 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 35,50 0,00 3,00 0,00 308,00 102,67 0,00 0,83 0,83 0,25 avg-cpu: %user %nice %system %iowait %steal %idle 22,78 0,00 2,25 0,00 0,00 74,97 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 24,72 0,00 0,62 0,00 0,00 74,66 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 24,66 0,00 0,38 0,00 0,00 74,97 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 1,50 0,00 1,00 0,00 20,00 20,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 24,50 0,00 0,62 0,00 0,00 74,88 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 1,00 0,00 8,00 8,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 23,75 0,00 1,38 0,00 0,00 74,88 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 23,75 0,00 1,38 0,12 0,00 74,75 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 23,00 0,00 32,50 0,00 444,00 13,66 0,08 2,57 0,11 0,35 avg-cpu: %user %nice %system %iowait %steal %idle 23,65 0,00 1,38 0,00 0,00 74,97 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 24,00 0,00 1,25 0,00 0,00 74,75 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 23,65 0,00 1,75 0,00 0,00 74,59 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 1,50 0,00 1,50 0,00 24,00 16,00 0,00 0,33 0,33 0,05 avg-cpu: %user %nice %system %iowait %steal %idle 23,75 0,00 1,62 0,00 0,00 74,62 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 23,75 0,00 1,75 0,00 0,00 74,50 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 16,00 0,00 16,50 0,00 260,00 15,76 0,00 0,24 0,09 0,15 avg-cpu: %user %nice %system %iowait %steal %idle 10,15 0,00 17,17 3,76 0,00 68,92 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 11472,00 0,00 67,00 0,00 20180,00 301,19 28,29 72,07 3,54 23,75 avg-cpu: %user %nice %system %iowait %steal %idle 8,58 0,00 16,90 1,89 0,00 72,64 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 1483,00 0,00 83,00 0,00 84664,00 1020,05 74,54 1180,75 11,07 91,85 avg-cpu: %user %nice %system %iowait %steal %idle 8,60 0,00 16,58 0,12 0,00 74,69 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 16,50 0,00 2,00 0,00 148,00 74,00 0,00 1,00 0,75 0,15 avg-cpu: %user %nice %system %iowait %steal %idle 7,78 0,00 19,07 8,41 0,00 64,74 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 9898,50 0,00 41,50 0,00 36976,00 890,99 54,54 345,17 9,81 40,70 avg-cpu: %user %nice %system %iowait %steal %idle 4,28 0,00 11,19 20,50 0,00 64,03 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 4305,50 0,00 109,50 0,00 75932,00 693,44 81,54 1087,47 9,13 100,00 avg-cpu: %user %nice %system %iowait %steal %idle 9,25 0,00 15,38 0,38 0,00 75,00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 3,00 0,00 1956,00 652,00 0,05 909,17 5,67 1,70 avg-cpu: %user %nice %system %iowait %steal %idle 8,26 0,00 16,90 0,00 0,00 74,84 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 21,75 0,00 3,25 0,00 0,00 75,00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 2,00 0,00 1,00 0,00 24,00 24,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 24,53 0,00 0,63 0,00 0,00 74,84 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 24,38 0,00 0,75 0,00 0,00 74,88 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 23,50 0,00 4,00 0,00 220,00 55,00 0,00 0,38 0,25 0,10 avg-cpu: %user %nice %system %iowait %steal %idle 24,50 0,00 0,62 0,00 0,00 74,88 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 24,41 0,00 0,63 0,00 0,00 74,97 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 24,66 0,00 0,50 0,00 0,00 74,84 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 1,50 0,00 1,50 0,00 24,00 16,00 0,00 0,33 0,33 0,05 avg-cpu: %user %nice %system %iowait %steal %idle 24,25 0,00 0,75 0,00 0,00 75,00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 14,02 0,00 11,14 0,00 0,00 74,84 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 9,38 0,00 15,75 0,00 0,00 74,88 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 5,00 0,00 2,00 0,00 56,00 28,00 0,00 0,25 0,25 0,05 avg-cpu: %user %nice %system %iowait %steal %idle 9,25 0,00 15,88 0,00 0,00 74,88 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 8,38 0,00 16,75 0,00 0,00 74,88 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 1,50 0,00 1,00 0,00 20,00 20,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 9,00 0,00 16,12 0,00 0,00 74,88 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 9,25 0,00 15,88 0,00 0,00 74,88 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 10,50 0,00 16,50 0,00 216,00 13,09 0,01 0,67 0,09 0,15 avg-cpu: %user %nice %system %iowait %steal %idle 9,02 0,00 16,04 0,00 0,00 74,94 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 1,00 0,00 1,50 0,00 20,00 13,33 0,00 0,00 0,00 0,00 avg-cpu: %user %nice %system %iowait %steal %idle 4,51 0,00 21,90 0,00 0,00 73,59 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 9347,50 0,00 11,00 0,00 5344,00 485,82 5,71 66,95 5,77 6,35 avg-cpu: %user %nice %system %iowait %steal %idle 6,93 0,00 10,08 7,81 0,00 75,19 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 45,00 7,50 86,50 112,00 70576,00 752,00 53,76 624,86 8,33 78,30 avg-cpu: %user %nice %system %iowait %steal %idle 1,12 0,00 1,00 0,00 0,00 97,88 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00Kommentar
-
Da bin ich ganz bei Dir - es ist in der Tat sonderbar! Insbesondere 12s vs 72s beim DB-Check. Aber darauf habe "ich" (EDOMI) wie gesagt keinen Einfluss - das sind einfach nur check-statements in mySql.
Beim Beenden werden eigentlich nur diverse DB's zurückgesetzt/gelöscht und es wird auf das Beenden der anderen Prozesse gewartet (siehst Du ja auch im Log).
Das 30s-Timeout der GUI ist natürlich willkürlich gewählt, da der gesamte Vorgang normalerweise in ein paar Sekunden erledigt ist (auch mit "voller" DB).
EDIT:
Irgendwie scheint bei Dir mySql generell "etwas" lahm zu sein? Z.B. in Deinem Log:
Das "Queue leeren" braucht 16 Sekunden - da wird lediglich eine DB geleert ("DELETE FROM...").Code:2017-02-23 20:16:14 062016 SYSINFO 25542 Prozess SYSINFO gestartet Ok 2017-02-23 20:16:30 346007 MAIN 25533 Queue leeren Ok
Zuletzt geändert von gaert; 25.02.2017, 16:45.EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)Kommentar
-
Tja, was soll ich sagen, es ist nicht so, dass da irgendwas irgendwo anschlagen wuerde. Die "schlimmste" Auslastung waehrend des ganzen Prozesses ist in etwa dergestalt:
Also 75% idle, 0.12% iowait... besser gehts ja kaum *schulterzuck*Code:avg-cpu: %user %nice %system %iowait %steal %idle 23,75 0,00 1,38 0,12 0,00 74,75 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0,00 23,00 0,00 32,50 0,00 444,00 13,66 0,08 2,57 0,11 0,35Kommentar
-
Mh... Mir fällt da auch nix mehr ein... Vielleicht probierst Du tatsächlich mal jonofe zu folgen? So ne VM ist doch fix eingerichtet
EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)Kommentar
Kommentar