Massiver Performance-Einbruch nach Update auf 21

Hallo zusammen,

nach einem Update von 19 über 20 auf 21 ist der Server mit der Installation Nextcloud und nur mir als Benutzer völlig überlastet. Die Überlastung stellt sich insofern dar, dass ein Wechsel in den Menüs im Frontend viele Sekunden bis mehrere Minuten dauern. Auch eine Speicheraufrüstung von 2GB (Version 19) auf 4GB (Version (21) hat keinen Erfolg gebracht.

Alle bis dahin gemeldeten Fehler (in dem Überblick) wurden bereits behoben.

Nun die Angaben zum System:

vServer auf Hetzner
Linux 5.4.0-72-generic x86_64 (Ubuntu 20.04)
Intel Xeon Processor (Skylake, IBRS) (2 cores) - 3.75 GB
PHP Version: 7.4.3

  • Arbeitspeicher-Grenzwert: 512 MB
  • Maximale Ausführungszeit: 3600
  • Maximale Größe zum Hochladen: 2 MB
    MySQL (MariaDB) Version: 10.3.25
    Apache/2.4.41 (Ubuntu)
    Nextcloud läuft in VM

Die durchschnittliche Last liegt bei 0,75 bis teilweise 1,3

Das Einzige was in der logs auffällt, dass dies mit mehreren Einträgen pro Sekunde munter vollgeschrieben wird und alle Meldungen immer wieder “/appinfo/app.
php is deprecated, use \OCP\AppFramework\Bootstrap\IBootstrap on the application class instead.”
zum Inhalt haben.

Mehr ist nicht zu sehen. Ist das normal, dass die log Datei mit so vielen Warnhinweisen voll geschrieben wird? Denn deprecated heisst ja eigentlich nur veraltet und deutet nicht auf einen Fehler hin.

Das System macht einen inkonsistenten Eindruck, so als ob hier während des Updates bestimmte erforderliche Routinen warum auch immer nicht gelaufen sind. Indexe, Primäre Schlüssel sowie umzuwandelnde Integerfelder, alles was moniert wurde, habe ich bereits ohne Fehler durchgeführt.

Gibt es eine Funktion, die grundsätzlich die Konsistenz der gesamten Installation prüft und mögliche Fehler aufzeigt?

Hi, das klingt mir nach Error upgrading to Nextcloud 21 - Segfault · Issue #25761 · nextcloud/server · GitHub

Also ich habe mit apc.enable_cli=1 in der php.ini mal wie hier dargelegt einen Versuch gestartet, leider ohne Erfolg.

Der Eintrag muss nicht in die php.ini sondern in die apcu.ini

Mit Blick in die Konsole vom Firefox hat der Aufruf der Seite nextcloud/index.php/apps/files eine Wartezeit von 57,04 Sekunden, d.h. der Browser bekommt über diese Zeitspanne auf den GET keine Antwort.

Welche Apps sind installiert?

Folgende Apps sind aktiv, jeweils “vorgestellt” markiert:
Accessibility
Activity
Brute-force settings
Calendar
Collabora Online
Collaborative tags
Comments
Contacts
Contacts Interaction
Dashboard
Deck
Deleted files
Federation
File sharing
First run wizard
Log Reader
Mail
Monitoring
Nextcloud announcements
Notifications
Password policy
PDF viewer
Photos
Privacy
Recommendations
Right click
Share by mail
Support
Text
Theming
Update notification
Usage survey
User status
Versions
Video player
Weather status

Ich finde auf meinem System keine apcu.ini. Es ist aber auch kein FPM im Einsatz. Auf dem Server läuft nur diese eine Nextcloud Instanz und nicht mehr.

Ist Apcu in deiner config.php Datei aktiv? Falls ja hilft es evtl. die Zeile zu entfernen.

Nein, Apcu ist in der config.php nicht konfiguriert.

Mit Blick auf htop fällt auf, dass alle drei CPU-Kerne durchschnittlich mit knapp 0,5 last fahren und der apache2 hier die Last verursacht.

Mit Blick in das log wird erkennbar, dass ein auf Server laufendes Programm hier die nextcloud-Instanz spammt.

127.0.0.1 - - [28/Apr/2021:18:44:22 +0200] “GET /nextcloud/index.php/login HTTP/1.1” 200 6155 “-” “Nextcloud Server Crawler”
127.0.0.1 - - [28/Apr/2021:18:45:24 +0200] “GET /nextcloud/apps/richdocumentscode/proxy.php?req=/hosting/capabilities HTTP/1.1” 301
127.0.0.1 - - [28/Apr/2021:18:45:24 +0200] “GET /nextcloud/apps/richdocumentscode/proxy.php?req=/hosting/capabilities HTTP/1.1” 302
127.0.0.1 - - [28/Apr/2021:18:44:23 +0200] “GET /nextcloud/index.php/login HTTP/1.1” 200 6155 “-” “Nextcloud Server Crawler”
127.0.0.1 - - [28/Apr/2021:18:45:25 +0200] “GET /nextcloud/apps/richdocumentscode/proxy.php?req=/hosting/capabilities HTTP/1.1” 301
127.0.0.1 - - [28/Apr/2021:18:44:23 +0200] “GET /nextcloud/index.php/login HTTP/1.1” 200 6156 “-” “Nextcloud Server Crawler”
127.0.0.1 - - [28/Apr/2021:18:45:26 +0200] “GET /nextcloud/apps/richdocumentscode/proxy.php?req=/hosting/capabilities HTTP/1.1” 301
127.0.0.1 - - [28/Apr/2021:18:45:26 +0200] “GET /nextcloud/apps/richdocumentscode/proxy.php?req=/hosting/capabilities HTTP/1.1” 302
127.0.0.1 - - [28/Apr/2021:18:44:23 +0200] “GET /nextcloud/index.php/login HTTP/1.1” 200 6162 “-” “Nextcloud Server Crawler”

Ich kann leider nicht erkennen, welches Programm das hier macht.

Da die Version 21 den Server schonungslos in die Knie zwingt, würde ich gerne Apps, die nicht zwingend benötigt werden, nach und nach deaktivieren. Wie finde ich diese?

Problem behoben, Ursache weiterhin unbekannt.

Hammermethode (Wartungsmodus an, apache aus, Installationsdateien verschieben, aus frisch heruntergeladenen Programmdateien der Version 21 entpackt, config und data hierhin kopiert, sichergestellt das Eigner und Rechte passen, apache starten, Wartungsmodus aus, Installation läuft wieder mit gewohnter und erwartungsgemäßer Geschwindigkeit. Der Nextcloud Server Crawler hat endlich das Apache Spammen beendet. Die Datenbank war ja schon konvertiert und die fehlende Index und Primärschlüssel und Umwandlung der Integerfelder abgeschlossen.

Scheinbar ist eine App aus 19, die aber nach dem Update als OK angezeigt wurde, der Auslöser gewesen. Also bei jedem Major Update am Besten entgegen der Anleitung keine App aus der vorherigen Version kopieren, sondern nativ neu installieren. Wenn nicht da, nun dann eben Pech gehabt. Schade ist nur, dass man vor einem Update nicht erkennen kann, welche zusätzlich installierte Apps migriert werden und welche eben nicht.

Nachtrag: Natürlich stehen der Datenbank noch Einträge über angeblich aktive Apps, die dann als solche in der Übersicht der Apps angezeigt werden. Hier zunächst Deinstallieren und anschließend herunterladen und installieren wählen. Also vor dem Update eine Liste machen, dann abarbeiten.

Welche App war es?

Also, aus der o.g. Liste habe ich
→ Collabora Online
nicht installiert. Hier wird immer wieder nochmals ein Passwort abgefragt.
Aber die App-Verwaltung ist scheinbar auch nicht konsistent. So wird Mail, obwohl “deinstalliert” und wieder installiert, in der Liste der aktiven App nicht angezeigt. Ist aber oben in der Menüleiste verfügbar, also aktiv. Eine Deinstallation wäre aus dem Menü nicht mehr möglich.

Mit sudo -u www-data php occ app:list sieht es hingegen anders aus:

accessibility: 1.7.0
activity: 2.14.3
bruteforcesettings: 2.1.0
calendar: 2.2.1
cloud_federation_api: 1.4.0
comments: 1.11.0
contacts: 3.5.1
contactsinteraction: 1.2.0
dashboard: 7.1.0
dav: 1.17.1
deck: 1.4.1
federatedfilesharing: 1.11.0
federation: 1.11.0
files: 1.16.0
files_pdfviewer: 2.1.0
files_rightclick: 1.0.0
files_sharing: 1.13.1
files_trashbin: 1.11.0
files_versions: 1.14.0
files_videoplayer: 1.10.0
firstrunwizard: 2.10.0
logreader: 2.6.0
lookup_server_connector: 1.9.0
mail: 1.9.5
nextcloud_announcements: 1.10.0
notifications: 2.9.0
oauth2: 1.9.0
password_policy: 1.11.0
photos: 1.3.0
privacy: 1.5.0
provisioning_api: 1.11.0
recommendations: 1.0.0
serverinfo: 1.11.0
settings: 1.3.0
sharebymail: 1.11.0
support: 1.4.0
survey_client: 1.9.0
systemtags: 1.11.0
text: 3.2.0
theming: 1.12.0
twofactor_backupcodes: 1.10.0
updatenotification: 1.11.0
user_status: 1.1.1
viewer: 1.5.0
weather_status: 1.1.0
workflowengine: 2.3.0
Disabled:
admin_audit
bbb
encryption
files_external
user_ldap

bruteforcesettings: 2.1.0 und - mail: 1.9.5 sind hier installiert und aktiv.

Ich habe Collabora Online nebst Built-in-Code-Server zum Test ebenfalls ohne Perfomance-Probleme installiert. Allerdings kann der nun nach dem Updaet die Open-Document-Datein nicht mehr öffnen. Ich habe es wieder deinstalliert, kann ich drauf verzichten.

Also abschließend bleibt unbekannt, welche App aus 19 offensichtlich fehlerhaft migriert wurde.

Es wäre hilfreich, wenn es auch für Installationstabelle der Datenbank eine Prüffunktion gibt, die anhand der existierenden Verzeichnisse feststellen kann, ob eine App installiert oder deinstalliert ist.

Ist schon witzig, wenn die Last des Servers auf allen drei CPU-Kernen mit aktiven Nextcloud nun nur noch 0.0 | 0.02 | 0.03 ist.

Es stellt sich die Frage, was diesen “Nextcloud Server Crawler”, der ja offensichtlich auf dem Server aus der Nextcloud-Instanz von was auch immer gestartet wird, dazu bewegt, den Apache so zu derart zu spammen, dass die Last so dratisch steigt.