Frage Wie wirkt sich die Anzahl der Unterverzeichnisse auf die Lese- / Schreibleistung des Laufwerks unter Linux aus?


Ich habe ein EXT3 formatiertes Laufwerk auf einem Linux CentOS Server. Dies ist ein Web-App-Datenlaufwerk und enthält ein Verzeichnis für jedes Benutzerkonto (es gibt 25.000 Benutzer). Jeder Ordner enthält Dateien, die der Benutzer hochgeladen hat. Insgesamt hat diese Festplatte ungefähr 250 GB Daten.

Hat die Strukturierung des Laufwerks mit all diesen Verzeichnissen Auswirkungen auf die Lese- / Schreibleistung des Laufwerks? Beeinflusst es einen anderen Leistungsaspekt, den ich nicht kenne?

Gibt es irgendetwas an sich falsch oder schlecht, wenn man die Dinge so strukturiert? Vielleicht nur die falsche Wahl des Dateisystems?

Ich habe vor kurzem versucht, zwei Datenlaufwerke zusammenzuführen und habe festgestellt, dass EXT3 auf 32.000 Unterverzeichnisse beschränkt ist. Das hat mich wundern warum. Es scheint albern, dass ich es so gebaut habe, wenn man bedenkt, dass jede Datei eine eindeutige ID hat, die einer ID in der Datenbank entspricht. Leider ...


10
2018-02-16 20:21


Ursprung


Irgendein Grund, warum Sie so etwas nicht tun können homes/u/username, homes/j/joeblow,homes/s/somebody,...? - Zoredache
Diese Gruppierungsmethode, die von @Zoredache aufgelistet wird, ist, wie wir es früher immer gemacht haben (auf viel kleineren Maschinen mit einer großen Anzahl von Benutzern). - Brian Knoblauch
@Zoredache Dies sieht aus wie armer Mann B-Baum-Hashing. Dies ist jedoch langsamer, da es nicht im Kernel-Bereich läuft und ein wenig mehr Lesevorgänge benötigt und es möglicherweise nicht gut ausbalanciert ist. Der htree von ext3 und ext4 ist besser. Siehe auch: ext2.sourceforge.net/2005-ols/paper-html/node3.html - Mircea Vutcovici
Sie sollten eine Antwort markieren ... - ewwhite


Antworten:


Dies ist einfach, um die Optionen für sich selbst zu testen, in deiner Umgebung und vergleiche die Ergebnisse. Ja, es wirkt sich negativ auf die Leistung aus, wenn die Anzahl der Verzeichnisse zunimmt. Ja, andere Dateisysteme können helfen, diese Barrieren zu umgehen oder die Auswirkungen zu verringern.

Das XFS-Dateisystem ist besser für diese Art von Verzeichnisstruktur. ext4 ist wahrscheinlich gerade in Ordnung. Zugriff und Operationen auf das Verzeichnis werden einfach langsamer, wenn die Anzahl der Unterverzeichnisse und Dateien zunimmt. Das ist sehr ausgesprochen unter ext3 und nicht so sehr auf XFS.


7
2018-02-16 20:24



XFS ist definitiv das Dateisystem, das für diese Struktur verwendet wird, da es Millionen Unterverzeichnisse unterstützt und die Leistung scheint nicht beeinflusst zu sein wie EXT3, wo die Auswirkung signifikant ist ... basierend auf einem Graphen, den ich jetzt nicht finden kann. - T. Brian Jones


Die Antwort ist nicht so einfach wie die Wahl des Dateisystems. Sane Dateisysteme haben seit langem keine linearen Listen mehr für Verzeichnisse verwendet, was bedeutet, dass die Anzahl der Einträge in einem Verzeichnis keinen Einfluss auf die Dateizugriffszeit hat ....

außer wenn es das tut.

In der Tat bleibt jede Operation schnell und effizient, unabhängig von der Anzahl der Einträge, aber einige Aufgaben beinhalten eine wachsende Anzahl von Operationen. Offensichtlich, ein einfaches tun ls dauert lange, und Sie sehen nichts, bis alle Inodes gelesen und sortiert wurden. Tun ls -U (unsortiert) hilft ein wenig, weil man sehen kann, dass es nicht tot ist, aber die Zeit nicht merklich reduziert. Weniger offensichtlich ist, dass jede Wildcard-Erweiterung jeden einzelnen Dateinamen prüfen muss, und es scheint, dass in den meisten Fällen auch der gesamte Inode gelesen werden muss.

Kurz gesagt: Wenn Sie sicher sein können, dass keine Anwendung (einschließlich Shell-Zugriff) jemals einen Wildcard verwenden wird, können Sie riesige Verzeichnisse ohne Reue erhalten. Aber wenn im Code einige Platzhalter auftauchen, sollten Sie die Verzeichnisse besser unter tausend Einträge halten.

bearbeiten:

Alle modernen Dateisysteme verwenden gute Datenstrukturen für große Verzeichnisse, also eine einzige Operation, die den Inode eines Spezifisch Die Datei wird sogar auf riesigen Verzeichnissen ziemlich schnell sein.

Aber die meisten Anwendungen machen nicht nur Einzeloperationen. Die meisten von ihnen tun entweder ein vollständiges Verzeichnis oder ein Wildcard-Matching. Diese sind langsam, egal was, denn sie beinhalten das Lesen aller Einträge.

Zum Beispiel: Nehmen wir an, Sie haben ein Verzeichnis mit einer Million Dateien namens 'foo-000000.txt' bis 'foo-999999.txt' und ein einzelnes 'natalieportman.jpeg'. Diese werden schnell sein:

  • ls -l foo-123456.txt
  • open "foo-123456.txt"
  • delete "foo-123456.txt"
  • create "bar-000000.txt"
  • open "natalieportman.jpeg"
  • create "big_report.pdf"

diese werden scheitern, aber auch schnell ausfallen:

  • ls -l bar-654321.txt
  • open bar-654321.txt
  • delete bar-654321.txt

diese werden langsam sein, auch wenn sie nur sehr wenige Ergebnisse liefern; Selbst diejenigen, die fehlschlagen, schlagen nach dem Scannen aller Einträge fehl:

  • ls
  • ls foo-1234*.txt
  • delete *.jpeg
  • move natalie* /home/emptydir/
  • move *.tiff /home/seriousphotos/

6
2018-02-17 03:26





Stellen Sie zunächst sicher, dass die ext3-Partition die dir_index Flagge gesetzt.

sudo dumpe2fs /dev/sdaX |grep --color dir_index

Wenn es fehlt, können Sie es aktivieren. Sie müssen das Dateisystem unmounten und dann Folgendes ausführen:

sudo tune2fs -O dir_index /dev/sdaX
sudo e2fsck -Df /dev/sdaX

Dann mounten Sie das Dateisystem.


5
2017-10-31 21:04





Es macht keinen Unterschied, bis Sie die ext3 32.000 Namen pro Verzeichnis Grenze treffen. Das Upgrade auf ext4 kann das umgehen, genauso wie die anderen Vorteile, die ext4 hat.


2
2018-02-16 23:44





Je mehr Einträge (Dateien und Verzeichnisse) Sie in einem einzelnen Verzeichnis haben, desto langsamer wird der Zugriff. Dies gilt für jedes Dateisystem, obwohl einige schlechter sind als andere.

Eine bessere Lösung besteht darin, eine Verzeichnishierarchie wie folgt zu erstellen:

/users/a/aaron/
/users/a/andrew/
/users/b/betty/
/users/b/brian/

Und wenn Sie immer noch eine bessere Leistung benötigen, können Sie mehrere Ebenen erweitern:

/users/a/a/aaron
/users/a/n/anna
/users/a/n/andrew

Die meisten Mail-Systeme verwenden diesen Trick mit ihren Mail-Warteschlangendateien.

Außerdem habe ich festgestellt, dass bei einigen Dateisystemen, die in der Vergangenheit viele Einträge in einem Verzeichnis hatten, der Verzeichniszugriff langsam wird. Mach ein ls -ld auf dem Verzeichnis, um die Größe des Verzeichniseintrags selbst zu sehen. Wenn es mehrere MB oder mehr ist und das Verzeichnis relativ leer ist, erhalten Sie möglicherweise eine schlechte Leistung. Benennen Sie das Verzeichnis aus dem Weg, erstellen Sie ein neues mit dem gleichen Namen und Berechtigungen und Besitz, und verschieben Sie dann den Inhalt Ihres alten Verzeichnisses in das neue Verzeichnis. Ich habe diesen Trick viele Male benutzt, um Mail-Server, die durch das Dateisystem gebremst wurden, erheblich zu beschleunigen.


2
2018-02-17 19:12





Ich habe kürzlich einen Speicherserver entwickelt, der Dutzende Millionen von Dateien und Hunderttausende von Verzeichnissen erstellen musste. Ich habe XFS mit ext4 und reiserfs verglichen. Ich fand, dass ext4 in meinem Fall etwas schneller war als XFS. Reiser war interessant, hatte aber Einschränkungen, so dass er fallen gelassen wurde. Ich fand auch, dass ext4 signifikant schneller war als ext3.

Wenn Sie viele Dateien pro Verzeichnis erhalten, beginnt die Dateiöffnungszeit zu leiden. Datei-I / O nicht. Die Zeit für das Löschen von Dateien leidet ebenfalls. Bei ext4 ist es jedoch nicht zu langsam. Unter ext3 ist es jedoch ziemlich auffällig. XFS und ext4 sind ziemlich schnell dabei.

Als ich zum letzten Mal XFS angeschaut habe und die Vorteile und Nachteile der Verwendung von XFS gegenüber ext4 abgewogen habe, habe ich Berichte über Datenverlust mit XFS gefunden. Ich bin mir nicht sicher, ob das immer noch ein Problem ist oder ob es jemals passiert ist, aber es machte mich nervös genug, um klarzukommen. Da ext4 das Standardfs in Ubuntu ist, hat es sich leicht über XFS durchgesetzt.

Also, zusätzlich zum Vorschlag von tylerl, der aus der Managementperspektive helfen wird, Ich schlage vor, Sie können auf ext4 upgraden. Das Limit pro Verzeichnis beträgt 64000 Einträge mit ext4

Ein weiterer Vorteil ist die fsck-Zeit ist wesentlich schneller. Ich hatte nie Probleme mit Korruption.

Das Schöne an ext4 ist, dass Sie ein ext3-Volume an ext4 anschließen können, um es auszuprobieren. Sehen: Migration eines Live-Systems von ext3 nach ext4 Dateisystem

Ein Zitat von diesem Link:

Wenn Sie von den Einschränkungen von   ext3, und nicht bereit, Risiken einzugehen, ist es vielleicht nicht wert. Auf der   Andererseits, nach erfolgreichem Abschluss des Migrationsverfahrens   System kann schneller arbeiten, kürzere Dateisystemprüfungen durchführen,   und haben eine erhöhte Zuverlässigkeit ohne negative Auswirkungen.

Also, mach weiter und probier es aus. Ich schlage vor, Sie zuerst zu sichern.


2
2017-10-31 20:44





Es wird DEFINITIV einige Konsequenzen davon haben. Der primäre wird IO lesen / schreiben sein. Darüber hinaus ist es nur eine sehr erschreckende Art, mit dieser Art von Daten umzugehen (in diesem Maßstab).


1
2018-02-16 20:24



Wäre es weniger erschreckend, alle Dateien in dasselbe Verzeichnis zu stellen? - T. Brian Jones
Ich nehme an, es hängt von deiner Definition von gruselig ab. Die Tatsache, dass Sie eine DB verwenden, um all dies zu koordinieren, scheint weniger beängstigend. Ich würde sicherlich versuchen und zumindest die Verzeichnisstruktur auf eine Alternative reduzieren? Das heißt, basierend auf Datum, Gruppierung usw. - Publiccert
Sie sind nach Benutzern gruppiert. Gibt es Beispiele für andere Arten, wie große Dateisysteme wie diese für eine Web-App strukturiert sind? - T. Brian Jones
Die meisten Systeme, auf die ich gestoßen bin, verwenden EXT3 leider nicht. Ich denke, das könnte deine erste Hürde sein. - Publiccert
Falsch. Sobald eine Datei geöffnet und ein offenes Handle erhalten wurde, ist die E / A-Verbindung zur Datei nicht beeinträchtigt. Die Dateiöffnungszeit ist jedoch beeinträchtigt. - Matt


In der Vergangenheit habe ich XFS benutzt, um die Grenzen von Ext3 mit Erfolg zu überwinden.

Die erste Auflistung von Dateisystem-Inhalten dauert eine Weile, bis das System alle Verzeichnis- / Dateiinformationen gelesen hat. Zusätzliche Operationen sind schneller, da der Kernel die Informationen jetzt zwischenspeichert.

Ich habe gesehen, dass Admins "find / somepath 2> & 1> / dev / null" regelmäßig in Cron ausführen, um den Cache aktiv zu halten, was zu einer besseren Performance führt.


1
2018-02-16 22:32





Ich habe einige Fragen und mögliche Engpässe.

Erstens, ist dies ein CentOS 5 oder 6 System? Denn in 6 haben wir ein unglaubliches Werkzeug namens blktrace, das ideal ist, um die Auswirkungen in solchen Situationen zu messen.

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html

Wir können dann die Ausgabe mit btt analysieren und herausfinden, wo der Engpass liegt: Anwendung, Dateisystem, Scheduler, Speicher - bei welcher Komponente der IO die meiste Zeit verbringt.

Nun, theoretisch zu Ihrer Frage kommen, wird es offensichtlich die Anzahl der Inodes erhöhen und während Sie weiterhin erstellen oder auf neue oder vorhandene Dateien oder Verzeichnisse innerhalb von Verzeichnissen zuzugreifen, wird die Zugriffszeit erhöhen. Der Kernel muss eine umfangreichere Dateisystemhierarchie durchqueren und daher ist dies zweifellos ein Overhead.

Ein weiterer zu beachtender Punkt ist, dass mit steigender Anzahl der Verzeichnisse die Inode- und Dentry-Cache-Nutzung steigt, was bedeutet, dass mehr RAM verbraucht wird. Dies kommt unter Slab-Speicher, also, wenn Ihr Server wenig Speicher hat, ist das ein weiterer Punkt des Denkens.

Apropos ein Beispiel aus der realen Welt, ich habe kürzlich gesehen, dass auf einem hoch verschachtelten ext3 fs die Erstellung eines Subdirs zum ersten Mal etwa 20 Sekunden dauert, während es in ext4 etwa 4 Sekunden dauert. Das liegt daran, wie die Blockzuordnung in verschiedenen Dateisystemen strukturiert ist. Wenn du XFS oder ext4 verwendest, ist es unnötig zu sagen, dass du einen Leistungsschub bekommst, wie klein auch immer.

Also, wenn Sie nur fragen, was die richtige Wahl des Dateisystems ist, ist ext3 ein wenig veraltet. Das ist alles, was ich ohne weitere Daten und Benchmark anbieten kann.


1
2017-10-31 18:31





Es ist keine Option auf CentOS 5, und nicht sicher, wie viel es eine Option auf CentOS 6 ist, aber ich habe das Gefühl, dass eine B-Baum oder B * Tree-basierte Lösung, dh BTRFS, eine konsistente, wenn nicht sogar signifikant bessere Leistung in Ihrem Fall bieten würde Szenario, wenn man nur mit gutem Gewissen seine wertvollen Daten anvertrauen könnte (das würde ich immer noch nicht tun).

Aber wenn Sie es sich leisten können, könnten Sie es testen.


0
2017-11-03 23:45