staging.inyokaproject.org

top - 18:54:17 up 40 min,  2 users,  load average: 1.07, 2.64, 2.16
Tasks: 473 gesamt,   2 laufend, 471 schlafend,   0 gestoppt,   0 Zombie
%CPU(s):  5.1 us,  1.7 sy,  0.0 ni, 92.1 id,  0.4 wa,  0.0 hi,  0.6 si,  0.0 st
MiB Spch :  32003.6 gesamt,  22858.9 frei,   3523.6 belegt,   5621.0 Puff/Cache
MiB Swap:  38942.0 gesamt,  38942.0 frei,      0.0 belegt.  28006.7 verfü Spch

top - 19:00:13 up 46 min,  2 users,  load average: 1.08, 1.58, 1.82
Tasks: 475 gesamt,   2 laufend, 473 schlafend,   0 gestoppt,   0 Zombie
%CPU(s):  4.7 us,  1.8 sy,  0.0 ni, 93.1 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Spch :  32003.6 gesamt,  20850.2 frei,   3515.2 belegt,   7638.1 Puff/Cache
MiB Swap:  38942.0 gesamt,  38942.0 frei,      0.0 belegt.  28015.1 verfü Spch

Ich frage micb, ob es eine Chance gibt das System merklich schneller zu machen?

Es geht um vorwiegend Umbenennung von Dateien nach Analyse der Metadaten.

Also die CPU langeweilt sich. Man müsste wohl bei der HDD bzw. den Lese- und Schreibvorgängen ansetzen. 10TB SSD ist nicht finanzierbar.

Bestenfalls kann ich mir partielles Umkopieren auf eine SSD vorstellen.

Eine SSD bringt richtig Geschwindigkeit, System auf die SSD, Daten auf die HDD und via /etc/fstab ins System einbinden. Als Mountpoint nimmst du dann entweder /media oder /home/$USER, ist im Grunde egal.

Ich habe mich daran erinnert, früher gab es mal Ramdisks.

Wie legt man sowas unter Ubuntu an? Am liebsten temporär als User, der das Script ausführt.

SSD für alle Daten ist nicht bezahlbar.

Ich kann mir folgendes vorstellen, von dem 32GB Speicher verwende ich 10GB für eine Ramdisk, dürfte meistens reichen. Sehr oft sogar 5GB. Kann man ja leicht prüfen, Ordner kleiner als 10GB kopieren in Ramdisk, sonst nicht.

Das Script kopiert die Daten in die Ramdisk, arbeitet sie ab und kopiert sie zurück. Muss man sich nur mehr überlegen, wie man sich vor einem Stromausfall vor Datenverlust sichert. Irgendwie in der Richtung unter anderem Namen zurückkopieren, vorhandenes Verzeichnis umbenennen, bearbeitetes verzeichnis in ursprünglichen Namen umbenennen, ursprüngliches Verzeichnis löschen.

Ich denke jetzt bin ich mit dem Thema hier falsch.

RAM-Disk erstellen

Danke, braucht wohl alles sudo.

glaskugel schrieb:

Danke, braucht wohl alles sudo.

Nein! Doch! Oh!

glaskugel schrieb:

SSD für alle Daten ist nicht bezahlbar.

Hat ja auch keiner verlangt. Die Idee lautete:

Frieder108 schrieb:

System auf die SSD, Daten auf die HDD und via /etc/fstab ins System einbinden.

„System auf die SSD“ ist mit 64 GB gut bedient, wenn du nicht Hunderte von Snaps hast. 64 GB SSD gibt’s für 15 € bei kleinanzeigen.de.

--ks

„System auf die SSD“ ist mit 64 GB gut bedient

Das System läuft auf SSD und einiges andere auf anderen SSD auch. Multimediadateien sind auf HDDs.

Es braucht viel Zeit, wenn Fotos analysiert werden. 300 Fotos ein paar Stunden, aber das ist alles extrem komplex, zB wenn (selten) pro Sekunde mehrere Fotos gemacht werden, aber auch dafür muss es eine Lösung geben. Dann werden auch Farbräume analysiert, etc. Ich hatte ursprünglich mal angenommen, ich mache in der Regel nicht mehrere Fotos in 1 Minute. Die Zeiten ändern sich, das galt für analog.

Festplattenmodell: ST12000NM0007-2A
Festplattenmodell: ST6000VN0021-1ZA
Festplattenmodell: ST6000VN0021-1ZA
Festplattenmodell: WDC WD20EARS-00S
Festplattenmodell: XA960ME10063   

Ich frage mich gerade warum fdisk die NVME nicht anzeigt. Die WDC könnte ich rauswerfen um Platz bei den Ports zu bekommen.

Genau genommen müsste ich also 12+6+6=24TB durch SSD ersetzen, eigentlich mehr, ist schon ziemlich voll mit eigenen Videos.

Aber die Idee ist vielleicht das Script umzuschreiben und die NVME zu verwenden und dorthin umzukopieren, dann brauche ich kein root. Bei der NVME, ursprünglich für das System gedacht, bin ich mir nicht sicher, ob die vielleicht einen Bug hat, aber dafür könnte man sie riskieren. Das Ergebnis wird ja kontrolliert.

glaskugel schrieb:

%CPU(s):  5.1 us,  1.7 sy,  0.0 ni, 92.1 id,  0.4 wa,  0.0 hi,  0.6 si,  0.0 st

Es geht um vorwiegend Umbenennung von Dateien nach Analyse der Metadaten.

Also die CPU langeweilt sich. Man müsste wohl bei der HDD bzw. den Lese- und Schreibvorgängen ansetzen.

Wenn die Festplatte der Flaschenhals wäre, würde der Wert für wait (wa) höher sein. Das kann man gut beobachten, wenn man Daten von einem langsamen auf ein schnelles Medium kopiert oder umgekehrt.

Du solltest bei der Effizienz deines Skriptes ansetzen, möglicherweise auf mehrere CPU-Threats arbeiten lassen. Leider sieht man in deiner top-Ausgabe die CPU Auslastung deines Skriptes nicht, wahrscheinlich ist nur ein Kern ausgelastet. Die Plattenauslastung kannst du mit iotop beobachten. Im Forum "Shell und Programmieren" wirst du sicher Hilfe finden.

Gruß TNT

möglicherweise auf mehrere CPU-Threats arbeiten lassen.

Du hast mich wieder an das Problem erinnert.

Ich schränke jetzt mal auf den Fotobereich ein.

Da wird intensivst verwendet

• exiftool

• Imagemagick

• Online-Abfragen

Die Online-Abfragen habe ich optimiert, zumindest gibt es die gleiche Abfrage nicht hintereinander. Mir ist schon klar, dass das am meisten bremst.

Es wird zB die Farbe / Farbstich eines Fotos berechnet, indem auf 1 Pixel verkleinert wird.

Der Vorteil des Scripts ist, es funktioniert, andererseits ist es an die 10 Jahre gewachsen und chaotisch, weil immer wieder was dazu gebastelt. Ziemlich aufwendig ist es, kaputte Exifdaten von alten Fotos zu einem brauchbaren Wert zu konfigurieren. Plausible Exif-Daten sind aber Voraussetzung für die weitere Abarbeitung des Scripts.

Ich glaube Imagemagick, speziell convert und identify, kann mittlerweile Multithread, aber exiftool nicht.

Sieht irgendwie danach aus, dass bessere Hardware nicht viel bringt. Das Script kann sicher optimiert werden, aber von der Logik muss eine Datei nach der nächsten abgearbeitet werden, weil sich Variablen aus der vorhergehenden Datei ergeben, alles ziemlich komplex und ich bin bisher davor zurüückgeschreckt, an was funktionierendem was zu ändern-