Hallo, ich koennte ein paar Tipps gebrauchen, an welchen Stellen im System man die Performance verbessern kann, wenn man sehr viele Dateien in einem Verzeichnis hat ( 100000 - 200000). Es laeuft eine Anwendung die halt eine solche Anzahl von Dateien produziert. Die Anwendung bietet keine Moeglichkeit die Dateien auf mehrere Verzeichnisse zu verteilen. Es egeben sich dann aber (Zeit-)Probleme bei "ls" und beim Zugriff ueber Samba (auch bei Dateizugriff mit vollstaendigem Dateinahmen). Mehr Hauptspeicher? Kernelparameter? Dateisystem? Wer hat Hinweise oder links? Vielen Dank Thomas
On 18 Sep 2001, at 8:50, Thomas Franz wrote:
Hallo,
ich koennte ein paar Tipps gebrauchen, an welchen Stellen im System man die Performance verbessern kann, wenn man sehr viele Dateien in einem Verzeichnis hat ( 100000 - 200000).
Es laeuft eine Anwendung die halt eine solche Anzahl von Dateien produziert. Die Anwendung bietet keine Moeglichkeit die Dateien auf mehrere Verzeichnisse zu verteilen. Es egeben sich dann aber (Zeit-)Probleme bei "ls" und beim Zugriff ueber Samba (auch bei Dateizugriff mit vollstaendigem Dateinahmen).
Mehr Hauptspeicher? Kernelparameter? Dateisystem? Wer hat Hinweise oder links?
Tja, da hast Du IMO in einen Problembereich hineingestoßen. Hier bei uns sind in diversen Verzeichnissen tausende von Files abgelegt. Dabei ist mir aufgefallen, daß der direkte Zugriff auf eine Datei z.B. mittels "ls -l Dateiname" schnell ist. Schwieriger sind Zugriffe mit Wildcards "ls -l A*". Ist ja auch irgendwie klar. Wir versuchen hier immer, die Zahl der Dateien pro Verzeichnis überschaubar zu halten, indem wir nicht mehr benutzte Dateien älter als X-(Tage/Stunden) in Unterverzeichnisse moven. Alle Batchprogramme hier haben keine Probleme, da sie sowohl ihre Workdateien als auch Logfiles etc. immer direkt mit Namen ansprechen. Performance Maßnahmen sind IMO nicht nötig, wenn man den Dateinamen genau kennt. Schwieriger sind z.B. so Aufräumaktionen, die eine evtl. große Zahl an Dateien erfassen. Aber da ist mir auch keine Lösung bekannt. Braucht Dein Programm wirklich diese Riesenzahl im Zugriff? Oder sind davon nicht nur einige wirklich in Gebrauch und der Rest nicht mehr? In dem Fall würde ich eine Archivierungsstrategie entwickeln. Ansonsten kann ich Dir da auch nicht helfen. Andreas
Andreas Kyek wrote:
On 18 Sep 2001, at 8:50, Thomas Franz wrote:
ich koennte ein paar Tipps gebrauchen, an welchen Stellen im System man die Performance verbessern kann, wenn man sehr viele Dateien in einem Verzeichnis hat ( 100000 - 200000). [...] Tja, da hast Du IMO in einen Problembereich hineingestoßen.
Ja, leider. Und ich wüßte auch nicht, wie man das Problem lösen sollte, wenn sich die Anzahl der Dateien pro Verzeichnis nicht verringern läßt.
Hier bei uns sind in diversen Verzeichnissen tausende von Files abgelegt. Dabei ist mir aufgefallen, daß der direkte Zugriff auf eine Datei z.B. mittels "ls -l Dateiname" schnell ist.
Richtig. Das Einlesen des eigentlichen Verzeichnisses ist noch ein relativ kleines Problem. Und damit kann man auch noch halbwegs schnell zu einem bekannten Dateinamen die entsprechende I-Node-Nummer finden und damit direkt auf diese eine Datei zugreifen. Auch ein einfaches ls ohne Optionen (ggf. darauf achten, ob ls ein Alias ist, das bereits Optionen impliziert) sollte noch einigermaßen zügig gehen. Auch dabei wird das Verzeichnis eingelesen (was in etwa dem Lesen einer entsprechend großen Datei entspricht), dann werden die Namen noch sortiert und das war's.
Schwieriger sind Zugriffe mit Wildcards "ls -l A*". Ist ja auch irgendwie klar.
Ja, denn dabei wird für jede einzelne Datei ein stat()-Aufruf gemacht, um die über den Dateinamen und die I-Node-Nummer (nur das steht im eigentlichen Verzeichnis) hinausgehenden Eigenschaften der Datei (die im I-Node stehen) herauszubekommen. Auch eine farbige Hervorhebung verschiedener Dateitypen macht diese Abfrage nötig. Und das ist ein Aufwand, der deutlich über das einfache, sequentielle Lesen des Verzeichnisses hinausgeht. Man könnte überlegen, ob mehr Speicher etwas bringt. Wenn dieses Verzeichnis häufig aufgelistet wird, dann bleibt vielleicht ein Großteil der benötigten Daten im Cache und man spart sich beim wiederholten Aufruf zumindest ein paar Plattenzugriffe. Aber ich denke, so richtig schnell wird's damit auch nicht. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org http://www.informatik.uni-bremen.de/~eilert/
* Eilert Brinkmann schrieb am 19.Sep.2001:
Andreas Kyek wrote:
On 18 Sep 2001, at 8:50, Thomas Franz wrote:
ich koennte ein paar Tipps gebrauchen, an welchen Stellen im System man die Performance verbessern kann, wenn man sehr viele Dateien in einem Verzeichnis hat ( 100000 - 200000). [...] Tja, da hast Du IMO in einen Problembereich hineingestoßen.
Ja, leider. Und ich wüßte auch nicht, wie man das Problem lösen sollte, wenn sich die Anzahl der Dateien pro Verzeichnis nicht verringern läßt.
Hier bei uns sind in diversen Verzeichnissen tausende von Files abgelegt. Dabei ist mir aufgefallen, daß der direkte Zugriff auf eine Datei z.B. mittels "ls -l Dateiname" schnell ist.
Richtig. Das Einlesen des eigentlichen Verzeichnisses ist noch ein relativ kleines Problem. Und damit kann man auch noch halbwegs schnell zu einem bekannten Dateinamen die entsprechende I-Node-Nummer finden und damit direkt auf diese eine Datei zugreifen. Auch ein einfaches ls ohne Optionen (ggf. darauf achten, ob ls ein Alias ist, das bereits Optionen impliziert) sollte noch einigermaßen zügig gehen. Auch dabei wird das Verzeichnis eingelesen (was in etwa dem Lesen einer entsprechend großen Datei entspricht), dann werden die Namen noch sortiert und das war's.
Mit ls -U wird nicht sortiert, dann dürfte es deutlich schneller sein. Versuch doch mal /bin/ls -U und auch /bin/ls -Ul. Würde mich auch mal interessieren, wie schnell das ist. /bin/ls deshalb, weil bei SuSE ls ein alias ist. Ohne Farben dürfte es aber deutlich schneller sein. Bernd -- Homepages von deutschsprachigen Linux-Gurus: Kristian Köhntopp: http://www.koehntopp.de/kris/artikel/ Sven Guckes: http://www.math.fu-berlin.de/~guckes/sven Robin S Socha: http://socha.net/index2.html |Zufallssignatur 10
Bernd Brodesser wrote:
Mit ls -U wird nicht sortiert, dann dürfte es deutlich schneller sein. Versuch doch mal /bin/ls -U und auch /bin/ls -Ul. Würde mich auch mal interessieren, wie schnell das ist.
Ich habe mal in einem Verzeichnis mit etwas weniger als 100000 (leeren) Dateien einen Test gemacht. Das Verzeichnis selbst hatte eine Größe von knapp 2 MB. Ergebnis: /bin/ls ca. 3 Sekunden /bin/ls -U ca. 0,5 Sekunden /bin/ls -Ul 19 Minuten, 45 Sekunden (Jeweils keine Bildschirmausgabe, sondern Ausgabeumleitung nach wc -l.) In anderen Worten: Falls man das Abfragen der Dateieigenschaften nicht vermeiden kann, kommt's auf das Sortieren nicht mehr an. Übrigens wird bei dieser Verzeichnisgröße auch das Anlegen oder Löschen von Dateien schon merklich langsamer.
Ohne Farben dürfte es aber deutlich schneller sein.
Ja. Die Verwendung von Farben und -l dürften auf die Geschwindigkeit ungefähr den gleichen Effekt haben, da ja beide auf dem Abfragen der Informationen in den I-Nodes der einzelnen Dateien abhängen. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org http://www.informatik.uni-bremen.de/~eilert/
Eilert Brinkmann wrote:
Bernd Brodesser wrote:
Mit ls -U wird nicht sortiert, dann dürfte es deutlich schneller sein. Versuch doch mal /bin/ls -U und auch /bin/ls -Ul. Würde mich auch mal interessieren, wie schnell das ist.
Ich habe mal in einem Verzeichnis mit etwas weniger als 100000 (leeren) Dateien einen Test gemacht. Das Verzeichnis selbst hatte eine Größe von knapp 2 MB. Ergebnis:
/bin/ls ca. 3 Sekunden /bin/ls -U ca. 0,5 Sekunden /bin/ls -Ul 19 Minuten, 45 Sekunden
(Jeweils keine Bildschirmausgabe, sondern Ausgabeumleitung nach wc -l.)
In anderen Worten: Falls man das Abfragen der Dateieigenschaften nicht vermeiden kann, kommt's auf das Sortieren nicht mehr an. Übrigens wird bei dieser Verzeichnisgröße auch das Anlegen oder Löschen von Dateien schon merklich langsamer.
Ohne Farben dürfte es aber deutlich schneller sein.
Ja. Die Verwendung von Farben und -l dürften auf die Geschwindigkeit ungefähr den gleichen Effekt haben, da ja beide auf dem Abfragen der Informationen in den I-Nodes der einzelnen Dateien abhängen.
Vielleicht darf ich mein urspruengliches Problem noch mal etwas genauer schildern. Ich habe naemlich nicht primaer ein Problem mit "ls", nur das Verhalten ist proportional. Ich produziere mittels "gs" aus einer(!) sehr grossen Postscript-Datei eben jene grosse Anzahl von tiff-Dateien, die spaeter einzeln gedruckt werden muessen. An diesen Vorgaben kann ich nichts aendern. Der "gs" bietet ueber den Schalter "-sOutputFile=<prefix>%06d.." die Option die vielen Output-Dateien zu benennen. Aber sie landen unweigerlich in einem Verzeichnis. Dieses Verzeichnis wird ueber SAMBA exportiert, weil der ganze Druck- Klapperatismus auf einer Win-Kiste laeuft(auch dagegen ist nichts zu machen). Die Drucksoftware auf Win hat die Liste der vollstaendigen Dateinamen im Bauch und liest eine Datei nach der anderen ueber Samba und knallt sie auf einem Hochleistungseinzelblattdrucker raus. Nun zeigt sich, dass bei dieser grossen Anzahl von Dateien, das Lesen ueber SAMBA so lange dauert, dass der Drucker zwischen zwei Druckauftraegen (sprich A4-Seiten) in einen Wartemodus geht, weil der naechste Job nicht schnell genug kommt. Dadurch schaukelt sich die Zeit der Abarbeitung drastisch hoch. Es hat sich gezeigt, dass das Verhalten von der Anzahl der Dateien im Verzeichnis abhaengt, analog wie beim "ls". Im Bereich 1000-2000 gibt es kein Problem. Aus dem analogen Verhalten bin ich erstmal nicht davon ausgegangen, dass es sich um ein reines SAMBA-Problem handelt. Bevor ich nun die Folterinstrumente raushole und in den Ghostscript eine Logik reinprogrammiere die Unterverzeichnisse nach einem bestimmten Schema anlegt, wollte ich erstmal die Systemseite abklopfen und habe hier mal angefragt, ob es vielleicht Kerneleinstellungen u. ae. gibt, an denen man mal drehen sollte. Noch mal richtig Hauptspeicher nachfassen wollen wir als erstes. Eines hatte ich bislang auch noch nicht erwaehnt. Ich habe kein ext2-System, sondern benutze reiserfs, da das extra verspricht, gerade viele Dateien besonders effizient handeln zu koennen. Thomas
On Thursday, 20. September 2001 16:52, Thomas Franz wrote:
anlegt, wollte ich erstmal die Systemseite abklopfen und habe hier mal angefragt, ob es vielleicht Kerneleinstellungen u. ae. gibt, an denen man mal drehen sollte.
Hast du dieses Filesystem mal mit der mount Option "noatime" gemounted? Peter
Thomas Franz wrote:
Bevor ich nun die Folterinstrumente raushole und in den Ghostscript eine Logik reinprogrammiere die Unterverzeichnisse nach einem bestimmten Schema anlegt, wollte ich erstmal die Systemseite abklopfen und habe hier mal angefragt, ob es vielleicht Kerneleinstellungen u. ae. gibt, an denen man mal drehen sollte.
Laß es, schau dir angehängtes Shellskript an, es macht das was du suchst. Am Anfang Hinweise lesen. cu Gerald
Thomas Franz schrieb am Thu, 20 Sep 2001 16:52:11 +0200: Systemeinstellungen - viele Dateien
Eilert Brinkmann wrote:
Bernd Brodesser wrote:
Mit ls -U wird nicht sortiert, dann dürfte es deutlich schneller sein. Versuch doch mal /bin/ls -U und auch /bin/ls -Ul. Würde mich auch mal interessieren, wie schnell das ist.
Ich habe mal in einem Verzeichnis mit etwas weniger als 100000 (leeren) Dateien einen Test gemacht. Das Verzeichnis selbst hatte eine Größe von knapp 2 MB. Ergebnis:
.. Vielleicht darf ich mein urspruengliches Problem noch mal etwas genauer schildern. Ich habe naemlich nicht primaer ein Problem mit "ls", nur das Verhalten ist proportional. Ich produziere mittels "gs" aus einer(!) sehr grossen Postscript-Datei eben jene grosse Anzahl von tiff-Dateien, die spaeter einzeln gedruckt werden muessen. An diesen Vorgaben kann ich nichts aendern. Der "gs" bietet ueber den Schalter "-sOutputFile=<prefix>%06d.." die Option die vielen Output-Dateien zu benennen. Aber sie landen unweigerlich in einem Verzeichnis. Dieses Verzeichnis wird ueber SAMBA exportiert, weil der ganze Druck- Klapperatismus auf einer Win-Kiste laeuft(auch dagegen ist nichts zu machen). Die Drucksoftware auf Win hat die Liste der vollstaendigen Dateinamen im Bauch und liest eine Datei nach der anderen ueber Samba und knallt sie auf einem Hochleistungseinzelblattdrucker raus. Nun zeigt sich, dass bei dieser grossen Anzahl von Dateien, das Lesen ueber SAMBA so lange dauert, dass der Drucker zwischen zwei Druckauftraegen (sprich A4-Seiten) in einen Wartemodus geht, weil der naechste Job nicht schnell genug kommt. Dadurch schaukelt sich die Zeit der Abarbeitung drastisch hoch. Es hat sich gezeigt, dass das Verhalten von der Anzahl der Dateien im Verzeichnis abhaengt, analog wie beim "ls". Im Bereich 1000-2000 gibt es kein Problem. Aus dem analogen Verhalten bin ich erstmal nicht davon ausgegangen, dass es sich um ein reines SAMBA-Problem handelt. Bevor ich nun die Folterinstrumente raushole und in den Ghostscript eine Logik reinprogrammiere die Unterverzeichnisse nach einem bestimmten Schema anlegt, wollte ich erstmal die Systemseite abklopfen und habe hier mal angefragt, ob es vielleicht Kerneleinstellungen u. ae. gibt, an denen man mal drehen sollte. Noch mal richtig Hauptspeicher nachfassen wollen wir als erstes. Eines hatte ich bislang auch noch nicht erwaehnt. Ich habe kein ext2-System, sondern benutze reiserfs, da das extra verspricht, gerade viele Dateien besonders effizient handeln zu koennen.
Thomas
Ich weiß nichts über reiser, aber sag mal, wie groß sind eigentlich die Einzeldateien und sind sie alle gleich bzw. ähnlich groß ? Hast Du das schon geschrieben - hab den thread leider nicht so verfolgt... Dann könnte es evt. was nützen, die Device-Blockgröße der Partition darauf anzupassen, zumindest in meinen Uralt-Sinix-Unterlagen wurde da behauptet, daß das in einem solchen Fall auch Performance geben soll -- may the tux be with You! Joerg Thuemmler sysadmin@vordruckleitverlag.de Vordruck Leitverlag GmbH Berlin, ZNL Freiberg Halsbruecker Str. 31b, 09599 Freiberg, Germany Tel. +49 (0)3731/303121
* Joerg Thuemmler schrieb am 21.Sep.2001:
Ich weiß nichts über reiser, aber sag mal, wie groß sind eigentlich die Einzeldateien und sind sie alle gleich bzw. ähnlich groß ? Hast Du das schon geschrieben - hab den thread leider nicht so verfolgt... Dann könnte es evt. was nützen, die Device-Blockgröße der Partition darauf anzupassen, zumindest in meinen Uralt-Sinix-Unterlagen wurde da behauptet, daß das in einem solchen Fall auch Performance geben soll
Dadurch wird natürlich Plattenplatz gespart. Und wenn man doppelt und dreifach indirekte Adressierung vermeidet, ist das auch nicht verkehrt. Aber bei so vielen Dateien werden diese Dateien ohnehin nicht allzu groß sein. Bernd -- Umsteiger von Microsoft Windows xx? Hast Du schon file://usr/doc/howto/de/DE-DOS-nach-Linux-HOWTO.txt gelesen? Auch file://usr/doc/Books/Linuxhandbuch.dvi ist zu empfehlen. |Zufallssignatur 1
Joerg Thuemmler wrote:
Thomas Franz schrieb am Thu, 20 Sep 2001 16:52:11 +0200: Systemeinstellungen - viele Dateien
[Verzeichnis mit mehr als 100.000 Dateien]
Dieses Verzeichnis wird ueber SAMBA exportiert, weil der ganze Druck- Klapperatismus auf einer Win-Kiste laeuft(auch dagegen ist nichts zu machen). Die Drucksoftware auf Win hat die Liste der vollstaendigen Dateinamen im Bauch und liest eine Datei nach der anderen ueber Samba und knallt sie auf einem Hochleistungseinzelblattdrucker raus. Nun zeigt sich, dass bei dieser grossen Anzahl von Dateien, das Lesen ueber SAMBA so lange dauert, dass der Drucker zwischen zwei Druckauftraegen (sprich A4-Seiten) in einen Wartemodus geht, weil der naechste Job nicht schnell genug kommt.
Wie viel Verzögerung ist dafür nötig? Ich nehme mal an, daß es um mehr als nur ein paar Sekunden geht, oder?
Es hat sich gezeigt, dass das Verhalten von der Anzahl der Dateien im Verzeichnis abhaengt, analog wie beim "ls". Im Bereich 1000-2000 gibt es kein Problem.
Das spricht dafür, daß nicht das Lesen der einzelnen Dateien das Problem ist (wobei das Finden einer Datei im Verzeichnis auch merklich länger dauern kann), sondern daß zwischendurch jeweils das komplette Verzeichnis noch einmal eingelesen wird, womöglich mit sämtlichen Dateieigenschaften (entsprechend ls -l). Kommt das von der Verzögerung her hin? [...]
Dann könnte es evt. was nützen, die Device-Blockgröße der Partition darauf anzupassen, zumindest in meinen Uralt-Sinix-Unterlagen wurde da behauptet, daß das in einem solchen Fall auch Performance geben soll
Das wird in diesem Fall wohl nicht ausschlaggebend sein. Wenn die Datei erstmal geöffnet ist, geht das eigentliche Lesen der Datei ja schnell genug -- mit weniger Dateien klappt ja alles. Das Problem ist der mit der Verzeichnisgröße steigende Zeitbedarf zum Finden einer Datei und zum Einlesen des Verzeichnisses. Obwohl sich eine Veränderung der Blockgröße auch darauf auswirken würde, aber ich glaube nicht, daß der Effekt hier so sehr ins Gewicht fallen würde. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org http://www.informatik.uni-bremen.de/~eilert/
participants (7)
-
Andreas Kyek -
B.Brodesser＠t-online.de -
Eilert Brinkmann -
Gerald Goebel -
Joerg Thuemmler -
Peter Wiersig -
Thomas Franz