Erfahrungsbericht hp ThinClient als FHEM-Server

[Lucky2k12]

 Danke Werner, für die Antwort!

Code Auswählen Erweitern

free
              total        used        free      shared  buff/cache   available
Mem:        3504880      906616     1554396       47404     1043868     2315040
Swap:             0           0           0


Die DB wird täglich optimiert, sollte jedenfalls.
Ich hab die Logs auch dezimiert, da kommen etwa 10 Werte pro Minute rein.

[Wernieman]

Nein ich meinte, ob die DB für das System optimiert wurde!

10 Werte pro Minute ist für eine DB eigentlich nichts ... nur ist leider mysql (mariaDB) in der Standardinstallaion unoptimiert. Also hast Du in der Config die DB optimiert?

Code Auswählen Erweitern

Die DB wird täglich optimiert, sollte jedenfalls.
Du meinst ein "optimize Table"? Ist übrigens nicht immer supersauber, da er dadurch die Indexes neu aufbauen muß und auch die internen optimierungen zu den Tabellen vergisst ...

Optimize ist gut, aber bitte nicht täglich!

[gloob]

War in diesem Fall ja kein Stromausfall, wenn ich richtig lese, war das Gerät vorher ordentlich heruntergefahren. Nur logisch, dass nach dem Abschalten und Wiedereinschalten der Spannungsversorgung das Gerät aus bleibt.
Evtl. kann man in BIOS etwas wie "power on" oder "allways on" einstellen oder mit einem Kondensator parallel zum Einschaltknopf versuchen.

Bei Dell Geräten kann man zumindest im Bios einstellen, dass sie IMMER hochfahren, wenn Spannung am Netzteil anliegt, egal ob vorher sauber runter gefahren wurde oder nicht.

[Wzut]

nur ist leider mysql (mariaDB) in der Standardinstallaion unoptimiert. Also hast Du in der Config die DB optimiert?

sorry wenn ich mich da jetzt einmische , aber hast du Tipps oder eine Quelle was an der MariaDB zu optimieren ist unter dem Gesichtspunkt FHEM ?
IMHO nimmt Beta_User das dann bestimmt mit ins Thin Client Wiki

[Lucky2k12]

Nein ich meinte, ob die DB für das System optimiert wurde!

Code Auswählen Erweitern

Die DB wird täglich optimiert, sollte jedenfalls.
Du meinst ein "optimize Table"?

Ich habe MySQL mehr RAM zugewiesen ( weiß denn Parameter gerade nicht mehr, ich schau heute Abend Mal nach.)

Was sollte man außerdem machen?

Mit optimieren meinte ich eher aufräumen, Tagesdurchschnitt nach 90 Tagen und so.
optimize Table führe ich auch gelegentlich per heidisql aus.

Sorry war missverständlich ausgedrückt.

Gesendet von meinem Mi 9T Pro mit Tapatalk

[Beta-User]

Bei Dell Geräten kann man zumindest im Bios einstellen, dass sie IMMER hochfahren, wenn Spannung am Netzteil anliegt, egal ob vorher sauber runter gefahren wurde oder nicht.

Das geht auch bei den HP's, die Option heißt halt je nach BIOS-Lieferant (bzw. ggf. Version) anders... (Ist mWn. auch nichts, was auf die ThinClients begrenzt wäre).

Was das Speicherthema angeht:
Das kenne ich neuerdings auch (seit T620@Debian 10, bei dem T5470@Debian 9 war das nie ein bemerkbares Thema).
Als mögliche Verursacher auf der FHEM-Seite (neu im System) habe ich auch vorrangig DbLog und MPD (der MPD selbst läuft woanders, und ich habe dem Modul untersagt, die MPD-Datenbank zu lesen, das hatte sonst einen immensten Speicheranstieg zur Folge (ca. 1,5GB/Tag, k.A., ob das noch mehr geworden wäre)) unter Beobachtung, ansonsten gäbe es neu noch HUEBridge/HUEDevice.
Daneben gibt's eventuell noch TelegramBot, aber die zwei (pollenden) Instanzen sind schon ewig eingerichtet, könnte allenfalls was mit den Änderungen auf der Serverseite (beim Anbieter) zusammenhängen.

@Wernieman:
Die Installationsanleitung für DbLog im Wiki ist veraltet, da werden Pakete verwendet, die es zwischenzeitlich nicht mehr gibt. Vielleicht magst du dazu was aktualisiertes liefern (im Wiki-Bereich oder direkt im Wiki), und dann gleich "sinnvolle" Optimierungsschritte für "Datenbank-DAU"s wie mich vorschlagen?

(Ich pack's gerne auch ins ThinClient-Wiki, aber m.E. ist das eher ein generelles Thema, das genauso auf den Pi und andere SBC-Lösungen übertragbar ist).

Ansonsten die Bitte: Beide Themen (Speicherloch und DbLog-Optimierung) sind "eigentlich" kein Thema für diesen Thread, da mAn. nicht hardware-related. Wäre sinnvoller, das im passenden Thread bzw. separat zu diskutieren.

Gruß, Beta-User


Ach so, bei der Gelegenheit auch noch ein on-Topic-Teil ...

Zwischenstand zum T620:
Sehr zufrieden bis dahin .
Einziges "Manko": Muß irgendwann mal entweder den USB-Pi-HM-PCB-Stick aus dem Gehäuse holen (meine ganzen anderen Eigenbau-"Luftschnittstellen" hängen zwischenzeitlich in einem ausgebeinten FritzBox-Gehäuse, da wäre noch Platz) oder eine externe Antenne dranlöten; das Gehäuse schirmt ziemlich... Tendiere zur Antenne .

[Wernieman]

... habe aktuell kein mysql (mariaDB) für FHEm laufen. Entsprechend kann ich wenig optimi9rungsmöglichkeiten speziell für diese Anwendung sagen.
Ich bin auch kein spezieller mysql-Administrator, sondern in der generellen Linux-Schiene unterwegs. Da wäre ein Spezialist wahrscheinlich besser ......

Ich gehe davon aus, das die indizes passend gesetzt wurden?

Btw:
Da ich nicht mal weiß, was die Geräte an RAM haben, kann ich auch schlecht in die Richtung Tipps geben.

Aber Stichwörter währen:
Speicher
Indexgröße

[Beta-User]

  Nochmal: DB-DAU...

Habe nur das "notwendigste" aus diesem Artikel gemacht: https://wiki.fhem.de/wiki/DbLog
Dabei bei der Installation eben das anders gemacht, was für mariaDB erforderlich ist.

Rest/Optimierung: Bisher Fehlanzeige . Allerdings ist die Regex ziemlich eng gesetzt, da landen v.a. Umweltdaten, die meine MySensors-Nodes liefern (und etwas Zigbee), der Rest ist erst mal weiter FileLog-basiert (wenn überhaupt geloggt wird).

Wollte erst mal sehen, ob das überhaupt läuft und welche Unterschiede zu sehen sind. Muß sagen: bei Plots macht sich das mit der Datenbank deutlich bemerkbar, auch schon ohne Optimierung.

Speicher ist an sich kein Thema, das Teil hat "nur" 4 GB. Aber da keine GUI läuft und daneben im Moment nur noch deCONZ, ist es nicht sooo wichtig, ob FHEM jetzt davon 5% oder 10% nimmt (müßte mal nachsehen, aber das ist im Moment geschätzt eher <1% Anstieg pro Tag). Da ich derzeit häufiger updates mache (wg. attrTemplate und AutoSchuttersControl => Neustart), war mir das Thema bisher auch nicht so wichtig, dass ich das aktiver angegangen wäre, und auch auf der SSD ist reichlich Platz.

Aber währen dich das so schreibe, bin ich am Zweifeln, ob ich mit meinen nicht vorhandenen DB-Kenntnissen nicht besser beraten wäre, das mit sqlite zu machen?

(aber auch das ist OT, nur bin ich der TE... ).

[Wernieman]

Also bei 4 GByte könntest Du bei einem Server, der ansonsten nichts macht (abgesehen von fhem), doch der DB 2 GByte definitiv zuweisen.

Nur mal so als Idee:

Code Auswählen Erweitern

innodb_buffer_pool_size         = 1G
query_cache_type        = 1
query_cache_limit       = 1M
query_cache_size        = 128M


Es sei denn, Du hast dort schon gedreht ....

[Lucky2k12]

@Beta-User
Ich verstehe dich also richtig, dass es hardwareseitig keinen Grund gibt, warum der T610 mit ein bischen mysql so stark beschäftigt sein sollte!?
Ich habe außer FHEM noch mosquitto und nodered dashboard sowie grafana am laufen, aber die ziehen alle kaum am load:

Code Auswählen Erweitern


top - 18:49:23 up 2 days,  3:38,  1 user,  load average: 2,60, 2,64, 2,49
Tasks: 133 total,   1 running, 132 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1,3 us,  0,8 sy,  0,0 ni, 45,4 id, 52,4 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem :  3504880 total,  1346960 free,   957388 used,  1200532 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  2259932 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
30297 mysql     20   0 1787380 160416  17168 S   2,0  4,6   0:05.77 mysqld
1243 ludwig    20   0  974556 155968  29036 S   0,7  4,5  27:59.70 node-red
30334 root      20   0   44896   3808   3184 R   0,7  0,1   0:05.57 top
  516 root      20   0  202176  17116   4400 S   0,3  0,5   7:51.40 lepresenced
  604 root      20   0  503596  79280  43928 S   0,3  2,3   2:13.17 dockerd
  678 mosquit+  20   0   42316   4964   4364 S   0,3  0,1   4:02.99 mosquitto
30476 root      20   0       0      0      0 S   0,3  0,0   0:00.43 kworker/0:1
    1 root      20   0  204800   7244   5428 S   0,0  0,2   0:07.48 systemd
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.07 kthreadd
    3 root      20   0       0      0      0 S   0,0  0,0   0:03.12 ksoftirqd/0
    5 root       0 -20       0      0      0 S   0,0  0,0   0:00.00 kworker/0:0H


Total DISK READ :       0.00 B/s | Total DISK WRITE :       0.00 B/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:       0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
  245 be/3 root          0.00 B     36.00 K  0.00 % 67.75 % [jbd2/sda1-8]
30328 be/4 mysql         0.00 B      2.00 M  0.00 % 59.94 % mysqld
30306 be/4 mysql         0.00 B      0.00 B  0.00 % 31.14 % mysqld
30314 be/4 mysql         0.00 B   1116.00 K  0.00 % 29.34 % mysqld
30309 be/4 mysql         0.00 B      0.00 B  0.00 % 19.18 % mysqld
30318 be/4 mysql         0.00 B      3.75 M  0.00 %  2.40 % mysqld
30315 be/4 mysql         0.00 B   1508.00 K  0.00 %  2.27 % mysqld
  678 be/4 mosquitt      0.00 B      4.00 K  0.00 %  0.00 % mosquitto -c /etc/mosquitto/mosquitto.conf
    1 be/4 root          0.00 B      0.00 B  0.00 %  0.00 % init
    2 be/4 root          0.00 B      0.00 B  0.00 %  0.00 % [kthreadd]
    3 be/4 root          0.00 B      0.00 B  0.00 %  0.00 % [ksoftirqd/0]
  516 be/4 root          0.00 B      0.00 B  0.00 %  0.00 % perl /usr/sbin/lepres~--loglevel LOG_WARNING
    5 be/0 root          0.00 B      0.00 B  0.00 %  0.00 % [kworker/0:0H]
    7 be/4 root          0.00 B      0.00 B  0.00 %  0.00 % [rcu_sched]
    8 be/4 root          0.00 B      0.00 B  0.00 %  0.00 % [rcu_bh]
    9 rt/4 root          0.00 B      0.00 B  0.00 %  0.00 % [migration/0]




Es gibt auch noch den Artikel https://wiki.fhem.de/wiki/DbLog-MySQL , aber das überlappt inhaltlich recht stark mit dem von dir genannten.

@Wernieman:
Danke nochmal für die Hints!
Die innodb_buffer_pool_size hatte ich schon auf 1G, cache_size war auf 16M, die Änderung hat aber wohl leider nicht geholfen.
Ich überprüfe grad nochmal die Indices und verpiss mich dann aus Beta-Users Thread

[Wernieman]

Code Auswählen Erweitern

mosquitto und nodered dashboard sowie grafana

Ich glaube Du verstehst load nicht richtig. load gibt die Anzahl der auf IO wartenden Prozesse an.
https://de.wikipedia.org/wiki/Load
https://de.wikipedia.org/wiki/Load#Der_Load_Average_auf_Unix-Systemen

Du kannst also ein Prozess mit praktisch 0 CPU-Leistung haben, der aber eine load von 1 erzeugt, wenn er auf Hardware wartet. Es könnte also jeder Deiner Prozesse sein ... da hilft also kein top. Einfach mal einen Prozess runterfahren und gucken, was der load dann macht.

Aber wie oben schon mal gesagt:
Könntest Du einen neuen Thread aufmachen? Das ist ein Installations/Konfigurations-Problem und nicht ein ThinClient Problem

[DS_Starter]

Hallo miteinander,

ich habe mal ein bisschen was gelesen und vermute dass der Beitrag #133 von Lucky2k12 das Problem ist um das es momentan geht.

Ich habe DBLog auf mariadb am laufen, und das scheint das Problem zu sein.
apptime zeigt auch DBLogging als Spitzenreiter an.

Das deutet darauf hin , dass DbLog bei dir im synchronen Modus läuft, was der Standard ist. Allerdings ist es auch unter diesen Umständen nicht in Ordnung dass die Werte auffällig sind.
Um mehr herauszubekommen setze im ersten Schritt bitte die Attribute:

Code Auswählen Erweitern


showproctime = 1
showNotifyTime = 1

Wenn das gemacht ist führe bitte ein

Code Auswählen Erweitern

set <name> configCheck

aus und poste mal die Ausgabe.

Ich hab die Logs auch dezimiert, da kommen etwa 10 Werte pro Minute rein.

Das ist ein "Fliegenschiß" 
Meine MariaDB auf einer VM mit 750M RAM verarbeitet 4000 gecachte Events innerhalb von 0.7136 Sekunden (im asynchronen Mode)

Um die Datenbank-Einstellungen selbst zu checken bietet sich das Script mysqltuner an.
Du kannst es installieren mit:

Code Auswählen Erweitern

sudo apt-get install mysqltuner

Aufruf als root mit:

Code Auswählen Erweitern

mysqltuner --user <DB-Adminuser> --pass <DB-Adminuser-Passwort>

Der Check bringt dann Hinweise was man an der DB-Konfiguration ändern sollte. Diese Dinge werden wahrscheinlich in der Datei

Code Auswählen Erweitern

/etc/mysql/mariadb.conf.d/50-server.cnf

eingetragen. MariaDB inkludiert mehrere Verzeichnisse in denen Konfigurationsdateien sein können. Ausgangspunkt ist die
/etc/mysql/my.cnf. Dort steht drin welche Verzeichnisse durchsucht werden:

Code Auswählen Erweitern


# The MariaDB configuration file
#
# The MariaDB/MySQL tools read configuration files in the following order:
# 1. "/etc/mysql/mariadb.cnf" (this file) to set global defaults,
# 2. "/etc/mysql/conf.d/*.cnf" to set global options.
# 3. "/etc/mysql/mariadb.conf.d/*.cnf" to set MariaDB-only options.
# 4. "~/.my.cnf" to set user-specific options.
#
# If the same option is defined multiple times, the last one will apply.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.

#
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]

# Import all .cnf files from configuration directory
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/


Grüße,
Heiko

[Wernieman]

mysqltuner kannte ich noch nicht .. danke für den Tipp (Unabhängig von FHEM)

Bei mir übrigens bearbeitet er keine Config-Files. Er gibt nur eine Ausgabe zur Optimierung

Ansonsten würde ich mir mal die Belastung mit "mytop" ansehen.

Aber:
Dieses hat nichts mehr mit diesem thread zu tuen. Können wir bitte dafür einen neuen aufmachen?

[DS_Starter]

Moin Werner,

ja das Script gibt nur Infos aus, es bearbeitet nichts. Ändern muss man selbst und auch die Ausgaben vorher bewerten und etwas recherchieren, nichz einfach blind übernehmen. 
Neuer Thread ist auch gut weil OT !

LG,
Heiko

[Lucky2k12]

Neuer Thread, hier geht's weiter:
https://forum.fhem.de/index.php/topic,103996.0.html


Danke für eure Geduld und Hilfe soweit