Updating grommunio 2022.12.1 to 2023.11.1

nettania · 2023-11-21T16:28:07+00:00

Hi, today I tried to perform an update of the 2022.12.1 appliance to 2023.11.1 using zypper dup. After updating I had a problem with MariaDB, the timeout was...

crpb

WalterH

Thx for the info about postfix, i missed that it calls /usr/sbin/grommunio-postfix. So basically your Article about extending it to the latest state to make use of all changes?
That was still on my list for a couple hosts 🙈.
I will probably try my first upgrade this weekend. Was only testing the OVA till yet and already have a few tickets open 😊

WalterH

crpb So basically your Article about extending it to the latest state to make use of all changes?

The script works similar.

Vogi

nettania Current situation after latest update (16:00):

Outlook on windows is working without issues!
Webmail is unfortunately currently nearly not useable, still 503 and 504 error and a lot of messages about lossing connection to the server, loading of an E-Mail takes a long time.
Outlook for Mac: E-Mails arriving and sending is possible, but serveral sync conflicts, when loading E-Mail with external sources. Calendar entries are shown and can be edited. Contacts are displayed but only as empty entry.
MacOS: Contacts are shown also as empty.
iOS: Fortunately I have no issues.

For me the situation after update is much worse:

Outlook working, but very slow sync
iPhone: Working but even slower. Often stops syncing with "account error". From time to time the password must be re-entered
Webmail: First login shows the web-UI. But as soon as i select an item, it hangs and responds with a 504 error

My system is a VM on a Synology 920+ It worked without any issues until the update.
No error entries can be seen in the logs, only timeouts in the sync.log.

I know that this is not a good error report - but I have no idea what to do to locate the problem
Went back to a snapshot before this update and everything is good again.

Andy

I currently have two VM installations on a Synology DS1621xs+ for testing with the new appliance Build11.2 with the ISO. In parallel I performed with my productive installation v2022.12.1 “Update” via the admin GUI.

The installation was completely changed from v2022.12.1 with lp154 to v2023.11.1 with lp155 and run without problems. Maybe you can describe how did you carry out the update?

nettania

Today, I tried a second approach to migrate a 2022.12.1 to 2023.11.1, performing the following steps:

Changed the timeout for starting mariadb to infinity
Login on CUI and select "Aktualisiere das System"
Executing the update process without any issues.
Restarting the appliance
Executing update using the GUI.

The result ist, that the update works, but the webmail is still not useable, endless loading, and permanent 503 and 504 errors in the browser console. Several synchronization conflicts with Microsoft Outlook for windows. Deleting the browser cache did not help.

I had to rollback the update loading the old snapshot.

I also created a virtual machine with the current ova and there everything worked. But I do not hope that I have to migrate the productive instance by exporting all accounts and importing it to the new appliance.

Florian

Vogi

nettania The result ist, that the update works, but the webmail is still not useable, endless loading, and permanent 503 and 504 errors in the browser console. Several synchronization conflicts with Microsoft Outlook for windows. Deleting the browser cache did not help.

This describes exactly ma problems.

@Andy: I don't think, that this is an "installation issue". I tried to update several times (via zypper, WebUI and combinbations) but the result was always the same. The system became unusable with the latest versions but without any helpful log entries... returning to the last working snapshot was the only way for me to make it work again...

WalterH

nettania Changed the timeout for starting mariadb to infinity
Login on CUI and select "Aktualisiere das System"

Why you change the timeout? The database is small, the update needs only seconds.
Try the update on command line with zypper ref -f; zypper up; grommunio-update update --noreboot

Andy

Doe you try the above showed "UPGRADE" button for this? Which browser you are using and doe you try to use different browsers? How many postboxes you have? Maybe is possible, to use Outlook to transfer and test one postbox.

nettania

Hello,
in my case the schema update took a long time (about 5 minutes), don't know why.

Today I tried a new update approach using the following way:

Updated the system using the CUI menu.
Restarted the system
Afterwards switched to the grommunio backend
First performed the update using the update button
After update was finished I restarted the system
Went again into the gommunio backend and performed a upgrade.
After upgrade restarted the system again.

I am now on 2023.11.1 and everything seams to work currently. The webmail is useable, but still slower than the old one, especially when loading an HTML E-Mail with external resources, and when switching between my two accounts (personal one and the office account). I will see how it goes today, currently I do not want to go back.

As information: My E-Mail account has as size of 1.1 GB is not really big.

Florian

WalterH

nettania the schema update took a long time (about 5 minutes)

Do you talk about Maria DB or SQLite DB schema update?

nettania

WalterH
MariaDB schema update.

mwilliams

nettania

I smell either

you are using files as well and the database is a bit larger (grofiles compared to grommunio), rendering innodb_buffer_pool_size too small to fit into ram

you are using ancient/slow/overloaded storage drives

you have millions of users on community

Comparison: schema upgrade with 42k users in 6.4 secs from schema ver 20 (ancient) to current (on relatively modest) HW with SSDs in SAN.

Vogi

Hallo zusammen,

ich hänge leider weiterhin beim Update. Bei mir läuft grommunio in einer VM auf einer Synolgy DS920+ - zugegeben nicht die performanteste Plattform - aber bisher eben problemlos möglich.

Sobald ich aber auf die aktuelle Version update, wird das System extrem träge. Die Synchronisation am Handy dauert mehrere Minuten, bei Outlook genauso... und das Webinterface lädt aber bei der ersten Bedienung kommt irgendwann ein 504 Error.

Auf der Admin-Oberfläche erkennt man, dass das System deutlich mehr auf die virtuelle Platte zugreift:

Beim Wechsel zurück auf den Snapshot vor der Update sieht es meist so aus:

Lt. iotop (Aufruf mit -aoP, Ausgabe nach ein paar Minuten) ist hierfür for allem [brtfs-transacti] ursächlich:

Zum Vergleich vorm Update (Zeitdauer nicht identisch):

Hat noch irgendwer Ideen, was hier jetzt anders ist? Ich würde ungern die Hardware austauschen, da sie bisher den Zweck als Mailserver problemlos erfüllt hat.

THE_FRICKLER

Vogi

Wie viel RAM und wie viele CPU Kerne habt ihr der VM gegeben?
Ich komme auch aus dem Syno-Lager und hatte hier auch öfter Probleme mit der Schwupptizität. Bei VOGI läuft zusätzlich zu GRO noch ein Jitsi-Meet. Das würde ich mal deaktivieren mittels systemctl.
Unter Btrfs spielt die Fragmentierung eine Rolle, da können die Hinweise von @"crpb" helfen. Manchmal hilft da auch einfaches Abwarten. Meine GRO VM unter Proxmox läuft mit 4 vCPU und 6 vGB RAM problemlos. Meine Kopano-VM auf einer DS220+ läuft mit 2 Kernen und 3,25 GB RAM ebenso ganz geschmeidig. Hier liegt die VM aber auf einer SSD und die MySQL Verbindung ist über externe Instanz (Bare-Metal) angebunden

crpb

Ich würde mal mit nem btrfs scrub -B start / anfangen. Und evtl. noch btrfs balance start /.
Das hier lässt vermuten das es sich um fragmentierung handelt aber ist auch nur so eine vermutung anhand der beschreibung "Symptoms include btrfs-transacti...."...
Es gibt auch noch btrfs filesystem defrag -r /PFAD aber am besten folgendes lesen.
https://btrfs.readthedocs.io/en/latest/Defragmentation.html
https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html#man-filesystem-cmd-defragment

Vogi

Hallo zusammen,

danke für Eure Rückmeldungen - immerhin scheint nicht nur mein System betroffen zu sein...

crpb Ich würde mal mit nem btrfs scrub -B start / anfangen. Und evtl. noch btrfs balance start /.

Hab ich durchgeführt und ist auch durchgelaufen, eine Verbesserung konnte ich nicht feststellen.

WalterH Mal ein top und dann 1 im top tippen, was zeigt das an?

Vor dem Update:

Uud dann direkt im Anschluss:

THE_FRICKLER Wie viel RAM und wie viele CPU Kerne habt ihr der VM gegeben?

Bei mir sind vier Kerne und 8GB RAM zugewiesen.

Andy Es ist schon irritierend, wenn von jetzt auf nachher solche Steigerungen erfolgen durch ein Update.

Eben... nachdem ich bisher keine Probleme hatte und jetzt damit auch nicht alleine bin, scheint es ja ein generelles Problem zu sein... zumindest wenn eine Synology als Host zum Einsatz kommt.

Andy ollten wir vielleicht in Richtung Host auch die Konfiguration nennen

Ich nutze ebenfalls ein HDD Raid - mir ist bewusst, dass das nicht optimal ist. Aber "gesund" dürfte es für SSDs auch nicht sein, wenn das Update jetzt diesen mehr abverlangt.

WalterH

Mal ein top und dann 1 im top tippen, was zeigt das an?

freiser

Hallo in die Runde,
auch ich betreibe grommunio in einer VM auf einer Synology (DS220+). Bisher lief das System mit einer sehr zufriedenstellenden Geschwindigkeit. Nach dem Update auf die aktuelle Version habe auch ich das Problem, dass das Gesamtsystem deutlich langsamer geworden ist. Beispielsweise geht die io-Auslastung in der Admin-Oberfläche für mehrere Minuten in den Bereich von 50% wenn man in der Weboberfläche / grommunio-Client ein Verzeichnis wechselt. Die Reaktionszeiten in der Weboberfläche / grommunio-Client sind dabei auch entsprechend lang bzw. träge.

Andy

Es ist schon irritierend, wenn von jetzt auf nachher solche Steigerungen erfolgen durch ein Update. Da hier bereits zum BRTFS diskutiert wird, sollten wir vielleicht in Richtung Host auch die Konfiguration nennen. Meinerseits kann ich auf dem weg zum aktuellen Stand nichts nachteiliges feststellen.

Konfiguration: DS1621xs+, VM mit 4 GB RAM, 4 CPUs auf NVMe FireCuda 530 NVMe-SSD im RAID1

freiser

Also, wie bereits geschrieben, die vorherige Version lief bei mir ohne Geschwindigkeitsprobleme. Ich verwende eine DS220+ mit 18 GB und einem RAID1 auf HDDs. Die gommunio VM verwendet aktuell 2 CPUs und 10 GB RAM.

Der Leerlaufzustand der grommunio VM stellt sich wie folgt im Dashboard dar:

Wenn, z.B. im Client, ein Verzeichnis gewechselt wird dann geht die Last für ca. 2-3 Minuten hoch:

Anschliessend sieht es wieder wie folgt aus:

Das gesamte Handling im Client ist entsprechend langsam / verzögert. Dies ist bei der vorherigen grommunio Version nicht so gewesen.

Andy

freiser auf HDDs

Unabhängig vom Problem ist jede Aktivität von Grommunio deutlich zeitintensiver, wenn die VM auf HDDs statt auf SSDs läuft. Die Betriebsempfehlung für den VMM und für VMs liegt auf SSD.

Davon abgesehen wäre jedoch interessant, was an Grommunio verändert wurde, dass die Speicheraktivitäten zugenommen haben, welche sich in diesem Fall nun wesentlich deutlicher bemerkbar machen. Ggf. läst sich das anpassen oder der vorherige Zustand lässt sich reaktivieren.

Andy

Andy Unabhängig vom Problem ist jede Aktivität von Grommunio deutlich zeitintensiver, wenn die VM auf HDDs statt auf SSDs läuft. Die Betriebsempfehlung für den VMM und für VMs liegt auf SSD

Ich lese dazu nicht zum ersten mal, dass seit dem Update auf v2023.11.1 die Abläufe zäher sind. Noch immer ist nichts bekannt, was da im System implementiert wurde, was so etwas hervorruft. Wenn nun zB. eine Defragmentierung im Hintergrund läuft, wäre das ggf. ein möglicher Grund, den man beim Betrieb mit HDDs bemerken würde, mit SSDs und insbesondere NVMe würde das gar nicht gross ins Gewicht fallen.

Vielleicht kannst Du mal für Tests eine zweite VM installieren und schauen, wie sich diese verhält, vielleicht ist es ja auch etwas anderes. Ich unterstelle mal, der Host zeigt die HDDs als iO. an.

nettania 4CPUs, 6GB RAM

Ich betreibe das mit 4+4, allerdings auf NVMe und das läuft flüssig, mit HDDs würde ich auch mal 8 oder 10 GB RAM testen.

« Previous Page Next Page »