{"id":36999,"date":"2019-10-31T22:15:13","date_gmt":"2019-10-31T19:15:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov\/"},"modified":"2019-10-31T22:15:13","modified_gmt":"2019-10-31T19:15:13","slug":"haki-pri-rabote-s-bolshim-chislom-melkih-fajlov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov","title":{"rendered":"Tipps f\u00fcr den Umgang mit einer gro\u00dfen Anzahl kleiner Dateien","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Idee f\u00fcr den Artikel entstand spontan aus einer Diskussion in den Kommentaren zu einem Artikel \u201eEinige Informationen zu inode\u201c<\/a><\/noindex>.<\/p>\n

\"Tipps
\n
\nDas Problem liegt darin, dass die interne Spezifikation unserer Dienste die Speicherung einer enormen Anzahl kleiner Dateien umfasst. Aktuell haben wir etwa mehrere Hundert Terabyte solcher Daten. Und wir sind auf einige offensichtliche und weniger offensichtliche Stolpersteine gesto\u00dfen und haben sie erfolgreich \u00fcberwunden.<\/p>\n

Deshalb teile ich unsere Erfahrungen, vielleicht kann ihnen jemand n\u00fctzlich sein.
\n<\/a><\/noindex><\/p>\n

Erstes Problem: \u201eKein Speicherplatz mehr auf dem Ger\u00e4t\u201c<\/h2>\n

\nWie im oben genannten Artikel erw\u00e4hnt, besteht das Problem darin, dass es freie Bl\u00f6cke im Dateisystem gibt, aber die inodes aufgebraucht sind.<\/p>\n

Die Zahl der verwendeten und freien inodes kann mit dem Befehl \u00fcberpr\u00fcft werden df -ih<\/code>:<\/p>\n

\"Tipps
\n
\nIch werde den Artikel nicht zusammenfassen, kurz gesagt, auf der Festplatte gibt es sowohl Bl\u00f6cke direkt f\u00fcr Daten als auch Bl\u00f6cke f\u00fcr Metainformationen, die inodes (Indexknoten) sind. Ihre Anzahl wird bei der Initialisierung des Dateisystems festgelegt (hier geht es um ext2 und seine Nachfolger) und \u00e4ndert sich danach nicht. Das Verh\u00e4ltnis von Datenbl\u00f6cken zu inodes wird aus statistischen Daten berechnet, in unserem Fall, bei vielen kleinen Dateien, sollte sich das Verh\u00e4ltnis zugunsten der Anzahl der inodes verschieben \u2013 es sollten mehr von ihnen vorhanden sein.<\/p>\n

In Linux gibt es bereits Optionen mit unterschiedlichem Verh\u00e4ltnis, und all diese vordefinierten Konfigurationen befinden sich in der Datei \/etc\/mke2fs.conf<\/code>.
\nDaher kann beim ersten Initialisieren des Dateisystems \u00fcber mke2fs das entsprechende Profil angegeben werden.<\/p>\n

Hier sind einige Beispiele aus der Datei:<\/p>\n

    small = {\n        blocksize = 1024\n        inode_size = 128\n        inode_ratio = 4096\n    }\n\n    big = {\n        inode_ratio = 32768\n    }\n\n    largefile = {\n        inode_ratio = 1048576\n        blocksize = -1\n    }\n<\/code><\/pre>\n
\nDen gew\u00fcnschten Anwendungsfall kann man mit der Option «-T» beim Aufruf von mke2fs ausw\u00e4hlen. Es ist auch m\u00f6glich, die ben\u00f6tigten Parameter manuell festzulegen, wenn es keine fertige L\u00f6sung gibt.<\/p>\n
Weitere Einzelheiten sind in den Handb\u00fcchern f\u00fcr mke2fs.conf<\/code> und mke2fs<\/code>.<\/p>\n
Ein Punkt, der im oben genannten Artikel nicht behandelt wird, ist die M\u00f6glichkeit, die Blockgr\u00f6\u00dfe f\u00fcr Daten festzulegen. Offensichtlich macht es f\u00fcr gro\u00dfe Dateien Sinn, eine gr\u00f6\u00dfere Blockgr\u00f6\u00dfe zu w\u00e4hlen, w\u00e4hrend es f\u00fcr kleine Dateien sinnvoll ist, eine kleinere zu w\u00e4hlen. <\/p>\n
Es ist jedoch eine interessante Eigenschaft zu beachten, wie die Architektur des Prozessors.
\nIch habe mir irgendwann einmal \u00fcberlegt, dass ich f\u00fcr gro\u00dfe Bilddateien eine gr\u00f6\u00dfere Blockgr\u00f6\u00dfe ben\u00f6tige. Das Ganze geschah unter h\u00e4uslichen Bedingungen, auf einer Heimdateispeicherl\u00f6sung von WD auf ARM-Architektur. Ohne lange nachzudenken stellte ich die Blockgr\u00f6\u00dfe auf 8K oder 16K anstelle der standardm\u00e4\u00dfigen 4K ein, nachdem ich die Einsparungen gemessen hatte. Und alles war wunderbar, bis damaliger der Speicher ausfiel, w\u00e4hrend die Festplatte intakt war. Steckte ich die Festplatte in einen normalen Computer mit einem gew\u00f6hnlichen Intel-Prozessor, erhielt ich die \u00dcberraschung: unsupported block size. Es war unsch\u00f6n. Die Daten sind vorhanden, alles gut, aber sie konnten nicht gelesen werden. Prozessoren wie i386 und \u00e4hnliche k\u00f6nnen nicht mit Blockgr\u00f6\u00dfen arbeiten, die nicht der Seitenformatgr\u00f6\u00dfe des Speichers entsprechen, und diese betr\u00e4gt genau 4K. Letztlich endete es damit, dass wir Programme aus dem User-Space verwendeten, alles war langsam und tr\u00fcbselig, aber wir haben die Daten gerettet. Wer interessiert ist, kann nach dem Namen des Programms googeln. fuseext2<\/code>. Moral der Geschichte: Entweder man denkt alle F\u00e4lle im Voraus durch, oder man gibt sich nicht als Superheld aus und verwendet die Standardkonfigurationen f\u00fcr Haushaltsbenutzer.<\/p>\n
UPD. Laut der Anmerkung eines Nutzers berez<\/a><\/noindex> stelle ich klar, dass die Blockgr\u00f6\u00dfe f\u00fcr i386 4K nicht \u00fcberschreiten sollte, aber sie muss nicht unbedingt genau 4K betragen, d.h. 1K und 2K sind zul\u00e4ssig.<\/p>\n
Also, so haben wir die Probleme gel\u00f6st.<\/p>\n
Zun\u00e4chst sind wir auf das Problem gesto\u00dfen, als die mehrterabyte gro\u00dfe Festplatte mit Daten \u00fcberf\u00fcllt war und wir die Konfiguration des Dateisystems nicht \u00e4ndern konnten.<\/p>\n
Zweitens musste eine schnelle L\u00f6sung her.<\/p>\n
Schlie\u00dflich kamen wir zu dem Schluss, dass wir das Gleichgewicht \u00e4ndern m\u00fcssen, indem wir die Anzahl der Dateien reduzieren.
\nUm die Anzahl der Dateien zu verringern, wurde beschlossen, die Dateien in ein gemeinsames Archiv zu packen. Angesichts unserer Spezifikationen haben wir alle Dateien \u00fcber einen bestimmten Zeitraum in ein Archiv gepackt und die Archivierung wurde t\u00e4glich nachts mit einem Cron-Job durchgef\u00fchrt.<\/p>\n
Wir haben das Zip-Archiv ausgew\u00e4hlt. In den Kommentaren zum vorherigen Artikel wurde Tar vorgeschlagen, aber damit gibt es eine Schwierigkeit: Es hat kein Inhaltsverzeichnis, und die Dateien liegen hintereinander (nicht von ungef\u00e4hr, dass \u201etar\u201c eine Abk\u00fcrzung f\u00fcr \u201eTape Archive\u201c ist, ein Erbe der Bandlaufwerke), d.h. wenn man eine Datei am Ende des Archivs lesen m\u00f6chte, muss man das gesamte Archiv lesen, da es keine Verschiebungen f\u00fcr jede Datei relativ zum Anfang des Archivs gibt. Das ist also ein langwieriger Vorgang. Bei Zip ist alles viel besser: Es hat eben dieses Inhaltsverzeichnis und die Verschiebungen der Dateien innerhalb des Archivs, und die Zugriffszeit f\u00fcr jede Datei h\u00e4ngt nicht von ihrer Position ab. Au\u00dferdem konnte in unserem Fall die Komprimierungsoption \u201e0\u201c festgelegt werden, da alle Dateien bereits im Voraus in gzip komprimiert waren.<\/p>\n
Die Clients holen die Dateien \u00fcber Nginx ab, und laut der alten API wird einfach der Dateiname angegeben, zum Beispiel so:<\/p>\n
http:\/\/www.server.com\/hydra\/20170416\/0453\/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5\n<\/code><\/pre>\n
\nUm die Dateien on-the-fly zu entpacken, haben wir das Modul nginx-unzip-module gefunden und eingebunden (https:\/\/github.com\/youzee\/nginx-unzip-module<\/a><\/noindex>), und zwei Upstreams konfiguriert.<\/p>\n
Das Ergebnis war diese Konfiguration:<\/p>\n
\"Tipps
\n
\nDie zwei Hosts in den Einstellungen sahen so aus:<\/p>\n
server {\n  listen *:8081;\n\n  location \/ {\n    root      \/home\/filestorage;\n  }\n}<\/code><\/pre>\n
<\/p>\n
server {\n  listen *:8082;\n\n  location ~ ^\/hydra\/(\\d+)\/(\\d+)\/(.*)$ {\n    root      \/home\/filestorage;\n    file_in_unzip_archivefile \"\/home\/filestorage\/hydra\/$1\/$2.zip\";\n    file_in_unzip_extract \"$2\/$3\";\n    file_in_unzip;\n  }\n}\n<\/code><\/pre>\n
\nUnd die Konfiguration der Upstreams auf dem \u00fcbergeordneten Nginx:<\/p>\n
upstream storage {\n  server server.com:8081;\n  server server.com:8082;\n}\n<\/code><\/pre>\n
\nSo funktioniert es:<\/p>\n