મોટી સંખ્યામાં નાની ફાઇલો સાથે કામ કરવા માટે હેક્સ

લેખ માટેનો વિચાર લેખ પરની ટિપ્પણીઓમાંની ચર્ચામાંથી સ્વયંભૂ જન્મ્યો હતો "ઇનોડ વિશે કંઈક".

હકીકત એ છે કે અમારી સેવાઓની આંતરિક વિશિષ્ટતા એ મોટી સંખ્યામાં નાની ફાઇલોનો સંગ્રહ છે. આ ક્ષણે અમારી પાસે આવા સેંકડો ટેરાબાઇટ ડેટા છે. અને અમે કેટલાક સ્પષ્ટ અને એટલા સ્પષ્ટ ન હોય તેવા રેક્સ મળ્યા અને સફળતાપૂર્વક તેમની શોધખોળ કરી.

તેથી, હું અમારો અનુભવ શેર કરી રહ્યો છું, કદાચ તે કોઈને ઉપયોગી થશે.

સમસ્યા એક: "ઉપકરણ પર કોઈ જગ્યા બાકી નથી"

ઉપરોક્ત લેખમાં જણાવ્યા મુજબ, સમસ્યા એ છે કે ફાઇલ સિસ્ટમ પર મફત બ્લોક્સ છે, પરંતુ inode સમાપ્ત થઈ ગયું છે.

તમે આદેશ વડે વપરાયેલ અને ફ્રી ઇનોડ્સની સંખ્યા ચકાસી શકો છો df -ih:

હું લેખને ફરીથી કહીશ નહીં; ટૂંકમાં, ડિસ્કમાં ડેટા માટેના બંને બ્લોક્સ અને મેટા-માહિતી માટેના બ્લોક્સ છે, જેને inodes (ઇન્ડેક્સ નોડ) તરીકે પણ ઓળખવામાં આવે છે. જ્યારે ફાઇલ સિસ્ટમ શરૂ થાય ત્યારે તેમની સંખ્યા સેટ કરવામાં આવે છે (અમે ext2 અને તેના અનુગામીઓ વિશે વાત કરી રહ્યા છીએ) અને વધુ બદલાતું નથી. ડેટા બ્લોક્સ અને ઇનોડ્સનું સંતુલન સરેરાશ આંકડાકીય ડેટામાંથી ગણવામાં આવે છે, પરંતુ અમારા કિસ્સામાં, જ્યારે ઘણી નાની ફાઇલો હોય છે, ત્યારે સંતુલન ઇનોડ્સની સંખ્યા તરફ વળવું જોઈએ - તેમાં વધુ હોવા જોઈએ.

Linux પહેલાથી જ વિવિધ બેલેન્સ સાથે વિકલ્પો પૂરા પાડે છે, અને આ તમામ પૂર્વ-ગણતરી રૂપરેખાંકનો ફાઇલમાં છે /etc/mke2fs.conf.
તેથી, mke2fs મારફતે ફાઈલ સિસ્ટમના પ્રારંભિક આરંભ દરમિયાન, તમે ઇચ્છિત રૂપરેખાને સ્પષ્ટ કરી શકો છો.

અહીં ફાઇલમાંથી કેટલાક ઉદાહરણો છે:

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

    big = {
        inode_ratio = 32768
    }

    largefile = {
        inode_ratio = 1048576
        blocksize = -1
    }

mke2fs ને કૉલ કરતી વખતે તમે “-T” વિકલ્પનો ઉપયોગ કરીને ઇચ્છિત ઉપયોગ કેસ પસંદ કરી શકો છો. જો કોઈ તૈયાર સોલ્યુશન ન હોય તો તમે મેન્યુઅલી જરૂરી પરિમાણો પણ સેટ કરી શકો છો.

વધુ વિગતો માટે માર્ગદર્શિકાઓમાં વર્ણવેલ છે mke2fs.conf и mke2fs.

ઉપરોક્ત લેખમાં એક વિશેષતા જેને સ્પર્શવામાં આવી નથી તે એ છે કે તમે ડેટા બ્લોકનું કદ સેટ કરી શકો છો. દેખીતી રીતે, મોટી ફાઇલો માટે મોટા બ્લોક સાઇઝનો અર્થ થાય છે, નાની ફાઇલો માટે નાની ફાઇલનો અર્થ થાય છે.

જો કે, પ્રોસેસર આર્કિટેક્ચર જેવી રસપ્રદ સુવિધાને ધ્યાનમાં લેવી યોગ્ય છે.
મેં એકવાર વિચાર્યું કે મોટી ફોટો ફાઇલો માટે મને મોટા બ્લોક કદની જરૂર છે. તે ઘરે થયું, ARM આર્કિટેક્ચર પર WD નામના હોમ ફાઇલ સ્ટોર પર. ખચકાટ વિના, મેં અગાઉ બચત માપ્યા પછી, પ્રમાણભૂત 8k ને બદલે બ્લોકનું કદ 16k અથવા 4k પર સેટ કર્યું. અને સ્ટોરેજ પોતે નિષ્ફળ ન થાય ત્યાં સુધી બધું સારું હતું, અને ડિસ્ક હજી જીવંત હતી. નિયમિત ઇન્ટેલ પ્રોસેસર સાથે નિયમિત કમ્પ્યુટરમાં ડિસ્ક ઇન્સ્ટોલ કર્યા પછી, મને આશ્ચર્ય થયું: એક અસમર્થિત બ્લોક કદ. અમે પહોંચી ગયા છીએ. ડેટા ત્યાં છે, બધું સારું છે, પરંતુ તે વાંચવું અશક્ય છે. i386 અને સમાન પ્રોસેસર્સ બ્લોક માપો સાથે કામ કરી શકતા નથી જે મેમરી પૃષ્ઠના કદને અનુરૂપ નથી, જે બરાબર 4k છે. સામાન્ય રીતે, યુઝર સ્પેસમાંથી યુટિલિટીઝના ઉપયોગ સાથે આ બાબતનો અંત આવ્યો, બધું ધીમું અને ઉદાસી હતું, પરંતુ ડેટા સાચવવામાં આવ્યો હતો. જો કોઈને રસ હોય, તો યુટિલિટીનું નામ ગૂગલ કરો fuseext2. નૈતિક: કાં તો તમામ કેસોનો અગાઉથી વિચાર કરો, અથવા સુપરહીરો હોવાનો ડોળ ન કરો અને ગૃહિણીઓ માટે માનક સેટિંગ્સનો ઉપયોગ કરો.

યુપીડી. વપરાશકર્તા ટિપ્પણી અનુસાર બેરેઝ હું સ્પષ્ટ કરવા માંગુ છું કે i386 માટે બ્લોકનું કદ 4k કરતાં વધુ ન હોવું જોઈએ, પરંતુ તે બરાબર 4k હોવું જરૂરી નથી, એટલે કે. 1k અને 2k સ્વીકાર્ય છે.

તો, અમે સમસ્યાઓ કેવી રીતે હલ કરી?

સૌપ્રથમ, જ્યારે મલ્ટિ-ટેરાબાઇટ ડિસ્ક ડેટાથી ભરેલી હોય ત્યારે અમને સમસ્યા આવી, અને અમે ફાઇલ સિસ્ટમ ગોઠવણીને બદલી શક્યા નહીં.

બીજું, તાત્કાલિક ઉકેલની જરૂર હતી.

પરિણામે, અમે નિષ્કર્ષ પર આવ્યા કે અમારે ફાઇલોની સંખ્યા ઘટાડીને સંતુલન બદલવાની જરૂર છે.
ફાઇલોની સંખ્યા ઘટાડવા માટે, ફાઇલોને એક સામાન્ય આર્કાઇવમાં મૂકવાનો નિર્ણય લેવામાં આવ્યો હતો. અમારી વિશિષ્ટતાઓને ધ્યાનમાં રાખીને, અમે ચોક્કસ સમયગાળાની બધી ફાઇલોને એક આર્કાઇવમાં મૂકીએ છીએ, અને દરરોજ રાત્રે ક્રોન ટાસ્કનો ઉપયોગ કરીને આર્કાઇવિંગ હાથ ધરીએ છીએ.

પસંદ કરેલ ઝિપ આર્કાઇવ. અગાઉના લેખની ટિપ્પણીઓમાં, ટાર સૂચવવામાં આવ્યું હતું, પરંતુ તેની સાથે એક મુશ્કેલી છે: તેમાં સમાવિષ્ટોનું કોષ્ટક નથી, અને તેમાંની ફાઇલો સ્ટ્રીમમાં સંગ્રહિત છે (તે માત્ર એટલું જ નથી કે "ટાર" એ સંક્ષેપ છે. “ટેપ આર્કાઇવ” માટે, ટેપ ડ્રાઇવનો વારસો), એટલે કે . જો તમારે આર્કાઇવના અંતે ફાઇલ વાંચવાની જરૂર હોય, તો તમારે સંપૂર્ણ આર્કાઇવ વાંચવાની જરૂર છે, કારણ કે તેમાં આર્કાઇવની શરૂઆતમાં સંબંધિત દરેક ફાઇલ માટે ઑફસેટ્સ શામેલ નથી. અને તેથી તે એક લાંબી કામગીરી છે. ઝિપમાં બધું વધુ સારું છે: તે આર્કાઇવમાં સમાવિષ્ટો અને ફાઇલ ઑફસેટ્સનું સમાન કોષ્ટક ધરાવે છે, અને દરેક ફાઇલનો ઍક્સેસ સમય તેના સ્થાન પર આધારિત નથી. ઠીક છે, અમારા કિસ્સામાં, કમ્પ્રેશન વિકલ્પને "0" પર સેટ કરવાનું શક્ય હતું, કારણ કે બધી ફાઇલો પહેલેથી જ gzip માં સંકુચિત હતી.

ક્લાયંટ nginx દ્વારા ફાઇલો પુનઃપ્રાપ્ત કરે છે, અને જૂના API અનુસાર, ફક્ત ફાઇલનું નામ ઉલ્લેખિત છે, ઉદાહરણ તરીકે આના જેવું:

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

ફ્લાય પર ફાઇલોને અનપૅક કરવા માટે, અમે nginx-unzip-module મોડ્યુલ શોધી અને કનેક્ટ કર્યું (https://github.com/youzee/nginx-unzip-module) અને બે અપસ્ટ્રીમ સેટ કરો.

પરિણામ નીચેની ગોઠવણી હતી:

સેટિંગ્સમાં બે હોસ્ટ આના જેવા દેખાતા હતા:

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;
  }
}

અને અપસ્ટ્રીમ nginx પર અપસ્ટ્રીમ રૂપરેખાંકન:

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

તે કેવી રીતે કામ કરે છે:

• ક્લાયંટ ફ્રન્ટ nginx પર જાય છે
• ફ્રન્ટ nginx પ્રથમ અપસ્ટ્રીમથી ફાઇલને સેવા આપવાનો પ્રયાસ કરે છે, એટલે કે. સીધા ફાઇલ સિસ્ટમમાંથી
• જો ત્યાં કોઈ ફાઇલ ન હોય, તો તે બીજા અપસ્ટ્રીમમાંથી મોકલવાનો પ્રયાસ કરે છે, જે આર્કાઇવની અંદર ફાઇલ શોધવાનો પ્રયાસ કરે છે.

સમસ્યા બે: ફરીથી "ઉપકરણ પર કોઈ જગ્યા બાકી નથી"

જ્યારે ડિરેક્ટરીમાં ઘણી બધી ફાઈલો હોય ત્યારે આ બીજી સમસ્યાનો સામનો કરવો પડે છે.
અમે ફાઇલ બનાવવાનો પ્રયાસ કરી રહ્યા છીએ, જગ્યા ન હોવાની તંત્ર ફરિયાદ કરે છે. અમે ફાઇલનું નામ બદલીએ છીએ અને તેને ફરીથી બનાવવાનો પ્રયાસ કરીએ છીએ.

તે બહાર વળે છે.

તે આના જેવું કંઈક દેખાય છે:

ઇનોડ્સ તપાસવાથી કંઈ મળ્યું નથી - ત્યાં ઘણા મફત છે.
લોકેશન તપાસવું એ જ છે.
અમે વિચાર્યું કે ડિરેક્ટરીમાં ઘણી બધી ફાઈલો હોઈ શકે છે, અને તેના પર મર્યાદા છે, પરંતુ ફરીથી કોઈ: ડિરેક્ટરી દીઠ ફાઇલોની મહત્તમ સંખ્યા: ~1.3 × 10^20

હા, અને જો તમે નામ બદલો તો તમે ફાઇલ બનાવી શકો છો.
નિષ્કર્ષ - સમસ્યા ફાઇલના નામમાં છે.

વધુ શોધો દર્શાવે છે કે ડિરેક્ટરી ઇન્ડેક્સ બનાવતી વખતે સમસ્યા હેશિંગ અલ્ગોરિધમમાં છે; મોટી સંખ્યામાં ફાઇલો સાથે, તમામ આગામી પરિણામો સાથે અથડામણ જોવા મળે છે. તમે અહીં વધુ વિગતો વાંચી શકો છો: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Hash_Tree_Directories

તમે આ વિકલ્પને નિષ્ક્રિય કરી શકો છો, પરંતુ... બધી ફાઇલોમાં શોધ કરતી વખતે નામ દ્વારા ફાઇલની શોધ અણધારી રીતે લાંબી બની શકે છે.

 tune2fs -O "^dir_index" /dev/sdb3

સામાન્ય રીતે, આ એક અસ્થાયી ઉકેલ છે જે કામ કરી શકે છે.

નૈતિક: ડિરેક્ટરીમાં ઘણી બધી ફાઇલો સામાન્ય રીતે ખરાબ વસ્તુ છે. આવું કરવાની કોઈ જરૂર નથી.

સામાન્ય રીતે આવા કિસ્સાઓમાં, નેસ્ટેડ ડિરેક્ટરીઓ ફાઇલના નામના પ્રથમ અક્ષરો દ્વારા અથવા કેટલાક અન્ય પરિમાણો દ્વારા બનાવવામાં આવે છે, ઉદાહરણ તરીકે, તારીખો દ્વારા, મોટાભાગના કિસ્સાઓમાં આ દિવસને બચાવે છે.
પરંતુ નાની ફાઇલોની કુલ સંખ્યા હજુ પણ ખરાબ છે, ભલે તે ડિરેક્ટરીઓમાં વિભાજિત હોય - પછી પ્રથમ સમસ્યા જુઓ.

સમસ્યા ત્રણ: ફાઇલોની સૂચિ કેવી રીતે જોવી જો તેમાંની ઘણી હોય

અમારી પરિસ્થિતિમાં, જ્યારે અમારી પાસે ઘણી બધી ફાઈલો હોય છે, ત્યારે એક યા બીજી રીતે અમે નિર્દેશિકાની સામગ્રીને કેવી રીતે જોવી તેની સમસ્યાનો સામનો કરવો પડ્યો.

પ્રમાણભૂત ઉકેલ - આદેશ ls.
ઓકે, ચાલો જોઈએ કે 4772098 ફાઈલો પર શું થાય છે:

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

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

30 સેકન્ડ... ખૂબ વધારે હશે. તદુપરાંત, મોટાભાગનો સમય યુઝર સ્પેસમાં ફાઈલોની પ્રક્રિયા કરવામાં ખર્ચવામાં આવે છે, અને કર્નલની કામગીરી પર બિલકુલ નહીં.

પરંતુ ત્યાં એક ઉકેલ છે:

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

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

3 સેકન્ડ. 10 ગણી ઝડપી.
હુરે!

યુ.પી.ડી.

વપરાશકર્તા તરફથી વધુ ઝડપી ઉકેલ બેરેઝ - વર્ગીકરણ અક્ષમ કરો ls

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

સમસ્યા ચાર: ફાઇલો સાથે કામ કરતી વખતે મોટી LA

સમય સમય પર એવી પરિસ્થિતિ ઊભી થાય છે જ્યારે તમારે એક મશીનથી બીજા મશીનમાં ફાઇલોના સમૂહની નકલ કરવાની જરૂર હોય છે. તે જ સમયે, એલએ ઘણીવાર અવાસ્તવિક રીતે વધે છે, કારણ કે બધું જ ડિસ્કના પ્રદર્શન પર આધારિત છે.

તમે જે સૌથી સ્માર્ટ વસ્તુ કરવા માંગો છો તે છે SSD નો ઉપયોગ કરવો. ખરેખર ઠંડી. એકમાત્ર પ્રશ્ન મલ્ટિ-ટેરાબાઇટ SSDs ની કિંમત છે.

પરંતુ જો ડિસ્ક સામાન્ય હોય, તો તમારે ફાઇલોની નકલ કરવાની જરૂર છે, અને આ એક પ્રોડક્શન સિસ્ટમ પણ છે, જ્યાં ઓવરલોડ ક્લાયંટ તરફથી અસંતુષ્ટ ઉદ્ગારો તરફ દોરી જાય છે? ઓછામાં ઓછા બે ઉપયોગી સાધનો છે: nice и ionice.

nice — પ્રક્રિયાની પ્રાધાન્યતા ઘટાડે છે, તે મુજબ શેડ્યૂલર અન્ય, ઉચ્ચ અગ્રતા પ્રક્રિયાઓ માટે વધુ સમયના ટુકડાઓનું વિતરણ કરે છે.
અમારી પ્રેક્ટિસમાં, તે મહત્તમ (19 એ ન્યૂનતમ અગ્રતા છે, -20 (માઈનસ 20) મહત્તમ છે) પર સરસ સેટ કરવામાં મદદ કરે છે.

ionice - તે મુજબ I/O શેડ્યુલિંગને સમાયોજિત કરે છે

જો તમે RAID નો ઉપયોગ કરી રહ્યા છો અને તેને અચાનક સિંક્રનાઇઝ કરવાની જરૂર છે (અસફળ રીબૂટ પછી અથવા તમારે ડિસ્ક બદલ્યા પછી RAID એરેને પુનઃસ્થાપિત કરવાની જરૂર છે), તો કેટલીક પરિસ્થિતિઓમાં સિંક્રનાઇઝેશનની ઝડપ ઘટાડવાનો અર્થ થાય છે જેથી અન્ય પ્રક્રિયાઓ વધુ કાર્ય કરી શકે. અથવા ઓછા પ્રમાણમાં. નીચેનો આદેશ આ માટે મદદ કરશે:

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

પાંચમી સમસ્યા: રીઅલ-ટાઇમમાં ફાઇલોને કેવી રીતે સિંક્રનાઇઝ કરવી

અમારી પાસે હજી પણ એટલી જ મોટી સંખ્યામાં ફાઈલો છે કે જેને ટાળવા માટે બીજા સર્વર પર બેકઅપ લેવાની જરૂર છે... ફાઈલો સતત લખાઈ રહી છે, તેથી ન્યૂનતમ નુકસાન થવા માટે, તમારે શક્ય તેટલી ઝડપથી તેમની નકલ કરવાની જરૂર છે.

માનક ઉકેલ: SSH પર Rsync.

આ એક સારો વિકલ્પ છે સિવાય કે તમારે તેને દર થોડીક સેકન્ડમાં કરવાની જરૂર હોય. અને ત્યાં ઘણી બધી ફાઇલો છે. જો તમે તેમની નકલ ન કરો તો પણ, તમારે હજી પણ કોઈક રીતે સમજવાની જરૂર છે કે શું બદલાયું છે, અને ઘણી મિલિયન ફાઇલોની તુલના કરવામાં સમય લાગે છે અને ડિસ્ક પર લોડ થાય છે.

તે. દર વખતે સરખામણી કર્યા વિના, આપણે તરત જ જાણવાની જરૂર છે કે શું નકલ કરવાની જરૂર છે.

બચાવ - lsyncd. Lsyncd - લાઇવ સિંકિંગ (મિરર) ડિમન. તે rsync દ્વારા પણ કામ કરે છે, પરંતુ વધારામાં inotify અને fsevens નો ઉપયોગ કરીને ફેરફારો માટે ફાઇલ સિસ્ટમનું નિરીક્ષણ કરે છે અને ફક્ત તે ફાઇલોની નકલ કરવાનું શરૂ કરે છે જે દેખાય છે અથવા બદલાઈ છે.

સમસ્યા છ: ડિસ્કને કોણ લોડ કરી રહ્યું છે તે કેવી રીતે સમજવું

દરેક વ્યક્તિ કદાચ આ જાણે છે, પરંતુ તેમ છતાં, ચિત્ર પૂર્ણ કરવા માટે: ડિસ્ક સબસિસ્ટમને મોનિટર કરવા માટે એક આદેશ છે iotop - જેમ top, પરંતુ તે પ્રક્રિયાઓ દર્શાવે છે જે ડિસ્કનો સૌથી વધુ સક્રિય રીતે ઉપયોગ કરી રહી છે.

માર્ગ દ્વારા, સારી જૂની ટોચ તમને એ સમજવા માટે પણ પરવાનગી આપે છે કે ડિસ્કમાં કોઈ સમસ્યા છે કે નહીં. આ માટે બે સૌથી યોગ્ય વિકલ્પો છે: લોડ એવરેજ и રાહ જુઓ.

પ્રથમ બતાવે છે કે સેવા માટે કતારમાં કેટલી પ્રક્રિયાઓ છે, સામાન્ય રીતે 2 થી વધુ - કંઈક પહેલેથી જ ખોટું થઈ રહ્યું છે. જ્યારે સક્રિયપણે બેકઅપ સર્વર્સ પર નકલ કરીએ છીએ, ત્યારે અમે 6-8 સુધીની મંજૂરી આપીએ છીએ, જે પછી પરિસ્થિતિને અસામાન્ય ગણવામાં આવે છે.

બીજું એ છે કે પ્રોસેસર ડિસ્ક ઓપરેશનમાં કેટલું વ્યસ્ત છે. IOwait>10% એ ચિંતાનું કારણ છે, જો કે ચોક્કસ લોડ પ્રોફાઇલવાળા અમારા સર્વર્સ પર તે સતત 40-50% છે, અને આ ખરેખર ધોરણ છે.

હું અહીં સમાપ્ત કરીશ, જો કે સંભવતઃ એવા ઘણા મુદ્દાઓ છે જેનો આપણે સામનો કરવો પડ્યો નથી, મને ટિપ્પણીઓ અને રસપ્રદ વાસ્તવિક કેસોના વર્ણનની રાહ જોવામાં આનંદ થશે.

સોર્સ: www.habr.com