PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Maximalzahl Files/Unterordner pro Ordner



partizan
17.11.04, 21:28
Guten Abend zusammen!

habe bei php4-forum.de den Hinweis erhalten, mich hierher zu wenden. Was ich nun hoffnungsfroh mache.

Mein Problem:
Ich habe aktuell rund 14.800 PNG-Files in einem Ordner liegen. Seit heute Nachmittag ist der Upload via HTTP (sprich Browser) weiterer Files nur noch eingeschränkt möglich. Es geht NICHT um die geschwindigkeit des Uploads, sondern um Ja/Nein.

Meine Vermutung:
Ich könnte mir vorstellen, dass ich langsam an eine Maximalzahl gelange. Dazu habe ich über Google gesucht und Hinweise gefunden, dass auf Linuxsystemen bei 15.000 bzw. 16.000 Feierabend sein soll.

Die Alternativen:
Dass 14.800 Files in einem Ordner nicht die Hochkultur der Programmierung sind, ist mir klar. Alternativ könnte ich mit rund 600 Unterordnern arbeiten, um die Zahl der Files pro Ordner zu reduzieren... aber vielleicht stoße ich damit ja auch an eine Grenze?

Daher meine Frage:
Ist es richtig, dass es solche Obergrenzen gibt? Und wenn ja, wie hoch sind diese bei Files bzw. bei Unterordnern.

Mein System:
Debian 3.0 mit aktuellem Kernel, Apache 1.3.29

Bitte, bitte - wenn mir jemand helfen kann... ich sollte das bis zum Morgengrauen wieder einigermaßen in Schuß haben.

DANKE!
René

marce
18.11.04, 07:38
die max. Anzahl von Files und Ordnern ist vom installierten Filesystem abhängig (vereinfacht gesagt) - da für jedes File ein (oder mehrere) Inodes vergeben werden. Und wenn dann die Inodes aus sind, dann können keine Files mehr erstellt werden. (Details und mehr dazu jibbet in jedem Buch / Script über Unix)

15000 Files / Ordner ist aber "ein Witz" - ich habe hier bei mir mal Performance-Tests laufen lassen, ob ein Filesystem bzw. Apache langsamer wird, wenn 300000 Files in einem Ordner sind - gab keinerlei Probleme.

Wenn Du Upload per http bzw. dann wohl über ein php-Skript machst, würde ich den "Fehler" eher beim php suchen - evtl. ist der Speicherverbrauch des Scriptes zu gross (weil er z.B. das komplette Vz. einliesst) und so an Grenzen stösst, die Du aber in der php.ini nach hinten schieben kannst.

Edit: vegessene Satzzeichen

taylor
18.11.04, 07:51
15000 Files / Ordner ist aber "ein Witz" - ich habe hier bei mir mal Performance-Tests laufen lassen, ob ein Filesystem bzw. Apache langsamer wird, wenn 300000 Files in einem Ordner sind - gab keinerlei Probleme.

Ich hab mal die Wikipedia dazu befragt:


Das Dateisystem begrenzt die Anzahl von Unterverzeichnissen in einem gegebenen Verzeichnis auf 32.768 Stück. Weiterhin wird angewarnt, wenn in einem Verzeichnis mehr als ca. 10.000-15.000 Dateien liegen, da Dateioperationen in solch großen Verzeichnissen lange dauern können. Die tatsächlich maximal mögliche Anzahl von Dateien ist wieder akademischer Natur, da man Schwierigkeiten haben wird, genügend eindeutige Dateinamen zu finden, bevor man an das Limit von 130 Trillionen Dateien pro Verzeichnis stößt. Handhabbar wären solche Verzeichnisse ohnehin nicht mehr.

http://de.wikipedia.org/wiki/Ext3#Dateisystemgrenzen

tictactux
18.11.04, 08:04
>> 15000 Files / Ordner ist aber "ein Witz"
hmm... wer öfter ein noch nicht gecachtes /usr/share/doc auf
Debian öffnet, muß dabei leider immer noch mit ein paar Sekunden
Bedenkpausen leben...
Und bei meinem cddb-Server mit >200k Dateien in manchen Verzeichnissen
mach ich das mit ext2 nur wenn der Kaffee fertig ist ;) (mittlerweile nicht
mehr, denn er läuft auf Reiser).
Ist also auch eine Frage der Nutzungsart.

<kernel>/Documentation/filesystems/ext*.txt enthält lesenswerte
Informationen zu dieser FS-Familie. U.a. (kernel 2.4.27)

> There is an upper limit of 32768 subdirectories in a single directory.
>
> There is a "soft" upper limit of about 10-15k files in a single directory
> with the current linear linked-list directory implementation. This limit
> stems from performance problems when creating and deleting (and also
> finding) files in such large directories. Using a hashed directory index
> (under development) allows 100k-1M+ files in a single directory without
> performance problems (although RAM size becomes an issue at this point)

EDIT: Die Kaffepause war zu lang ;)

marce
18.11.04, 08:13
ok, muss dazu folgendes sagen: der Test lief bei mir auf ReiserFS.

Das Operationen "lange" dauern (was ist lange?) dürfte dann daran liegen, dass dann (wenn ich mich recht an die Vorlesung erinnere - kann also Quark sein, was jetzt kommt...) die Baumstruktur der Inodes zum Greifen kommt - also nicht mehr nur auf einen inode zugegriffen werden muss sondern hierarchisch in die Tiefe (inode->inode->datei) gegangen wird (und das dauert natürlich).

... müsste aber nochmals genauer recherchieren bzw. Scripte raussuchen...

partizan
18.11.04, 08:13
15000 Files / Ordner ist aber "ein Witz" - ich habe hier bei mir mal Performance-Tests laufen lassen, ob ein Filesystem bzw. Apache langsamer wird, wenn 300000 Files in einem Ordner sind - gab keinerlei Probleme.
Wenn Du Upload per http bzw. dann wohl über ein php-Skript machst, würde ich den "Fehler" eher beim php suchen - evtl. ist der Speicherverbrauch des Scriptes zu gross (weil er z.B. das komplette Vz. einliesst) und so an Grenzen stösst, die Du aber in der php.ini nach hinten schieben kannst.[/I]

Hallo marce,
nichts für ungut, aber das Script läuft seit zwei Jahren ohne größere Anpassungen seelenruhig vor sich hin. Es liest auch nicht das Verzeichnis aus, da ich zuvor bereits weiß, dass der Name des PNG unique ist (unixtime+bild_name). Und 15.000 scheint nicht unbedingt ein Witz zu sein, nachdem, was diejenigen nach dir geantwortet haben.

Trotzdem herzlichen Dank für deine Reaktion
René

partizan
18.11.04, 08:16
Ich hab mal die Wikipedia dazu befragt

Hallo taylor...
seltsam... muss ich wohl nach den falschen Sachen gegoogelt haben... sonst findet der die Wiki-Sachen doch zu allem.
Was mich aber erfreut, sind die 32k Unterverzeichnisse... da dürfte ich die 600+ verwenden können. Dabei ist zwar mit einem Anwachsen zu rechnen, aber bei max. 3.500 gibt es eine natürliche Obergrenze.

Vielen Dank für deine Antwort
René

tictactux
18.11.04, 08:19
Eine andere Idee, da sich das ja in einer http-Umgebung abspielt:
kann durch Cachen zu vieler PNGs evtl. an File-Handle Grenzen
gestoßen werden ?

partizan
18.11.04, 08:20
This limit
> stems from performance problems when creating and deleting (and also
> finding) files in such large directories.
EDIT: Die Kaffepause war zu lang ;)

Hallo Tictactux,

creating und deleting, darum gehts... ansonsten sind die Bildernamen fein in einer DaBa-Tabelle abgetragen und machen auch sonst keine Probleme... Finding ist nach meiner Beobachtung nicht mal ein Millisekundenproblem... die Bildchen sind ratzifatzi da.

Und: Kaffeepausen können NIE zu lang sein...
:rolleyes:

Dank auch dir
René

partizan
18.11.04, 08:23
die Baumstruktur der Inodes zum Greifen kommt - also nicht mehr nur auf einen inode zugegriffen werden muss sondern hierarchisch in die Tiefe (inode->inode->datei) gegangen wird (und das dauert natürlich).

Hallo marce,
das kann freilich ein Problem sein... da ich aber nie die Inhalte des Bilderverzeichnisses durchsuche, sondern gezielt auf einzelne Bilders zugreife, sind hier zumindest noch keine Probleme aufgetreten. Eher erscheint mir der Hinweis von Tictactux bedenkenswerte (creating/deleting).
René

partizan
18.11.04, 08:26
Eine andere Idee, da sich das ja in einer http-Umgebung abspielt:
kann durch Cachen zu vieler PNGs evtl. an File-Handle Grenzen
gestoßen werden ?

Hallo Tictactux,
eher unwahrscheinlich... gecached wird eher "mechanisch": beim Upload verwende ich in PHP imagecreate und muss das Bildchen speichern, bevor ich es zeigen kann. Sprich: Hier ist kein systemimmaneter Cache notwendig. Wobei ich andererseits keine Ahnung habe, ob das System sich da nicht doch etwas zusammencached.

René