Tööd suure arvu väikeste failidega

Artikli idee sündis spontaanselt kommentaaride arutelust artikli all „Mõned asjad inode'ist“.

Asi on selles, et meie teenuste sisemise töö eripära on tohutu arvu väikeste failide säilitamine. Praeguseks on meil umbes sadu terabaite selliseid andmeid. Oleme kohtunud mitmete ilmselgete ja vähem ilmselgete takistustega ning oleme neist edukalt üle saanud.

Seega jagan meie kogemusi, ehk on kellelegi kasulik.

Esimene probleem: "Seade pole rohkem ruumi"

Nagu mainitud eelmises artiklis, on probleem selles, et failisüsteemis on tasuta bloke, kuid inode'id on otsa saanud.

Kasutatud ja vabu inode'e saab kontrollida käsuga df -ih:

Ma ei hakka artiklit ümber jutustama, kuid lühidalt, kettal on nii andmete plokid kui ka meta-informatsiooni plokid, mida nimetatakse ka inodes (indeksi sõlmed). Nende arv määratakse failisüsteemi initsialiseerimise käigus (juttu on ext2-st ja selle järeltulijatest) ning edaspidi ei muutu. Andmeplokkide ja inodide tasakaal arvutatakse keskmiste andmete põhjal, meie juhul, kui on palju väikeseid faile, peaks tasakaal nihkuma inodide arvu suunas — neid peab olema rohkem.

Linuxis on juba ette nähtud erineva tasakaalu variandid, ja kõik need eelnevalt arvutatud konfiguratsioonid asuvad failis /etc/mke2fs.conf.
Seega saab failisüsteemi algse initsialiseerimise käigus mke2fs kaudu määrata vajaliku 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 kasutusvariandi valimiseks saab kasutada valikku «-T» mke2fs käivitamisel. Samuti võib vajaduse korral käsitsi määrata vajalikud parameetrid, kui valmis lahendust pole.

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

Üks põhjusi, mida eespool mainitud artiklis ei käsitletud — on andmeploki suuruse määramine. Ilmselgelt on suurte failide jaoks mõttekas kasutusele võtta suurem plokk, väikeste jaoks aga väiksem.

Kuid tasub arvestada sellise huvitava aspektiga nagu protsessori arhitektuur.
Kordagi mõtlesin, et suurte piltfailide jaoks on mul vaja suuremat plokki. Asi toimus kodus, WD nime all tuntud kodu failiserveris ARM-arhitektuuril. Mõtlesin ja määrasin ploki suuruseks kas 8k või 16k tavalise 4k asemel, eelnevalt mõõtes, kui palju saan kokku hoida. Ja kõik oli suurepärane, kuni server lõpetas töötamise, kuigi kett oli elus. Kui panin ketta tavalisest arvutisse Inteli protsessoriga, sain üllatuse: mitte toetatud ploki suurus. Andmed olid olemas, kõik oli korras, kuid lugeda ei saanud. Protsessorid i386 ja sarnased ei oska töötada plokkide suurustega, mis ei vasta mälulehe suurusele, see on täpselt 4k. Kokkuvõttes lõppes kõik kasutajarekvisiitide utiliitide abil, see oli aeglane ja kurb, kuid andmed saadi siiski kätte. Kellele huvi pakub — otsige utiliidi nime järgi. fuseext2. Moraal: kas tuleb kõik juhtumid ette mõelda või mitte püüda end superkangelasena esitada ja kasutada standardseid seadeid koduperenaiste jaoks.

UPD. Kasutaja märkusele berez Selgitan, et i386 jaoks ei tohiks ploki suurus ületada 4k, kuid see ei pruugi tingimata olla täpselt 4k, st lubatud on ka 1k ja 2k.

Nii et, kuidas me probleemidega hakkama saime.

Esiteks sattusime probleemiga kokku, kui mitme terabaidi kõvaketas oli andmetest pungil, ja me ei saanud failisüsteemi konfiguratsiooni muuta.

Teiseks oli lahendus hädasti vajalik.

Kokkuvõttes jõudsime järeldusele, et peame tasakaalu muutma, vähendades failide arvu.
Failide arvu vähendamiseks otsustasime koguda kõik failid üheks arhiviks. Arvestades meie eripära, kogusime ühe arhiivi kõik failid teatud ajavahemiku jooksul ja tegime arhiveerimise cron-tööülesandena igal ööl.

Valisite zip-arhiivi. Eelmises artiklis soovitati tar'u, kuid sellel on üks probleem: see ei sisalda sisukorda ning failid on seal voogesitusena (mitte juhuslikult - „tar“ on lühend „Tape Archive“, mis pärineb lintkettasid kasutamisest), st kui soovite lugeda faili arhiivi lõpus, peate lugema kogu arhiivi, kuna seal ei ole nihkeid iga faili jaoks arhiivi algusest. Seetõttu on see aeganõudev protsess. Zip-formaadis on asjad palju paremad: see sisaldab just seda sisukorda ja failide nihkeid arhiivi sees, mistõttu on iga faili juurde pääsemise aeg sõltumatu selle asukohast. Meie puhul oleks me võinud määrata ka „0“ tihendamisvaliku, kuna kõik failid olid juba eelnevalt gzip-iga kokku pakitud.

Kliendid saavad faile kätte nginx'i kaudu, ja vastavalt vanale API-le antakse lihtsalt faili nimi, näiteks nii:

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

Et faile reaalajas lahti pakkida, leidsime ja ühendasime nginx-unzip-module'i (https://github.com/youzee/nginx-unzip-module) ja konfigureerisime kaks upstream'i.

Tulemusena sai selline konfigureerimine:

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 tõukserverite konfiguratsioon ülemisel nginx-il:

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

Kuidas see töötab:

• Kliendit läheb front nginx-i
• Front nginx püüab anda faili esimesest tõukurist, st otse failisüsteemist
• Kui faili pole — püüab anda teisest tõukurist, mis püüab faili leida arhiivi seest

Teine probleem: jälle "No space left on device"

See on teine probleem, millega me silmitsi seisame, kui kataloogis on palju faile.
Proovime faili luua, süsteem protestib, et ruumi pole. Muudame faili nime ja proovime jälle luua.

Saame hakkama.

Tundub umbes nii:

Inodes'i kontrollimine ei andnud midagi — neid on palju vabade.
Rоми kontrollimisest — sama asi.
Mõtleme, et võib-olla on kataloogis liiga palju faile ja sellel on piirang, kuid ei: Maksimaalne failide arv kataloogis: ~1.3 × 10^20

Ja faili saab luua, kui nime muudetakse.
Järeldus — probleem on faili nimes.

Edasised uuringud näitasid, et probleem on katalooge indekseerimise ajal kasutatavates hash-algoritmides, millega suures failihulgas tekivad konfliktid ning kõik sellest tulenevad tagajärjed. Täiendavaid andmeid leiate siit: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Hash_Tree_Directories

Selle valiku võib välja lülitada, kuid... faili leidmine nime põhjal võib muutuda ettearvamatult pikaajaliseks, kui tuleb läbi käia kõik failid.

 tune2fs -O "^dir_index" /dev/sdb3

Üldiselt võib see ajutise lahendusena töötada.

Moraal: palju faile kataloogis on tavaliselt halb. Nii ei tohi teha.

Tavaliselt luuakse sellistes olukordades sisemised kataloogid, faili nime esialgsete tähtede või mõne muu parameetri, näiteks kuupäevade järgi, enamasti päästab see olukorra.
Kuid väikeste failide arv on ikkagi halb, isegi kui need on jagatud kataloogidesse — sel juhul vaadake esimest probleemi.

Kolmas probleem: kuidas vaadata, kui faile on palju

Meie olukorras, kus meil on palju faile, oleme varem või hiljem silmitsi seisnud probleemiga, kuidas vaadata katalooge.

Standardslahendus — 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… liiga palju. Ja 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. Kümme korda kiirem.
Hurraa!

UPD.

Veelgi kiirem lahendus kasutajalt berez — sortimise keelamine ls

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

Probleem neli: suur LA failidega töötamisel

Aeg-ajalt tekib olukord, kus on vaja kopeerida hulk faile ühest masinast teise. Sellegipoolest tõuseb LA sageli ebanormaalselt kõrgeks, kuna kõik sõltub ketaste jõudlusest.

Kõige mõistlikum, mida soovitakse — kasutada SSD-d. Tegelikult äge. Ainult hindadega suure mahutavusega SSD-de osas on küsimus.

Aga kui kettad on tavalised, siis faile on vaja kopeerida ja see on samas ka tootmissüsteem, kus koormus põhjustab rahulolematust klientide seas? On vähemalt kaks kasulikku tööriista: nice ja ionice.

nice — vähendab protsessi prioriteeti, vastavalt sellele planeerija jagab rohkem aega teistele, kõrgema prioriteediga protsessidele.
Meie praktikas aitas määrata nice maksimaalselt (19 — see on minimaalne prioriteet, -20 (miinus 20) — maksimaalne).

ionice — vastavalt kohandab sisse- / väljuvate andmete prioriteeti (I/O planeerimine)

Kui teil on RAID ja see vajab äkki sünkroonimist (kui taaskäivitamine ebaõnnestus või tuleb RAID-massiivi taastamine pärast ketta vahetamist), siis mõnes olukorras on mõttekas vähendada sünkroonimise kiirus, et teised protsessid saaksid enam-vähem adekvaatselt 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

Kasutame kõiki neid tohutuid failihulki, mida tuleb varundada teisele serverile, et vältida... Faile kirjutatakse pidevalt, seetõttu tuleb neid kopeerida nii kiiresti kui võimalik, et minimeerida kaotusi.

Standardlahendus: Rsync üle SSH.

See on hea variant, kui seda ei pea tegema iga paari sekundi järel. Ja faile on palju. Isegi kui neid ei kopeerita — tuleb mingil moel ikkagi aru saada, mis on muutunud, ja võrrelda mitme miljoni faili vahel — see on aega ja koormust kettale.

See, me peame kohe teadma, mida kopeerida, ilma et iga kord võrreldakse.

Päästmine — lsyncd. Lsyncd — Elus sünkroonimise (peegli) deemon. See töötab ka rsynci kaudu, kuid lisaks jälgib see failisüsteemi muudatusi inotify ja fsevents abil ning käivitab kopeerimise ainult nende failide jaoks, mis on loodud või muudetud.

Kuues probleem: kuidas mõista, kes koormab kettad

Seda teavad tõenäoliselt kõik, kuid täieliku pildi jaoks: kettasüsteemi jälgimiseks on käsk iotop — midagi sarnast top, kuid see näitab kõige aktiivsemalt kettaid kasutavaid protsesse.

Muide, vana hea top aitab samuti mõista, kas kettad on probleemsed. Kord, milleks on kaks sobivamat parameetrit: Load Average ja IOwait.

Esimene näitab, kui palju protsesse ootavad teenindamist, tavaliselt üle 2 on juba murettekitav. Aktiivse kopeerimise korral varundusse lubame kuni 6-8, pärast seda peetakse olukorda ebanormaalseks.

Teine – kui palju protsessor on kettaoperatsioonidega hõivatud. IOwait >10% – on põhjust muretseda, kuigi meie serverites, kus on spetsiifiline koormuse profiil, on see püsivalt 40-50%, ja see on tõeliselt norm.

Selle lõpetan, kuigi kindlasti on palju hetki, millega me pole silmitsi seisnud, ootan huviga kommentaare ja huvitavaid tõelisi juhtumeid.

Allikas: habr.com