{"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\/da\/blog\/administrirovanie\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov","title":{"rendered":"Tips til arbejde med et stort antal sm\u00e5 filer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ideen til artiklen opstod spontant fra en diskussion i kommentarerne til artiklen \u201eNoget om inode\u201c<\/a><\/noindex>.<\/p>\n

\"Tips
\n
\nDet er s\u00e5dan, at den interne specifikation af vores services er opbevaringen af enorme m\u00e6ngder sm\u00e5 filer. Lige nu har vi omkring flere hundrede terabyte af s\u00e5danne data. Og vi er st\u00f8dt p\u00e5 nogle \u00e5benlyse og ikke s\u00e5 \u00e5benlyse problemer og har heldigvis klaret os forbi dem.<\/p>\n

Derfor deler jeg vores erfaring, m\u00e5ske kan den v\u00e6re til hj\u00e6lp for nogen.
\n<\/a><\/noindex><\/p>\n

Problem nummer et: \u201eIngen plads tilbage p\u00e5 enheden\u201c<\/h2>\n

\nSom n\u00e6vnt i den ovenfor n\u00e6vnte artikel, er problemet, at der er ledige blokke p\u00e5 filsystemet, men at inodes er udt\u00f8mt.<\/p>\n

Antallet af brugte og ledige inodes kan tjekkes med kommandoen df -ih<\/code>:<\/p>\n

\"Tips
\n
\nJeg vil ikke gentage artiklen, men kort sagt er der p\u00e5 disken b\u00e5de blokke direkte til data og blokke til metadata, som er inodes (indeksnoder). Deres antal bestemmes ved initialisering af filsystemet (b\u00e5de ext2 og dens efterkommere), og derefter \u00e6ndres det ikke. Balancen mellem datablokke og inodes beregnes udfra gennemsnitsdata, men i vores tilf\u00e6lde, hvor der er mange sm\u00e5 filer, b\u00f8r balancen skubbes i retning af antallet af inodes - der skal v\u00e6re flere af dem.<\/p>\n

I Linux er der allerede forudsete muligheder med forskellig balance, og alle disse forudberegnede konfigurationer findes i filen \/etc\/mke2fs.conf<\/code>.
\nDerfor kan man angive den \u00f8nskede profil ved den prim\u00e6re initialisering af filsystemet via mke2fs.<\/p>\n

Her er nogle eksempler fra filen:<\/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
\nDu kan v\u00e6lge den \u00f8nskede anvendelse ved hj\u00e6lp af indstillingen «-T» ved kald af mke2fs. Du kan ogs\u00e5 manuelt angive de n\u00f8dvendige parametre, hvis der ikke er en klar l\u00f8sning.<\/p>\n
Flere detaljer er beskrevet i manualerne for mke2fs.conf<\/code> og mke2fs<\/code>.<\/p>\n
En funktion, der ikke er ber\u00f8rt i den ovenn\u00e6vnte artikel, er muligheden for at angive st\u00f8rrelsen p\u00e5 datablokken. Det er \u00e5benlyst, at for store filer giver det mening med en st\u00f8rre blokst\u00f8rrelse, for sm\u00e5 filer med en mindre. <\/p>\n
Men man skal tage h\u00f8jde for en interessant egenskab, som er processorarkitekturen.
\nEngang t\u00e6nkte jeg, at jeg havde brug for en st\u00f8rre blokst\u00f8rrelse til store fotofiler. Det var i hjemmemilj\u00f8et p\u00e5 en WD-filopbevaring baseret p\u00e5 ARM-arkitektur. Uden at t\u00e6nke n\u00e6rmere over det satte jeg blokst\u00f8rrelsen til enten 8k eller 16k i stedet for den standard 4k, efter at jeg havde m\u00e5lt besparelsen. Og alt var vidunderligt, indtil lageret pludselig svigtede, selvom disken stadig virkede. Da jeg satte disken i en almindelig computer med en almindelig Intel-processor, fik jeg en overraskelse: underst\u00f8ttet blokst\u00f8rrelse. Datan er der, alt ser godt ud, men det er umuligt at l\u00e6se det. i386-processorer og lignende kan ikke arbejde med blokst\u00f8rrelser, der ikke svarer til st\u00f8rrelsen p\u00e5 hukommelsessiden, som netop er 4k. Alt i alt endte det med at bruge v\u00e6rkt\u00f8jer fra brugerrummet; alt var langsomt og trist, men vi reddede data. For dem, der er interesserede \u2014 goggle efter navnet p\u00e5 v\u00e6rkt\u00f8jet. fuseext2<\/code>. Moralen er: enten t\u00e6nke p\u00e5 alle scenarier p\u00e5 forh\u00e5nd, eller ikke opf\u00f8re sig som en superhelt og bruge standardindstillingerne til hjemmebrugere.<\/p>\n
UPD. If\u00f8lge brugerens bem\u00e6rkning berez<\/a><\/noindex> pr\u00e6ciserer jeg, at for i386 m\u00e5 blokst\u00f8rrelsen ikke overstige 4k, men beh\u00f8ver ikke n\u00f8dvendigvis at v\u00e6re pr\u00e6cis 4k, det vil sige 1k og 2k er tilladt.<\/p>\n
S\u00e5dan l\u00f8ste vi problemerne.<\/p>\n
For det f\u00f8rste st\u00f8dte vi p\u00e5 problemet, da den mange terabyte store disk var fyldt med data, og vi kunne ikke \u00e6ndre konfigurationen af filsystemet.<\/p>\n
For det andet var der brug for en hurtig l\u00f8sning.<\/p>\n
Vi kom derfor frem til, at vi skulle \u00e6ndre balancen ved at mindske antallet af filer.
\nFor at reducere antallet af filer blev det besluttet at samle filerne i et f\u00e6lles arkiv. I betragtning af vores specifik, samlede vi alle filer i et arkiv for en bestemt tidsperiode, og vi udf\u00f8rte arkiveringen med en cron-opgave hver nat.<\/p>\n
Valgt zip-arkiv. I kommentarerne til den tidligere artikel blev tar foresl\u00e5et, men der er en udfordring: det har ikke et indholdsfortegnelse, og filerne opbevares i en fortl\u00f8bende str\u00f8m (og det er ikke for ingenting, at \"tar\" er en forkortelse for \"Tape Archive\", et levn fra b\u00e5ndopbevaring), dvs. hvis man skal l\u00e6se en fil i slutningen af arkivet, skal man l\u00e6se hele arkivet, da der ikke er offsets for hver fil i forhold til arkivets begyndelse. Derfor er det en lang operation. I zip er alt meget bedre: det har det \u00f8nskede indholdsfortegnelse og offsets for filerne inden i arkivet, og adgangstiden til hver fil er uafh\u00e6ngig af dens placering. I vores tilf\u00e6lde kunne vi desuden angive kompressionsmuligheden til \"0\", da alle filer allerede var komprimeret i gzip.<\/p>\n
Kunderne henter filer via nginx, og i henhold til det gamle API angives blot filnavnet, f.eks. s\u00e5ledes:<\/p>\n
http:\/\/www.server.com\/hydra\/20170416\/0453\/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5\n<\/code><\/pre>\n
\nFor at dekomprimere filer on-the-fly fandt vi og tilsluttede nginx-unzip-module (https:\/\/github.com\/youzee\/nginx-unzip-module<\/a><\/noindex>) og indstillede to upstreams.<\/p>\n
Resultatet blev en konfiguration som denne:<\/p>\n
\"Tips
\n
\nDe to v\u00e6rter i indstillingerne s\u00e5 s\u00e5ledes ud:<\/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
\nOg konfigurationen af upstreams p\u00e5 den overordnede nginx:<\/p>\n
upstream storage {\n  server server.com:8081;\n  server server.com:8082;\n}\n<\/code><\/pre>\n
\nS\u00e5dan fungerer det:<\/p>\n