Mp4 Video wird nicht abgespielt, langsamer login, Swap Speicher

Hi Leute,

ich kämpfe momentan etwas mit der Videowiedergabe auf meiner Nextcloud 18. Videos sind im mp4 Format auf der Nextcloud. Leider erscheint sehr oft “error loading file” oder es läd ewig ehe es abspielt. Über htop ist mir auch aufgefallen, dass Nextcloud sehr stark den Swap Speicher in Anspruch nimmt anstatt den richtigen Arbeitsspeicher, der langweilt sich zu tode anscheinend. Hier mal eine Übersicht:


Vielleicht kann mir hier jemand helfen den richtigen Parametern in Nextcloud mehr Speicher zuzuweisen. PHP-fpm habe ich 512mb zugewiesen. redis und mysql habe ich leider keine Ahnung wie viel Speicher man dort wo zuweisen sollte bei einem Raspi4 4GB Modell.
Und vielleicht kann mir ja auch jemand helfen, oder verraten wieso der Login so enorm lange dauert. Die Seiten ansich laden relativ zügig.

Gruß Phil

Hallo @iGodPhil
dein Nextcloud nimmt den Speicher nicht in Anspruch , bzw. eigentlich sollte es transparent sein und nicht lokalisierbar.
Aber… da dein Nexcloud 1,3% des Speichers benutzt, bin ich ziemlich sicher, dass es im Hauptspeicher ist. Der Speicherfresser ist irgendwo anders (DB?).
Das Tuning an sich ist etwas zwischen Kunst und Wissenschaft mit einem Schuss Vodoo - da wirst Du die allgemeinen Empfehlungen nehmen und einfach ausprobieren müssen.
Langsame logins, sind - meiner Erfahrung nach - eine Mischung aus DB und Harddisk Problem (beide zu langsam und so…)

Gibt es einen Grund, die Dateien per “php occ files:scan” zu scannen (erster Eintrag in blau)? Machst du das dauernd? Das macht doch gar keinen Sinn. Vielleicht ist es deswegen langsam. Hast du dafür irgendwelche Jobs laufen? Wie oft machst du das?

1 Like

Und 2te mit PID 22605. Es scheint parallel 2 mal gelaufen → Das verbraucht Ressourcen signifikant.
Ich habe auch deswegen ein Script geschrieben:

Du kannst es auch mit --all nutzen, wird aber prüfen ob es ein Prozess schön lauft und somit nicht parallel startet.

1 Like

Wie meinst du das mit transparent?

Ich nehme ehrlich gesagt auch an, dass es an der DB liegt aber ehrlich gesagt finde ich nicht so wirklich die my.cnf der MariaDB im NextcloudPI Image. Unter /etc/mysql befinden sich zwar files aber dort steht nirgends was mit InnoDB und dergleichen wo man die Parameter einstellen könnte. Falls es hilft könnte ich diese hier noch reinkopieren.

Auf absehbarer Zeit soll der Raspi für die Nextcloud eh durch einen MiniPC abgelöst werden, aber das muss erstmal bis zu den Semesterferien warten.

transparent heisst, dass Du - oder das Programm - nicht feststellen kann, wo es läuft. Da müsste man mit einem Debugger und Speicheradressierung dahinter, der Kernel sollte es vor den laufenden prozessen verbergen und selbst managen. Es gibt da (meines Wissens) keine Tools, die ein Programm in den Swap oder Hauptspeicher verschieben können und/oder eindeutig zu lokalisieren.

Nachdem du hoffentlich dein “files:scan --all” - Problem gelöst hast, poste bitte noch mal eine neue htop-Ausgabe. Drück dann mal auf “m” und poste die htop-Ausgabe erneut. Dann ist sie sortiert nach Speicherverschwendung. Evtl. boote und schaue wie sich der Speicher über die Zeit entwickelt. Post auch dafür die htop-Screenshots.

Ich teste kurz aus womit das zusammenhänge könnte. Kann sein, da ich über SMB auch auf die Daten zugreifen muss, die Intervalle dafür zu kurz sind und er zu lange braucht. Im NCP Panel habe ich dafür zwei Einträge wo man den Scan einstellen kann.

Edit: Also der Eintrag ist erstmal für den file-scan verantwortlich. Videos laden trotzdem extrem langsam.

Deaktiviere den File-Scan mal vollständig. Schau mit “htop”, dass da wirklich nichts mehr von läuft. Können die Leute nicht per Nextcloud die Daten hochladen? Dann kannst du dir das Scannen ganz sparen.

Scanne vielleicht nächstes Mal direkt im Terminal. Dann siehst du auch wie lange das wirklich dauert.

Nach der Deaktivierung des Scannes im Zweifel einmal booten. Und dann fang mit deiner Problemstellung ganz von vorne an. Poste dafür neue htop-Screenshots.

Achso Ok. Würde eventuell ein vorübergehendes abschalten des Swap Speichers sinnvoll sein, um zu schauen, ob es dann besser läuft?

Also ich weiß dass der file-scan ca 30-45 min dauerte vor einer weile. Ich stell ihn jetzt mal um auf einmal am Tag. Das reicht eigentlich auch.

htop spuckt mir jetzt erstmal das hier aus nach dem Neustart:

Deaktiviere mal temporär den Swap
swapoff -a

Poste auch mal

free -h

Falls das funktioniert, setze es mal auf 0, damit scheinbar oder hoffenltich erst ganz am Ende geswappt wird.

https://docs.couchbase.com/server/4.0/install/install-swap-space.html

oder

https://debianforum.de/forum/viewtopic.php?t=171456
(lese bis zur 3. Seite)

Die beiden Links werde ich heute Abend mal durchlesen. Mit deaktivierten Swap gibt es aber auch keine Änderung bei der Geschwindigkeit. Manchmal bringt ein Abspielen von Videos Gefühlt den ganzen Server zum Absturz und es dauert eine gefühlte Ewigkeit bis er dann die Seite neuladen kann.

htop:

free -h:

Immerhin nutzt du so temporär keinen Swap mehr. Aber vielleicht es ja weitere Ursachen. Am besten du versuchst mal unterschiedliche Videos.

Du kannst ja mal diese Big Buck Bunny - Videos versuchen (downloaden, zur Nextcloud hochladen und anschauen)
https://peach.blender.org/download/

Probiere evtl. eine 60-Minuten-Test-Nextcloud zum Vergleich:
https://try.nextcloud.com

Danke erstmal. Ich werde das heute Abend mal testen und mich melden. Ich hatte gestern auch einen Thread gelesen, dass es unter Nextcloud 18 teilweise Probleme mit den Videoformaten und Tonspuren gibt. Mal schauen, ob es daran liegt.

  1. Durch die richtige Einstellung und Optimierung der Datenbank-Parameter lässt sich die Performance siginifikant steigern - such mal hier im Forum danach.
  2. Ein Raspi ist eben kein Server, da solltest du nicht zu viel erwarten - ganz besonders, wenn noch (viele) andere Dinge darauf laufen.

Man könnte mal testweise die Ein-Dateien-PHP-Mini-Cloud TinyFileManager auf den Apache2 hochladen (.htaccess von Nextcloud bzgl. Rewrite umbedennen, damit der Zugriff überhaupt funktioniert) und dann dort mal ein Video aufrufen. Nutzt eigentlich die gleichen HTML5-Mechanismen. Da sieht man dann, ob der Pi auch so in die Knie geht.

Also wie wir jetzt festgestellt haben liegt es auch am verwendeten Browser. In Chrome werden die Videos sofort abgespielt bei mir lokal am Rechner, hingegen bei Safari erhalte ich nur die Fehlermeldung. Über das Internet muss er erstmal etwas buffern. Am Handy erscheint egal ob Safari Firefox oder Chrome nur eine Fehlermeldung. Weiter macht es auch einen Unterschied ob ein Freund seinen Bildschirm während der Vorlesung aufnimmt und hochläd oder ich. Beide nehmen mit max 1920x1080 in mp4 und aac Format auf. Meine Videos werden sofort abgespielt, seine hingegen müssen zum teil relativ lange laden ehe sie abspielen.
Sehr merkwürdig jedenfalls.

Das liegt vermutlich daran, daß das MOOV Atom am Dateiende anstatt am Beginn gespeichert ist.

Wow das kann es wirklich sein weil er seinen Bildschirm über ffmpeg aufnimmt und ich mit obs. Das werde ich später gleich mal Testen wenn man dieses Moov Atom analysiert und berichten. Vielen Dank schon mal.