På jobb her om dagen kjørte vi i to-hundre (nye filer i sekundet) “rett i en veggen”, da antallet filer på filsystemet ble for mange og alt gikk i stå.
Hovedsaklig møtte vi på to problemer: ingen flere ledige inodes, og lang venting på å liste ut alle filene, med millioner av filer lagret i én og samme katalog.
Filene ble lagret på filsystemet EXT4 i Linux, Ubuntu 14.04.1 LTS.
EXT4 har en fastsatt grense for antall filer som filsystemet kan håndtere, og denne settes under oppretting av filsystemet, så denne kunne vi ikke endre.
Videre klarer ikke EXT4 å håndtere stort mer enn ca 100k filer i én og samme katalog uten at alt går i sneglefart.
Vi måtte finne et nytt filsystem, noe som ikke hadde noen øvre grense for antall filer, med unntak av diskplass så klart.
Andre filsystemer til unnsetning
Vi måtte gjøre noen tester for å finne ut hvilket filsystem vi kan bruke istedenfor EXT4.
Kandidatene vi kom fram til var BTRFS, XFS og ZFS.
I tillegg vurderte vi OneFS, et produkt fra Isilon som vi allerede har kjørende i produksjon, et nettverkslagringssystem som er spesialisert til å håndtere veldig store datamengder, men dette produktet er heller ikke bra til å håndtere veldig mange filer i én katalog.
Vi kan rett og slett ikke bruke den på grunn av risiko for å krasje hele filsystemet og ta med oss alle andre systemer i produksjon som bruker dette.
Testingen jeg gjorde er relativt enkel:
- Opprettet tomme filer på 20 GB, loopback-montert og formattert med filsystemet som skulle testes
- Kopierte 1.6M (1.644.553) filer på til sammen 19 GB, alle i én katalog, til hver av filsystemene
- Tømte Linux OS-cache før testing av hvert filsystem
- Tok tiden for detailjert sortert utlisting (kald test)
- Tok tiden for detailjert sortert utlisting enda en gang (varm test)
- Tok tiden for usortert utlisting (varm test)
I tillegg tok jeg noen notater om komprimeringsgrad for de filsystemene som støttet komprimering, og hvor mye OS-cache og minne som ble brukt etter gjennomført testing.
Maskinene har noen bakgrunnsprosesser som vil kunne allokerer noe minne mens testene kjøres, men jeg anses aktiviteten på disse som lite i forhold til ressursbeslaget disse testene vil gjøre.
Hastighet på lesing eller skriving av innholdet i filene er ikke det viktigste for oss.
Det er små filer, fra 50 KB til 500 KB, så det er viktigere at vi kan lese flere filer raskt enn å lese én stor fil raskt.
Vi trenger et filsystem som lar oss jobbe med filene, skrive nye filer, flytte filer og kopiere filer når behovene melder seg, istedenfor å krype stille sammen for å dø – altså er uthenting av metadata om filer og utlisting av filene viktige kriterier.
For å tømme OS-cache på Linux kjørte jeg følgende kommando:
echo 3 | sudo tee /proc/sys/vm/drop_caches
For utføring av testen “detailjert sortert utlisting” kjørte jeg følgende kommando:
time ls -lht KATALOG | wc -l
For utføring av testen “usortert utlisting” kjørte jeg følgende kommando:
time ls -1 -U KATALOG | wc -l
Disse kommandoene tar tiden for å liste ut filer.
I steden for å bruke tid på å printe ut all teksten til konsollet så gjorde jeg en telling av linjer, som også ble en verifikasjon på at jeg hadde kopiert over alle filene til alle filsystemene som ble testet.
Testoppsett
Filene lå opprinnelig på Server1 på et EXT4-filsystem.
Disse ble kopiert over til Server2 hvor testene av de andre filsystemene ble gjort.
Server2 hadde omtrent ingen annen aktivitet mens testene pågikk, så målingene skal være nokså nøyaktige.
For å måle opp mot problemet vårt ble også testene gjennomført på Server1 mot EXT4.
I tillegg gjennomførte jeg en test på Server1 over NFS mot XFS-filområdet til Server2.
Filsystemene ble i hovedsak opprettet med standard-opsjoner på Ubuntu 14.04.1 LTS.
Komprimering ble aktivert i BTRFS og ZFS.
Resultater
På Server1 gjennomførte jeg en tømming av OS-cache, men målte ikke minneallokeringsbruk, da det er andre tjenster som kjører på serveren, og det kunne gitt villedende resultater.
NFS-testen fra Server1 mot Server2 sitt XFS-testoppsett mangler noen måletall, tall jeg anså som uviktige å måle på grunn av nettverksseparasjonen.
Den kalde testen av detaljert utlisting av filer ble ikke gjennomført over NFS.
Skriving av filer til ZFS ble merkbart tregere for hver fil som ble skrevet – i starten var overføringshastigheten over 6.5 MB/s, men slutta på 3.2 MB/s.
Usikkert om det skyldes komprimering, diskstørrelse eller andre årsaker.
| Server1 | Server2 | Server2 | Server2 | Server1 | |
| EXT-4 | BTRFS | XFS | ZFS | NFS over Server2 XFS | |
| Block-size (GB) | 83 | 10 | 25 | 10 | |
| Diskbruk (GB) | 19,0 | 8,0 | 19,0 | 6,5 | |
| KB / inode | 16,0 | 1,0 | 1,0 | 0,5 | |
| detailjert sortert utlisting (kald) | 03:22 | 03:36 | 01:53 | 08:20 | ??? |
| detailjert sortert utlisting (varm) | 00:44 | 00:19 | 00:16 | 00:33 | 07:40 |
| usortert utlisting (varm) | 00:02 | 00:02 | 00:01 | 00:15 | 00:15 |
| Allokert RAM (GB) | ??? | 5,9 | 3,45 | 3,3 | |
| OS-cache (GB) | 0,1 | 3,7 | 0,8 | 1,4 | |
Tid ble målt i minutter og sekunder.
BTRFS, XFS og ZFS allokerer inodes dynamisk.
EXT4 var eneste som hadde et maksimalt antall inodes.
BTRFS rapporterte ikke om inodes i “df -i”, verken ledige eller brukte.
Både XFS og ZFS var fleksible i ledige inodes som ble rapportert og endret seg i takt med ledig diskplass.
Alle filsystemene gjennomførte testene innen akseptabel hastighet når systemet var varm.
Allikevel var BTRFS og XFS de raskeste her med svar på under 20 sekunder, mens ZFS brukte 33 sekunder og EXT4 brukte 44 sekunder.
XFS var klart raskest når systemet var kald med svar på under 2 minutter.
EXT4 og BTRFS var nokså like med omkring 3,5 minutter når systemet var kald.
ZFS brukte uakseptabel lang tid (over 8 minutter) når systemet var kald.
EXT4, BTRFS og XFS leverte et akseptabelt raskt svar på usortert utlisting av filene, på maksimalt 2 sekunder.
XFS var raskest, på 1 sekund.
ZFS brukte uakseptable 15 sekunder.
Alle filsystemene unntatt EXT4 allokerte mye minne og cache for å utføre testene.
Det er usikkert om loopback-monteringen på Server2 kan ha hatt innvirkning.
EXT4 allokerte bare 109 MB som cache, men den var også noe tregere enn de andre når systemet var varm.
XFS allokerte 3.5 GB minne, hvorav 830 MB cache.
ZFS allokerte 3.3 GB minne, hvorav 1.4 GB cache.
BTRFS allokerte 5.9 GB minne, hvorav 3.7 GB cache.
Konklusjon
Vi anså XFS til å være best for våre behov.
Den leverte svar innen akseptabel tid både da systemet var kaldt og varmt, og var også den raskeste til å levere usortert utlisting av filene.
ZFS skuffet stort med uakseptabelt trege svar.
BTRFS brukte for mye minne, men ellers virket den lovende.
Felles for både BTRFS og ZFS var at komprimering var aktivert.
Kanskje kunne minnebruken vært lavere for både BTRFS og ZFS om testingen ble utført uten komprimering.
Det er god aktivitet rundt BTRFS i Linux-kildekoden og ser ut til å bli arvtakeren til EXT3/4.
BTRFS har funksjoner for blant annet komprimering og snapshotting, og det vil være aktuelt med ny vurdering av BTRFS senere.
Avslutning-rant
Etter at ny diskenhet ble koblet til Server1 og XFS ble satt opp, så dukket et nytt problem fram – overføring av filene fra EXT4-partisjonen til den nye XFS-partisjonen gikk i trege 1 MB/s.
Løsningen ble å overføre filene tilbake fra Server2 sitt XFS-filsystem over NFS…
Et enda større problem møtte vi med en annen katalog, som inneholder omkring 1.1 millioner kataloger, som igjen inneholder filer, men mer om dette kan diskuteres over et par kanner kaffe – jeg har god tid…