SQL-Adapter verursacht hohe CPU-Last

bvol

1.14.2 verhält sich unauffällig. CPU Last im erwarteten Bereich, also gem. top zwischen 0 und 0.4%. Wie es sein soll.

bvol

@Urs hier das Cleanup Script: (es legt eine zusätzliche Tabelle mit den "gesäuberten" Daten an. Es sortiert nach ID und TS und schreibt nur die zum vorigen Wert geänderten Werte.)

<?php

// SQL Verbindung
			$sqlserver = "MYSQLSERVERIP:3307"; // DB Server:Port
			$sqluser = "admin"; // DB User
			$sqlpw = "*******"; // DB User PW
			$sqlDB = "iobroker"; // DB Name
			$sourceTable = "ts_number"; // Source Table
			$cleanTable = $sourceTable ."_cleaned"; // Temp Table
			$writedatasets =100; // Number of datasets written to Temp Table using single SQL Statement
			$SQLqueryLIMIT=0; // For Testing purposes. 0 selects all Source sets.


// DB Verbindung bauen
			error_reporting(0);
			$db = mysqli_connect($sqlserver, $sqluser, $sqlpw, $sqlDB);
			print_r ($db->connect_error);
			if ($db->connect_errno) {
			    die('Sorry - gerade gibt es ein Problem');
			}
// Attempt select query execution
if ($SQLqueryLIMIT > 0) {
	$sql = "SELECT * FROM ".$sourceTable." ORDER BY id ASC,ts ASC LIMIT ".$SQLqueryLIMIT;
}
else {
	$sql = "SELECT * FROM ".$sourceTable." ORDER BY id ASC,ts ASC";
}


// load Table to memory
if($result = mysqli_query($GLOBALS['db'],$sql)){
// do nothing
}

// Create Cleantable

$sql ="DROP TABLE IF EXISTS `".$cleanTable."`";
mysqli_query($GLOBALS['db'],$sql);
$sql ="CREATE TABLE `".$cleanTable."` SELECT * FROM `".$sourceTable."` WHERE 1 = 2";
mysqli_query($GLOBALS['db'],$sql);
$sql ="ALTER TABLE `".$cleanTable."` ADD PRIMARY KEY (`id`,`ts`)";
mysqli_query($GLOBALS['db'],$sql);


$idprev=0;
$valprev=0;
$saetze=0;
$DataArr = array();
while($row = mysqli_fetch_array($result)){
	if (($row['val']==$valprev) && ($row['id']==$idprev)) {
		//echo $idprev .  " " . $valprev .  " " . $tsprev  . " Behalten \n";
		//echo $row['id'] .  " " . $row['val'] .  " " . $row['ts']  . " Loeschen \n";
		}
	else
		{
			$fieldVal1 = ($row['id']);
      $fieldVal2 = ($row['ts']);
      $fieldVal3 = ($row['val']);
			$fieldVal4 = ($row['ack']);
			$fieldVal5 = ($row['_from']);
			$fieldVal6 = ($row['q']);
			$DataArr[] = "('$fieldVal1','$fieldVal2','$fieldVal3','$fieldVal4','$fieldVal5','$fieldVal6')";
			$idprev=$row['id'];
			$valprev=$row['val'];
			$tsprev=$row['ts'];
			$saetze++;
		}
	if ($saetze==$GLOBALS['writedatasets']){
		$sql = "INSERT INTO ".$cleanTable." (id, ts, val, ack, _from, q) values ";
		$sql .= implode(',', $DataArr);
		$sql .= ";";
		// echo $sql;
		mysqli_query($GLOBALS['db'], $sql);
		$saetze=0;
		unset($DataArr); // $DataArr is gone
		$DataArr = array(); // $DataArr is here again
	}


}
if ($saetze>=0){
	//echo implode(',', $DataArr);
	$sql = "INSERT INTO ".$cleanTable." (id, ts, val, ack, _from, q) values ";
	$sql .= implode(',', $DataArr);
	$sql .= ";";
	//echo $sql;
	mysqli_query($GLOBALS['db'], $sql);
}

echo mysqli_num_rows($result);
// Free result set
mysqli_free_result($result);
// DB Verbindung schliessen
mysqli_close($db);
?>

Code als php Script speichern und mit php ausführen. ACHTUNG: Script zieht die gesamte Tabelle in den Speicher, sorgt also für genügend RAM, je nachdem wie gross die Tabelle ist.

Zum Testen $SQLqueryLIMIT mal auf 1000 setzen, dann werden nur die ersten 1000 Tabelleneinträge geholt.

$writedatasets =100; definiert die Anzahl an Datensätzen, die mittels einem SQL Statement in die cleaned Tabelle geschrieben werden. Sorgt für mehr Speed, kann aber den MySQL Server überfordern. Mit dem Wert 100 habe ich gute Erfahrungen gemacht.

$sourceTable = "ts_number"; -> gibt die zu lesende Tabelle an.

Wenn das Ergebnis den Erwartungen entspricht, dann mittels phpMyAdmin o.Ä. die Tabellen entsprechend umbenennen...

s.bormann

@apollon77 Bei mir läuft auch wieder alles! Danke fürs Fixen!

Urs

@bvol hey, cool, vielen Dank. Muss mal schauen wann ich dazu komme das mal auszuprobieren. Melde mich wieder.

etv

Ich habe die selben Meldungen für Datenpunkte die ich leider gelöscht habe bevor ich das Logging disabled hab...

Aber durch die ganze Testerei hab ich jetzt verschiedene hässliche Meldungen vom SQL Adapter bzw von MariaDB:

sql.0	2020-06-04 03:59:59.727	warn	(3939) No realID found for web-speedy.0.Results.server.ping
sql.0	2020-06-04 03:59:59.727	warn	(3939) No realID found for web-speedy.0.Results.speeds.upload_MB
sql.0	2020-06-04 03:59:59.727	warn	(3939) No realID found for web-speedy.0.Results.speeds.download_Mb
sql.0	2020-06-04 03:59:59.727	warn	(3939) No realID found for web-speedy.0.Results.speeds.download_MB
sql.0	2020-06-04 03:59:59.727	warn	(3939) No realID found for vodafone-speedtest.0.Results.ping.packetLoss
sql.0	2020-06-04 03:59:59.727	warn	(3939) No realID found for vodafone-speedtest.0.Results.ping.avg
sql.0	2020-06-04 03:59:59.727	warn	(3939) No realID found for vodafone-speedtest.0.Results.ping.max
sql.0	2020-06-04 03:59:59.727	warn	(3939) No realID found for vodafone-speedtest.0.Results.ping.min
sql.0	2020-06-04 03:59:59.727	warn	(3939) No realID found for vodafone-speedtest.0.Results.upload_Mb
sql.0	2020-06-04 03:59:59.727	warn	(3939) No realID found for vodafone-speedtest.0.Results.upload_MB
sql.0	2020-06-04 03:59:59.727	warn	(3939) No realID found for vodafone-speedtest.0.Results.download_MB

Auch meine Frage - wie bekommt man die weg? Wie kann man das SQL Logging für nicht mehr existente Datenpunkte abdrehen?

Liebe Grüße
Tom

Dr. Bakterius

@etv Geloggt wird eh nicht mehr, aber die Werte befinden sich noch in der Datenbank. Das wäre auch so, wenn du das Logging vorher deaktiviert hättest. Ich habe die entsprechenden Werte direkt aus der Datenbank gelöscht. Da sollte man aber wissen was man tut.

apollon77

@Dr-Bakterius Dem Adapter ist egal was in der DB steht ... kann es sein das aus irgend einem Grund nur der STate gelköscht ist aber das Objekt noch da ist ... ja das Thema steht noch auf der Liste ...

@etv
mach bitte mal an der Kommandozeile

iobroker object get vodafone-speedtest.0.Results.ping.packetLoss

und

iobroker state get vodafone-speedtest.0.Results.ping.packetLoss

Und sag mal was das gibt

liv-in-sky

@apollon77

habe da auch massig davon

Image 6.png

kam durch json-import von anderen usen - für script-testen
datenpunkte sind mitlerweile gelöscht

apollon77

@liv-in-sky Und das State? das noch da?

liv-in-sky

@apollon77

der wird doch mitgelöscht, wenn man die datenpunkte löscht ? oder

habe mal abgefragt:

log(getState('maxcube.0.devices.thermostat_101881.setpoint').val)

Image 11.png

apollon77

@liv-in-sky Ja sollte er ... ich versuche es zu verstehen ... Also alles ausschliessen

An sich liesst der sql Adapter zu Beginn die Objekte die ein custom haben ... also wenn Objekte gelöscht sind sollte er die nie bekommen

liv-in-sky

@apollon77

genau so hätte ich mir das auch vorgestellt

wenn ich mit dem tool in der datenbank suche nach max kommt auch nix

Image 12.png

liv-in-sky

@apollon77

in der sql datenbank ist noch was - aber das ist wohl das problem

Image 13.png

apollon77

@liv-in-sky Nein ist es nicht. Dem Adapter ist egal was in der DB steht. Er nimmt die Objekte die sql aktiviert haben und arbeitet damit. Er schaut nur dann in der DB nach ob ein Objekt schon bekannt ist oder nicht.

liv-in-sky

@apollon77 aber wo kann den noch was in redis oder in den objekten (text) sein - beides des dp's ist weg

gib bitte bescheid, wenn ich noch was nachschauen soll

apollon77

@liv-in-sky Genau DAS verstehe ich noch nicht

Dr. Bakterius

@apollon77 sagte in SQL-Adapter verursacht hohe CPU-Last:

Dem Adapter ist egal was in der DB steht ... kann es sein das aus irgend einem Grund nur der STate gelköscht ist aber das Objekt noch da ist ... ja das Thema steht noch auf der Liste ...

Verstehe jetzt nicht wirklich was du meinst. Ich habe die Aufzeichnung eines Datenpunktes gestoppt. Bei nächsten Start des SQL-Adapters kamen genau diese Meldungen der Objekte die nicht mehr geloggt wurden (die es aber noch gibt). In der DB waren die datapoints-Einträge und die Werte (ts_number) noch vorhanden. Nachdem ich diese gelöscht hatte, waren auch die Meldungen vom Adapter weg.

Urs

Das Verhalten kann ich in einer etwas geänderten Form bestätigen. Ich hatte mehrere Adapter welche Daten in die DB geschrieben haben komplett deinstalliert. Es waren somit auch keine Datenpunkte mehr vorhanden. Seut da bekam ich die Fehler.
Ich hab es damals darauf geschoben dass ich die DP nicht deaktiviert habe bevor ich die entsprechenden Adapter deinstalliert habe, ob das wirklich so ist hab ich nicht weiter recherchiert.

Auch bei mir waren die Fehler erst weg als ich die entsprechenden Einträge in der Datenbank von Hand gelöscht habe.

Gruss
Urs

apollon77

Ok, das waren die ausschlagebenden Hinweise ... ich glaub ich habs. Bitte 1.15.2 testen

liv-in-sky

@apollon77
bekomme nun keine warnungen mehr beim start der instanz - danke

werden die werte in der datenbank nun auch gelöscht oder ist das unwichtig?

NEWS

SQL-Adapter verursacht hohe CPU-Last

Support us

1.6k
Online

30.5k
Users

76.8k
Topics

1.2m
Posts

NEWS

SQL-Adapter verursacht hohe CPU-Last

Support us

1.6kOnline

30.5kUsers

76.8kTopics

1.2mPosts

1.6k
Online

30.5k
Users

76.8k
Topics

1.2m
Posts