[vz-users] ständig Gateway Timeout - Performance DB steigern
Andreas Goetz
cpuidle at gmail.com
Fr Apr 2 07:30:19 CEST 2021
Slow query log ist erstmal ne gute Idee, die kannst du dann mit explain plan einzeln analysieren.
Viele Grüße, Andreas
> Am 01.04.2021 um 23:47 schrieb René W. <tylonhh at gmail.com>:
>
>
> Hallo Zusammen,
>
> ich kann mittlerweile nur noch müßig aufs Frontend zugreifen. Erst nach mehrmaligen Laden.
> Firefox 87.0 (64bit)
> Mein Setup sieht folgendermaßen aus. USB-IR -> Raspberry 3B+ -> Synology NAS
> Das sollte doch eigentlich den Pi entlasten. Auch habe ich bereits die manuelle Aggregation per Hand durchgeführt mit
> php /var/www/volkszaehler.org/bin/aggregate run -m full -l day -l hour -l minute
> (Quelle: https://wiki.volkszaehler.org/howto/datenmengen)
>
> Bei der Prüfung der Aggregation habe ich:
> version "0.3"
> capabilities
> database
> data
> rows 48231750
> size 4097835008
> aggregation
> rows 5486728
> size 630407168
> ratio 8.791
>
> Sollte also klappen. Auch die regelmäßige Aggregation ist im cronjob hinterlegt.
>
> Vielleicht was auffälliges in der vzlogger.conf ?
>
> {
> "retry": 0,
> "daemon": true,
> "verbosity": 0,
> "log": "/var/log/vzlogger.log",
> "push": [],
> "local": {
> "enabled": false,
> "port": 8080,
> "index": false,
> "timeout": 0,
> "buffer": 0
> },
> "meters": [
> {
> "enabled": true,
> "allowskip": true,
> "interval": -1,
> "aggtime": 10,
> "aggfixedinterval": true,
> "channels": [
> {
> "api": "volkszaehler",
> "uuid": "07689860- XXXXXXXX", //Haus Q3D
> "middleware": "http://192.168.178.22:81/middleware.php",
> "identifier": "1-0:1.7.0", //Wirkleistung 1-0:1.7.0 0.2868
> //"secretKey": "",
> //"type": "device",
> //"scaler": 1000,
> "aggmode": "AVG", //"AVG", // "AVG" Der Mittelwert für Leistung, "MAX" für Zähler, "SUM" für Counter
> "duplicates": 0
> },
> {
> "api": "volkszaehler",
> "uuid": "c1006760- XXXXXXXX", //Haus Q3D
> "middleware": "http://192.168.178.22:81/middleware.php",
> "identifier": "1-0:1.8.0", //Gesamtleistung 1-0:1.7.0 0.2868
> //"secretKey": "",
> //"type": "device",
> //"scaler": 1000,
> "aggmode": "MAX", //"AVG", // "AVG" Der Mittelwert für Leistung, "MAX" für Zähler, "SUM" für Counter
> "duplicates": 0
> }
> ],
> "protocol": "d0",
> "device": "/dev/usb-ir-lesekopf0",
> "dump_file": "",
> //"pullseq": "2f3f210d0a",
> //"ackseq": "auto",
> "baudrate": 9600,
> //"baudrate_read": 9600,
> "parity": "7e1"
> //"wait_sync": "off",
> //"read_timeout": 10,
> //"baudrate_change_delay": 0
> },
> {
> "enabled": true,
> "allowskip": true,
> "interval": -1,
> "aggtime": -1, // >interval
> "aggfixedinterval": true,
> "channels": [
> {
> "api": "volkszaehler",
> "uuid": "eb3fa3d0- XXXXXXXX", //WP Elster AS1440 0.1833
> "middleware": "http://192.168.178.22:81/middleware.php",
> "identifier": "1-1:1.7.0", //Leistung
> "aggmode": "AVG", // "AVG" Der Mittelwert für Leistung, "MAX" für Zähler, "SUM" für Counter
> "secretKey": "",
> //"type": "device",
> //"scaler": 0.001,
> "duplicates": 0
> },
> {
> "api": "volkszaehler",
> "uuid": "c105ad10-XXXXXXXX", //WP Elster AS1440 0.1833
> "middleware": "http://192.168.178.22:81/middleware.php",
> "identifier": "1-1:1.8.0", //Gesamt
> "aggmode": "MAX", // "AVG" Der Mittelwert für Leistung, "MAX" für Zähler, "SUM" für Counter
> "secretKey": "",
> //"type": "device",
> //"scaler": 1,
> "duplicates": 0
> },
> {
> "api": "volkszaehler",
> "uuid": "563d4950- XXXXXXXX", //WP Elster AS1440 0.1833
> "middleware": "http://192.168.178.22:81/middleware.php",
> "identifier": "1-1:1.8.1", //HT
> "aggmode": "AVG", // "AVG" Der Mittelwert für Leistung, "MAX" für Zähler, "SUM" für Counter
> "secretKey": "",
> //"type": "device",
> //"scaler": 1,
> "duplicates": 0
> },
> {
> "api": "volkszaehler",
> "uuid": "953700e0- XXXXXXXX", //WP Elster AS1440 0.1833
> "middleware": "http://192.168.178.22:81/middleware.php",
> "identifier": "1-1:1.8.2", //NT
> "aggmode": "AVG", // "AVG" Der Mittelwert für Leistung, "MAX" für Zähler, "SUM" für Counter
> "secretKey": "",
> //"type": "device",
> //"scaler": 1,
> "duplicates": 0
> }
> ],
> "protocol": "d0",
> "device": "/dev/usb-ir-lesekopf1", //
> "dump_file": "",
> "pullseq": "2F3F210D0A",
> "ackseq": "auto",
> "baudrate": 300,
> "baudrate_read": 9600,
> "parity": "7e1",
> //"wait_sync": "off",
> "baudrate_change_delay": 500,
> "read_timeout": 100
> }
> ]
> }
>
> In phpMyAdmin habe ich noch folgende Performance Probleme entdeckt. Da traue ich mich aber nicht ran. Muss da nicht in der Logik was geändert werden?
>
> Problem
> Empfehlung
> {long_query_time} ist auf 10 Sekunden oder mehr gesetzt, somit werden nur langsame Abfragen geloggt, die länger als 10 Sekunden laufen.
> Es wird empfohlen, long_query_time auf einen niedrigeren Wert zu setzen, abhängig von Ihrer Umgebung. Gewöhnlich wird ein Wert von 1 bis 5 Sekunden vorgeschlagen.
> Die Überwachung langsamer Anfragen ist deaktiviert.
> Loggen von langsamen Abfragen einschalten, indem slow_query_log auf 'ON' gesetzt wird. Das hilft beim Erkennen von grauenhaft langsamen Abfragen.
> Version ist aus Quellen übersetzt, keine offizielle MySQL-Binärversion.
> Wenn Sie den Quellcode nicht kompiliert haben, kann es sein, dass Sie ein Paket verwenden, welches durch eine Distribution verändert wurde. Die MySQL-Dokumentation ist nur für offizielle MySQL Binaries gültig, nicht für Paket-Distributionen (z.B. RedHat, Debian/Ubuntu, etc).
> Zu viele Sortierungen verursachen temporäre Tabellen.
> Ziehen Sie in Betracht, sort_buffer_size und/oder record_rnd_buffer zu erhöhen, je nach verfügbarem Speicher Ihres Systems.
> Es werden viele Zeilen sortiert.
> Auch wenn ein hoher Anteil an Zeilensortierungen nicht falsch ist, sollten Sie darauf achten, dass die Abfragen, die viele Sortierungen verwenden, indizierte Spalten in der ORDER-BY-Klausel verwenden, da dies zu viel schnellerem Sortieren führt.
> Es werden zu viele Joins ohne die Benutzung von Indizes durchgeführt.
> Dies bedeutet, dass Joins vollständige Tabellenscans durchführen. Indizes für die Spalten zu verwenden, die in den Join-Bedingungen eingesetzt werden, wird die Joins erheblich beschleunigen.
> Die Lese-Rate fester Positionen ist hoch.
> Dies deutet darauf hin, dass viele Abfragen Sortieren und/oder vollständige Tabellen-Scan benötigen, einschließlich Join-Abfragen die keine Indizes verwenden. Fügen Sie Indizes hinzu wo zutreffend.
> Lese-Rate nächste Tabellenzeile ist hoch.
> Dies deutet darauf hin, dass viele Abfragen Full Table Scans durchführen. Fügen Sie Indizes hinzu wo zutreffend.
> Viele temporäre Tabellen werden auf die Festplatte geschrieben, anstelle im Speicher gehalten zu werden.
> Erhöhen von max_heap_table_size und tmp_table_size könnten helfen. Jedoch werden einige temporären Tabellen immer unabhängig vom Wert dieser Variablen auf den Datenträger geschrieben. Um diese zu verhindern müssen Sie Ihre Abfragen so umschreiben das es nicht zu diesen Bedingungen kommt (Innerhalb einer temporären Tabelle: Vorhandensein eines BLOB- oder TEXT-Spalte oder eine Spalte größer als 512 Bytes) wie am Anfang von Artikel der Pythian Group erwähnt wird
> MyISAM Schlüssel-Cache (Indize Cache) % benutz ist niedrig.
> Sie müssen möglicherweise Ihren key_buffer_size verkleinern, überprüfen Sie Ihre Tabellen um zu sehen ob Indizes entfernt wurden oder Überprüfen Sie Abfragen und Erwartungen um zu sehen welche Indizes verwendet werden.
> Der % von Indizes, die den MyISAM Schlüsselpuffer verwenden ist gering.
> Sie müssen möglicherweise Key_buffer_size erhöhen.
> Hohe Anzahl an Tabellen-Öffnungen.
> Öffnen von Tabellen erfordert Festplatten I/O, welches langsam ist. Erhöhung von Table_open_cache könnte dies vermeiden.
> Zu viele Clienten werden abgebrochen.
> Clienten werden in der Regel abgebrochen, wenn sie ihre Verbindung zu MySQL nicht richtig schließen. Dies kann aufgrund von Netzwerkproblemen oder Quellcode der Datenbank-Handler nicht ordnungsgemäß schließen passieren. Überprüfen Sie Ihre Netzwerk und Quellcode.
> Zu viele Clienten werden abgebrochen.
> Clienten werden in der Regel abgebrochen, wenn sie ihre Verbindung zu MySQL nicht richtig schließen. Dies kann aufgrund von Netzwerkproblemen oder Quellcode der Datenbank-Handler nicht ordnungsgemäß schließen passieren. Überprüfen Sie Ihre Netzwerk und Quellcode.
> Der Abfragen-Zwischenspeicher ist nicht aktiviert.
> Der Abfrage-Zwischenspeicher verbessert die Leistung, wenn er korrekt konfiguriert wurde. Aktivieren Sie ihn indem Sie query_cache_size auf ein zweistelligen MiB-Wert und query_cache_type auf 'ON' setzen. Beachten Sie: Ignorieren Sie diese Empfehlung, wenn Sie memcached benutzen.
>
>
> Gruß René
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20210402/22bebb5b/attachment-0001.html>
Mehr Informationen über die Mailingliste volkszaehler-users