ധാരാളം ചെറിയ ഫയലുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നതിനുള്ള ഹാക്കുകൾ

ലേഖനത്തിലേക്കുള്ള അഭിപ്രായങ്ങളിലെ ചർച്ചയിൽ നിന്നാണ് ലേഖനത്തിനുള്ള ആശയം സ്വയമേവ ജനിച്ചത് "ഇനോഡിനെക്കുറിച്ച് ചിലത്".

ഞങ്ങളുടെ സേവനങ്ങളുടെ ആന്തരിക സവിശേഷത ഒരു വലിയ എണ്ണം ചെറിയ ഫയലുകളുടെ സംഭരണമാണ് എന്നതാണ് വസ്തുത. നിലവിൽ നൂറുകണക്കിന് ടെറാബൈറ്റ് ഡാറ്റ ഞങ്ങളുടെ പക്കലുണ്ട്. കൂടാതെ വ്യക്തവും അത്ര വ്യക്തമല്ലാത്തതുമായ ചില റേക്കുകൾ ഞങ്ങൾ കാണുകയും അവ വിജയകരമായി നാവിഗേറ്റ് ചെയ്യുകയും ചെയ്തു.

അതിനാൽ, ഞാൻ ഞങ്ങളുടെ അനുഭവം പങ്കിടുന്നു, ഒരുപക്ഷേ ഇത് ആർക്കെങ്കിലും ഉപയോഗപ്രദമാകും.

പ്രശ്നം ഒന്ന്: "ഉപകരണത്തിൽ ഇടമില്ല"

മുകളിൽ സൂചിപ്പിച്ച ലേഖനത്തിൽ സൂചിപ്പിച്ചതുപോലെ, ഫയൽ സിസ്റ്റത്തിൽ ഫ്രീ ബ്ലോക്കുകൾ ഉണ്ട് എന്നതാണ് പ്രശ്നം, പക്ഷേ ഐനോഡ് തീർന്നു.

കമാൻഡ് ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഉപയോഗിച്ചതും സ്വതന്ത്രവുമായ ഐനോഡുകളുടെ എണ്ണം പരിശോധിക്കാം df -ih:

ഞാൻ ലേഖനം വീണ്ടും പറയില്ല; ചുരുക്കത്തിൽ, ഡിസ്കിൽ ഡാറ്റയ്ക്കുള്ള ബ്ലോക്കുകളും മെറ്റാ ഇൻഫർമേഷനുള്ള ബ്ലോക്കുകളും അടങ്ങിയിരിക്കുന്നു, ഇത് ഐനോഡുകൾ (ഇൻഡക്സ് നോഡ്) എന്നും അറിയപ്പെടുന്നു. ഫയൽ സിസ്റ്റം ആരംഭിക്കുമ്പോൾ അവരുടെ നമ്പർ സജ്ജീകരിച്ചിരിക്കുന്നു (ഞങ്ങൾ 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. ധാർമികത: ഒന്നുകിൽ എല്ലാ കേസുകളും മുൻകൂട്ടി ചിന്തിക്കുക, അല്ലെങ്കിൽ ഒരു സൂപ്പർഹീറോ ആയി നടിക്കുകയും വീട്ടമ്മമാർക്കായി സാധാരണ ക്രമീകരണങ്ങൾ ഉപയോഗിക്കുകയും ചെയ്യരുത്.

UPD. ഉപയോക്തൃ അഭിപ്രായം അനുസരിച്ച് ബെറെസ് i386 ന്റെ ബ്ലോക്ക് വലുപ്പം 4k കവിയാൻ പാടില്ല എന്ന് വ്യക്തമാക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു, എന്നാൽ അത് കൃത്യമായി 4k ആയിരിക്കണമെന്നില്ല, അതായത്. 1k, 2k എന്നിവ സ്വീകാര്യമാണ്.

അപ്പോൾ, ഞങ്ങൾ എങ്ങനെ പ്രശ്നങ്ങൾ പരിഹരിച്ചു?

ഒന്നാമതായി, ഒരു മൾട്ടി-ടെറാബൈറ്റ് ഡിസ്ക് ഡാറ്റ നിറഞ്ഞപ്പോൾ ഞങ്ങൾക്ക് ഒരു പ്രശ്നം നേരിട്ടു, കൂടാതെ ഫയൽ സിസ്റ്റം കോൺഫിഗറേഷൻ മാറ്റാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞില്ല.

രണ്ടാമതായി, ഒരു പരിഹാരം അടിയന്തിരമായി ആവശ്യമാണ്.

തൽഫലമായി, ഫയലുകളുടെ എണ്ണം കുറച്ചുകൊണ്ട് ബാലൻസ് മാറ്റേണ്ടതുണ്ടെന്ന നിഗമനത്തിൽ ഞങ്ങൾ എത്തി.
ഫയലുകളുടെ എണ്ണം കുറയ്ക്കുന്നതിന്, ഫയലുകൾ ഒരു പൊതു ആർക്കൈവിൽ ഇടാൻ തീരുമാനിച്ചു. ഞങ്ങളുടെ പ്രത്യേകതകൾ കണക്കിലെടുത്ത്, ഞങ്ങൾ ഒരു നിശ്ചിത കാലയളവിൽ എല്ലാ ഫയലുകളും ഒരു ആർക്കൈവിൽ ഇടുകയും എല്ലാ രാത്രിയും ഒരു ക്രോൺ ടാസ്ക് ഉപയോഗിച്ച് ആർക്കൈവിംഗ് നടത്തുകയും ചെയ്യുന്നു.

തിരഞ്ഞെടുത്ത zip ആർക്കൈവ്. മുമ്പത്തെ ലേഖനത്തിലെ അഭിപ്രായങ്ങളിൽ, ടാർ നിർദ്ദേശിച്ചു, പക്ഷേ അതിൽ ഒരു ബുദ്ധിമുട്ട് ഉണ്ട്: ഇതിന് ഒരു ഉള്ളടക്ക പട്ടിക ഇല്ല, അതിലെ ഫയലുകൾ ഒരു സ്ട്രീമിൽ സംഭരിച്ചിരിക്കുന്നു (ഇത് "ടാർ" എന്നത് ഒരു ചുരുക്കെഴുത്ത് മാത്രമല്ല. "ടേപ്പ് ആർക്കൈവ്" എന്നതിനായി, ടേപ്പ് ഡ്രൈവുകളുടെ പാരമ്പര്യം), അതായത്. ആർക്കൈവിന്റെ അവസാനത്തിൽ നിങ്ങൾക്ക് ഒരു ഫയൽ വായിക്കണമെങ്കിൽ, ആർക്കൈവിന്റെ ആരംഭവുമായി ബന്ധപ്പെട്ട ഓരോ ഫയലിനും ഓഫ്‌സെറ്റുകൾ അടങ്ങിയിരിക്കാത്തതിനാൽ, നിങ്ങൾ മുഴുവൻ ആർക്കൈവും വായിക്കേണ്ടതുണ്ട്. അതിനാൽ ഇത് ഒരു നീണ്ട പ്രവർത്തനമാണ്. സിപ്പിൽ എല്ലാം വളരെ മികച്ചതാണ്: ആർക്കൈവിനുള്ളിൽ ഇതിന് ഒരേ ഉള്ളടക്ക പട്ടികയും ഫയൽ ഓഫ്‌സെറ്റുകളും ഉണ്ട്, കൂടാതെ ഓരോ ഫയലിലേക്കുള്ള ആക്‌സസ് സമയം അതിന്റെ സ്ഥാനത്തെ ആശ്രയിക്കുന്നില്ല. ശരി, ഞങ്ങളുടെ കാര്യത്തിൽ, കംപ്രഷൻ ഓപ്ഷൻ "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

കാലാകാലങ്ങളിൽ ഒരു മെഷീനിൽ നിന്ന് മറ്റൊന്നിലേക്ക് ഒരു കൂട്ടം ഫയലുകൾ പകർത്തേണ്ട സാഹചര്യം ഉണ്ടാകുന്നു. അതേ സമയം, LA പലപ്പോഴും അയഥാർത്ഥമായി വളരുന്നു, കാരണം എല്ലാം ഡിസ്കുകളുടെ പ്രകടനത്തെ ആശ്രയിച്ചിരിക്കുന്നു.

നിങ്ങൾ ചെയ്യാൻ ആഗ്രഹിക്കുന്ന ഏറ്റവും മികച്ച കാര്യം ഒരു SSD ഉപയോഗിക്കുക എന്നതാണ്. ശരിക്കും അടിപൊളി. മൾട്ടി-ടെറാബൈറ്റ് എസ്എസ്ഡികളുടെ വിലയാണ് ഏക ചോദ്യം.

എന്നാൽ ഡിസ്കുകൾ സാധാരണമാണെങ്കിൽ, നിങ്ങൾ ഫയലുകൾ പകർത്തേണ്ടതുണ്ട്, ഇതും ഒരു പ്രൊഡക്ഷൻ സിസ്റ്റം ആണ്, ഓവർലോഡ് ക്ലയന്റുകളിൽ നിന്നുള്ള അസംതൃപ്തമായ ആശ്ചര്യങ്ങളിലേക്ക് നയിക്കുന്നു? കുറഞ്ഞത് രണ്ട് ഉപയോഗപ്രദമായ ഉപകരണങ്ങൾ ഉണ്ട്: nice и ionice.

nice - പ്രക്രിയയുടെ മുൻഗണന കുറയ്ക്കുന്നു, അതനുസരിച്ച് ഷെഡ്യൂളർ മറ്റ് ഉയർന്ന മുൻഗണനയുള്ള പ്രക്രിയകൾക്ക് കൂടുതൽ സമയ സ്ലൈസുകൾ വിതരണം ചെയ്യുന്നു.
ഞങ്ങളുടെ പ്രയോഗത്തിൽ, അത് പരമാവധി (19 ആണ് ഏറ്റവും കുറഞ്ഞ മുൻഗണന, -20 (മൈനസ് 20) എന്നത് പരമാവധി) ആയി സജ്ജീകരിക്കാൻ സഹായിച്ചു.

ionice — അതിനനുസരിച്ച് I/O ഷെഡ്യൂളിംഗ് ക്രമീകരിക്കുന്നു

നിങ്ങൾ റെയിഡ് ഉപയോഗിക്കുകയും അത് പെട്ടെന്ന് സമന്വയിപ്പിക്കുകയും ചെയ്യുകയാണെങ്കിൽ (പരാജയപ്പെട്ട റീബൂട്ടിന് ശേഷം അല്ലെങ്കിൽ ഒരു ഡിസ്ക് മാറ്റിസ്ഥാപിച്ചതിന് ശേഷം റെയ്ഡ് അറേ പുനഃസ്ഥാപിക്കേണ്ടതുണ്ട്), ചില സാഹചര്യങ്ങളിൽ സിൻക്രൊണൈസേഷൻ വേഗത കുറയ്ക്കുന്നത് അർത്ഥമാക്കുന്നു, അതുവഴി മറ്റ് പ്രക്രിയകൾ കൂടുതൽ പ്രവർത്തിക്കും. അല്ലെങ്കിൽ വേണ്ടത്ര കുറവ്. ഇനിപ്പറയുന്ന കമാൻഡ് ഇതിന് സഹായിക്കും:

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

പ്രശ്നം അഞ്ച്: തത്സമയം ഫയലുകൾ എങ്ങനെ സമന്വയിപ്പിക്കാം

ഒഴിവാക്കാൻ രണ്ടാമത്തെ സെർവറിലേക്ക് ബാക്കപ്പ് ചെയ്യേണ്ട അതേ വലിയ എണ്ണം ഫയലുകൾ ഇപ്പോഴും ഞങ്ങളുടെ പക്കലുണ്ട്... ഫയലുകൾ നിരന്തരം എഴുതിക്കൊണ്ടിരിക്കുന്നു, അതിനാൽ കുറഞ്ഞ നഷ്ടം ഉണ്ടാകാൻ, നിങ്ങൾ കഴിയുന്നത്ര വേഗത്തിൽ അവ പകർത്തേണ്ടതുണ്ട്.

സ്റ്റാൻഡേർഡ് സൊല്യൂഷൻ: SSH വഴി Rsync ചെയ്യുക.

ഓരോ കുറച്ച് സെക്കൻഡിലും നിങ്ങൾ ഇത് ചെയ്യേണ്ടതില്ലെങ്കിൽ ഇത് ഒരു നല്ല ഓപ്ഷനാണ്. കൂടാതെ ഒരുപാട് ഫയലുകൾ ഉണ്ട്. നിങ്ങൾ അവ പകർത്തിയില്ലെങ്കിൽപ്പോലും, എന്താണ് മാറിയതെന്ന് നിങ്ങൾ എങ്ങനെയെങ്കിലും മനസ്സിലാക്കേണ്ടതുണ്ട്, കൂടാതെ നിരവധി ദശലക്ഷം ഫയലുകൾ താരതമ്യം ചെയ്യാൻ സമയമെടുക്കുകയും ഡിസ്കുകളിൽ ലോഡ് ചെയ്യുകയും ചെയ്യുന്നു.

ആ. ഓരോ തവണയും താരതമ്യം നടത്താതെ, എന്താണ് പകർത്തേണ്ടതെന്ന് നമുക്ക് ഉടനടി അറിയേണ്ടതുണ്ട്.

രക്ഷ - lsyncd. Lsyncd - തത്സമയ സമന്വയം (മിറർ) ഡെമൺ. ഇത് rsync വഴിയും പ്രവർത്തിക്കുന്നു, എന്നാൽ കൂടാതെ inotify, fsevents എന്നിവ ഉപയോഗിച്ച് മാറ്റങ്ങൾക്കായി ഫയൽ സിസ്റ്റത്തെ നിരീക്ഷിക്കുകയും ദൃശ്യമാകുന്നതോ മാറിയതോ ആയ ഫയലുകൾ മാത്രം പകർത്താൻ തുടങ്ങുന്നു.

പ്രശ്നം ആറ്: ആരാണ് ഡിസ്കുകൾ ലോഡ് ചെയ്യുന്നതെന്ന് എങ്ങനെ മനസ്സിലാക്കാം

എല്ലാവർക്കും ഇത് അറിയാം, എന്നിരുന്നാലും, ചിത്രം പൂർത്തിയാക്കാൻ: ഡിസ്ക് സബ്സിസ്റ്റം നിരീക്ഷിക്കാൻ ഒരു കമാൻഡ് ഉണ്ട് iotop - പോലെ top, എന്നാൽ ഡിസ്കുകൾ ഏറ്റവും സജീവമായി ഉപയോഗിക്കുന്ന പ്രക്രിയകൾ കാണിക്കുന്നു.

വഴിയിൽ, ഡിസ്കുകളിൽ പ്രശ്നമുണ്ടോ ഇല്ലയോ എന്ന് മനസിലാക്കാൻ നല്ല പഴയ ടോപ്പ് നിങ്ങളെ അനുവദിക്കുന്നു. ഇതിന് ഏറ്റവും അനുയോജ്യമായ രണ്ട് ഓപ്ഷനുകൾ ഉണ്ട്: ലോഡ് ശരാശരി и ഐഒവൈറ്റ്.

സേവനത്തിനായുള്ള ക്യൂവിൽ എത്ര പ്രോസസ്സുകൾ ഉണ്ടെന്ന് ആദ്യത്തേത് കാണിക്കുന്നു, സാധാരണയായി 2-ൽ കൂടുതൽ - ഇതിനകം എന്തോ കുഴപ്പം സംഭവിക്കുന്നു. ബാക്കപ്പ് സെർവറുകളിലേക്ക് സജീവമായി പകർത്തുമ്പോൾ, ഞങ്ങൾ 6-8 വരെ അനുവദിക്കുന്നു, അതിനുശേഷം സാഹചര്യം അസാധാരണമായി കണക്കാക്കപ്പെടുന്നു.

ഡിസ്ക് പ്രവർത്തനങ്ങളിൽ പ്രോസസ്സർ എത്ര തിരക്കിലാണ് എന്നതാണ് രണ്ടാമത്തേത്. IOwait>10% ആശങ്കയ്‌ക്ക് കാരണമാകുന്നു, എന്നിരുന്നാലും ഒരു പ്രത്യേക ലോഡ് പ്രൊഫൈലുള്ള ഞങ്ങളുടെ സെർവറുകളിൽ ഇത് സ്ഥിരമായി 40-50% ആണ്, ഇത് ശരിക്കും ഒരു മാനദണ്ഡമാണ്.

ഞാൻ ഇവിടെ പൂർത്തിയാക്കും, ഒരുപക്ഷേ ഞങ്ങൾക്ക് കൈകാര്യം ചെയ്യേണ്ടതില്ലാത്ത നിരവധി പോയിന്റുകൾ ഉണ്ടെങ്കിലും, രസകരമായ യഥാർത്ഥ കേസുകളുടെ അഭിപ്രായങ്ങൾക്കും വിവരണങ്ങൾക്കും കാത്തിരിക്കാൻ ഞാൻ സന്തുഷ്ടനാണ്.

അവലംബം: www.habr.com