{"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 zum Umgang mit einer gro\u00dfen Anzahl kleiner Dateien","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Idee zu diesem Artikel entstand spontan aus einer Diskussion in den Kommentaren zu einem vorherigen Artikel \u201eEinige Informationen \u00fcber Inodes\u201c<\/a><\/noindex>.<\/p>\n

\"Tipps
\n
\nDas Besondere an der internen Funktionsweise unserer Dienste ist die Speicherung einer enormen Anzahl kleiner Dateien. Aktuell haben wir etwa mehrere hundert Terabyte solcher Daten. Dabei sind wir auf einige offensichtliche sowie weniger offensichtliche Probleme gesto\u00dfen und haben erfolgreich deren Herausforderungen gemeistert.<\/p>\n

Daher teile ich unsere Erfahrungen, die vielleicht f\u00fcr andere n\u00fctzlich sein k\u00f6nnten.
\n<\/a><\/noindex><\/p>\n

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

\nWie in dem oben genannten Artikel erw\u00e4hnt, besteht das Problem darin, dass zwar freie Bl\u00f6cke im Dateisystem vorhanden sind, die Inodes jedoch ersch\u00f6pft sind.<\/p>\n

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

\"Tipps
\n
\nIch werde den Artikel nicht erneut wiederholen, aber kurz gesagt gibt es auf der Festplatte sowohl Bl\u00f6cke f\u00fcr die Daten selbst als auch Bl\u00f6cke f\u00fcr die Metainformationen, die als inodes (Indexknoten) bekannt sind. Ihre Anzahl wird bei der Initialisierung des Dateisystems festgelegt (wir sprechen hier von ext2 und seinen Nachfolgern) und \u00e4ndert sich danach nicht. Das Gleichgewicht zwischen Datenbl\u00f6cken und inodes wird aus durchschnittlichen Daten berechnet; in unserem Fall, wo es viele kleine Dateien gibt, sollte das Gleichgewicht zugunsten der Anzahl der inodes verschoben werden \u2013 es sollten mehr inodes vorhanden sein.<\/p>\n

In Linux wurden bereits Optionen mit unterschiedlichem Gleichgewicht vorgesehen, und all diese vorab berechneten Konfigurationen befinden sich in der Datei \/etc\/mke2fs.conf<\/code>.
\nDaher kann beim anf\u00e4nglichen Initialisieren des Dateisystems mit mke2fs das gew\u00fcnschte 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
\nDie gew\u00fcnschte Nutzung kann mit der Option «-T» beim Aufruf von mke2fs ausgew\u00e4hlt werden. Alternativ k\u00f6nnen die erforderlichen Parameter auch manuell festgelegt werden, falls keine fertige L\u00f6sung vorhanden ist.<\/p>\n
Weitere Einzelheiten sind in den Handb\u00fcchern f\u00fcr mke2fs.conf<\/code> und mke2fs<\/code>.<\/p>\n
Eine in dem oben genannten Artikel nicht behandelte Besonderheit ist die M\u00f6glichkeit, die Blockgr\u00f6\u00dfe festzulegen. Es liegt auf der Hand, dass f\u00fcr gro\u00dfe Dateien eine gr\u00f6\u00dfere Blockgr\u00f6\u00dfe sinnvoll ist, w\u00e4hrend f\u00fcr kleinere Dateien eine kleinere Blockgr\u00f6\u00dfe vorteilhaft ist. <\/p>\n
Es ist jedoch wichtig, eine interessante Eigenschaft zu ber\u00fccksichtigen: die Architektur des Prozessors.
\nIch habe irgendwann einmal dar\u00fcber nachgedacht, dass ich f\u00fcr gro\u00dfe Fotodateien eine gr\u00f6\u00dfere Blockgr\u00f6\u00dfe ben\u00f6tige. Das Ganze fand unter Heimbedingungen auf meiner WD-Festplatte mit ARM-Architektur statt. Nach kurzer \u00dcberlegung stellte ich die Blockgr\u00f6\u00dfe auf entweder 8k oder 16k statt des Standardwerts von 4k ein, nachdem ich die Einsparungen gemessen hatte. Alles lief gro\u00dfartig, bis die Festplatte ausfiel, w\u00e4hrend die Daten noch intakt waren. Als ich die Festplatte in einen normalen Computer mit einem klassischen Intel-Prozessor einbaute, erhielt ich die \u00dcberraschung: Nicht unterst\u00fctzte Blockgr\u00f6\u00dfe. Tja. Die Daten waren da, alles gut, aber ich konnte sie nicht lesen. Prozessoren wie i386 und \u00e4hnliche Modelle k\u00f6nnen mit Blockgr\u00f6\u00dfen nicht umgehen, die nicht mit der Seitengr\u00f6\u00dfe des Speichers \u00fcbereinstimmen, und diese betr\u00e4gt genau 4k. Im Gro\u00dfen und Ganzen endete es damit, dass ich Tools aus dem Benutzerraum verwendete; alles war langsam und traurig, aber ich konnte die Daten retten. Wer interessiert ist, kann nach dem Namen des Tools googeln. fuseext2<\/code>. Moral: Entweder alle F\u00e4lle im Voraus durchdenken oder sich nicht als Superheld zu f\u00fchlen und die Standardoptionen f\u00fcr den Hausgebrauch nutzen.<\/p>\n
UPD. Auf den Hinweis des Benutzers berez<\/a><\/noindex> Ich m\u00f6chte klarstellen, dass die Blockgr\u00f6\u00dfe f\u00fcr i386 4 k nicht \u00fcberschreiten darf, aber sie muss nicht unbedingt genau 4 k betragen; d.h., 1 k und 2 k sind zul\u00e4ssig.<\/p>\n
So haben wir die Probleme gel\u00f6st.<\/p>\n
Zun\u00e4chst standen wir vor dem Problem, dass die mehrterabyte gro\u00dfe Festplatte mit Daten voll war und wir die Konfiguration des Dateisystems nicht \u00e4ndern konnten.<\/p>\n
Zweitens war eine schnelle L\u00f6sung erforderlich.<\/p>\n
Am Ende kamen wir zu dem Schluss, dass wir das Verh\u00e4ltnis ver\u00e4ndern m\u00fcssen, indem wir die Anzahl der Dateien reduzieren.
\nUm die Anzahl der Dateien zu verringern, haben wir beschlossen, die Dateien in einem gemeinsamen Archiv abzulegen. Angesichts unserer Besonderheiten haben wir alle Dateien \u00fcber einen bestimmten Zeitraum in ein Archiv gepackt und die Archivierung mit einem Cron-Job t\u00e4glich nachts durchgef\u00fchrt.<\/p>\n
Sie haben ein 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 sequenziell darin (nicht umsonst ist \u201etar\u201c eine Abk\u00fcrzung f\u00fcr \u201eTape Archive\u201c, ein Erbe von Bandlaufwerken). Das bedeutet, wenn Sie eine Datei am Ende des Archivs lesen m\u00fcssen, m\u00fcssen Sie das gesamte Archiv durchlesen, da es keine Offset-Informationen f\u00fcr jede Datei relativ zum Anfang des Archivs gibt. Das ist eine langwierige Operation. Bei zip sieht es viel besser aus: Es hat das genannte Inhaltsverzeichnis und Offsets f\u00fcr die Dateien innerhalb des Archivs, und die Zugriffszeit auf jede Datei ist nicht von ihrem Standort abh\u00e4ngig. In unserem Fall konnten wir auch die Komprimierungsoption \u201e0\u201c festlegen, da alle Dateien bereits im gzip-Format komprimiert waren.<\/p>\n
Die Kunden greifen \u00fcber nginx auf die Dateien zu, und laut dem 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 folgende Konfiguration:<\/p>\n
\"Tipps
\n
\nDie beiden 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