Eine Frage der Geschwindigkeit

[uselessuser]

Hallo Forum,

ich habe derzeit eine knappe Million Dateien hier herumliegen, die mittels diverser Python- und Shellskripte modifiziert bzw. auf Merkmale hin untersucht werden sollen.
Eigentlich wollte ich das auf dem Server der Uni machen, aber der hat ein Problem mit den vielen Dateien und ist nicht in der Lage, bei einem for i in ./*; do vor 12 Stunden loszulegen. Das Problem liegt wohl irgendwo bei der Verbindung zum Fileserver, ist aber erstmal nicht loesbar.

Ich ueberlege jetzt, ob es Sinn machen koennte, das hier auf meinem MacBook Pro zu machen. Ich habe eine ziemlich volle interne Festplatte und eine externe, die ueber FireWire 400 angeschlossen ist. Welche von beiden macht mehr Sinn? Sind ueberhaupt grossartige Unterschiede zu erwarten? Auch im Hinblick darauf, dass hier nur ein 2 GHz Core Duo werkelt und in der Uni eben ziemlich neue Hardware...

 

[andi.reidies]

Also wenn Du nicht mittels Threads die Dateiverarbeitung parallel anstösst, bringt dir der Core 2 Duo oder ähnliche Multi-Proc-Systeme gar nichts !!

Dann wird wohl eher die HDD / File-IO Performance der Bottleneck sein. Bei nem File-Server hast Du wohl round-trips vom Client zum Server und zurück.

Daher könnte das lokale Bearbeiten der Dateien - in Zusammenhang mit der hohen IO Performance über FireWire - wirklich was bringen.

a.

 

[cynic]

Da hat Andi voellig Recht. Bei der Menge an Dateien, die da gelesen werden muessen dauert das ganze natuerlich.
Bei allen von dir genannten Moeglichkeiten hast du einen Flaschenhals.

Nichts desto trotz koenntest du von multiplen Threads profitieren, solange der Controller mitmacht.

 

[?=?]

Hallo Forum,

ich habe derzeit eine knappe Million Dateien hier herumliegen,
--- 8< ---
--- >8 ---
Eigentlich wollte ich das auf dem Server der Uni machen, aber der hat ein Problem mit den vielen Dateien und ist nicht in der Lage, bei einem for i in ./*; do vor 12 Stunden loszulegen.

Alle Filesysteme (mit denen ich praktische Erfahrungen habe) machen bei derartig vielen Dateien in einem Directory (oder habe ich dich falsch verstanden?) massive Probleme.
Die theoretischen Grenzen liegen zwar vielleicht viel höher, aber das Design der internen Datenstrukturen und die Zugriffsverfahren fordern ihren zeitlichen Tribut.

Um das zu verifizieren solltest du direkt auf dem Server (z.B. per ssh) in dem betreffenden Verzeichnis mal ein "ls" ausführen. Vermutlich wird schon das "Ewigkeiten" dauern.
Wenn dem so ist hilft wahrscheinlich nur, die Files auf mehrere Directories zu verteilen.
Es ist allerdings auch einen Versuch Wert, einfach nur mal die Dateiliste vorab zu erzeugen (und abzuspeichern, z.B. per "ls -1 >../ls.out"), um die einzelnen Dateien später so viel schneller ermitteln zu können.


?=?

 

[uselessuser]

Ja, die Dateien liegen in genau einem Verzeichnis.
Ist denn zu erwarten, dass eine Aufteilung viel bringt? Die absolute Menge der Dateien bleibt ja gleich.

Ein 'ls' dauert uebrigens rund zwei Minuten, ja. Hauptsaechlich greifen ja Python-Skripte auf die Dateien zu, und jedesmal werden diese danach umbenannt. Bei so einem kaskadenartigen Verfahren hilft es natuerlich auch nicht, alles vorab in eine Datei zu schreiben, sondern ich muss jedesmal mit einer selbstgebastelten Methode und os.path.* die exakte Liste einholen...

Auf dem MacBook Pro geht's uebrigens auch nicht viel flotter. Besonders fein finde ich, dass der Finder aufhoert zu reagieren, wenn ich in das Verzeichnis gehe.

 

[?=?]

Ja, die Dateien liegen in genau einem Verzeichnis.
Ist denn zu erwarten, dass eine Aufteilung viel bringt? Die absolute Menge der Dateien bleibt ja gleich.

Nach meiner Erfahrung steigt die Zugriffszeit auf Directory-Einträge(!) deutlich überproportional mit der Anzahl der Files/Links/etc. in einem Directory. Also gilt es, die Anzahl der Directory-Zugriffe zu minimieren.

Ein 'ls' dauert uebrigens rund zwei Minuten, ja. Hauptsaechlich greifen ja Python-Skripte auf die Dateien zu, und jedesmal werden diese danach umbenannt.

Wenn das simple minimieren der Anzahl der Directory-Zugriffe nicht möglich ist ("umbenennen" ist nichts weiter als eine Operation auf Directory-Einträgen), dann solltest du versuchen, die Auswirkungen der (vermuteten) überproportionalen Steigerung der Zugriffszeiten zu verringern, in dem du mit mehreren Directories mit weniger Eintägen arbeitest.
BTW: 2 Minuten für ein "ls" mit 500.000 Einträgen finde ich schon recht flott.

Bei so einem kaskadenartigen Verfahren hilft es natuerlich auch nicht, alles vorab in eine Datei zu schreiben, sondern ich muss jedesmal mit einer selbstgebastelten Methode und os.path.* die exakte Liste einholen...

Alternativ könntest du dir aber auch in dem Python-Skript eine eigene Baumstruktur anlegen, die die Directory-Struktur spiegelt. Das könnte wiederholtes Einlesen von der Platte ersparen.

Auf dem MacBook Pro geht's uebrigens auch nicht viel flotter. Besonders fein finde ich, dass der Finder aufhoert zu reagieren, wenn ich in das Verzeichnis gehe.

Der wird wohl ohne besonderes caching für alle 500.000 Files versuchen, sich die Information über die assoziierten Icons zu besorgen . . .

Ich weiß nicht, nach welchen Kriterien die Dateinamen gebildet werden. Vielleicht kannst du bei der Erzeugung relativ einfach einen Hash-Wert aus dem Dateinamen erzeugen (simpelst: Anfangsbuchstabe), den du als Sub-Directory-Namen verwendest, um darin die Datei abzulegen.

Schließlich hängt auch viel davon ab, wie oft das ganze Verfahren ablaufen soll.

Im übrigen kann ich nur sagen: Ausprobieren.


?=?

 

[uselessuser]

Nach meiner Erfahrung steigt die Zugriffszeit auf Directory-Einträge(!) deutlich überproportional mit der Anzahl der Files/Links/etc. in einem Directory. Also gilt es, die Anzahl der Directory-Zugriffe zu minimieren.

Hier scheint es mir eher so, dass das erstellen der Liste mit den Files zu lange dauert. Der Zugriff auf eine einzelne Datei geht flugs wie immer, wenn die Shell aber alle Dateien finden/auflisten/etc soll, geht das Tempo in die Knie. Daher meine zwelfelnde Frage. Aber ich habe keinen Schimmer, wie das genau implementiert ist.

Wenn das simple minimieren der Anzahl der Directory-Zugriffe nicht möglich ist ("umbenennen" ist nichts weiter als eine Operation auf Directory-Einträgen), dann solltest du versuchen, die Auswirkungen der (vermuteten) überproportionalen Steigerung der Zugriffszeiten zu verringern, in dem du mit mehreren Directories mit weniger Eintägen arbeitest.

Nein, geht leider nicht (jede Datei wird pro Schritt genau einmal bearbeitet). Ich werde mal sehen, was die Verteilung auf Unterverzeichnisse bringt. Aber ueber die Baum-Idee werde ich nachdenken, sobald es daran geht, die ganzen Teilskripte zu einem einzigen Prozess zusammenzufassen. Derzeit ist das alles noch Alpha, quasi.

In jedem Fall danke fuer die Antworten.