I installed #Immich yesterday evening on my #ZimaBlade 2 using #Proxmox. The setup was incredibly easy, and I was able to directly upload some photos. However, this caused the CPU to run at 100% and triggered temperature warnings. đ«Ł
I need to investigate if thereâs anything I can optimize to reduce the CPU load. I donât want to think about what will happen when I upload all my 20k photos.
ZimaBlade 7700 DIY NAS Kit
To me, a single board computer is defined not only by parts living on one circuit board, but with the added modifier that neither
https://interfacinglinux.com/2025/12/01/zimablade-7700-diy-nas-kit/
Noch einmal #Nextcloud
Die #WebDAV implementierung auf Linux ist offenbar sehr mangelhaft.
Eine per WebDAV ĂŒber #GOA #GnomeOnlineAccounts gemountete Nextcloud hat massive Performance-Probleme. Videos lassen sich kaum bis nicht abspielen. GroĂe Dateien öffnen... dauert. Drag&Drop von #Thunar oder #Nautilus in den #Firefox... brachte sogar meinen Firefox zum Absturz. Auf #Chromium ist es nicht besser.
Auch manuell per davfs eine Nextcloud-Freigabe mounten macht es nicht besser.
Ich schob bisher der Nextcloud die "Schuld" in die Schuhe. PHP und auf einem #Zimablade... ist halt nicht so performant...
Aber per sshfs/sftp gemountet ist es doch rasend schnell... fast wie von lokal.
Und dann entdeckte ich auf der Suche nach Lösungen, dass die Linux-Implementierung von WebDAV einfach grottig ist und ich nicht allein mit dem Problem mit Nextcloud bin.
Ich will die Verzeichnisse nÀmlich nicht syncen - wie mit der Nextcloud-App - sondern ich will sie remote mounten.
Also stieĂ ich bei der Recherche auf diesen tollen Artikel
muetsch.io/fixing-slow-nextcloâŠ
Hier nutzt er die FĂ€higkeit von #rclone eine WebDAV Freigabe zu mounten.
Das einzige was mir an der Lösung nicht gefÀllt ist die system-systemd Lösung.
Also hab ich es auf eine Unit fĂŒr den user-systemd umgebaut.
Einrichten von rclone wie im Artikel, nur folgendes File erstellen:
sudo editor /etc/systemd/user/rclone-nextcloud.service
Und mit folgendem Inhalt befĂŒllen
Benny
VoidZeroOne 
Interfacing Linux
jakob đŠđč â
[Unit]
Description=RClone mount for Nextcloud
Documentation=man:rclone(1)
After=network-online.target
Wants=network-online.target
AssertPathIsDirectory=/home/%u/SHARED/nextcloud
[Service]
Type=simple
ExecStart=/usr/bin/rclone mount nextcloud: %h/SHARED/nextcloud \
--config=%h/.config/rclone/rclone.conf \
--vfs-cache-mode full \
--vfs-cache-max-age 1h \
--vfs-cache-max-size 1G \
--buffer-size 16M \
--dir-cache-time 72h \
--umask 002 \
--uid %U \
--gid %G \
--daemon-timeout 30s
ExecStop=/bin/fusermount -u %h/SHARED/nextcloud
TimeoutStartSec=60
TimeoutStopSec=20
KillMode=process
Restart=on-failure
RestartSec=30
StartLimitInterval=300
StartLimitBurst=3
[Install]
WantedBy=default.targetSpeichern und als USER (!!!!) folgendes ausfĂŒhren:systemctl --user daemon-reload && systemctl --user enable --now rclone-nextcloud.service
Und dann in seinem Homeverzeichnis/SHARED/ nachsehen. Da sollte sich dann ein Ordner befinden, wo man den Inhalt seiner Nextcloud wiederfindet.
Ich hab gerade 30 Videos mit in Summe ~50GB Daten auch hinkopiert (mit Drag & Drop in Nautilus) und die Daten waren ratzfatz drĂŒben auf der Nextcloud!!
Ja sogar totem spielt die Videos tadellos ab. Ăber GOA gemountet muss ich da erstmal 1-2 Minuten warten und dann zeigt er mir nur einzelne Frames statt eines Videos...
Ich hab hier #NextcloudAIO auf einem #Zimablade laufen.
Und ich hab eine spezielle Anforderung... selbstgewĂ€hlt natĂŒrlich.
Ich hab mir mal ein Script geschrieben, dass alle möglichen Dateinamen von Kameras frisst und ggfs. aus dem Dateinamen ein Erstellungsdatum auslesen kann, so keines in den #EXIF Daten des Bildes festgelegt ist.
Am Ende der Behandlung mit dem Script steht dann ein Erstellungsdatum in den Exif-Daten und der Dateiname folgt der Konvention YYYYMMDD-HHMMSS.<dateierweiterung>
Die Idee dahinter war, dass die Bilder auch bei einem Shell-Dateilisting in der richtigen zeitlichen Reihenfolge aufgelistet werden, und dass auch Bilder/Videos in denen keine Metadaten zur Erstellung gespeichert sind, diese bekommen und in div. Zeitleisten in Nextcloud auch richtig geordnet aufscheinen.
Sonst ist mir das nÀmlich zuviel Chaos.
Gut. Das Script hab ich schon lange im Einsatz und funktionierte auf meiner alten Nextcloud (bare-metal) und auf einem NAS gut und machte, was es soll.
Mit incron habe ich den Upload-Ordner (Bei der Nextcloud meistens SofortUpload benannt) ĂŒberwacht und das Script sprang dann bei jedem neuen File dort an und verschob es umbenannt in ein Verzeichnis + Subdir nach YYYY/YYYY_MM
Ab und zu einmal hÀngte sich incrond auf... war nicht schön, aber handlebar.
Zweite Herausforderung bei der #Nextcloud:
Wenn ich im Filesystem direkt herumpfusche, kriegt die Nextcloud das nicht mit. Die Files bleiben so lange unsichtbar, bis ich mit occ files:scan wieder alles neu einlese.
Das dauert aber laaaaaaaange. Denn ich habe viiiiiiiele Files.
Alternativ kann ich mit dem config-Parameter 'filesystem_check_changes' => 1, auch ein Verzeichnis beim öffnen von der Nextcloud indizieren lassen... nicht schön, denn das haut die ohnedies nicht ĂŒberragende Performance der Nextcloud ziemlich zusammen. Und zwar immer. Egal ob nun files neu eingelesen werden mĂŒssen, oder nicht.
Au0erdem hat incrond ein Problem. Dazu gibts schon lĂ€nger einen Bugreport von mir, der aber schon ĂŒber ein Jahr nicht behandelt wurde... wenn ich ein Verzeichnis lösche, haut es incrond auf und es stĂŒrzt ab. AuĂerdem ist die Performance beim rekursiven Ăberwachen schlecht... es stĂŒrzt manchmal aus unerfindlichen GrĂŒnden ab.
Also bin ich auf inotifywait gekommen. Das scheint viel stabiler als incron zu sein (baut aber auf der selben Kernel-Schnittstelle auf).
Jetzt hab ich mein Script so angepasst, dass ein Script den Upload-Ordner ĂŒberwacht, und fĂŒr jedes hochgeladene File einen batch-Job erstellt, damit das Bild dann mit meinem Script behandelt wird, wenn die Last am Serverchen niedrig ist... so bleibt die Nextcloud immer erreichbar, auch wenn ich viele Bilder gleichzeitig hochlade.
Ein zweites Script ĂŒberwacht dann das "files" Verzeichnis aller User auf Ănderungen und schreibt den Dateinamen samt Pfad eines hinzugekommenen Files oder das Parent-Verzeichnis eines entfernten Files/Verzeichnisses in verschiedene Stapel-Files. Da diese Filenamen auch mehrfach vorkommen können, brauchts dann noch einen Cronjob:
Diese list diese Stapelfiles aus, macht ein sort|uniq drauf und schreibt das Ergebnis in ein Tempfile und trunkated gleichzeitig das Stapelfile, welches damit wieder vom Script neu befĂŒllt werden kann.
Dann fĂŒhrt es mit docker exec im Nextcloud-Container der Nextcloud AIO ein occ files:scan bzw. occ groupfolders:scan mit einer --path= Angabe aus um wirklich nur die verĂ€nderten Verzeichnisse und Files einzulesen. Das geht VIEL schneller, als regelmĂ€Ăig den gesamten Inhalt zu scannen. Und es haut mir die Performance am Frontend nicht zusammen, wenn ich mehrere Verzeichnisse nacheinander aufrufe.
Klingt kompliziert?
Ist es auch.
Aber momentan scheint es zu funktionieren.
Algu té o ha provat el mini-ordinador "Zimablade", el model amb 4 nuclis...
Estic plantejant-me un d'aquests per a trastejar i fer cosetes a l'aula.
#ZimaBoard #zimablade #linux #professor #miniordinadors #preguntes
joseinquiet
Venn Stone
TerrorPUP