Ideja e artikullit lindi spontanisht nga diskutimi në komentet e artikullit .
E vërteta është se specifikimi i brendshëm i funksionimit të shërbimeve tona është ruajtja e një numri të madh skedarësh të vegjël. Aktualisht kemi rreth qindra terabajt të tillë të dhënash. Dhe kemi hasur në disa pengesa të qarta dhe jo shumë të qarta dhe i kemi kaluar ato me sukses.
Prandaj po ndaj përvojën tonë, ndoshta do t'i shërbejë dikujt.
Problemi i parë: «Nuk ka hapësirë të mbetur në pajisje»
Siç u përmend në artikullin e mësipërm, problemi është se ka blloqe të lira në sistemin e dosjeve, por inode-ët janë ezauruar.
Numrin e inode-ve të përdorura dhe të lira mund ta kontrolloni me komandën df -ih:
Nuk do ta pĂ«rsĂ«ris artikullin, nĂ«se e shohim shkurt, nĂ« disk ka blloqe tĂ« drejta pĂ«r tĂ« dhĂ«nat, si dhe blloqe pĂ«r metainformacionin, tĂ« njohura si inode (indeks i nyjĂ«s). Numri i tyre pĂ«rcaktohet gjatĂ« inicializimit tĂ« sistemit tĂ« dosjeve (flasim pĂ«r ext2 dhe pasardhĂ«sit e saj) dhe mĂ« tej nuk ndryshohet. Balancimi i blloqeve tĂ« tĂ« dhĂ«nave dhe inode-ve llogaritet nga tĂ« dhĂ«nat mesatare, ndĂ«rsa nĂ« rastin tonĂ«, ku ka shumĂ« skedarĂ« tĂ« vegjĂ«l, balancimi duhet tĂ« zhvendoset nĂ« anĂ«n e numrit tĂ« inode-ve â duhet tĂ« jenĂ« mĂ« shumĂ«.
Në Linux gjithashtu janë parashikuar variante me një balancim të ndryshëm, dhe të gjitha këto konfiguracione të paracaktuara ndodhen në skedarin /etc/mke2fs.conf.
Prandaj, gjatë inicializimit të parë të sistemit të dosjeve përmes mke2fs, mund të specifikoni profilin e nevojshëm.
Ja disa shembuj nga skedari:
small = {
blocksize = 1024
inode_size = 128
inode_ratio = 4096
}
big = {
inode_ratio = 32768
}
largefile = {
inode_ratio = 1048576
blocksize = -1
}
Zgjidhni variantin e nevojshëm të përdorimit me opsionin «-T» gjatë thirrjes së mke2fs. Po ashtu, mund të specifikoni manualisht parametrat e nevojshëm, nëse nuk ka një zgjidhje të gatshme.
Më shumë detaje janë përshkruar në manualet për mke2fs.conf dhe mke2fs.
NjĂ« karakteristikĂ« e papĂ«rmendur nĂ« artikullin e mĂ«sipĂ«rm â mund tĂ« specifikoni madhĂ«sinĂ« e bllokut tĂ« tĂ« dhĂ«nave. Ose, pĂ«r skedarĂ« tĂ« mĂ«dhenj ka kuptim qĂ« blloku tĂ« jetĂ« mĂ« i madh, pĂ«r tĂ« vegjlit â mĂ« i vogĂ«l.
Megjithatë, është e rëndësishme të merret parasysh një karakteristikë interesante, siç është arhitektura e procesorit.
NĂ« njĂ« moment unĂ« mendoja se mĂ« duhej njĂ« madhĂ«si mĂ« e madhe blloku pĂ«r skedarĂ«t e mĂ«dhenj tĂ« fotografive. Kjo ndodhi nĂ« kushte shtĂ«piake, nĂ« njĂ« ruajtĂ«s skedarĂ«sh WD mbi arkitekturĂ«n ARM. UnĂ«, pa menduar shumĂ«, vendosa madhĂ«sinĂ« e bllokut 8k ose 16k nĂ« vend tĂ« standardit 4k, pas njĂ« matjeje tĂ« kursimit. Dhe gjithçka ishte shkĂ«lqyer deri nĂ« momentin kur ruajtĂ«si dĂ«shtoi, ndĂ«rkohĂ« qĂ« disku ishte i gjallĂ«. Pasi e vendosa diskun nĂ« njĂ« kompjuter tĂ« zakonshĂ«m me njĂ« procesor Intel tĂ« zakonshĂ«m, mora njĂ« surprizĂ«: madhĂ«si blloku e papĂ«rshtatshme. E shkuara. TĂ« dhĂ«nat janĂ« aty, gjithçka Ă«shtĂ« mirĂ«, por nuk Ă«shtĂ« e mundur tĂ« lexohen. ProcesorĂ«t i386 dhe tĂ« ngjashmit nuk dinĂ« tĂ« punojnĂ« me madhĂ«si blloku qĂ« nuk pĂ«rputhen me madhĂ«sinĂ« e faqeve tĂ« memories, e cila Ă«shtĂ« saktĂ«sisht 4k. NĂ« pĂ«rgjithĂ«si, kjo pĂ«rfundoi me pĂ«rdorimin e utiliteteve nga hapĂ«sira e pĂ«rdoruesit, gjithçka ishte e ngadalshme dhe e trishtueshme, por tĂ« dhĂ«nat u shpĂ«tuan. PĂ«r ata qĂ« janĂ« tĂ« interesuar â kĂ«rkoni me emrin e utilitetit. fuseext2. MĂ«simi: ose tĂ« mendosh pĂ«r tĂ« gjitha rastet paraprakisht, ose tĂ« mos bĂ«sh si njĂ« superheroi dhe tĂ« pĂ«rdorĂ«sh cilĂ«sime standarde pĂ«r amvisat.
UPD. Sipas vërejtjes së përdoruesit duke sqaruar se për i386 madhësia e bllokut nuk duhet të tejkalojë 4k, por nuk është e nevojshme të jetë saktësisht 4k, pra janë të pranueshme 1k dhe 2k.
Pra, si i zgjidhëm problemet ne.
Së pari, ne u përballëm me problemin kur disku me shumë terabajt ishte i mbushur me të dhëna dhe ne nuk mund të riparonim konfigurimin e sistemit të skedarëve.
Së dyti, zgjidhja kërkohej menjëherë.
Në fund arritëm në përfundimin se duhej të ndryshonim balancën, duke reduktuar numrin e skedarëve.
Për të reduktuar numrin e skedarëve, u vendos të vendosim skedarët në një arkiv të përbashkët. Duke marrë parasysh specifikën tonë, ne vendosëm në një arkiv të gjithë skedarët për një periudhë të caktuar kohore dhe e bëmë arkivimin me një task cron çdo natë.
ZgjodhĂ«m njĂ« arkiv zip. NĂ« komentet e artikullit tĂ« mĂ«parshĂ«m u propozuan tar, por me tĂ« ka njĂ« kompleksitet: nuk ka indeks, dhe skedarĂ«t nĂ« tĂ« janĂ« tĂ« radhitur nĂ« mĂ«nyrĂ« kaotike (nuk Ă«shtĂ« rastĂ«si qĂ« "tar" Ă«shtĂ« shkurtim pĂ«r "Tape Archive", trashĂ«gimi e paisjeve me kasetĂ«), dmth. nĂ«se duam tĂ« lexojmĂ« njĂ« skedar nĂ« fund tĂ« arkivit â duhet tĂ« lexojmĂ« tĂ« gjithĂ« arkivin, pasi nuk ka offset pĂ«r secilin skedar nĂ« raport me fillimin e arkivit. Pra, kjo Ă«shtĂ« njĂ« operacion i gjatĂ«. NĂ« zip, gjĂ«rat janĂ« shumĂ« mĂ« mirĂ«: ai ka atĂ« indeksin dhe offset skedarĂ«ve brenda arkivit, dhe koha e qasjes nĂ« çdo skedar nuk varet nga pozita e tij. Gjithashtu, nĂ« rastin tonĂ« mund tĂ« ishte caktuar opsioni i kompresimit "0", pasi tĂ« gjithĂ« skedarĂ«t ishin tashmĂ« kompresuar nĂ« gzip.
Klientët marrin skedarët përmes nginx, dhe sipas API të vjetër, thjesht jepet emri i skedarit, për shembull kështu:
http://www.server.com/hydra/20170416/0453/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5
Për të shpaketuar skedarët në fluks, gjetëm dhe lidhëm modulin nginx-unzip-module () dhe konfiguruam dy upstream.
Si rezultat, u krijua një konfigurim i tillë:
Dy host-e në konfigurim dukeshin kështu:
server {
listen *:8081;
location / {
root /home/filestorage;
}
}server {
listen *:8082;
location ~ ^/hydra/(d+)/(
root /home/filestorage;
file_in_unzip_archivefile "/home/filestorage/hydra/$1/$2.zip";
file_in_unzip_extract "$2/$3";
file_in_unzip;
}
}
Dhe konfigurimi i upstream-eve në nginx e lartë:
upstream storage {
server server.com:8081;
server server.com:8082;
}
Si funksionon:
- Klienti shkon në nginx front
- Front nginx përpiqet të japë skedarin nga upstream i parë, dmth. drejtpërdrejt nga sistemi i skedarëve
- NĂ«se skedari nuk ekziston â pĂ«rpiqet tĂ« japĂ« nga upstream i dytĂ«, i cili pĂ«rpiqet tĂ« gjejĂ« skedarin brenda arkivit
Problemi i dytë: përsëri "Nuk ka hapësirë të mbetur në pajisje"
Ky është problemi i dytë me të cilin u përballëm, kur në katalog ka shumë skedarë.
Ne përpiqemi të krijojmë një skedar, sistemi ankohet se nuk ka hapësirë. Ndryshojmë emrin e skedarit dhe përpiqemi përsëri ta krijojmë.
Dhe funksionon.
Duket kështu:
Kontrolli i inodes nuk dha asgjĂ« â ka shumĂ« tĂ« lirĂ«.
Kontrolli i hapĂ«sirĂ«s â po tĂ« njĂ«jtĂ«n gjĂ«.
Mendova se ndoshta ka shumë skedarë në katalog, dhe për këtë ka një kufizim, por përsëri jo: Numri maksimal i skedarëve për katalog: ~1.3 à 10^20
Po ashtu, skedarin mund ta krijosh, nëse ndryshon emrin.
PĂ«rfundimi â problemi Ă«shtĂ« te emri i skedarit.
Kërkime të mëtejshme treguan se problemi është te algoritmi i hash-it kur ndërtohet indeksi i katalogut, me numër të madh skedarësh vërehen kolizionet me të gjitha pasojat e tyre. Më shumë detaje mund të lexoni këtu:
Mund të çaktivizoni këtë opsion, por... kërkimi i skedarit sipas emrit mund të bëhet papritur shumë i gjatë gjatë kalimit në të gjithë skedarët.
tune2fs -O "^dir_index" /dev/sdb3
Në përgjithësi, si një zgjidhje përkohësore mund të funksionojë.
Mora e historisë: shumë skedarë në një katalog zakonisht është e keqe. Nuk duhet bërë kështu.
Zakonisht në këto raste krijohen katalogë të brendshëm, sipas shkronjave të para të emrit të skedarit ose sipas ndonjë parametri tjetër, për shembull, sipas datave, në shumicën e rasteve kjo shpëton.
Por numri total i skedarĂ«ve tĂ« vegjĂ«l Ă«shtĂ« vazhdimisht i keq, edhe nĂ«se ata ndahen nĂ« katalogĂ« â atĂ«herĂ« shihni problemin e parĂ«.
Problemi i tretë: si të shikoni listën e skedarëve, nëse ka shumë.
Në situatën tonë, kur kemi shumë skedarë, për ndonjë arsye, ne përballemi me problemin se si të shikojmë përmbajtjen e katalogut.
Zgjidhja standarde është komandë ls.
Ok, le të shohim se çfarë ndodh me 4772098 skedarë:
$ time ls /home/app/express.repository/offercache/ >/dev/null
real 0m30.203s
user 0m28.327s
sys 0m1.876s
30 sekonda... është shumë. Dhe koha kryesore shkon në përpunimin e skedarëve në hapësirën e përdoruesit, dhe aspak në funksionimin e bërthamës.
Por ka një zgjidhje:
$ time find /home/app/express.repository/offercache/ >/dev/null
real 0m3.714s
user 0m1.998s
sys 0m1.717s
3 sekonda. 10 herë më e shpejtë.
Hurra!
Për të përmirësuar kuptimin e tipave të mundshëm të njerëzve, pak e kam ndryshuar emrin e tyre:
NjĂ« zgjidhje edhe mĂ« e shpejtĂ« nga pĂ«rdoruesi â çaktivizimi i rendit ls
time ls -U /home/app/express.repository/offercache/ >/dev/null
real 0m2.985s
user 0m1.377s
sys 0m1.608s
Problemi i katërt: LA e madhe gjatë punës me skedarët
Herë pas here ndodhet situata kur duhet të kopjoni një mori skedarësh nga një makinë në një tjetër. Gjatë kësaj, shpesh ndodh të rritet ndjeshëm LA, pasi gjithçka varet nga performanca e disqeve të vet.
Ajo që është më arsyeshme është të përdorni SSD. Realisht e mahnitshme. Pyetja është vetëm për çmimin e SSD-ve të shumë terabyte.
Por nëse disqet janë normale, duhen kopjuar skedarët, dhe kjo është gjithashtu sistem prodhimi, ku ngarkesa çon në pakënaqësi të klientëve? Ka të paktën dy mjete të dobishme: nice dhe ionice.
nice â ul prioritetin e procesit, pĂ«rkatĂ«sisht, plani i ekzekutimit ndan mĂ« shumĂ« kuota kohe pĂ«r proceset e tjera, mĂ« me prioritet.
NĂ« praktikĂ«n tonĂ« ka ndihmuar tĂ« vendosim nice maksimal (19 â Ă«shtĂ« prioriteti minimal, -20 (minus 20) â maksimal).
ionice â pĂ«rkatĂ«sisht rregullon prioritetin e hyrjes/daljes (I/O scheduling)
Nëse përdorni RAID dhe ai papritur ka nevojë të sinkronizohet (pas një rinisjeje të dështuar ose ndihmë për rikuperimin e RAID-it pas zëvendësimit të një disku), në disa situata ka kuptim të zvogëloni shpejtësinë e sinkronizimit, për t'i lejuar proceset e tjera të funksionojnë mjaft normalisht. Komanda e tillë do të ndihmojë:
echo 1000 > /proc/sys/dev/raid/speed_limit_max
Problemi i pestë: Si të sinkronizoni skedarët në kohë reale
Kemi të njëjtat sasi masive skedarësh, të cilat duhet t'i bëjmë backup në serverin e dytë për të shmangur⊠Skedarët shkruhen vazhdimisht, kështu që për të pasur minimumin e humbjeve, duhet t'i kopjojmë ato sa më shpejt të jetë e mundur.
Zgjidhja standarde: Rsync mbi SSH.
Kjo është një mundësi e mirë, nëse nuk duhet ta bëni këtë çdo disa sekonda. Dhe ka shumë skedarë. Edhe nëse nuk i kopjoni, duhet të kuptoni se çfarë ka ndryshuar, dhe krahasimi i disa miliona skedarëve është kohë dhe ngarkesë në disqe.
Pra, na nevojitet të dimë menjëherë se çfarë duhet të kopjojmë, pa e nisur krahasimin çdo herë.
ShpĂ«timi Ă«shtĂ« â lsyncd. Lsyncd â . Ai gjithashtu funksionon pĂ«rmes rsync, por pĂ«rveç kĂ«saj monitoron sistemin e skedarĂ«ve pĂ«r ndryshime duke pĂ«rdorur inotify dhe fsevents dhe nisin kopjimin vetĂ«m pĂ«r skedarĂ«t qĂ« janĂ« krijuar ose ndryshuar.
Problemi i gjashtë: Si të kuptoni kush ngarkon diskët
KĂ«tĂ« ndoshta e dinĂ« tĂ« gjithĂ«, por megjithatĂ« pĂ«r plotĂ«sinĂ« e pamjes: pĂ«r monitorimin e nĂ«n-sistemave tĂ« disqeve ka komandĂ«n iotop â e ngjashme me top, por tregon proceset qĂ« pĂ«rdorin diskĂ«t mĂ« aktivisht.
P.S. Vjetër e mirë top gjithashtu lejon të kuptoni nëse ka probleme me diskët apo jo. Për këtë ka dy parametra më të përshtatshëm: Load Average dhe IOwait.
ParĂ« e parĂ« tregon se sa procese janĂ« nĂ« radhĂ« pĂ«r shĂ«rbim, zakonisht mĂ« shumĂ« se 2 â diçka nuk shkon siç duhet. GjatĂ« kopjimit aktiv nĂ« serverĂ«t e backup-it kemi tolerancĂ« deri nĂ« 6-8, pas kĂ«saj situata konsiderohet jo normale.
E dyta â sa Ă«shtĂ« e angazhuar procesori nĂ« operacionet e disqeve. IOwait >10% â shkak pĂ«r shqetĂ«sim, megjithatĂ« nĂ« serverĂ«t tanĂ« me profil tĂ« ngarkesĂ«s specifike ndodh qĂ« tĂ« jetĂ« stabilisht 40-50%, dhe kjo Ă«shtĂ« vĂ«rtet normale.
Këtu do ta mbyll, megjithatë me siguri ka shumë momente me të cilat na është dashur të përballemi, do të pres me kënaqësi komentet dhe përshkrimet e rasteve interesante reale.
Burimi: habr.com
