Sie sind nicht angemeldet.

ulle

Fortgeschrittener

Beiträge: 228

Danksagungen: 65

  • Nachricht senden

21

Freitag, 6. Januar 2017, 09:12

Nein das ist garnicht gut. Dateisysteme haben riesen Probleme mit einer riesigen anzahl an dateien in einem Ordner. Du wirst da bald deinen kompletten server lahmlegen.
Auf welcher Quelle beruht deine Aussage? Ich kann das leider nicht bestätigen. Ich habe ein paar relativ große Applikationen mit Laravel entwickelt, welche auch viele kleine Template Snippets haben. Alle Template Files werden gecacht und eine Verlangsamung des System ist nicht festzustellen.

Deswegen würde mich die Quelle für deine These interessieren.

nOnAmE

Fortgeschrittener

Beiträge: 172

Wohnort: Neuenkirchen

Beruf: Anwendungsentwickler

Danksagungen: 14

  • Nachricht senden

22

Freitag, 6. Januar 2017, 09:20

Nein das ist garnicht gut. Dateisysteme haben riesen Probleme mit einer riesigen anzahl an dateien in einem Ordner. Du wirst da bald deinen kompletten server lahmlegen.
Auf welcher Quelle beruht deine Aussage? Ich kann das leider nicht bestätigen. Ich habe ein paar relativ große Applikationen mit Laravel entwickelt, welche auch viele kleine Template Snippets haben. Alle Template Files werden gecacht und eine Verlangsamung des System ist nicht festzustellen.

Deswegen würde mich die Quelle für deine These interessieren.


Laravel cached die Dateien aber auch alle in Unterverzeichnisse.
Denke um genau das Problem zu umgehen.

Wobei ich da auch nur ein Problem sehe, wenn der komplette Ordner mal ausgelesen werden muss, wenn das Script aber direkt auf die passende Datei zugreift, sollte es da nicht zu Problemen kommen.
Hatte da mal auf einem Server ein Problem mit Session Dateien die nicht gelöscht wurden (mehrere 100000 Besucher am Tag), ist natürlich erst dann aufgefallen als keine Inodes mehr frei waren.

simbad

Profi

Beiträge: 1 010

Wohnort: Berlin

Beruf: Software Entwickler

Danksagungen: 184

  • Nachricht senden

23

Freitag, 6. Januar 2017, 10:27

Bei einem ext2-filesystem kann es schwierigkeiten geben, weil darin die Verzeichnis-Info etwas ungünstig verteilt sind. Da macht es durchaus Sinn eine Strukturierung über Unterverzeichnisse einzubauen. Aber wer benutzt denn noch ext2 ?
ext4/btrfs/xfs und wie sie alle unter Linux/Unix heissen verwalten die Directory-Einträge in Datenbankähnlichen Strukturen, und sind somit sehr effektiv. Unter Windows ist NTFS ebenfalls ein Filesystem das seine Directories in DB ähnlichen Strukturen speichert.

Natürlich dauert es in einem File-Browser meist eine gefühlte Ewigkeit bis 1Mio Files in einem Directory angezeigt werden, was aber vielmehr der Menge an Aktionen geschuldet ist, die im File-Browser gemacht werden müssen um, zum Beispiel, eine Preview zu jeder Datei zu rendern.

Was ebenfalls einen Einfluss haben kann ist, wenn viele Dateien geöffnet werden. Wenn man so 1000 Files/pro Sekunde öffnet, dann schlägt sich das sicherlich auf das gesamt System nieder. Aber die reine Menge an Dateien ist heutzutage keine Bremse mehr.
„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“Albert Einstein
Das Entwickler BLOG
Pierre-Romain Main Page

Fhizban

unregistriert

24

Freitag, 6. Januar 2017, 10:50

juhu Diskussion!

Noname hat mich auf eine idee gebracht, ich könnte für jeden eingeloggten spieler noch einen ordner anlegen - aber es wird ohnehin immer nur eine datei direkt ausgelesen.

jedoch, hab ich es jetzt nochmal umgestellt:

vorher hatte ich jedes template für jeden spieler einzigartig. das habe ich jetzt einfach rausgenommen und nun sind die templates für alle spieler allgemein

weiss nicht was mich gestern dazu bewogen hat es unique zu machen

wahrscheinlich weil die spieler verschieden fraktionen angehören und upgrades auf gebäude/einheiten durchführen können. aber selbst dann macht es keinen sinn.

derzeit kann ich es noch nicht ganz überblicken, da das system insgesamt enorm komplex geworden ist

die überlegung war:

"mein kampfflieger stufe 2 ist nicht dein kampfflieger stufe 3, und schon gleich garnicht wenn du klingonen spielst und ich vulkanier".

deshalb waren alle templates unique. nach der neuen methode würden sich halt alle "klingonen kampfflieger stufe 2" (und so weiter) vom selben gecachten template bedienen, was in meinen augen keinen fehler darstellt.

lange rede, kurzer sinn:

von ca. 200 cache templates pro spieler konnte es jetzt auf ca. cache 300 templates für alle spieler reduziert werden

allein die "bauliste" ist immer gleich, macht kein sinn X baulisten für X spieler zu cachen.

so, ihr könnt weiter debattieren :-D

fkrauthan

Schüler

Beiträge: 96

Wohnort: Vancouver

  • Nachricht senden

25

Dienstag, 10. Januar 2017, 01:27

Selbst Ext4 hat damit probleme. Habe das selbst schon auf meinem server hinbekommen da der ja trotzdem fuer jeden datenzugriff erst die volle tabelle durchschauen muss (und wenn es bloed kommt ist der eintrag ja am ende). Ausserdem so sachen wie existiert die datei muss er ja auf jeden fall die komplette tabelle durchschauen. Wie gesagt es passiert nicht bei ein paar 1000 Dateien aber sollte das mal wirklich gross werden kommt man da ganz schnell in performance probleme wo man erstmal null ahnung hat wieso alles langsam ist^^

simbad

Profi

Beiträge: 1 010

Wohnort: Berlin

Beruf: Software Entwickler

Danksagungen: 184

  • Nachricht senden

26

Dienstag, 10. Januar 2017, 15:29

Nö.
Dann machste was falsch.
Ich habe mir ein kleines Programm geschrieben, das 1Mio Files in einem Verzeichnis erzeugt, da 16 Bytes hineinschreibt und dann erstmal die Datei schliesst. Der Name ist eine zufällige 16Stellige Hexadezimal-Zahl.
Dann werden 1Mio Files aufgemacht, der Inhalt gelesen und wieder geschlossen.
Und dann werden die 1 Mio Files über ihren Namen gelöscht.

Das ganze läuft auf einem AMD Rechner mit einer 2.4GHz APU 16GB RAM und einem RAID5-Array aus 4 Desktop-Platten mit 5400 rpm. Also nicht die Welt.

Ich habe dabei massive Geschwindigkeitsschwankungen, was von der Buffer Belegung abhängig ist.
Wenns schlecht läuft braucht mein Rechner:


85 Sek fürs erzeugen
5 Sekunden zum lesen
56 Sekunden zum löschen.

Dabei habe ich zu beginn noch 4% - 10% IOWaits, beim löschen dann geht das durch die Decke, weshalb das löschen auch so lange dauert.

Bei 2Mio files habe ich:

239 Sekunden für das Erzeugen der Dateien, was immer noch 8000 Dateien pro sekunde sind.
Die weiteren Funktionen warte ich nicht ab ,weil es mir zu lange dauert.

Hier habe ich kontinuierlich um die 25% IOWaits und der Speicher ist vollständig mit Buffern belegt. Daher auch der Performance Einbruch.

Der erste Test zeigt das die Menge der Dateinamen wenig Einfluss auf die Performance hat. Viel entscheidender ist wieviel Speicher in dem Rechner steckt.
Auch wenn man die Dateien auf mehrere Verzeichnisse verteilen würde würde man am Ende am Buffer-Management des Kernels scheitern. Sobald der Speicher voll ist, ist es völlig egal wie die Dateien organisiert sind.

Also. Die Anzahl der Dateien pro Verzeichnis haben wenig Einfluss auf die Performance. Der Speicher der für das Filesystem gebraucht wird ist die Bremse. Und der ist unabhängig von der Verzeichnisstruktur.

Ach was ich noch sagen wollte. Seit ext3 Filesystem werden Hash Trees für den Zugriff auf die Directory-Einträge zur Verfügung gestellt. Ein Index-Baum für die Suche von Dateien nach Namen sollte eigentlich bei jedem modernen Filesystem enthalten sein und es würde mich wundern wenn das nicht der Fall wäre. Solche Index-Bäume beschleunigen die Suche nach Dateien doch erheblich.
„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“Albert Einstein
Das Entwickler BLOG
Pierre-Romain Main Page

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »simbad« (10. Januar 2017, 15:59)


Fhizban

unregistriert

27

Dienstag, 10. Januar 2017, 17:48

@simbad: das mit dem falsch hast du jetzt auf krauti bezogen oder?

hier läufts wunderbar mit tausend-und-ein-paar-zerquetschten dateien im directory

es könnten auch mal 2-3k bei voller auslastung werden, aber es wird sich im endeffekt in diesem bereich bewegen und das sollte locker drin sein.

PS: etliche mehr oder weniger kommerzielle/professionelle BGs dumpen ihre cache dateien auch in umfangreiche directories. also was solls.

simbad

Profi

Beiträge: 1 010

Wohnort: Berlin

Beruf: Software Entwickler

Danksagungen: 184

  • Nachricht senden

28

Dienstag, 10. Januar 2017, 20:46

Zitat

@simbad: das mit dem falsch hast du jetzt auf krauti bezogen oder?
Jo
„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“Albert Einstein
Das Entwickler BLOG
Pierre-Romain Main Page

fkrauthan

Schüler

Beiträge: 96

Wohnort: Vancouver

  • Nachricht senden

29

Mittwoch, 11. Januar 2017, 00:03

Simbad lass das mal in dem zustand ne weile laufen und hab noch andere IO Tasks wie DB die unter last steht laufen. Wie schon gesagt es passiert nicht instant aber du wirst damit in einem regulaeren Server betrieb auf lange sicht enorme Probleme haben wenn du nicht aufpasst.

simbad

Profi

Beiträge: 1 010

Wohnort: Berlin

Beruf: Software Entwickler

Danksagungen: 184

  • Nachricht senden

30

Mittwoch, 11. Januar 2017, 08:06

Nein das ist garnicht gut. Dateisysteme haben riesen Probleme mit einer riesigen anzahl an dateien in einem Ordner. Du wirst da bald deinen kompletten server lahmlegen.

Das war deine Aussage. Und die ist falsch. Weil, wie ich ja nun schon dargelegt habe, die Anzahl der Dateien in einem Verzeichnis nicht der limitierende Faktor ist.
.... Das macht den cache unoetig gross und braucht dann jedes mal tausende an filesystem zugriffen um das zu laden (sehr schlecht). ....

Das gilt nur wenn du meinst das man in Summe viele tausend Filesystemzugriffe bekommt. Um eine einzelne Datei zu öffnen braucht es meist nicht mehr als 1-2 Plattenzugriffe, weil das OS, egal ob Windows oder Linux, die Directory Blöcke selbst im Speicher hält. Buffer werden schon seit UNIX System V in LRU (Least Recently Used) Manier freigegeben. Wenn also ein Directory besonders häufig gelesen wird, wird der Buffer dazu nicht freigegeben und steht im Speicher.
Selbst Ext4 hat damit probleme. Habe das selbst schon auf meinem server hinbekommen
Das man auch mit einem Ext4 Filesystem das System langsam bekommt bezweifel ich im Grundsatz nicht. Ein Filesystem hat viele Schwächen. Ext4 ist typischerweise ein Journaling Filesystem. Das bedeutet, das jede Änderung am Filesystem in einem Journal zwischengespeichert wird und dieses Journal erst gelöscht wird, wenn tatsächlich alle darin verzeichneten Änderungen auch physikalisch ausgeführt worden sind. Das verhindert inkonsistente Filesysteme bei einem Absturz. Das ist übrigens identisch zu einem Transaction Log einer Datenbank. Das Journal kommt aber erst beim Schreiben der Daten zum Zuge, nicht beim Lesen.

Zitat

da der ja trotzdem fuer jeden datenzugriff erst die volle tabelle durchschauen muss (und wenn es bloed kommt ist der eintrag ja am ende). Ausserdem so sachen wie existiert die datei muss er ja auf jeden fall die komplette tabelle durchschauen.
Ebenfalls falsch. Ext2 hat das so gemacht, ist aber bereits so alt wie UNIX Systeme an sich. In Ext3 und Ext4 werden Hash-Trees verwendet. Andere Filesysteme benutzen B* Bäume wie in einer DB. Dabei muss nichts linear durchsucht werden.

Zitat

Wie gesagt es passiert nicht bei ein paar 1000 Dateien aber sollte das mal wirklich gross werden kommt man da ganz schnell in performance probleme wo man erstmal null ahnung hat wieso alles langsam ist

Die Performance Probleme, und auch das habe ich doch eigentlich deutlich gemacht, kommen von der Speicher Auslastung die durch ausstehende, meist Schreiboperationen, entstehen. Das System führt alle Operationen erstmal im Speicher aus. Und erledigt das Schreiben auf die Platten dann im Hintergrund. Solange das immer Schubweise geschieht merkt man das nicht. Wenn aber eine kontinuierliche Last auf die Platten kommt, dann ist irgendwann kein Speicher mehr da um die Operationen zwischen zu lagern. Dann werden konsequent alle IO-Operationen aller Prozesse langsamer, da der Prozess erst weiterlaufen kann wenn er seinen Auftrag an das OS hat abliefern können, was das OS erst erlaubt wenn wieder Speicher frei ist, was erst passiert wenn eine IO-Operation abgeschlossen ist.
Wenn also das System wegen des IO ausgebremst wird, dann ist das System offensichtlich zu schlapp für die ihm aufgeladene Aufgaben. IOWaits bremsen immer alle Anwendungen im gleichen Masse aus. Entweder man verteilt Aufgaben neu, in dem man zum Beispiel einen einzelnen DB-Server verwendet und Web-Server und PHP auf einer eigenen Maschine laufen lässt oder aber man analysiert seine Software und versucht die problematischen Bereiche zu finden. Man kann hier nicht allgemein auf ein Caching System mit Dateien verweisen. Es kann durchaus auch ein schlechtes DB-Konzept sein.

Das alles hat aber seinen Grund nicht im Filesystem, wie du mehrfach behauptet hast, sondern liegt einfach in der Natur der Sache.

Ich habe meinen Test heute morgen nochmal laufen lassen und dabei 100.000.000 mal eine jeweils zufällig ausgewählte Datei eingelesen. Während des Lesens hat sich kein Leistungseinbruch gezeigt. Das ganze ist ohne physikalische Leseoperationen ausgekommen. Das zeigt, das bei einem blockieren des Rechners am ehesten Schreiboperationen zu reduzieren sind. Da es hier um einen Caching-Mechanismus geht, und der macht auf Anwendungsebene nur Sinn wenn wenig geschrieben und viel gelesen wird, hat die Menge der im Cache auf der Platte befindlichen Dateien nur geringen Einfluss.

Also. Einfach machen und warten bis es langsam wird. Dann analysieren was der Auslöser ist und gezielt optimieren.
„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“Albert Einstein
Das Entwickler BLOG
Pierre-Romain Main Page

fkrauthan

Schüler

Beiträge: 96

Wohnort: Vancouver

  • Nachricht senden

31

Mittwoch, 11. Januar 2017, 08:17

simbad nochmal deine tests scheinen immer nur deinen Benchmark laufen zu haben. Sollte der Cache naemlich schon durch Datenbank etc belegt sein wirst du einen unterschied spueren. Aber ist ja auch egal. Ich kann dir nur sagen dass ich bereits mit ext4 genau das Problem hatte und daher wollte ich nur davor warnen das man das durchaus im auge behalten sollte.

simbad

Profi

Beiträge: 1 010

Wohnort: Berlin

Beruf: Software Entwickler

Danksagungen: 184

  • Nachricht senden

32

Mittwoch, 11. Januar 2017, 08:30

Hat aber nix mit dem Filesystem oder Filesystem-Typen zutun, sondern betrifft alle IO-Operationen, egal welche Art von Anwendung da läuft.
Hat somit auch nix mit dem Caching in Dateien zutun, sondern ist ein Problem aus der Kombination von der benutzen Hardware und der Aufgabe die diese Hardware bewältigen soll.
Und ich bezweifel ja auch nicht das du deinen Rechner in die Knie gezwungen hast weil du ihm eben mehr IO aufgelastet hast als er leisten kann.

Aber deine Aussagen bezgl. des Filesystems und was es alles macht etc. sind faktisch falsch. Und nur darum ging es mir. Mit meinem Testprogramm kann man sehr schön das verhalten sehen. Der Rest ist logische Überlegung und von mir ebenfalls ausgeführt worden. Wenn keine Buffer fürs File-IO mehr zur Verfügung stehen wird das System extrem langsam.
Das kann übrigens auch eine kleine Anwendung sein, die im Sekunden Takt Speicher belegt und nicht wieder freigibt. Denn die Buffer fürs File-IO werden zu Gunsten von Speicher der durch Anwendungen belegt wird eingedampft. Bedeutet, das einen Anwendung die durch einen Fehler 30% vom Speicher belegt, die Menge der File-IO Operationen die zwischengespeichert werden können drastisch reduziert. Damit setzen die IOWaits entsprechend früher ein.

Es gibt also im gesamten System eine Menge von Möglichkeiten etwas falsch zu machen. Da ist das Caching von immer wieder benötigten Daten in Dateien das geringste Problem und das File-System hat damit nichts zutun.
„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“Albert Einstein
Das Entwickler BLOG
Pierre-Romain Main Page

fkrauthan

Schüler

Beiträge: 96

Wohnort: Vancouver

  • Nachricht senden

33

Mittwoch, 11. Januar 2017, 08:34

Ich lass das einfach mal so stehen da diese diskussion zu nichts fuehrt.

simbad

Profi

Beiträge: 1 010

Wohnort: Berlin

Beruf: Software Entwickler

Danksagungen: 184

  • Nachricht senden

34

Mittwoch, 11. Januar 2017, 08:54

Ich verstehe nicht, warum man nicht, wenn man was offensichtlich falsches gesagt hat, dazu stehen kann?
Hier im Forum gibt es ganz wenige Leute die wirklich was von Betriebssystemen und Architektur verstehen. Wenn dann, egal wer, daher kommt und was faktisch falsches als Wahrheit verbreitet, dann ist das, in meinen Augen fatal. Deswegen diskutiere ich darüber auch.

Denn so wird die Unwahrheit zu Wahrheit umgemünzt. Und die Diskussion hat ja zu was geführt. Ich habe eine Unwahrheit aufgedeckt und die Fakten dargelegt. Ich behaupte hier nicht, und das habe ich auch nie in den vorherigen Posts, das du deinen Server nicht in die Knie gezwungen hast. Es mag sein das du auch durch weglassen eines File basierten Caching das ganze wieder ins Lot gebracht hast.

Aber beides hat, nach meinen Erfahrungen und der realen Implementierung von File-Systemen und anderen Mechanismen in einem OS, nichts mit den von dir propagierten Eigenschaften eines Filesystems zutun.
„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“Albert Einstein
Das Entwickler BLOG
Pierre-Romain Main Page

fkrauthan

Schüler

Beiträge: 96

Wohnort: Vancouver

  • Nachricht senden

35

Dienstag, 17. Januar 2017, 00:36

Wie schon gesagt dein benchmark sagt nichts aus solange alles aus dem Cache geladen wird. Interesannt wird es wenn er die Datensystemtabellen von der eigentlichen Platte laden muss... Aber das willst du ja nicht hoeren.

simbad

Profi

Beiträge: 1 010

Wohnort: Berlin

Beruf: Software Entwickler

Danksagungen: 184

  • Nachricht senden

36

Dienstag, 17. Januar 2017, 08:00

1. Doch rede ich davon. Denn mein Testprogramm macht genau das von dir beschriebene. Es verbrät den gesamten Speicher für den Inhalt der Dateien und zwingt das System alles direkt über die Platten abzuwickeln. Das passiert aber erst oberhalb von 1Million Files. Die Suche nach dem Dateinamen im Verzeichnis jedefalls hat keinen Einfluss auf die Geschwindigkeit.
2. Aber was hat der Cache mit dem Filesystem Typen zutun? Nichts !!!
3. Was sind denn Datensystemtabellen?
4. Richtig. Festplatten sind langsam. Deswegen gibt es Caches, Sector Read Ahead, Filesystem Read Ahead und noch vieles mehr.

Deine Aussage, die Suche nach einem spezifischen Dateinamen würde im Extremfall das durchsuchen des gesamten Directories verlangen, ist für aktuell typische Filesysteme falsch.
Und. Es ist ausschliesslich eine Frage ob du deinem System die Möglichkeit gibst noch nicht abgeschlossene IO Operation zu Ende zu bringen. Wenn das im Mittel nicht der Fall ist, dann bricht es zusammen, egal welcher Filesystemtyp. Dabei muss es aber nicht an einem Filebased Cache liegen. Das können auch ungünstig angelegte Indizes von Datenbanken sein oder ein Logfile.

Aber du hast recht. Mein Testprogramm ist scheisse und eigentlich habe ich von Betriebssystemen keine Ahnung. Es ist alles ausgemachter Blödsinn was ich schreibe und ich sollte meine Posts alle löschen damit bloss keiner auf die Idee kommt das man Daten auch einfach in eine Datei schreiben kann.
„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“Albert Einstein
Das Entwickler BLOG
Pierre-Romain Main Page

Fhizban

unregistriert

37

Dienstag, 17. Januar 2017, 18:49

streitgespräche sind ok. auch obwohl es ursprünglich mal mein thread war.

komisch nur das hier so wenig allgemeine aktivität herrscht - aber für streitereien ist anscheinend immer zeit

nix für ungut leute :-)

DaBu

Administrator

Beiträge: 875

Danksagungen: 333

  • Nachricht senden

38

Dienstag, 17. Januar 2017, 19:20

Ich schreibe ganz bewusst nichts dazu, ich vertraue da voll und ganz auf simbad's Kompetenz und die von vielen anderen hier.
Natürlich sollte man immer wieder etwas hinterfragen, allerdings geht das nicht immer und da fühle ich mich hier meist gut aufgehoben.

Habe ich ja bereits schon bei meiner letzten Frage gemerkt, auch wenn nicht jeder wirklich gelesen hatte was ich wollte ;).

Wenn du noch Fragen hast @Fhizban, dann solltest du wohl ein neues Thema aufmachen :D.

Lg,
DaBu
Irgendwas mit Medien

Ähnliche Themen

Social Bookmarks

Thema bewerten