Die Datenbak benutzt 7,2 GB RAM und dass ist genau so wie sie konfiguriert wurde. Die Config die er gepostet hat hat z.b. 6000MB buffer pool . Und dass ist ja auch nicht schlecht, da ansonsten jeder Datenbank aufruf zu einer Leseoperation auf der Festplatte fĂŒhrt.
Und da der Server 128GB ram hat kann man der Datenbank ohne probleme ein paar GB davon abgeben.
Neben meinen bereits erwÀhnten vorschlÀgen (z.b. slowquerylog ) hÀtte ich noch eine frage.
Der Systemcron lÀuft. Alle 5 Minuten.
Bezuglich des buffer pool gibt es ja wiedersprĂŒchliche Aussagen.
Einige behaupten sogar, dass wenn er zu hoch ist, das dass eher verlangsam?
In der slowquerylog finde ich keine Hinweise auf irgendwelche Fehler, Ausschnitt:
Full_scan: Yes Full_join: No Tmp_table: No Tmp_table_on_disk: No
Filesort: No Filesort_on_disk: No Merge_passes: 0 Priority_queue: No
SET timestamp=1648103524;
SELECT id, subject, message_id, in_reply_to, references, thread_root_id FROM oc_mail_messages WHERE (mailbox_id IN (SELECT id FROM oc_mail_mailboxes WHERE account_id = 45)) AND (message_id IS NOT NULL);
Datenbank und Fileordner sichern.
Alles Plattmachen (inklusive Betriebssystem) und neu installieren.
Ich gehe davon aus dass es nicht allzuviele User gibt und sie noch dazu in einem
privaten Umfelt sind. Damit denke ich dass dieses Vorgehen möglich ist, wenn deine User bittest alles zu sichern und neu hochzuladen.
Nicht vergessen allen sagen dass sie Calendar, Kontakte, Passwords. Phonetrack etc. selbststĂ€ndig sicher mĂŒssem.
Wenn das aufgesetzt ist und wieder wie gewĂŒnscht funktioniert kannst du dich an die Analyse machen was bei der alten nicht funktioniert hat.
Du kannst nicht sagen wie lange es dauert bis ein Debugging funktioniert und damit finde ich es besser ein funktionierendes System zu haben mit dem zufrieden bist und ohne Druck zu lernen was beim Alten schief gegangen ist.
Naja. Wenn man die Datenbank nicht wiederherstellt, dann gehen alle Shares verloren. Ich denke das will keiner der Anwender. Wenn die Datenbank jedoch wieder hergestellt wird, dann brauchen die Anwender aber auch nicht Kalender, Kontakte usw. sichern.
Leider wahr.
Aus eigener Erfahrung kann ich sagen wenn man als Anwender 30 Sekunden wartet dann ist es besser wenn es neu gemacht wird und man dann zwar etwas Arbeit hat aber es geht. Das Frustationslevel steigt bei jedem neuem Warten. Den Zustand gibt es jetzt schon ĂŒber eine Woche und da nicht absehbar ist wie lange das noch dauert denke ich es ist besser ein neues System aufzusetzten und eventuell das Alte zum Debuggen und eventuell als Altsystem noch zu haben.
beide System gleichzeitig laufen zu haben wÀre das Optimum.
Um sicher Shares zu behalten, kann man die App ShareRenamer verwenden. Bei Neuinstallation kann man die alten Namen wiederverwenden. Wobei man sich dann natĂŒrlich auf die Weiterentwicklung bzw. Support der App in neueren Releases verlassen muss.
FĂŒr Einzeldateien kann man sich noch die App Sharing Path anschauen.
Hat aber alles mit der Fragestellung nicht mehr viel zu tun.
Wenn Ihr die App Deck im Einsatz habt deaktiviert sie. Das bringt merkliche Entlastung. Das hat mir jetzt erst mal geholfen. Ich habe es am verhalten von redis entdeckt. redis wurde mit solchen Meldungen ĂŒberschwemmt:
1650606179.371726 [0 unix:/var/run/redis/redis.sock] âGETâ âcbd68a0ce27f6b13a3577cae0f74fb11/deck-cardMapperfindBoardId:1209â
1650606179.371802 [0 unix:/var/run/redis/redis.sock] âGETâ âcbd68a0ce27f6b13a3577cae0f74fb11/deck-cardMapperfindBoardId:1209â
1650606179.371899 [0 unix:/var/run/redis/redis.sock] âGETâ âcbd68a0ce27f6b13a3577cae0f74fb11/deck-cardMapperfindBoardId:1210â
1650606179.371976 [0 unix:/var/run/redis/redis.sock] âGETâ âcbd68a0ce27f6b13a3577cae0f74fb11/deck-cardMapperfindBoardId:1210â
1650606179.372074 [0 unix:/var/run/redis/redis.sock] âGETâ âcbd68a0ce27f6b13a3577cae0f74fb11/deck-cardMapperfindBoardId:1211â
1650606179.372150 [0 unix:/var/run/redis/redis.sock] âGETâ âcbd68a0ce27f6b13a3577cae0f74fb11/deck-cardMapperfindBoardId:1211â
1650606179.372247 [0 unix:/var/run/redis/redis.sock] âGETâ âcbd68a0ce27f6b13a3577cae0f74fb11/deck-cardMapperfindBoardId:1211â
1650606179.372323 [0 unix:/var/run/redis/redis.sock] âGETâ âcbd68a0ce27f6b13a3577cae0f74fb11/deck-cardMapperfindBoardId:1211â
1650606179.372427 [0 unix:/var/run/redis/redis.sock] âGETâ
hi, my German is not fluent enough to reply in German but I understand you have issues with your performance since upgrading to 23 and that disabling deck helped. There might be other apps that affect your performance as well like circles. I recommend you if you still have load issues to disable that one and see if it helps, and if it doesnât, disable your other apps one by one to check if any affects performance drastically.