Ideja e artikullit lindi spontanisht nga një diskutim në komentet e një artikulli. .
Problemi është se specifika e brendshme e funksionimit të shërbimeve tona është ruajtja e një numri të madh të skedarëve të vegjël. Aktualisht, ne kemi rreth qindra terabajt të tillë të dhënash. Dhe ne u ndeshëm me disa pengesa të qarta dhe jo shumë të qarta dhe i kaluam ato me sukses.
Prandaj, po ndaj pĂ«rvojĂ«n tonĂ«, ndoshta do tâi vijĂ« nĂ« ndihmĂ« dikujt.
Problemi i parë: «Nuk ka hapësirë të lirë në pajisje»
Siç u përmend në artikullin e mësipërm, problemi është se ka blloqe të lira në sistemin e skedarëve, por inodes kanë përfunduar.
Të kontrolloni numrin e inodes të përdorura dhe të lira mund të bëhet me komandën df -ih:
Nuk do ta përmbledh artikullin, nëse do ta shpjegojmë shkurt, disk ka si blloqe për të dhënat ashtu edhe blloqe për metainformacionin, të njohura si inodes (indeksi i nodit). Numri i tyre përcaktohet gjatë fillimit të sistemit të skedarëve (në këtë rast flasim për ext2 dhe pasardhësit e saj) dhe më pas nuk ndryshon. Balanca e blloqeve të të dhënave dhe inodes llogaritet nga të dhënat mesatare, në rastin tonë, ku ka shumë skedarë të vegjël, balanca duhet të zhvendoset në favor të numrit të inodes - ato duhet të jenë më shumë.
Në Linux tashmë janë parashikuar variante me balancë të ndryshme, dhe të gjitha këto konfigurime të paracaktuara ndodhen në skedarin /etc/mke2fs.conf.
Prandaj, gjatë fillimit të sistemit të skedarëve me mke2fs mund të specifikoni profilin e duhur.
Ja disa shembuj nga skedari:
small = {
blocksize = 1024
inode_size = 128
inode_ratio = 4096
}
big = {
inode_ratio = 32768
}
largefile = {
inode_ratio = 1048576
blocksize = -1
}
Për të zgjedhur variantin e duhur të përdorimit mund të përdorni opsionin «-T» gjatë thirrjes së mke2fs. Gjithashtu, mund të vendosni 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ë veçori e papërmendur në artikullin e mësipërm është se mund të vendosni madhësinë e bllokut të të dhënave. Sigurisht, për skedarët e mëdhenj ka kuptim të ketë një madhësi më të madhe blloku, ndërsa për skedarët e vegjël një madhësi më të vogël.
Megjithatë, duhet t'i kushtoni vëmendje një veçorie interesante si arkitektura e procesorit.
Njëherë m'u duk se për skedarët e mëdhenj të fotografive, kisha nevojë për një madhësi blloku më të madhe. Ajo ndodhi në kushte shtëpiake, në një ruajtës të dhënash WD me arkitekturë ARM. Unë, pa menduar shumë, vendosa madhësinë e bllokut 8k ose 16k në vend të standardit 4k, pas matjeve të kursimeve. Dhe gjithçka ishte mirë deri në momentin kur ruajtësi vetë dështoi, kur disku ishte funksional. Pas vendosjes së diskut në një kompjuter të zakonshëm me procesor të zakonshëm Intel, përballa një surprizë: madhësi blloku e paparamenduar. U bënë shumë të vështira. Të dhënat ishin aty, gjithçka ishte në rregull, por nuk mund të lexohej. Procesorët i386 dhe të ngjashëm nuk dinë të punojnë me madhësi bllokesh që nuk përputhen me madhësinë e faqes së memories, që është 4k. Në përgjithësi, u desh të përdorja utilitarët nga hapësira e përdoruesit, gjithçka ishte ngadalë dhe e trishtueshme, por të dhënat u shpëtuan. Për ata që janë të interesuar - kërkoni me emrin e utilitarit fuseext2. Moral: ose mendoni për të gjitha rastet paraprakisht, ose mos u bëni superheronj dhe përdorni cilësimet standarde për shtëpiakët.
UPD. Sipas vërejtjes së përdoruesit sqaroj se për i386 madhësia e bllokut nuk duhet të kalojë 4k, por nuk duhet domosdoshmërisht të jetë saktësisht 4k, pra janë të pranuar 1k dhe 2k.
Pra, si e zgjidhëm ne problemin.
Së pari, u përballëm me problemin kur disku shumë terabajt ishte i mbushur me të dhëna, dhe ne nuk mund të rregullonim konfigurimin e sistemit të skedarëve.
Së dyti, vendimi kishte nevojë për një zgjidhje të menjëhershme.
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ë mbledhim skedarët në një arkiv të vetëm. Duke marrë parasysh specifikën tonë, ne grumbulluam në një arkiv të vetëm të gjitha skedarët për një periudhë të caktuar, dhe realizuam arkivimin me një punë cron çdo natë.
Zgjedhim arkivin zip. Në komentet e artikullit të mëparshëm ishte propozuar tar, por kjo ka një vështirësi: ai nuk ka një përmbajtje, dhe skedarët atje janë në një rend të vazhdueshëm (nuk është rastësi që «tar» është një shkurtim për «Tape Archive», trashëgimi e ruajtësve të bandë), dmth. nëse duhet të lexoni një skedar në fund të arkivit - duhet të lexoni ose të gjithë arkivin, pasi atje nuk ka devijimesh për çdo skedar nga fillimi i arkivit. Prandaj, kjo është një operacion i gjatë. Në zip gjithçka është shumë më mirë: ai ka atë përmbajtje dhe devijimet e skedarëve brenda arkivit, dhe koha e aksesit në çdo skedar nuk varet nga pozita e tij. Dhe në rastin tonë mund të vendosim opsionin e comprimit në «0», sepse të gjithë skedarët tashmë ishin kompresuar në gzip.
Klientët marrin skedarët përmes nginx, dhe sipas API të vjetër, thjesht tregohet emri i skedarit, për shembull kështu:
http://www.server.com/hydra/20170416/0453/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5
Për të shpërthyer skedarët në flukse, gjetëm dhe lidhëm modul nginx-unzip-module () dhe konfiguruam dy upstreams.
Si rezultati, konfigurimi është i tillë:
Dy hostet në konfigurim duken si më poshtë:
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-it në nginx-in më të lartë:
upstream storage {
server server.com:8081;
server server.com:8082;
}
Si funksionon:
- Klienti shkon te front nginx
- Front nginx përpiqet të dorëzojë skedarin nga upstream-i i parë, dmth direkt nga sistemi i skedarëve
- NĂ«se skedari nuk ekziston â pĂ«rpiqet tĂ« dorĂ«zojĂ« nga upstream-i i dytĂ«, i cili pĂ«rpiqet tĂ« gjejĂ« skedarin brenda arkivit
Problemi i dytë: përsëri "Nuk ka hapësirë të majtë në pajisje"
Ky është problemi i dytë me të cilin u përballëm kur kishte shumë skedarë në katalog.
Përpiqemi të krijojmë një skedar, sistemi ankohet se s'ka vend. Ndryshojmë emrin e skedarit dhe sërish përpiqemi ta krijojmë.
Dhe ja, funksionon.
Duket përafërsisht kështu:
Kontrolli i inodes nuk dha asgjĂ« â ka shumĂ« tĂ« lirĂ«.
Kontrolli i hapĂ«sirĂ«s â e njĂ«jta gjĂ«.
Mendojmë se ndoshta ka shumë skedarë në katalog, dhe për këtë ka një kufizim, por përsëri jo: Maksimumi i numrit të skedarëve për katalog: ~1.3 à 10^20
Dhe gjithashtu, skedari mund të krijohet nëse ndryshojmë emrin.
PĂ«rfundimi â problemi Ă«shtĂ« te emri i skedarit.
Kërkimet e mëtejshme treguan se problemi ishte te algoritmi i hash-it gjatë ndërtimit të indeksit të katalogut, kur numri i madh i skedarëve rezulton në kolizione dhe pasojat përkatëse. Më shumë detaje mund të lexoni këtu:
Mund ta çaktivizoni këtë opsion, por⊠kërkimi i skedarit sipas emrit mund të bëhet papritur shumë i gjatë kur kaloni të gjithë skedarët.
tune2fs -O "^dir_index" /dev/sdb3
Në përgjithësi, si një zgjidhje e përkohshme, mund të funksionojë.
Morali: shumĂ« skedarĂ« nĂ« katalog â zakonisht Ă«shtĂ« e keqe. KĂ«shtu nuk duhet tĂ« bĂ«het.
Zakonsht në raste të tilla 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 i pĂ«rgjithshĂ«m i skedarĂ«ve tĂ« vegjĂ«l â Ă«shtĂ« ende e keqe, edhe nĂ«se i ndajmĂ« 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ë, në një mënyrë ose tjetër hasim problemin se si të shohim përmbajtjen e katalogut.
Zgjidhja standarde â komandat ls.
Ok, le të shohim se çfarë rezultati kemi 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 për përpunimin e skedarëve në hapësirën e përdoruesit, dhe jo për punën 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ë shpejt.
Hurrah!
UPD.
NjĂ« zgjidhje edhe mĂ« e shpejtĂ« nga pĂ«rdoruesi â çaktivizimi i renditjes nĂ« 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 i madh kur punoni me skedarët
Periodikisht ndodhin situata ku duhet të kopjosh shumë skedarë nga një makinë në një tjetër. Në këtë proces, shpesh rritet ndjeshëm LA, pasi gjithçka varet nga performanca e diskëve.
Më e mençur do të ishte të përdorim SSD. Në të vërtetë e mrekullueshme. Pyetja është vetëm për çmimin e SSD-ve shumë terabajt.
Por nëse diskët janë të zakonshëm, duhet të kopjosh skedarët, dhe gjithashtu kjo është një sistem prodhimi, ku ngarkesa shkakton pakënaqësi nga klientët? Ka të paktën dy mjete të dobishme: nice dhe ionice.
nice â ul prioritetin e procesit, duke dhĂ«nĂ« kĂ«shtu mĂ« shumĂ« kohĂ« tĂ« nevojshme pĂ«r proceset mĂ« prioritare.
NĂ« praktikĂ«n tonĂ« ka ndihmuar tĂ« vendosim nice nĂ« maksimum (19 â Ă«shtĂ« prioriteti minimal, -20 (minus 20) â prioriteti maksimal).
ionice â pĂ«rmirĂ«son prioritetin e input/output (I/O scheduling)
Nëse po përdorni RAID dhe ai ka nevojë të sinkronizohet papritur (pas një rimbushjeje të dështuar ose për të rikuperuar një grup RAID pas zëvendësimit të një disku), atëherë në disa situata ka kuptim të zvogëloni shpejtësinë e sinkronizimit, në mënyrë që proceset e tjera të mund të funksionojnë më lëvizshëm. Një komandë 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ëjtin numër të madh skedarësh, të cilët duhet të bëhen backup në një server të dytë për të shmangur⊠Skedarët shkruhen vazhdimisht, kështu që, për të minimizuar humbjet, duhet t'i kopjoni sa më shpejt të jetë e mundur.
Zgjidhja standarde: Rsync mbi SSH.
Ky Ă«shtĂ« njĂ« opsion i mirĂ«, pĂ«rveç nĂ«se kjo nuk duhet bĂ«rĂ« çdo disa sekonda. Edhe nĂ«se nuk i kopjon, duhet gjithsesi tĂ« kuptosh se çfarĂ« Ă«shtĂ« ndryshuar, dhe tĂ« krahasosh disa miliona skedarĂ« â Ă«shtĂ« kohĂ« dhe ngarkesĂ« nĂ« disqe.
Që do të thotë, na duhet të dimë menjëherë se çfarë duhet të kopjohet, pa filluar të krahasojmë çdo herë.
ShpĂ«timi Ă«shtĂ« lsyncd. Lsyncd â . Ai punon gjithashtu pĂ«rmes rsync, por pĂ«rveç kĂ«saj monitoron sistemin e skedarĂ«ve pĂ«r ndryshime duke pĂ«rdorur inotify dhe fsevents dhe fillon kopjimin vetĂ«m pĂ«r ata skedarĂ« qĂ« kanĂ« lindur ose ndryshuar.
Problemi i gjashtë: si të kuptohet kush po ngarkon disqet
Mendoj se tĂ« gjithĂ« e dinĂ« kĂ«tĂ«, por megjithatĂ« pĂ«r plotĂ«sinĂ« e pictures: pĂ«r monitorimin e sistemit tĂ« diskĂ«ve ka njĂ« komandĂ« iotop â tĂ« ngjashme me top, por qĂ« tregon proceset qĂ« po pĂ«rdorin disqet mĂ« aktivisht.
Për më tepër, i vjetër dhe i njohur top gjithashtu lejon të kuptohet nëse ka probleme me disqet ose jo. Për këtë, ka dy parametra më të përshtatshëm: Load Average dhe IOwait.
E para tregon se sa procese qĂ«ndrojnĂ« nĂ« radhĂ« pĂ«r shĂ«rbim, zakonisht mĂ« shumĂ« se 2 â do tĂ« thotĂ« qĂ« diçka nuk Ă«shtĂ« nĂ« rregull. GjatĂ« kopjimit aktiv nĂ« serverĂ«t e backup-it, ne lejojmĂ« deri nĂ« 6-8, pas kĂ«saj situata konsiderohet e jashtĂ«zakonshme.
E dyta â sa Ă«shtĂ« e zĂ«nĂ« procesori me operacionet e diskĂ«ve. IOwait >10% â arsye pĂ«r shqetĂ«sim, megjithatĂ« nĂ« serverĂ«t tanĂ« me profil ngarkese specifik, ndonjĂ«herĂ« qĂ«ndron rregullisht nĂ« 40-50%, dhe kjo Ă«shtĂ« vĂ«rtet normale.
Këtu do ta ndaloj, megjithatë sigurisht ka shumë aspekte që nuk na kanë ndodhur, me kënaqësi do të pres komente dhe përshkrime të rasteve interesante.
Burimi: habr.com
