Nipid paljude väikeste failidega töötamiseks

Artikli idee tulenes spontaanselt arutelust kommentaarides artikli all «Mõned asjad inode'ist».

Asi on selles, et meie teenuste sisemine eripära on tohutu hulga väikeste failide salvestamine. Praegusel hetkel on meil sadu terabait selliseid andmeid. Oleme silmitsi seisnud mõne ilmselge ja mitte nii ilmselge probleemiga ning oleme neist edukalt üle saanud.

Seetõttu jagan meie kogemusi, ehk on kellelegi kasuks.

Esimene probleem: „Seadmel pole ruumi”

Nagu mainitud eelnevas artiklis, on probleem selles, et failisüsteemis on vabad plokid, kuid inode'id on otsas.

Kasutatud ja vabad inode'id saab kontrollida käsklusega df -ih:

Ma ei hakka artiklit ümber jutustama, lühidalt öeldes, kettal on nii plokke, mis on mõeldud otse andmete jaoks, kui ka plokke meta-informatsiooni jaoks, need on inode'id (indeksi sõlm). Nende arv määratakse failisüsteemi initsialiseerimisel (räägime ext2 ja selle järeltulijatest) ning hiljem ei muutu. Andmeplokkide ja inode'ide tasakaalu arvutatakse keskmiste andmete põhjal, meie puhul, kus on palju väikeseid faile, peaks tasakaal olema suunatud inode'ide arvu suurendamisele — neid peaks olema rohkem.

Linuxis on juba ette nähtud erinevate tasakaalude variandid, ja kõik need eelnevalt arvutatud konfiguratsioonid asuvad failis /etc/mke2fs.conf.
Seetõttu saab failisüsteemi esmakordsel initsialiseerimisel käsklusega mke2fs määrata soovitud profiili.

Siin on mõned näited failist:

    small = {
        blocksize = 1024
        inode_size = 128
        inode_ratio = 4096
    }

    big = {
        inode_ratio = 32768
    }

    largefile = {
        inode_ratio = 1048576
        blocksize = -1
    }

Sobiva kasutusvõimaluse valimiseks saab kasutada valikut „-T” käskluse mke2fs kutsumisel. Samuti saab vajadusel käsitsi määrata vajalikud parameetrid, kui ei ole valmis lahendust.

Rohkem üksikasju on kirjeldatud manuaalides mke2fs.conf ja mke2fs.

Üksikasjad, mis ei olnud eelnevas artiklis käsitletud — andmeploki suurust saab määrata. Ilmselgelt on suurte failide jaoks mõistlikud suuremad plokid, väikeste jaoks aga väiksemad.

Siiski tuleks arvesse võtta sellist huvitavat omadust nagu protsessori arhitektuur.
Mõtlesin kunagi, et suurte piltide puhul on mul vaja suuremat ploki suurust. See toimus kodustes tingimustes, WD nime all tuntud kodu serveris, mis oli ehitatud ARM arhitektuuri peale. Mõtlesin siis, et seadistan ploki suuruseks kas 8k või 16k, standardse 4k asemel, pärast eelnevat säästude mõõtmist. Kõik oli suurepärane, kuni server ühel hetkel üles ütles, samas kõvaketas töötas. Panin kõvaketta tavalisse arvutisse tavalise Intel-i protsessoriga ja sain üllatuse: toetamata ploki suurus. Andmed olid olemas, kõik oli korras, aga lugeda ei saanud. i386 protsessorid ja sarnased ei oska töötada plokkide suurustega, mis ei vasta mälu lehe suurusele, mis on täpselt 4k. Lõppkokkuvõttes kasutasime user space'i tööriistu, kõik käis aeglaselt ja kurvalt, kuid me päästsime andmed. Huvi korral — otsige tööriista nime järgi fuseext2. Moraal: kas mõelda kõik juhtumid ette või mitte teeselda superkangelast ja kasutada standardseid seadistusi koduperenaiste jaoks.

UPD. Ühe kasutaja märkuse kohaselt berez täpsustan, et i386 ploki suurus ei tohi ületada 4k, kuid ei pea olema täpselt 4k, st lubatud on 1k ja 2k.

Nii et, kuidas meie probleemid lahendasime.

Esiteks, me puutusime probleemiga kokku, kui mitme terabaidi suurune kõvaketas oli andmetega täidetud, ja me ei saanud failisüsteemi konfiguratsiooni muuta.

Teiseks, lahendus oli hädasti vajalik.

Kokkuvõttes jõudsime järeldusele, et peame tasakaalu muutma, vähendades failide arvu.
Failide arvu vähendamiseks otsustasime faile kokku panna ühte ühisesse arhiivi. Arvestades meie spetsiifikat, panime ühte arhiivi kõik failid teatud ajavahemiku jooksul ja teostasime arhiveerimise cron-ülesandega igal ööl.

Valisite zip-arhiivi. Eelmises artiklis pakuti välja tar, kuid sellel on üks probleem: see ei sisalda sisukorda ja failid on seal järjestikku (ärge unustage, et «tar» on lühend «Tape Archive» ehk ribalõike pärand), seega kui soovite lugeda faili arhiivi lõpus, tuleb lugeda kogu arhiiv, kuna seal pole failide asukohtade kohta niheteid. Seetõttu on see aeglane protsess. Zipis on asjad palju paremad: tal on see sisukord ja failide nihked arhiivi sees, ning juurdepääsu aeg igale failile ei sõltu selle asukohast. Meie juhul võis seada tihendamise valiku «0», kuna kõik failid olid juba eelnevalt gzip'i sees tihendatud.

Kliendid võtavad faile nginx'i kaudu ja vanas API-s näidatakse lihtsalt faili nime, näiteks nii:

http://www.server.com/hydra/20170416/0453/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5

Kasutades faile otse lahti pakkida, leidsime ja lisasime nginx-unzip-module'i (https://github.com/youzee/nginx-unzip-module) ja seadistatud kaks upstream'i.

Tulemuseks sai selline konfiguratsioon:

Kaks hosti seadistustes nägid välja nii:

server {
  listen *:8081;

  location / {
    root      /home/filestorage;
  }
}

server {
  listen *:8082;

  location ~ ^/hydra/(d+)/(d+)/(.*)$ {
    root      /home/filestorage;
    file_in_unzip_archivefile "/home/filestorage/hydra/$1/$2.zip";
    file_in_unzip_extract "$2/$3";
    file_in_unzip;
  }
}

Ja upstream'i konfiguratsioon ülemisel nginx'il:

upstream storage {
  server server.com:8081;
  server server.com:8082;
}

Kuidas see töötab:

• Kliendi siseneb front nginx'i
• Front nginx üritab anda faili esimesest upstream'ist, st otse failisüsteemist
• Kui faili ei ole — üritab anda teiselt upstream'ilt, mis püüab leida faili arhiivi seest

Teine probleem: jälle «No space left on device»

See on teine probleem, millega me silmitsi seisame, kui kataloogis on palju faile.
Püüdleme faili luua, süsteem kurdab, et ruumi pole. Muudame faili nime ja proovime uuesti.

Saame hakkama.

Paistab välja umbes nii:

Inode'ide kontroll ei andnud midagi — neid on palju vabu.
Ruuumi kontroll — sama asi.
Mõtlesime, et võib-olla on kataloogis liiga palju faile ja sellel on piirang, kuid taas ei ole: Kataloogis lubatud maksimaalne failide arv: ~1,3 × 10^20

Ja faili luua on võimalik, kui muuta nime.
Järeldus — probleem on faili nimel.

Edasised otsingud näitavad, et probleem seisneb katalooge indekseerimise algoritmi hash-algoritmis, kus suurte failide arvuga tekivad kollisioonid kõigi sellele järgneva tagajärgedega. Täiendavad üksikasjad leiate siit: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Hash_Tree_Directories

Seda valikut on võimalik välja lülitada, kuid… faili leidmine nime järgi võib muutuda ettearvamatult pikaks, kui käiakse läbi kõik failid.

 tune2fs -O "^dir_index" /dev/sdb3

Üldiselt võib see toimida ajutise lahendusena.

Moraal: palju faile kaustas on tavaliselt halb. Nii ei tohiks teha.

Tavaliselt sellistes olukordades luuakse sisemisi kaustu, kas faili nime esimeste tähtede järgi või mõne muu parameetri, näiteks kuupäevade järgi, see päästab enamasti.
Aga üldine väikeste failide arv on ikkagi halb, isegi kui need on jaotatud kaustadesse — siis vaata esimest probleemi.

Kolmas probleem: kuidas vaadata failide nimekirja, kui neid on palju

Meie olukorras, kui meil on palju faile, oleme paratamatult kokku puutunud probleemiga, kuidas vaadata kausta sisu.

Standardsed lahendus — käsk ls.
Okei, vaatame, mis juhtub 4772098 failiga:

$ time ls /home/app/express.repository/offercache/ >/dev/null

real	0m30.203s
user	0m28.327s
sys	0m1.876s

30 sekundit… see on liiga palju. Peamine aeg kulub failide töötlemiseks kasutaja ruumis, mitte tuuma tööle.

Aga lahendus on olemas:

$ time find /home/app/express.repository/offercache/ >/dev/null

real	0m3.714s
user	0m1.998s
sys	0m1.717s

3 sekundit. 10 korda kiiremini.
Jee!

UPD.

Kasutajalt veelgi kiirem lahendus berez — sortimise keelamine käskluses ls

time ls -U /home/app/express.repository/offercache/ >/dev/null
real	0m2.985s
user	0m1.377s
sys	0m1.608s

Neljas probleem: suur LA failidega töötamisel

Aeg-ajalt juhtub, et tuleb kopeerida palju faile ühest masinast teise. Sellega seoses suureneb sageli LA, kuna kõik sõltub ketaste jõudlusest.

Mõistlik on kasutada SSD-d. See on tõeliselt äge. Küsimus on ainult mitme terabaidi SSD hindades.

Aga kui kettad on tavalised, tuleb faile kopeerida, ja see on veel tootmissüsteem, kus ülekoormus viib klientide rahulolematuse juurde? On vähemalt kaks kasulikku tööriista: nice ja ionice.

nice — vähendab protsessi prioriteeti, seega jaotab planeerija rohkem aeglasi kvante teistele, prioriteetsematele protsessidele.
Meie praktikas on aidanud määrata nice'i maksimaalseks (19 — minimaalne prioriteet, -20 — maksimaalne).

ionice — vastavalt reguleerib sisendi/väljundi prioriteeti (I/O planeerimine).

Kui teil on RAID ja see vajab äkki sünkroonimist (pärast ebaõnnestunud taaskäivitamist või RAID-massiivi taastamist pärast ketta vahetust), siis teatud olukordades on mõttekas vähendada sünkroonimise kiirust, et teised protsessid saaksid enam-vähem korralikult töötada. Selle jaoks aitab järgmine käsk:

echo 1000 > /proc/sys/dev/raid/speed_limit_max

Probleem viies: Kuidas sünkroonida faile reaalajas

Meil on kõik need tohutud failihulgad, mida tuleb varundada teisele serverile… Failid kirjutatakse pidevalt, seega, et minimeerida kaotusi, tuleb neid maksimaalse kiirusel kopeerida.

Standardlahendus: Rsync SSH kaudu.

See on hea variant, kui sellega ei pea tegelema kord paari sekundi tagant. Ja faile on palju. Isegi kui neid ei kopeerita, tuleb kuidagi ikkagi mõista, mis on muutunud, ja võrrelda mitme miljoni faili — see võtab aega ja koormab kettaid.

Kuna meil on vaja kohe teada, mida kopeerida, ilma igal korral võrgu käivitamata.

Päästmine — lsyncd. Lsyncd — Live Syncing (Mirror) Daemon. See töötab samuti rsynci kaudu, kuid jälgib lisaks failisüsteemi muudatusi, kasutades inotify ja fsevents, ning käivitab kopeerimise ainult nende failide jaoks, mis on tekkinud või muutunud.

Probleem kuues: kuidas aru saada, kes koormab kettaid

Seda teavad ilmselt kõik, kuid täieliku pildi saamiseks: diskisüsteemi jälgimiseks on käsk iotop — sarnane top, kuid näitab protsesse, mis kasutavad kettaid kõige aktiivsemalt.

Muide, vana hea top aitab samuti aru saada, kas kettas on probleeme või mitte. Selleks on kaks kõige sobivamat parameetrit: Load Average ja IOwait.

Esimene näitab, mitu protsessi ootavad teenindamist; tavaliselt, kui see on rohkem kui 2, on juba midagi valesti. Aktiivse varundamise ajal lubame kuni 6-8, pärast seda loetakse olukord erakorraliseks.

Teine — kui palju protsessor on kettaoperatsioonidega hõivatud. IOwait >10% — põhjustab muret, kuigi meil on serverites, millel on spetsiifiline koormusprofiil, stabiilselt 40-50%, ja see on tõeliselt normaalne.

Selle lõpetan, kuigi kindlasti on palju aspekte, millega me pole kokku puutunud; ootan hea meelega kommentaare ja huvitavaid tõelisi juhtumeid.

Allikas: habr.com