ich tracke meinen Shop seit etwa 2 Wochen mit Matomo. Im Bereich “DE” (eigene Website in Matomo) habe ich ca. 160 visits / 800 actions in 24h. Die Datenbank hat aktuell etwas über 50 MB (1 Website für alle Daten und 1 je Sprache).
Matomo läuft derzeit am kleinsten Hetzner “cloud” Server mit 1vcpu/2gb ram:
Wenn ich den Zeitraum auf etwas unter 2 Wochen beschränke klappt es.
Andere Auswertungen (“normale” Pages Übersicht etc.) funktionieren gut, vielleicht mal ein paar Sekunden Wartezeit, aber keine solchen Abbrüche.
Die CPU Auslastung liegt beim tracken immer unter 5%, nur wenn ich Auswertungen aufrufe geht die Last kurz auf 50-100%.
Ist es notwendig auf zB 4 oder 8 GB RAM auszurüsten um in Zukunft sinnvoll auswerten zu können, oder hakt es bei anderen Einstellungen?
Es würde mich ja nicht stören mal 10-20 Sekunden auf das Laden von so einer Liste zu warten - aber die Fehlermeldung nach wenigen Sekunden ist lästig.
Kommst du irgendwie an die genaue Fehlermeldung ran (aus dem PHP error_log)? Ansonsten wird es schwierig die Frage zu beantworten.
Grundsätzlich sollten 1 Kern und 2 GB RAM locker ausreichen für die genannten Zahlen, deshalb gehe ich eher von einem PHP-Konfig Problem aus. Wir selbst betreiben auf einer VM mit 4 Kernen und 4 GB RAM: 2 Matomo Instanzen, FTP-Server, ~30 Drupal Installationen mit dazugehörigen Datenbanken und sind immer noch weit von einer Auslastung entfernt.
Ich bin damit noch nicht ganz vertraut, auf die Schnelle finde ich aber das:
(Ubuntu Server 18.04)
/var/log/apache2/error.log
[Wed Sep 26 15:06:59.305631 2018] [php7:error] [pid 25877] [client 84.113.46.63:54014] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/stats/core/DataTable.php on line 1374, referer: https://stats.eventlights.shop/stats/index.php?module=CoreHome&action=index&idSite=1&period=day&date=today
[Wed Sep 26 15:06:59.626898 2018] [core:notice] [pid 2651] AH00051: child pid 25877 exit signal Segmentation fault (11), possible coredump in /etc/apache2
Es scheint also ein 128 MB Speicherlimit zu geben. Ich weiß nicht ob das so sein sollte, kommt mir bei 2 GB RAM etwas wenig vor (und dann gäbe es ja auch noch SWAP auf der SSD…)
–
Ich habe alles ganz laienhaft nach Anleitung installiert, also nichts besonderes konfiguriert, die Einstellungen beim Apache sollten so sein wie sie am Ubuntu Server standardmäßig sind.
Welche Konfiguration wäre zu ändern? Apache, PHP, Matomo?
Zu ändern wäre die php.ini Datei. Die liegt bei Ubuntu 18 und für apache unter /etc/php/7.2/apache2/.
Allerdings muss ich sagen, dass das Problem wohl eher ein anderes ist.
Folgendes würde ich dir raten:
In deinem Matomo stellst du unter System -> Allgemeine Einstellung -> Berichte archivieren, wenn diese im Browser angezeigt werden “Nein” ein.
Dann legst du in /etc/crontab folgenden Eintrag an: */15 * * * * root /usr/bin/php7.2 /var/www/html/stats/console core:archive --url=https://stats.eventlights.shop/stats/ > /var/log/piwik-archive.log
Dann wartest du auf den nächsten 15 Minutenpunkt ab und probierst nochmal dir die Daten anzeigen zu lassen.
Mit genau dem Hetzner vServer habe ich auch angefangen (nachdem ich nur einen Raspberry Pi verwendet habe), also sollte es bei korrekter Konfiguration auf jeden Fall ausreichen.
Ich würde mal den Tipp von @fdellwing befolgen (beachte nur, dass dann alle Reports bis zu 15min zeitverzögert sind) und das memory limit in der php.ini etwas höher setzen.
Falls auf dem Server nur Matomo laufen soll, könnte es vielleicht auch etwas bringen, die MySQL config etwas anzupassen, sodass die 2GB RAM gut ausgenützt werden.
@fdellwing@Lukas
danke. Ich habe “Archive reports when viewed from the browser” auf No gestellt, und den Cron eingerichtet.
Der Cron dürfte funktionieren, das script läuft lt. log in etwa 5 sek durch, also wirklich kaum etwas zu tun.
Das Problem besteht aber nach wie vor: Sobald ich die Entry Pages mit den Daten von 2-3 Wochen ansehen möchte bekomme ich (auch mit der neuen Einstellung) den selben Fehler.
Wenn es nicht am Live-archivieren liegt: Was macht das System sonst noch was mehr als 128MB Speicher bei PHP braucht?
Ich habe nun auch das Limit auf 256MB erhöht und Apache neu gestartet - das Problem tritt immer noch auf.
Und es ist wohl nicht sinnvoll das Limit noch weiter zu erhöhen:
Ideen was ich noch probieren könnte oder in welchen logs ich mehr Infos finden könnte?
Nur zur Info, der Cronjob kann nur die Reports für tage,wochen, monate, Jahre, etc. vorgenerieren. Wenn du einen beliebigen Zeitraum auswählst, muss für diesen Zeitraum der Report live generiert werden.
der Fehler kommt immer nach vielleicht 20 Sekunden Ladezeit oder so.
Kann es an einem Zeitlimit für Prozesse liegen? Das sollte natürlich nicht so kurz sein…
Wie sehe ich was das System eigentlich tut, und wo es hakt? Gibts dafür Logs, oder muss ich verbose logs einschalten oder so um das zu sehen?
An der Mysql Performance wird es eher nicht liegen, der Server ist ja kaum ausgelastet, normalerweise irgendwo bei 5%, und wenn ich einen Report ansehe gehts für ein paar Sekunden rauf. Aber es gibt ja quasi nur 1 Benutzer (mich).
kurz danach habe ich die Entry pages für die letzte Woche wieder aufgerufen, dieses mal hat es geklappt, ohne Fehler.
ABER: Auch mit deutlicher CPU Last - der zweite Ausschlag im Graph.
Der Aufruf der Seite verursacht also fast soviel CPU last wie der Cron job.
Das kommt mir komisch vor - wenn der Cronjob die Stats Vor-berechnet dann sollten sie ja quasi ohne Last geladen werden können. Es wird aber offenbar trotzdem noch viel berechnet.
