{"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\/nl\/blog\/administrirovanie\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov","title":{"rendered":"Tips voor het werken met een groot aantal kleine bestanden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Het idee voor dit artikel is spontaan ontstaan uit een discussie in de reacties op een artikel. \u00abWat je moet weten over inode\u00bb<\/a><\/noindex>.<\/p>\n

\"Tips
\n
\nHet punt is dat een interne specificiteit van onze services het opslaan van enorm veel kleine bestanden is. Op dit moment hebben we zo'n honderden terabytes aan dergelijke gegevens. We zijn tegen een aantal voor de hand liggende en minder voor de hand liggende problemen aangelopen en hebben deze succesvol overwonnen.<\/p>\n

Daarom deel ik onze ervaring, hopelijk is het nuttig voor iemand.
\n<\/a><\/noindex><\/p>\n

Probleem \u00e9\u00e9n: \u00abGeen ruimte meer op het apparaat\u00bb<\/h2>\n

\nZoals genoemd in het eerder genoemde artikel, is het probleem dat er vrije blokken op het bestandssysteem zijn, maar dat de inodes op zijn.<\/p>\n

Je kunt het aantal gebruikte en beschikbare inodes controleren met het commando df -ih<\/code>:<\/p>\n

\"Tips
\n
\nIk zal het artikel niet herhalen, kort samengevat houdt het in dat er op de schijf zowel blokken zijn voor gegevens als blokken voor metadata, de zogenaamde inodes (index node). Hun aantal wordt vastgesteld bij de initialisatie van het bestandssysteem (het betreft ext2 en zijn afgeleiden) en verandert daarna niet. De balans tussen gegevensblokken en inodes wordt berekend op basis van gemiddelde gegevens. In ons geval, met veel kleine bestanden, moet de balans verschuiven in de richting van het aantal inodes \u2014 er moeten er meer zijn.<\/p>\n

In Linux zijn al variaties met verschillende balansen voorzien, en al deze vooraf berekende configuraties zijn te vinden in het bestand \/etc\/mke2fs.conf<\/code>.
\nDaarom kan bij de initi\u00eble initialisatie van het bestandssysteem via mke2fs het benodigde profiel worden aangegeven.<\/p>\n

Hier zijn enkele voorbeelden uit het bestand:<\/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
\nDe juiste gebruiksoptie kan worden geselecteerd met de optie «-T» bij het aanroepen van mke2fs. Ook kunnen de benodigde parameters handmatig worden opgegeven als er geen kant-en-klaar oplossing is.<\/p>\n
Meer details zijn beschreven in de handleidingen voor mke2fs.conf<\/code> en mke2fs<\/code>.<\/p>\n
Een aspect dat niet aan bod kwam in het eerder genoemde artikel \u2014 het is mogelijk om de grootte van de gegevensblokken aan te geven. Het is duidelijk dat voor grote bestanden een grotere blokgrootte logisch is, terwijl voor kleine bestanden een kleinere blokgrootte nuttiger is. <\/p>\n
Maar het is belangrijk om een interessant aspect in overweging te nemen, zoals de architectuur van de processor.
\nOp een gegeven moment vroeg ik me af dat ik voor grote foto's een grotere blokgrootte nodig had. Dit gebeurde thuis, op mijn WD-bestandsopslag met ARM-architectuur. Zonder er al te veel over na te denken, stelde ik de blokgrootte in op 8k of 16k in plaats van de standaard 4k, nadat ik de besparingen had gemeten. En alles ging perfect tot het moment dat de opslag zelf defect raakte, terwijl de schijf nog goed was. Toen ik de schijf in een normale computer met een Intel-processor plaatste, kreeg ik een verrassing: een niet-ondersteunde blokgrootte. Dat was het dan. De gegevens zijn er, alles is goed, maar ze zijn niet leesbaar. i386-processoren en soortgelijke kunnen niet omgaan met blokgroottes die niet overeenkomen met de paginagrootte in het geheugen, en die is precies 4k. Kortom, het eindigde met het gebruik van hulpmiddelen uit de gebruikersruimte; alles was langzaam en treurig, maar de gegevens zijn gered. Voor degenen die ge\u00efnteresseerd zijn \u2014 zoek op de naam van het hulpmiddel. fuseext2<\/code>. Moraal: of denk aan alle gevallen van tevoren, of doe jezelf geen superheld voor en gebruik de standaardinstellingen voor huiseigenaren.<\/p>\n
UPD. Zoals opgemerkt door de gebruiker berez<\/a><\/noindex> , verduidelijk ik dat voor i386 de blokgrootte niet groter moet zijn dan 4k, maar niet noodzakelijkerwijs precies 4k moet zijn; 1k en 2k zijn ook toegestaan.<\/p>\n
Dus, zo hebben wij de problemen opgelost.<\/p>\n
Allereerst stuitten we op het probleem toen de meerterabyteschijf vol met gegevens was, en we konden de configuratie van het bestandssysteem niet veranderen.<\/p>\n
Ten tweede was er een dringende oplossing nodig.<\/p>\n
Uiteindelijk kwamen we tot de conclusie dat we de balans moesten aanpassen door het aantal bestanden te verminderen.
\nOm het aantal bestanden te verminderen, werd besloten om bestanden in \u00e9\u00e9n gezamenlijke archief te plaatsen. Gezien onze specificiteit, hebben we alle bestanden die binnen een bepaalde periode zijn gemaakt, in \u00e9\u00e9n archief geplaatst en hebben we de archivering dagelijks 's nachts uitgevoerd met een cron-taak.<\/p>\n
Gekozen voor een zip-archief. In de opmerkingen bij het vorige artikel werd tar voorgesteld, maar daarmee zijn er complicaties: het heeft geen inhoudsopgave en de bestanden liggen er in een stroom (niet voor niets is 'tar' een afkorting voor 'Tape Archive', een nalatenschap van magneetbanden), dat wil zeggen, als je een bestand aan het einde van het archief wilt lezen, moet je het hele archief doorlezen, omdat er geen offsets zijn voor elk bestand ten opzichte van het begin van het archief. Dit maakt het een langzame operatie. Bij zip is alles veel beter: het heeft die inhoudsopgave en offsets voor bestanden binnen het archief, en de toegangstijd tot elk bestand is niet afhankelijk van de plaatsing ervan. Bovendien kon in ons geval de compressie-optie '0' worden ingesteld, aangezien alle bestanden al van tevoren waren gecomprimeerd in gzip.<\/p>\n
Klanten halen bestanden op via nginx, en volgens de oude API, wordt simpelweg de bestandsnaam opgegeven, bijvoorbeeld zo:<\/p>\n
http:\/\/www.server.com\/hydra\/20170416\/0453\/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5\n<\/code><\/pre>\n
\nOm bestanden on the fly uit te pakken, hebben we de nginx-unzip-module gevonden en toegevoegd (https:\/\/github.com\/youzee\/nginx-unzip-module<\/a><\/noindex>) en twee upstreams ingesteld.<\/p>\n
Het resultaat was een configuratie als volgt:<\/p>\n
\"Tips
\n
\nTwee hosts in de instellingen zagen er als volgt uit:<\/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
\nEn de configuratie van de upstreams op de bovenliggende nginx:<\/p>\n
upstream storage {\n  server server.com:8081;\n  server server.com:8082;\n}\n<\/code><\/pre>\n
\nHoe het werkt:<\/p>\n