93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)

[abc2006]

Hi,
klappt. Vielen Dank.

Welche Option hat denn das Problem verursacht?
Ich habe ein bisschen das Gefühl, ich hab meine DB kaputtoptimiert, deshalb beschäftige ich mich grade etwas damit. Evtl kommt dann demnächst auch mal ein kompletter reinstall ...


Grüße,
Stephan

[DS_Starter]

Hi Stephan,

der in der Fehlermeldung drin steht:

...GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

Habe dann ein bisschen gegoogelt.
Aber schön dass es jetzt klappt. Wer weiß wie oft das sonst noch hochkommen würde.

Grüße
Heiko

[abc2006]

Hi,
seit gestern abend sind keine Daten mehr in die Datenbank geschrieben worden.

Mein Log ist voll von solchen Meldungen:

2017.12.06 18:32:49.344 5: DbLog logdb -> processing event Timestamp: 2017-12-06 03:28:21, Device: RE_TEMP_Ruecklauf_Solar, Type: DUMMY, Event
: , Reading: temperature, Value: 21.56, Unit:
2017.12.06 18:32:49.344 5: DbLog logdb -> processing event Timestamp: 2017-12-06 03:28:22, Device: Stromzaehler, Type: VZ, Event: , Reading: t
otal_power_L1, Value: 154, Unit:
2017.12.06 18:32:49.344 5: DbLog logdb -> processing event Timestamp: 2017-12-06 03:28:22, Device: RE_TEMP_Vorlauf_EG_Boden, Type: DUMMY, Even
t: , Reading: temperature, Value: 25.25, Unit:
2017.12.06 18:32:49.345 5: DbLog logdb -> processing event Timestamp: 2017-12-06 03:28:23, Device: RE_TEMP_Ruecklauf_EG_Boden, Type: DUMMY, Ev
ent: , Reading: temperature, Value: 23.81, Unit:
2017.12.06 18:32:49.345 5: DbLog logdb -> processing event Timestamp: 2017-12-06 03:28:24, Device: RE_TEMP_Ruecklauf_WT_EG, Type: DUMMY, Event
: , Reading: temperature, Value: 24.56, Unit:

2017.12.06 00:00:43.228 2: DbLog logdb -> Error table history - DBD::mysql::st execute_array failed: executing 540 generated 2 errors at ./FHEM/93_DbLog.pm line 1866.

2017.12.06 00:00:46.636 2: DbLog logdb -> Error table history - DBD::mysql::st execute_array failed: executing 598 generated 2 errors at ./FHEM/93_DbLog.pm line 1866.

2017.12.06 00:00:48.887 2: DbLog logdb -> Error table history - DBD::mysql::st execute_array failed: executing 608 generated 2 errors at ./FHEM/93_DbLog.pm line 1866.

2017.12.06 00:00:50.746 2: DbLog logdb -> Error table history - DBD::mysql::st execute_array failed: executing 618 generated 2 errors at ./FHEM/93_DbLog.pm line 1866.

2017.12.06 00:00:52.917 2: DbLog logdb -> Error table history - DBD::mysql::st execute_array failed: executing 626 generated 2 errors at ./FHEM/93_DbLog.pm line 1866.

Code Auswählen Erweitern

2017.12.06 18:39:27.109 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:27.213 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:27.761 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:28.282 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:28.285 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:28.288 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:28.395 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:28.940 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:29.484 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:30.150 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:30.153 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:30.156 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:30.580 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:31.124 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:31.683 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.018 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.021 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.160 5: CUL/RAW: /TED84CE02F1

2017.12.06 18:39:32.161 4: CUL_Parse: CUL_0 TED84CE02F1 -81.5
2017.12.06 18:39:32.162 5: CUL_0: dispatch TED84CE02
2017.12.06 18:39:32.241 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.655 5: CUL/RAW: /TED84CE82F1

2017.12.06 18:39:32.655 4: CUL_Parse: CUL_0 TED84CE82F1 -81.5
2017.12.06 18:39:32.656 5: CUL_0: dispatch TED84CE82
2017.12.06 18:39:32.718 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.721 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.724 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.802 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.805 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.867 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:33.521 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.


Auch ein attr logdb verbose 5 scheint nicht mehr output zu generieren.
Kann jemand helfen?
Was kann ich tun?

Grüße,
Stephan

PS: beim "list logdb" hängt sich fhem auf.
deshalb gibts hier nen Screenshot.

[DS_Starter]

Hi Stephan,

du hast 2 Datensätze die nicht in die DB wollen und Fehler versursachen. Letztlich hatte jemand genau den gleichen Fall weil seine Feldgrößen in der DB von den im DbLOg-Device verwendeten Größen unterschiedlich waren.

Zur Lösung schlage ich rstmal vor vor:

* setze dir cacheLimit hoch (5000) damit etwas Ruhe herrscht. Gleiches gilt für Syncinterval
* mache eine cacheexport "set ... exportcache nopurge" damit keine Daten verloren gehen
* dann führe mal "set ... configCheck" aus und poste was du siehst.

[abc2006]

Hi,

ich hab unten mal nen configCheck gesetzt, aber:

Da FHEM bereits aufgegeben hat (nicht mehr bedienbar, deshalb habe ich neu gestartet) sind die Daten nicht mehr im Cache.

Habe aber die TEST-Instanz noch laufen, da wurden die Daten geloggt.
Weiss auch nicht, ob dir das configCheck jetzt noch hilft:

Code Auswählen Erweitern

Result of connection check

Connection to database fhem successfully done.
Recommendation: settings o.k.

Result of encoding check

Encoding used by Client (connection): LATIN1
Encoding used by DB fhem: UTF8
Recommendation: Both encodings should be identical. You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file './db_fhem.conf' to the right value.

Result of logmode check

Logmode of DbLog-device logdb is: asynchronous
Recommendation: settings o.k.

Result of table 'history' check

Column width set in DB fhem.history: 'DEVICE' = 64, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 0, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table history and the field width used in device logdb don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:

DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32

You can change the column width in database by a statement like 'alter table history modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCMD' in DbRep or in a SQL-Editor of your choice. (switch logdb to asynchron mode for non-blocking).
The field width used by the module can be adjusted by attributes 'colEvent', 'colReading', 'colValue',

Result of table 'current' check

Column width set in DB fhem.current: 'DEVICE' = 64, 'TYPE' = no result, 'EVENT' = no result, 'READING' = 24, 'VALUE' = 24, 'UNIT' = no result
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 0, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table current and the field width used in device logdb don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:

DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32

You can change the column width in database by a statement like 'alter table current modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCMD' in DbRep or in a SQL-Editor of your choice. (switch logdb to asynchron mode for non-blocking).
The field width used by the module can be adjusted by attributes 'colEvent', 'colReading', 'colValue',

Result of check 'Search_Idx' availability

Index 'Search_Idx' exists and contains the recommended fields 'DEVICE', 'READING', 'TIMESTAMP'.
Recommendation: settings o.k.

Result of check 'Report_Idx' availability for DbRep-devices

You use at least one DbRep-device assigned to logdb, but the recommended index 'Report_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Report_Idx ON `history` (TIMESTAMP, READING) USING BTREE;'
Depending on your database size this command may running a long time.
Please make sure the device 'logdb' is operating in asynchronous mode to avoid FHEM from blocking when creating the index.
Note: If you have just created another index which covers the same fields and order as suggested (e.g. a primary key) you don't need to create the 'Report_Idx' as well !

Okay, erstmal als Antwort. Ich hab schon gesehn, da sind ein paar Sachen im argen, ich arbeite das erstmal durch.

Was ich aber loswerden wollte:
Kannst du für den Fall eine Fehlermeldung schreiben/generieren, die mir sagt, was das Problem ist?
Oder war das die Stelle, wo du meintest, dass dir die Datenbank nur einen allgemeinen Fehler liefert, aus dem du keine weiteren Infos holen kannst?

Und mich würde interessieren, warum (dadurch? ) FHEM abstürzt...
Wenn ich noch Infos liefern kann, lass es mich wissen!

Grüße,
Stephan

[DS_Starter]

Hi Stephan,

ja, der Check war hilfreich un aufschlussreich. Das Problem ist dadurch verursacht:

Column width set in DB fhem.history: 'DEVICE' = 64, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 0, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32

MySQL ist da etwas empfindlich bei solchen Misskonfigurationen, dafür gibts diesen Check.
Du kannst das Feld Reading vergrößern (empfohlen) oder per Attribut colReading im Modul beschränken.

Bei der current-Tabelle sieht es noch schlimmer aus. Da musst du mal ran.

Kannst du für den Fall eine Fehlermeldung schreiben/generieren, die mir sagt, was das Problem ist?

Naja, stand ja da.    Man muß es nur interpretieren können.

Und mich würde interessieren, warum (dadurch? ) FHEM abstürzt...

Nun, ich denke nicht dass FHEM "abgetürzt" ist. Du hast ein "list device" gemacht. Leider waren unmengen an Daten im Cache der im Browser angezeigt werden sollte. Dadurch war deine Browsersession überlastet. Wahrscheinlich hätte sich sich mit viel Geduld wieder eingekriegt.


Aber ich hatte dieses generelle Problem erkannt und mit etlichen weiteren Änderungen und einem Bugfix wegen dieses Problems:
https://forum.fhem.de/index.php/topic,80519.0.html
eine überarbeitet Version erstelt. Damit sollte es auch Geschichte sein dass wegen einem oder 2 Datensätzen der ganze Cache nicht in der Datenbank persistiert werden kann.
Das Problem mit dem "list Device" nehme ich mal mit auf die Agenda damit sowas nicht mehr vorkommt.

Die neue Version hänge ich gleich mit Begleittext hier an.
Bitte lade sie dir runter setze sie ein.
Eigentlich wäre es jetzt erstmal gut wenn du an der DB noch nichts richten würdest damit wir im Fehlerfall sehen wie das Modul reagiert.
Hat ein bisschen was von Versuchskaninchen....sorry 

Grüße
Heiko

[abc2006]

Code Auswählen Erweitern

Eigentlich wäre es jetzt erstmal gut wenn du an der DB noch nichts richten würdest damit wir im Fehlerfall sehen wie das Modul reagiert.
Hat ein bisschen was von Versuchskaninchen....sorry  :D

Kein Problem, dafür bin ich ja hier unterwegs.

Hab nur jetzt leider schon die ersten spalten verbreitert... Würde die TEST-Datenbank mal so hinbauen, wie die live-DB war/ist, dann müsste man den Fehler ja auch sehen... oder?

Was mir grade nicht so klar war: warum hatte auch das zweite logDB-Device, welches auf eine getrennte Datenbank (auf dem gleichen Server) loggt, Probleme? Sollten die nicht unabhängig voneinander laufen?

EDIT: die Spalte TYPE ließ sich schnell anpassen, die Spalte READING scheint deutlich aufwendiger zu sein ...

Grüße,
Stephan

[DS_Starter]

Was mir grade nicht so klar war: warum hatte auch das zweite logDB-Device, welches auf eine getrennte Datenbank (auf dem gleichen Server) loggt, Probleme? Sollten die nicht unabhängig voneinander laufen?

Davon hatte ich bisher nichts gelesen. Du hattest nur geschrieben :

Habe aber die TEST-Instanz noch laufen, da wurden die Daten geloggt.

Was gabs da für Probleme ?

Würde die TEST-Datenbank mal so hinbauen, wie die live-DB war/ist, dann müsste man den Fehler ja auch sehen... oder?

DAs wäre gut ... und ja, früher oder später.

[abc2006]

Was gabs da für Probleme ?

Ja, die Daten wurden geloggt.
Sorry, für das durcheinander, ich hab leider noch nicht so richtig den Durchblick, was hier was macht.

Die TEST-Instanz hatte insofern Probleme, dass die Fehlermeldung kam, dass die Daten nicht geschrieben werden konnten und es erneut versucht wird.

Die genaue Fehlermeldung hab ich leider grad nicht da, weil ich die Datenbank jetzt nicht noch zusätzlich stressen will...
Ab und zu muss es aber funktioniert haben, dann wurde der Cache von 3000-4000 wieder auf 0 gesetzt.
Vielleicht hat der Fehler im live-logdb die Datenbank so belastet, dass das Test-logdb nicht mehr richtig durchgekommen ist?

Nur mal als Idee, wie wäre es, wenn bei Problemen mindestens xxx Sekunden gewartet wird (zb. 1x SyncInterval), zusätzlich wird eine Datei angelegt und die vorhandenen/auflaufenden Nachrichten dort hineingeschrieben. Sobald der commit funktioniert hat, wird die Datei wieder gelöscht. Evtl. Optional ein Threshold, der einstellt, wie oft der commit fehlschlagen muss, bis so eine Datei erzeugt wird...

Grüße,
Stephan

[DS_Starter]

Die TEST-Instanz hatte insofern Probleme, dass die Fehlermeldung kam, dass die Daten nicht geschrieben werden konnten und es erneut versucht wird.

Die genaue Fehlermeldung hab ich leider grad nicht da, weil ich die Datenbank jetzt nicht noch zusätzlich stressen will...
Ab und zu muss es aber funktioniert haben, dann wurde der Cache von 3000-4000 wieder auf 0 gesetzt.
Vielleicht hat der Fehler im live-logdb die Datenbank so belastet, dass das Test-logdb nicht mehr richtig durchgekommen ist?

Auszuschließen wäre so etwas nicht wenn die Ressourcen aufgebraucht sind und die DB nicht mehr richtig arbeiten kann. Im Nachhinein kann man da nur mutmassen.

Nur mal als Idee, wie wäre es, wenn bei Problemen mindestens xxx Sekunden gewartet wird (zb. 1x SyncInterval), zusätzlich wird eine Datei angelegt und die vorhandenen/auflaufenden Nachrichten dort hineingeschrieben. Sobald der commit funktioniert hat, wird die Datei wieder gelöscht. Evtl. Optional ein Threshold, der einstellt, wie oft der commit fehlschlagen muss, bis so eine Datei erzeugt wird...

Die Sache mit der Datei kannst du dir bereits jetzt bauen.
Es gibt das Attr "cacheEvents" (siehe commandref). Setze dir das auf 2 und werte die Events mit einem Notify aus. Überschreitet der Wert einen Schwellenwert (natürlich höher) als cacheLimit, schreibe dir den Cache raus "set ... exportCache" . Wahlweise mit den Optionen purge/nopurge.
Und lasse dich informieren -> Mail/Telegram , what ever damit du reagieren kannst.

Das mit der Wartezeit bei Überschreiten des cacheLimits bei Fehler überlege ich mir mal.
Manchmal ist ein Fehler auch kein Fehler, zum Beispiel weil der User ein Offline Backup angeworfen hat oder die DB zur Wartung gestoppt hat usw. In dem Fall weiß er wieso die Fehler geworfen werden ...

Aber grundsätzlich braucht man solche Verrenkungen garnicht machen.  Wichtig ist die Ursache zu erkennen und zu beheben, in deinem Fall eine schlecht eingestellte Datenbank die früher oder später Probleme bereiten _muss_.
Gerade MySQL/MariaDB ist eine super dankbare DB die, richtig erstellt, einfach nur läuft, läuft, läuft .... 

So, jetzt teste ich die neue V noch etwas und stelle sie dann hier ein.

Grüße
Heiko

[DS_Starter]

Hallo zusammen,

in den letzten paar Tagen sind noch ein/zwei Issues aufgetreten, die mich veranlasst haben die hier angehängte Version 3.2.0 zu erstellen. Hier die Änderungen/Ergänzungen zur eingecheckten V2.22.15. zusammengefasst:

* neues Attribut "useCharfilter"
  Erlaubt nur die ASCII Zeichen von 32 bis 126 im Datensatz. Umlaute und "€" werden umgesetzt.

* ein neues Attribut "commitMode"
  Ändert das Autocommit- bzw. Transaktionsverhalten der DB. Dadurch ist es möglich mit den Tabellen ohne Transaktionen zu arbeiten.
  Im Code habe ich nochmal besonders danach geschaut dass alle Varianten unterstützt werden.
  (Advanced Feature)

* die Ausgaben sind erweitert (verbose 4), man sieht z.B. mit welchem AutoCommit/Transaktionsmode die Session läuft, bzw. wieviele Datensätze eines Sync-Laufs committed/rejected wurden -> Beispiel:

Code Auswählen Erweitern


2017.12.06 18:46:00.104 4: DbLog LogDB -> ################################################################
2017.12.06 18:46:00.105 4: DbLog LogDB -> ###      New database processing cycle - asynchronous        ###
2017.12.06 18:46:00.106 4: DbLog LogDB -> ################################################################
2017.12.06 18:46:00.107 4: DbLog LogDB -> MemCache contains 50 entries to process
2017.12.06 18:46:00.107 4: DbLog LogDB -> DbLogType is: Current/History
2017.12.06 18:46:00.133 4: DbLog LogDB -> AutoCommit mode: ON, Transaction mode: ON
2017.12.06 18:46:00.276 4: DbLog LogDB -> 50 of 50 events inserted into table history using PK on columns TIMESTAMP,DEVICE,READING
2017.12.06 18:46:00.278 4: DbLog LogDB -> insert history committed
2017.12.06 18:46:00.343 4: DbLog LogDB -> 50 of 50 events updated in table current using PK on columns DEVICE,READING
2017.12.06 18:46:00.345 4: DbLog LogDB -> insert / update table current committed




* für die reduceLog/Nbl sind Fortschrittsmitteilungen eingebaut, damit man sieht wo der Prozess ungefähr steht. Das gilt auch für das blockierende reduceLog.
  Hier muß man sich das Logfile außerhalb von fhem anschauen, z.B. mit tail -f <file>, um es zu verfolgen.  Das ist sicherlich insbesondere bei lang laufenden Prozessen von Interesse. Beispiel:

Code Auswählen Erweitern


2017.12.03 20:42:02.260 3: DbLog LogDB1: reduceLogNbl requested with DAYS=197, AVERAGE=DAY
2017.12.03 20:42:04.039 3: DbLog LogDB1: reduceLogNbl deleting 1448 records of day: 2017-05-18
2017.12.03 20:42:04.249 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-18 is: 100
2017.12.03 20:42:04.441 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-18 is: 200
2017.12.03 20:42:04.635 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-18 is: 300
......
2017.12.03 20:42:07.227 3: DbLog LogDB1: reduceLogNbl (hourly-average) updating 23 records of day: 2017-05-18
2017.12.03 20:42:07.316 3: DbLog LogDB1: reduceLogNbl (daily-average) updating 33, deleting 629 records of day: 2017-05-18
2017.12.03 20:42:07.501 3: DbLog LogDB1: reduceLogNbl (daily-average) deleting progress of day: 2017-05-18 is: 100
2017.12.03 20:42:07.677 3: DbLog LogDB1: reduceLogNbl (daily-average) deleting progress of day: 2017-05-18 is: 200
2017.12.03 20:42:07.879 3: DbLog LogDB1: reduceLogNbl (daily-average) deleting progress of day: 2017-05-18 is: 300
.....
2017.12.03 20:42:09.317 3: DbLog LogDB1: reduceLogNbl deleting 39029 records of day: 2017-05-19
2017.12.03 20:42:29.305 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-19 is: 10000
2017.12.03 20:42:51.521 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-19 is: 20000
2017.12.03 20:43:12.680 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-19 is: 30000
....



* neues Kommanndo "addCacheLine"
  Es erlaubt das Einfügen eines Datensatzes direkt in den Cache. Die Weiterverabeitung erfolgt beim nächsten Datenbank-Synclauf
 
* redesign der Push/PushAsync-Funktionen wegen dem Issue Forum: https://forum.fhem.de/index.php/topic,80519.0.html (hoffentlich)
  Dadurch sollte ebenfalls das eventuelle Problem beseitigt sein, dass ein fehlerhafter Datensatz im Cache verhindert, dass der restliche Cache
  in die DB eingefügt wird.

* einige kleinere / kosmetische Anpassungen

* Ergänzung: mit angehängter V3.3.0 wird bei "list device" der Inhalt des cache nicht mehr mit gelistet. Das verhindert im Fehlerfall (wenn der cache sehr groß ist), dass ein list die Browsersession überlastet.

Ich würde mich sehr über Rückmeldungen freuen.

Grüße
Heiko

[abc2006]

Überschreitet der Wert einen Schwellenwert (natürlich höher) als cacheLimit,

Erledigt.
Allerdings war der Cache-Wert nicht so hoch, als dass dort alle Events seit gestern Nacht drin gewesen wären. Es waren vllt 4000 Einträge drin...


Grüße,
Stephan

[abc2006]

Noch ne Frage, auf die ich irgendwie keine befriedigende Antwort finde:

Benötigt eine Datenbank (Tabelle, Datensatz) mit einem 128er Feld, von dem nur 1 Zeichen genutzt ist, mehr Speicher, als eine Datenbank mit einem 5er Feld, von dem 1 Zeichen genutzt ist?

Benötigt eine Datenbank (Tabelle, Datensatz) mit einer überflüssigen/leeren Spalte mehr Speicher als ohne diese Spalte?

Beeinflussen zu lange/unnötige Felder die Performance (negativ)?
Irgendwie werd ich aus der Doku nicht schlau...

Falls ja: warum ein 128er Feld für Value?
Warum Value und Event in der current-Table?

Grüße,
Stephan

[abc2006]

Grade hatte ich wieder ein Problem, mehr als 2000 Queries anstehen, es half nur noch ein kill.
Könnten unschöne Einträge wie der von HTTPMOD dafür verantwortlich sein?:

X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
Vary: Accept-Encoding
Server: cloudflare-nginx
CF-RAY: 3c9278282abc9706-FRA
2017.12.06 22:51:56.949 4: BTC_HTTPMOD: Read callback: request type was update retry 0,
Header: HTTP/1.1 200 OK
Date: Wed, 06 Dec 2017 21:51:56 GMT
Content-Type: text/html; charset=utf-8
Connection: close
Set-Cookie: __cfduid=ded74d2625a963ba7635e244bd13b493d1512597116; expires=Thu, 06-Dec-18 21:51:56 GMT; path=/; domain=.bitcoin.de; HttpOnly
Cache-Control: private
Set-Cookie: bitcoin_de_supercoin=04ec978fdccdf1c045c3f779bbefa5a7:ad748936490684509aebb82496e71c74de079faa; path=/; secure; httponly
Set-Cookie: bitcoin_de_language_keks=de_DE; expires=Fri, 05-Jan-2018 21:51:56 GMT; path=/; secure; httponly
Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
Vary: Accept-Encoding
Server: cloudflare-nginx
CF-RAY: 3c9278282abc9706-FRA,
Body: <!DOCTYPE html>
<html lang="de">
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <link rel="alternate" href="https://www.bitcoin.de" hreflang="x-default"/>
    <link rel="alternate" href="https://www.bitcoin.de/de" hreflang="de"/>
    <link rel="alternate" href="https://www.bitcoin.de/en" hreflang="en"/>
    <link rel="alternate" href="https://www.bitcoin.de/es" hreflang="es"/>
    <link rel="alternate" href="https://www.bitcoin.de/fr" hreflang="fr"/>
.....

Grüße,
Stephan

[DS_Starter]

Könnten unschöne Einträge wie der von HTTPMOD dafür verantwortlich sein?:

Immer wenn ein Feld im Modul länger ist als die DB zulässt ist es ein Problem.
Das ist natürlich ein außerordentliches Exemplar. In welches Felf sollte das denn rein ?

Benötigt eine Datenbank (Tabelle, Datensatz) mit einer überflüssigen/leeren Spalte mehr Speicher als ohne diese Spalte?

Meines Wissens nur 2 Byte

Beeinflussen zu lange/unnötige Felder die Performance (negativ)?

Nein bis vernachlässigbar. Viel wichtiger sind passende Indexe.

warum ein 128er Feld für Value?

Damit Werte bis 128 Byte hineinpassen    Es gibt ja auch Textwerte.

Warum Value und Event in der current-Table?

Die ganze Tabellenstruktur ist historisch gewachsen. Man braucht sie eigentlich nicht.

Es gibt einen Satz von Attribute, die mit "col..." anfangen. Damit kann man die Zeichenbreite im Modul der tatsächlichen Feldbeite in der DB anpassen.
Man kann sie aber auch benutzen um z.B. das Schreiben des Feldes Event zu verhindert indem man das Attribut colEvent = 0 setzt.

Grüße
Heiko