@umbm influx v2 kann auch noch influx v1 api auth influx v1 auth create

@grizzelbee würd gern testen fühle mich ausgegrenzt, da ich in ch sitze

@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...

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.

@Urs Bei mir waren string datensätze in der ts_number tabelle. Betroffene Adapter: weatherunderground, coronavirus-statistics, netatmo usw., also eigentlich alle adapter, die strings liefern. Die hm-* adapter waren nicht betroffen, da die keine strings liefern.
Wirklich Ruhe ist bei mir erst eingekehrt, nachdem ich konsequent alle string Lieferanten vom logging excluded habe. Zudem waren haufenweise Dubletten in der DB, was man recht schnell mit einer Kopie der Tabellen via sql sehen kann. So hatte die ts_number Tabelle, die zuvor 12Mio Datensätze hatte, nach der Kopie nur noch 8 Mio Datensätze...

Ich habe den Ärger nun auch genutzt und die Tabellen via php Script entrümpelt und alle Datensätze mit sort by id asc, ts asc eingelesen und dann, wenn val und id gleich waren, Zeile für Zeile geprüft und nur die nicht gleichen Datensätze in eine neue Tabelle geschrieben. Jetzt hat z.B. die ts_number nur noch 1.2 Mio Datensätze. Man sollte auf dem SQL Adapter einfach nie „trotzdem gleiche Werte aufzeichnen (Sekunden)“ aktivieren....

Die String Werte (weatherunderground) lese ich jetzt via simple-api aus und schreibe sie dann auch via simple-api in die richtige Tabelle. Das Ganze via php und halt nur für die Werte, die ich sowieso nur von Zeit zu Zeit pullen will.

Meine sql.0 Instanz konsumiert nun nur noch 0.3% mit Peaks bis 1% CPU im Docker Container, zuvor waren es dauerhaft 90-100%!

Gleiches habe ich auch auf einer zweiten, durch mich betreuten Installation durchgeführt, mit gleichem Ergebnis. Hierbei bin ich aber über ein MySQL Performance Thema gestolpert: Ich nutze ein Synology DS 918+ mit NVME cache, dort schluckte die MariaDB die sql inserts fast in Echtzeit (ca. 1Mio records pro Minute), auf der zweiten Installation auf einer DS 216+II war das Disksystem sofort am Anschlag und ich konnte nur knapp 10'000 records pro Minute schreiben.

ich bin bei Euch, bei mir sieht es genauso aus....

Vermutlich konnte ich das nun lösen und erfolgreich wieder auf stabile wechseln. Aus meiner Sicht ist der ursprüngliche Auslöser Adapter "sql": 1.13.1

Warum auch immer bin ich in den latest abgerutscht und hatte plötzlich massive Probleme mit der CPU Last im Docker auf meiner DS.

Ich habe ein Downgrade aus dem Latest hin zum. Stable gemacht.

pkill io
npm install iobroker.admin@4.0.10
npm install iobroker.flot@1.9.2
npm install iobroker.hm-rega@2.5.5
npm install iobroker.hm-rpc@1.14.2
npm install iobroker.hue@3.3.2
npm install iobroker.info@1.7.2
npm install iobroker.simple-api@2.4.5
npm install iobroker.socketio@3.0.7
npm install iobroker.vis@1.2.4
npm install iobroker.weatherunderground@3.1.6
npm install iobroker.web@3.0.8
npm install iobroker.js-controller@3.1.4
npm install iobroker.sql@1.12.5

Docker Container neu gestartet und erstmal Freude gehabt. Plötzlich ging aber die CPU wieder durch die Decke....

Da ich eine zweite nahezu identische Installation habe, mit genau den gleichen Paketversionen und aktiven Instanzen, konnte nur noch die DB einen Einfluss haben. Diese habe ich dann via phpMyadmin kopiert und siehe da, in der ts_number Tabelle war ein haufen Schrott drin, den phpMyadmin nicht kopieren wollte. Somit habe ich dann den entschrotteten Inhalt auf der neuen DB und siehe da, bisher ist die sql.0 Instanz wieder bei 0.3% - da wo sie auch hingehört.

Meine Vermutung ist nun, dass sql 1.13.1 irgendein Quatsch mit der DB anstellt