geschwindigkeit von großen verzeichnissen

FreeBSD, Gentoo, openSUSE, CentOS, Ubuntu, Debian
stanglwirt
Posts: 48
Joined: 2006-01-10 14:44

geschwindigkeit von großen verzeichnissen

Post by stanglwirt » 2006-01-10 14:51

Hi,
ist wohl so, daß ein Dateizugriff langsam wird, wenn sich in dem Verzeichnis viele Dateien befinden.

also z.b.
/user/1.txt
/user/2.txt

(mehrere tausend .txt dateien)

Wie sieht es mit der Performance bei folgender Konstellation aus:
/user/1/test.txt
/user/2/test.txt

(mehrere tausend unterverzeichnisse von /user worin sich jeweils nur wenige Dateien befinden.)

Ist das Problem mit dem langsamen Dateizugriff damit umgangen oder nicht? Wenn ich das richtig verstanden habe, wäre bei 2. Lösung lediglich der Zugriff auf Verzeichnis /user langsam.
Gibt es eine andere Lösung für das Problem bei vielen userspezifischen Dateien (keine Datenbank)?

cu

User avatar
Joe User
Project Manager
Project Manager
Posts: 11583
Joined: 2003-02-27 01:00
Location: Hamburg

Re: geschwindigkeit von großen verzeichnissen

Post by Joe User » 2006-01-10 14:58

stanglwirt wrote:Ist das Problem mit dem langsamen Dateizugriff damit umgangen oder nicht?
Nein.
stanglwirt wrote:Gibt es eine andere Lösung für das Problem bei vielen userspezifischen Dateien (keine Datenbank)?
Geeigneteres Filesystem (Reiser/XFS) verwenden.
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

stanglwirt
Posts: 48
Joined: 2006-01-10 14:44

Re: geschwindigkeit von großen verzeichnissen

Post by stanglwirt » 2006-01-10 15:12

wie kann ich das denn ohne anderes dateisystem umgehen? solch eine gravierende änderung ist bei meinem server fast nicht möglich.

würde es etwas bringen das user-verzeichnis weiter aufzusplitten?
also z.b. /user/100/1/test.txt (user 1-100)
/user/200/201/test.txt (user 201-300)

cu

encbladexp
Posts: 84
Joined: 2006-01-04 12:09
Location: Lichtenfels

Re: geschwindigkeit von großen verzeichnissen

Post by encbladexp » 2006-01-10 15:56

stanglwirt wrote:Gibt es eine andere Lösung für das Problem bei vielen userspezifischen Dateien (keine Datenbank)?
Mehr RAM kommt immer gut, dadurch kann der Kernel mehr Daten im Speicher behalten...

Welches Dateisystem ist den eigentlich drauf?

mfg Betz Stefan

User avatar
Joe User
Project Manager
Project Manager
Posts: 11583
Joined: 2003-02-27 01:00
Location: Hamburg

Re: geschwindigkeit von großen verzeichnissen

Post by Joe User » 2006-01-10 16:00

Eine Aufsplittung der Verzeichnisse/Dateien kann Dir etwas mehr Performance verschaffen, nur wird sich der Unterschied nur in Benchmarks wiederspiegeln, aber nicht in der Realität. Ohne den Wechsel des Filesystems bleibt Dir nur noch das Verlagern von /user auf eine andere/eigene Partition/Festplatte/RAMdisk, sofern Du dies nicht eh schon gemacht hast.
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

eizo
Posts: 6
Joined: 2005-09-06 13:21

Re: geschwindigkeit von großen verzeichnissen

Post by eizo » 2006-01-10 17:10

Bringt das eigentlich auch in einem Loopfile was? Also: / und Rest ext3, Loopfile (etwa das Mail-Verzeichnis) mit reiserfs

encbladexp
Posts: 84
Joined: 2006-01-04 12:09
Location: Lichtenfels

Re: geschwindigkeit von großen verzeichnissen

Post by encbladexp » 2006-01-10 18:41

eizo wrote:Bringt das eigentlich auch in einem Loopfile was? Also: / und Rest ext3, Loopfile (etwa das Mail-Verzeichnis) mit reiserfs
Das bringt eher nen negativen Effekt mit: Es wird noch langsamer... Den Das Loopfile liegt ja auf nem Dateisystem, also hast du (rein technisch gesehen) 2 Dateisystem übereinander... Mal abgesehen davon: Es ist nicht ratsam 2 Dateisystem übereinander zu stabeln, die beide Journaling unterstützen... Stichwort: Datenintegrität...

mfg Betz Stefan

User avatar
isotopp
RSAC
Posts: 482
Joined: 2003-08-21 10:21
Location: Berlin

Re: geschwindigkeit von großen verzeichnissen

Post by isotopp » 2006-01-26 10:32

stanglwirt wrote:Hi,
ist wohl so, daß ein Dateizugriff langsam wird, wenn sich in dem Verzeichnis viele Dateien befinden.

also z.b.
/user/1.txt
/user/2.txt

(mehrere tausend .txt dateien)
In ext2/ext3 sind Verzeichnisse als lineare Listen organisiert: Jeder Verzeichniseintrag enthält einen Zeiger auf seinen Nachfolger. Das wird bei vielen Dateien pro Verzeichnis relativ schnell sehr langsam.

Deine Idee mit der Aufsplittung in Unterverzeichnisse hilft. Das ist auch das, was z.B. Squid in solchen Fällen macht. Beachte aber, das Verzeichnisdateien niemals schrumpfen. Auch nach der Aufsplittung wird /user also groß (und langsam) bleiben. Du mußt also ein neues /u anlegen, Deinen Kram von /user/xyz nach /u/x/y/z moven und dann /u nach /user umbenennen.

Moderne Dateisysteme wie reiserfs und xfs haben Verzeichnisse, die als Baumstrukturen organisiert sind. Dort wächst die Lookup-Time für ein Verzeichnis also nicht mehr linear, sondern logarithmisch. In diesen Systemen tritt das Problem nicht auf.

Durch die Verwendung eines Loopback-Devices stellt Du das verwendete Dateisystem um, und damit wird auch der schnelle Verzeichniszugriff verwendet - das unterliegende Dateisystem ist bei einem Loopback-Device weitgehend egal. Du handelst Dir jedoch den Overhead durch das Loopback ein. Der kann - je nach Anwendung und Situation - jedoch kleiner sein als der Verlust durch die langsamen Verzeichniszugriffe.

ext3 hat in neueren Versionen auch die Möglichkeit, einzelne Verzeichnisse als Bäume statt als lineare Listen zu organisieren, wenn ich mich recht erinnere. Ich habe damit jedoch noch nicht experimentiert und weiß also nicht, wie stabil das ist, was die Voraussetzungen sind, und ob das Geschwindigkeitsmäßig effektiv ist. Der Benchmark, an den ich mich erinnere, hat das damals ziemlich abgekanzelt.

theton
Posts: 31
Joined: 2006-01-24 11:56
Location: Berlin

Re: geschwindigkeit von großen verzeichnissen

Post by theton » 2006-01-28 03:23

Ne absolute Notloesung waere auch einfach viel mehr RAM reinzubauen und die ganzen Dateien in einer entsprechend grossen RAMDisk zu halten. Kann man ja beim Booten einmalig in den RAM laden und beim Runterfahren sowie per Cron regelmaessig mit den Daten der Festplatte synchronisieren.

Roger Wilco
Administrator
Administrator
Posts: 6001
Joined: 2004-05-23 12:53

Re: geschwindigkeit von großen verzeichnissen

Post by Roger Wilco » 2006-01-28 12:31

FYI: Auf madpenguin.org startet gerade eine Artikelserie zum Thema Dateisystem-Design, die u. a. die Unterschiede zwischen "modernen" FS (im Artikel XFS) und traditionellen/alten FS (am Beispiel von FFS) beschreibt. http://www.madpenguin.org/cms/html/67/6045.html

User avatar
isotopp
RSAC
Posts: 482
Joined: 2003-08-21 10:21
Location: Berlin

Re: geschwindigkeit von großen verzeichnissen

Post by isotopp » 2006-01-28 12:37

Roger Wilco wrote:FYI: Auf madpenguin.org startet gerade eine Artikelserie zum Thema Dateisystem-Design, die u. a. die Unterschiede zwischen "modernen" FS (im Artikel XFS) und traditionellen/alten FS (am Beispiel von FFS) beschreibt. http://www.madpenguin.org/cms/html/67/6045.html
http://kris.koehntopp.de/artikel/diplom ... 0000000000
http://kris.koehntopp.de/artikel/diplom ... 0000000000
http://kris.koehntopp.de/artikel/diplom ... 0000000000

Lang ist's her... :)

User avatar
isotopp
RSAC
Posts: 482
Joined: 2003-08-21 10:21
Location: Berlin

Re: geschwindigkeit von großen verzeichnissen

Post by isotopp » 2006-01-28 12:52

Roger Wilco wrote:FYI: Auf madpenguin.org startet gerade eine Artikelserie zum Thema Dateisystem-Design, die u. a. die Unterschiede zwischen "modernen" FS (im Artikel XFS) und traditionellen/alten FS (am Beispiel von FFS) beschreibt. http://www.madpenguin.org/cms/html/67/6045.html
Dort steht
So, what was the problem with the Berkeley file system? Simple. All the inode information was stored in the superblock. This works fine for small drives, but picture in your mind a large drive. This would mean that the read head would have to go to the beginning of the drive to read an inode, then to the data blocks to get the file data, then back to the inode section, then back to the data and so on. This is called thrashing and is about as inefficient as file systems get.
Das ist leider Bullshit. Natürlich passen nicht alle Metadaten in den Superblock. Stattdessen stehen beim sysv-Dateisystem (dem ffs-Vorläufer) alle Inodes vorne auf der Platte zwischen dem Superblock und den Datenblöcken. Deswegen kommt es bei sysv zu Trashing.

Beim Berkeles-ffs passiert das genau nicht, denn ffs führt das Konzept der Block Groups ein (die dann in Folge auch erklärt werden, ohne Block Groups genannt zu werden). Das angesprochene Mapping von Block Groups auf Cylinder hat man übrigens recht bald wieder aufgegben, und zwar spätestens als Festplatten mit Interleave 1 üblich wurden (Ich hatte noch Platten mit Interleave 5 und 2, aber das war so um 1989 rum :) )

Auf Seite 2 geht es dann nur wenig besser organisiert weiter... *seufz*