Performance und Archivierung -Datenmenge nicht mehr berechenbar?-

Hallo in die Runde,

wir haben aktuell folgendes Problem:
eine unserer Sites (Intranet, SHP) erzeugt im Monat ca. 1.646.000 Besuche mit ca. 5.555.000 Seitenaufrufen. Wir haben ca. 85 Segmente zu berechnen.
Matomo ist so konfiguriert das es keine Ergebnisse zusammen fasst, sprich die “*maximum_rows” wurden überall sehr hoch angesetzt (>50000) .

Insgesamt sind auf der Matomo installation ca 100 Sites konfiguriert mit einem Gesamtaufkommen im Monat von ca 6,7 Millionen Besuchern und ca 24 Millionen Seitenaufrufen, ca 30 Millionen Aktionen.

Ja nach Besucher Aufkommen dauern die Berechnungen pro Site von wenigen Sekunden bis zu 1,5 Tagen.

Sorgenkind ist aktuell das ganz oben genannte.

Wie kann man die Archivierung deutlich beschleunigen? Wir haben bereits den Prozess mehrfach paralell gestartet, aktuell versuchen wir den Rückstand ohne die Segmente zu berechnen aber auch das dauert sehr lange. Die Datenbank läuft lokal. Beim Tracking nutzen wir bereits das “Queued Tracking” mittels Redis.

Wir sind dankbar für jede Idee die Hilft
Wir nutzen aktuell Version 4.5, Update im Moment nicht möglich.

Gruß an alle.

PS: wenn mehr infos benötigt werden bitte melden.

Hallo HerbstO,
das ist schon eine ganze Menge an Daten und erfordert somit auch spezielle Maßnahmen. Sprich das geht etwas über den Standard hinaus und geht dann auch Richtung Hardware-Optimierung.
Schlussendlich gibt es bei großen Installationen zwei Nadelöhre.

Zum Einen die Archivierung. In der Archivierung werden viele API-Calls durchgeführt, die teilweise auch lange Antworten und vorallem lange Antwortzeiten mit sich bringen. Sprich die Hebel sind hier Memory-Limit und Timeouts. Wenn z.B. JSONs mit 1000 Zeilen oder so zurückkommen :wink:

Ich kenne jetzt eure Hardware nicht, aber ich denke ihr seid den Empfehlungen auf https://matomo.org/faq/on-premise/matomo-requirements/ gefolgt. Gerade RAM solltet ihr aber wohl eher mind. 64GB haben. Da sehe ich die Angaben etwas unterdimensioniert.

Dann geht es an den Aufruf des Cronjobs.
Ich tendiere da immer diesen häufiger kleine Pakete abarbeiten zu lassen anstatt große Berge. Daher schaue ich, dass ich ihn z.B. alle 20 Minuten oder so aufrufe. Habt ihr mittels --concurrent-archivers= die Anzahl der Paralleljobs angepasst? → https://developer.matomo.org/guides/archiving-behavior-specification

Zudem sollte der Cronjob auch da Log wegschreiben, damit man das auswerten kann. Am Schluß im Protokoll sollte immer sowas wie

INFO [2024-02-17 23:05:43] 3260218 SUMMARY
INFO [2024-02-17 23:05:43] 3260218 Processed 24 archives.
INFO [2024-02-17 23:05:43] 3260218 Total API requests: 24
INFO [2024-02-17 23:05:43] 3260218 done: 24 req, 41842 ms, no error
INFO [2024-02-17 23:05:43] 3260218 Time elapsed: 41.842s

stehen. Sonst ist er ausgelaufen oder nicht rechtzeitig fertig geworden. Beim Cronjob Aufruf kannst du auch mittels -d das Memory-Limit mitgeben. Ebenso kannst du mit
–force-idsites=14 z.B. nur eine ID starten. --skip-segments-today kann man vielleicht auch einsetzen um die Last runter zu bringen.

Der Cronjob könnte also wie folgt aussehen:

10,30,50 * * * * www-data /usr/bin/php -d memory_limit=16G /var/www/matomo/console core:archive --url=http://www.domain.de --force-idsites=14 --concurrent-archivers=6 >> /var/log/matomo/matomo-archive.log

Der zweite Hebel ist die Datenbank. Da gibt es leider auch ganz viele Hebel. Wichtig ist meines Erachtens, dass du den ganzen Index der DB im Cache halten kannst.
Das wäre dann die Einstellung des innodb_buffer_pool_size.

Du siehst es gibt viele Hebel und verschiedene Aspekte die man zuerst wissen und individuell analysieren muss. Ein Kunde von mir hat immer Peaks bei den Zugriffen - dann aber richtig ordentlich. Da ist die Konfig dann wieder etwas anders. Im Normalfall bei gleichbleibenden Zugriffen kann man das aber in Griff kriegen. Ich hoffe, ich konnte dir hier ein paar Impulse geben. Um dich da aber besser beraten zu können, müsste man sich das bei euch genauer anschauen und leider auch Zeit rein stecken. Das könnte ich dann nicht mehr kostenfrei übernehmen. Du kannst dich aber gerne über PN bei mir melden, wenn du da Consulting brauchen würdest.

Viele Grüße
Tom

Hallo Tom,

danke für deine Vorschläge, das haben wir bereits alles schon umgesetzt. Der Server hat 32 Prozessoren und 256 GB RAM, die innodb_buffer_pool_size wurde bereits entsprechend angepasst und steht bei 200GB. Es laufen bereits mehrere Jobs parallel.

Mal sehen was wir weiter optimieren können.

Trotzdem Danke noch mal.

Gruß Ortwin

PS: mit Consulting ist es bei Behörden immer so eine Sache. :smile: