I dag vill vi berĂ€tta om nĂ„gra av de senaste uppdateringarna av Sherlock-systemet [detta Ă€r en högpresterande kluster frĂ„n Stanford University â anm. red.], som avsevĂ€rt snabbar upp listningen av filer i kataloger med mĂ„nga poster.
Till skillnad frÄn vanliga artiklar Àr detta snarare en insiderrapport om hur det dagliga arbetet med Sherlock gÄr till för att hÄlla det i bÀsta skick för vÄra anvÀndare. Vi hoppas kunna publicera fler sÄdana artiklar i framtiden.
Listning av mÄnga filer tar tid
Det hela började med en frĂ„ga till supporten frĂ„n en anvĂ€ndare. Han rapporterade ett problem dĂ€r körningen ls tar flera minuter i en katalog med mer Ă€n 15 000 poster i $SCRATCH [katalog för temporĂ€ra filer â anm. red.].
Tusentals filer i en och samma katalog skapar vanligtvis problem för filsystemet och detta rekommenderas definitivt inte. AnvÀndaren visste detta och erkÀnde att det inte var bra, men nÀmnde att pÄ hans laptop gÄr listningen 1000 gÄnger snabbare Àn i Sherlock. Naturligtvis berörde det oss. DÀrför granskade vi saken nÀrmare.
För ls ser snyggt ut
Vi granskade vad som faktiskt görs ls vid listning av kataloger, och varför processen tar sÄ mycket tid. I de flesta moderna distributioner ls utförs som standard ls --color=auto, för alla gillar fÀrger.
Men de vackra fÀrgerna har ett pris: för varje fil ls mÄste information om filtyp, behörigheter, flaggor, utökade attribut och liknande hÀmtas, för att vÀlja rÀtt fÀrg.
En av de enkla lösningarna pÄ problemet Àr att helt enkelt stÀnga av fÀrg i ls, men förestÀll dig anvÀndarnas upprördhet. Absolut inte att ta bort den fÀrgglada utskriften, vi Àr inte monster.
DÀrför granskade vi saken nÀrmare. ls fÀrgar poster via miljövariabeln LS_COLORS, som sÀtts av dircolors(1) baserat pÄ konfigurationsfilen dir_colors(5). Ja,den körbara filen lÀser konfigurationsfilen för att skapa en miljövariabel, som sedan anvÀnds av ls door , oavsett vad). För att ta reda pÄ vilken av fÀrgscheman som orsakar fördröjningen skapade vi en experimentell miljö:
LÄt oss gÄ in pÄ detaljerna
För att avgöra vilken av fÀrgscheman som orsakar fördröjning har vi skapat en experimentell miljö:
$ mkdir $SCRATCH/dont
$ touch $SCRATCH/dont/{1..10000} # försök inte detta hemma!
$ time ls --color=always $SCRATCH/dont | wc -l
10000
real 0m12.758s
user 0m0.104s
sys 0m0.699s12,7 sekunder för 10 000 filer, inte sÄ bra.
Förresten, du behöver en flagga
--color=always: Àven om den omvÀnt blirls --color=auto, menlsupptÀcker det nÀr det inte Àr anslutet till terminalen (till exempel via en kanal eller med omdirigering av utdata) och stÀnger av fÀrgning om instÀllt vÀrdeauto. Smart kille.
SÄ vad tar sÄ lÄng tid? Vi kollade med för att kontrollera paketöverföringen Ät bÄda hÄll:
$ strace -c ls --color=always $SCRATCH/dont | wc -l
10000
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
44.21 0.186617 19 10000 lstat
42.60 0.179807 18 10000 10000 getxattr
12.19 0.051438 5 10000 capget
0.71 0.003002 38 80 getdents
0.07 0.000305 10 30 mmap
0.05 0.000217 12 18 mprotect
0.03 0.000135 14 10 read
0.03 0.000123 11 11 open
0.02 0.000082 6 14 close
[...] Oj dÄ: 10 000 anrop lstat(), 10 000 anrop getxattr() (som alla misslyckas eftersom det inte finns nÄgra attribut som ls letar efter i vÄr miljö), 10 000 anrop capget().
Det hÀr gÄr sÀkert att optimera.
Attributets möjligheter? Nej.
Enligt tipsen , försökte vi stÀnga av attributkontrollen :
$ eval $(dircolors -b | sed s/ca=[^:]*:/ca=:)
$ time strace -c ls --color=always $SCRATCH/dont | wc -l
10000
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
98.95 0.423443 42 10000 lstat
0.78 0.003353 42 80 getdents
0.04 0.000188 10 18 mprotect
0.04 0.000181 6 30 mmap
0.02 0.000085 9 10 read
0.02 0.000084 28 3 mremap
0.02 0.000077 7 11 open
0.02 0.000066 5 14 close
[...]
------ ----------- ----------- --------- --------- ----------------
100.00 0.427920 10221 6 total
real 0m8.160s
user 0m0.115s
sys 0m0.961s Wow, acceleration till 8 sekunder! Vi blev av med alla dessa dyra anrop getxattr(), och anrop capget() försvann ocksÄ, utmÀrkt.
Men fortfarande finns dessa irriterande anrop lstat(), Ă€ven omâŠ
Hur mÄnga fÀrger behövs?
DÀrför tittade vi nÀrmare pÄ LS_COLORS.
Först stÀngde vi bara av den hÀr variabeln:
$ echo $LS_COLORS rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36: $ unset LS_COLORS $ echo $LS_COLORS $ time ls --color=always $SCRATCH\/dont | wc -l 10000 real 0m13.037s user 0m0.077s sys 0m1.092s
Vad!?! Fortfarande 13 sekunder?
Det visar sig att nÀr miljövariabeln LS_COLORS inte Àr definierad eller saknar endast ett av sina element =color:, anvÀnder den som standard den inbyggda databasen och anvÀnder fortfarande fÀrger. SÄ om du vill stÀnga av fÀrgningen för en viss filtyp mÄste du ÄsidosÀtta den med =: eller 00 i filen DIR_COLORS.
Efter mÄnga försök och misstag har vi smalnat ner sökningen till detta:
EXEC 00
SETUID 00
SETGID 00
CAPABILITY 00som skrivs som
LS_COLORS='ex=00:su=00:sg=00:ca=00:' Det innebÀr: fÀrga inte filer baserat pÄ attribut , men baserat pÄ bitar , eller pÄ .
Vi accelererar ls
Och om ingen av dessa kontroller görs, försvinner anropen, och nu Àr saken helt annorlunda: lstat() $ export LS_COLORS='ex=00:su=00:sg=00:ca=00:' $ time strace -c ls --color=always $SCRATCH\/dont | wc -l 10000 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 63.02 0.002865 36 80 getdents 8.10 0.000368 12 30 mmap 5.72 0.000260 14 18 mprotect 3.72 0.000169 15 11 open 2.79 0.000127 13 10 read [...] ------ ----------- ----------- --------- --------- ---------------- 100.00 0.004546 221 6 totalreal 0m0.337s user 0m0.032s sys 0m0.029s
0,3 sekunder för att lista 10 000 filer, rekord.Konfigurerar Sherlock
FrÄn 13 sekunder med standardinstÀllningar till 0,3 sekunder med en liten justering
betyder 40 gÄnger snabbare tack vare avsaknaden av LS_COLORS setuid setgid / och fÀrgade exekverbara filer. Ingen stor förlust. och fÀrgade körbara filer. Inte en sÄ stor förlust.
SjÀlvklart, nu Àr detta instÀllt i Sherlock för varje anvÀndare.
Men om du vill ÄterfÄ fÀrgsÀttningen kan du bara ÄtergÄ till standardinstÀllningarna:
$ unset LS_COLORS Men dÄ, pÄ kataloger med mÄnga filer, se till att brygga kaffe medan det pÄgÄr. ls.
KĂ€lla: habr.com
