etcd യുടെ മതിയായ പ്രകടനത്തിനായി ഫിയോ ഉപയോഗിച്ച് ഡിസ്കുകൾ എങ്ങനെ പരിശോധിക്കാം

കുറിപ്പ്. വിവർത്തനം.: etcd ഡാറ്റാബേസിന്റെ പ്രവർത്തനവുമായി ബന്ധപ്പെട്ട ഒരു യഥാർത്ഥ പ്രശ്നത്തിന് പരിഹാരം തേടി IBM ക്ലൗഡ് എഞ്ചിനീയർമാർ നടത്തിയ ഒരു ചെറിയ ഗവേഷണത്തിന്റെ ഫലമാണ് ഈ ലേഖനം. സമാനമായ ഒരു ചുമതല ഞങ്ങൾക്ക് പ്രസക്തമായിരുന്നു, എന്നിരുന്നാലും, രചയിതാക്കളുടെ പ്രതിഫലനങ്ങളുടെയും പ്രവർത്തനങ്ങളുടെയും ഗതി വിശാലമായ സന്ദർഭത്തിൽ രസകരമായിരിക്കാം.

മുഴുവൻ ലേഖനത്തിന്റെയും സംക്ഷിപ്ത സംഗ്രഹം: ഫിയോയും മറ്റും

ഒരു etcd ക്ലസ്റ്ററിന്റെ പ്രകടനം അടിസ്ഥാന സംഭരണത്തിന്റെ വേഗതയെ വളരെയധികം ആശ്രയിച്ചിരിക്കുന്നു. പ്രകടനം നിരീക്ഷിക്കുന്നതിന് etcd വിവിധ പ്രോമിത്യൂസ് മെട്രിക്കുകൾ കയറ്റുമതി ചെയ്യുന്നു. അതിലൊന്നാണ് wal_fsync_duration_seconds. മുതലായവയ്ക്കുള്ള ഡോക്യുമെന്റേഷനിൽ അതു പറയുന്നുഈ മെട്രിക്കിന്റെ 99-ാം ശതമാനം 10 എം.എസിൽ കവിയുന്നില്ലെങ്കിൽ സംഭരണം വേണ്ടത്ര വേഗത്തിൽ കണക്കാക്കാം…

Если вы обдумываете возможность организации кластера etcd на машинах под управлением Linux и хотите проверить, достаточно ли быстры накопители (например, SSD), рекомендуем воспользоваться популярным тестером I/O под названием fio. ഇനിപ്പറയുന്ന കമാൻഡ് പ്രവർത്തിപ്പിച്ചാൽ മതി (ഡയറക്‌ടറി test-data പരീക്ഷിച്ച ഡ്രൈവിന്റെ മൌണ്ട് ചെയ്ത പാർട്ടീഷനിൽ സ്ഥിതിചെയ്യണം):

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

ഔട്ട്‌പുട്ട് നോക്കാനും 99-ാമത്തെ പെർസന്റൈൽ അനുയോജ്യമാണോ എന്ന് പരിശോധിക്കാനും മാത്രമേ ഇത് ശേഷിക്കുന്നുള്ളൂ fdatasync 10 എം.എസ്. അങ്ങനെയാണെങ്കിൽ, നിങ്ങളുടെ ഡ്രൈവ് വേണ്ടത്ര വേഗത്തിൽ പ്രവർത്തിക്കുന്നു. ഒരു ഉദാഹരണ ഔട്ട്പുട്ട് ഇതാ:

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

കുറച്ച് കുറിപ്പുകൾ:

1. മുകളിലുള്ള ഉദാഹരണത്തിൽ, ഞങ്ങൾ പാരാമീറ്ററുകൾ ക്രമീകരിച്ചു --size и --bs ഒരു പ്രത്യേക കേസിനായി. അർത്ഥവത്തായ ഫലം ലഭിക്കുന്നതിന് fio, നിങ്ങളുടെ ഉപയോഗത്തിന് അനുയോജ്യമായ മൂല്യങ്ങൾ വ്യക്തമാക്കുക. അവ എങ്ങനെ തിരഞ്ഞെടുക്കാം എന്നത് ചുവടെ ചർച്ചചെയ്യും.
2. ടെസ്റ്റിംഗ് സമയത്ത് മാത്രം fio ഡിസ്ക് സബ്സിസ്റ്റം ലോഡ് ചെയ്യുന്നു. യഥാർത്ഥ ജീവിതത്തിൽ, മറ്റ് പ്രക്രിയകൾ ഡിസ്കിലേക്ക് എഴുതാൻ സാധ്യതയുണ്ട് (അതുമായി ബന്ധപ്പെട്ടവ കൂടാതെ wal_fsync_duration_seconds). ഈ അധിക ലോഡ് വർദ്ധിപ്പിക്കാം wal_fsync_duration_seconds. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ടെസ്റ്റിംഗിൽ നിന്നുള്ള 99-ാമത്തെ പെർസെൻറ്റൈൽ fio, 10 ms-ൽ അൽപ്പം കുറവ് മാത്രം, സ്റ്റോറേജ് പെർഫോമൻസ് മതിയാകാതിരിക്കാനുള്ള നല്ല സാധ്യതയുണ്ട്.
3. പരിശോധനയ്ക്കായി നിങ്ങൾക്ക് പതിപ്പ് ആവശ്യമാണ് fio 3.5 ൽ കുറവല്ല, കാരണം പഴയ പതിപ്പുകൾ ഫലങ്ങൾ സമാഹരിക്കുന്നില്ല fdatasync ശതമാനം രൂപത്തിൽ.
4. മുകളിലുള്ള നിഗമനം പൊതുവായ നിഗമനത്തിൽ നിന്നുള്ള ഒരു ചെറിയ ഉദ്ധരണി മാത്രമാണ് fio.

ഫിയോയെയും മറ്റും കുറിച്ച് കൂടുതൽ

WALs മുതലായവയെക്കുറിച്ച് കുറച്ച് വാക്കുകൾ

സാധാരണയായി, ഡാറ്റാബേസുകൾ ഉപയോഗിക്കുന്നു സജീവമായ ലോഗിംഗ് (റൈറ്റ്-എഹെഡ് ലോഗിംഗ്, WAL). etcd എന്നിവയും ബാധിക്കുന്നു. WAL നെക്കുറിച്ചുള്ള ഒരു ചർച്ച ഈ ലേഖനത്തിന്റെ പരിധിക്കപ്പുറമാണ്, എന്നാൽ ഞങ്ങളുടെ ആവശ്യങ്ങൾക്ക്, ഓരോ etcd ക്ലസ്റ്റർ അംഗവും സ്ഥിരമായ സംഭരണത്തിൽ WAL സംഭരിക്കുന്നു എന്നതാണ് നിങ്ങൾ അറിയേണ്ടത്. etcd ചില കീ-വാല്യൂ സ്റ്റോറേജ് ഓപ്പറേഷനുകൾ (അപ്ഡേറ്റുകൾ പോലുള്ളവ) WAL-ലേക്ക് എഴുതുന്നു, അവ നടപ്പിലാക്കുന്നതിന് മുമ്പ്. സ്നാപ്പ്ഷോട്ടുകൾക്കിടയിൽ ഒരു നോഡ് ക്രാഷ് ചെയ്യുകയും പുനരാരംഭിക്കുകയും ചെയ്താൽ, WAL-ന്റെ ഉള്ളടക്കത്തെ അടിസ്ഥാനമാക്കി മുമ്പത്തെ സ്നാപ്പ്ഷോട്ട് മുതൽ ഇടപാടുകൾ വീണ്ടെടുക്കാൻ etcd-ന് കഴിയും.

Таким образом, каждый раз, когда клиент добавляет ключ в KV-хранилище или обновляет значение существующего ключа, etcd добавляет описание операции в WAL, представляющий собой обычный файл в постоянном хранилище. Прежде чем продолжить работу, etcd ДОЛЖНА быть на 100% уверена, что запись в WAL действительно сохранена. Чтобы добиться этого в Linux, недостаточно использовать системный вызов write, поскольку сама операция записи на физический носитель может быть отложена. Например, Linux в течение некоторого времени может продержать WAL-запись в кэше ядра в памяти (например, в страничном кэше). Чтобы гарантировать, что данные записаны на носитель, после записи необходимо задействовать системный вызов fdatasync - ഇതുതന്നെയാണ് etcd ചെയ്യുന്നത് (നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന ഔട്ട്പുട്ടിൽ കാണാൻ കഴിയുന്നത് പോലെ strace; ഇവിടെ 8 - WAL ഫയൽ ഡിസ്ക്രിപ്റ്റർ):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".      20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

നിർഭാഗ്യവശാൽ, സ്ഥിരമായ സംഭരണത്തിലേക്ക് എഴുതുന്നതിന് കുറച്ച് സമയമെടുക്കും. fdatasync കോളുകളുടെ ദീർഘകാല നിർവ്വഹണം etcd-യുടെ പ്രകടനത്തെ ബാധിക്കും. റിപ്പോസിറ്ററി ഡോക്യുമെന്റേഷനിൽ സൂചിപ്പിച്ചിരിക്കുന്നു, മതിയായ പ്രകടനത്തിന് എല്ലാ കോളുകളുടെയും ദൈർഘ്യത്തിന്റെ 99-ാം ശതമാനം ആവശ്യമാണ് fdatasync ഒരു WAL ഫയലിലേക്ക് എഴുതുമ്പോൾ 10 ms-ൽ കുറവായിരുന്നു. സ്റ്റോറേജുമായി ബന്ധപ്പെട്ട മറ്റ് മെട്രിക്കുകൾ ഉണ്ട്, എന്നാൽ ഈ ലേഖനം അതിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കും.

ഫിയോ ഉപയോഗിച്ച് സംഭരണത്തെ വിലമതിക്കുന്നു

യൂട്ടിലിറ്റി ഉപയോഗിച്ച് etcd ഉപയോഗിക്കുന്നതിന് ഒരു നിശ്ചിത സംഭരണം അനുയോജ്യമാണോ എന്ന് നിങ്ങൾക്ക് വിലയിരുത്താവുന്നതാണ് fio - ഒരു ജനപ്രിയ I/O ടെസ്റ്റർ. ഡിസ്ക് I/O പല തരത്തിൽ സംഭവിക്കാം എന്ന് ഓർമ്മിക്കുക: സമന്വയം/അസമന്വയം, പല വ്യത്യസ്‌ത syscall ക്ലാസുകൾ തുടങ്ങിയവ. നാണയത്തിന്റെ മറുവശം അതാണ് fio ഉപയോഗിക്കാൻ വളരെ ബുദ്ധിമുട്ടാണ്. യൂട്ടിലിറ്റിക്ക് നിരവധി പാരാമീറ്ററുകൾ ഉണ്ട്, അവയുടെ മൂല്യങ്ങളുടെ വ്യത്യസ്ത കോമ്പിനേഷനുകൾ തികച്ചും വ്യത്യസ്തമായ ഫലങ്ങളിലേക്ക് നയിക്കുന്നു. etcd-യ്‌ക്ക് ന്യായമായ ഒരു എസ്റ്റിമേറ്റ് ലഭിക്കുന്നതിന്, fio സൃഷ്‌ടിക്കുന്ന റൈറ്റ് ലോഡ് etcd-യുടെ WAL ഫയൽ റൈറ്റ് ലോഡിന് കഴിയുന്നത്ര അടുത്താണെന്ന് നിങ്ങൾ ഉറപ്പാക്കേണ്ടതുണ്ട്:

• ഇതിനർത്ഥം സൃഷ്ടിച്ചത് എന്നാണ് fio ലോഡ് കുറഞ്ഞത് ഫയലിലേക്കുള്ള തുടർച്ചയായ റൈറ്റുകളുടെ ഒരു പരമ്പര ആയിരിക്കണം, ഓരോ റൈറ്റ് ഓപ്പറേഷനും ഒരു സിസ്റ്റം കോൾ ഉൾക്കൊള്ളുന്നു writeപിന്തുടരുന്നു fdatasync.
• തുടർച്ചയായ എഴുത്ത് പ്രവർത്തനക്ഷമമാക്കാൻ, നിങ്ങൾ ഫ്ലാഗ് വ്യക്തമാക്കണം --rw=write.
• ആ fio കോളുകൾ ഉപയോഗിച്ച് എഴുതി write (മറ്റ് സിസ്റ്റം കോളുകൾക്ക് പകരം - ഉദാഹരണത്തിന്, pwrite), പതാക ഉപയോഗിക്കുക --ioengine=sync.
• ഒടുവിൽ, പതാക --fdatasync=1 ഓരോന്നും ഉറപ്പാക്കുന്നു write ആയിരിക്കണം fdatasync.
• ഞങ്ങളുടെ ഉദാഹരണത്തിലെ മറ്റ് രണ്ട് പാരാമീറ്ററുകൾ ഇവയാണ്: --size и --bs - നിർദ്ദിഷ്ട ഉപയോഗ സാഹചര്യത്തെ ആശ്രയിച്ച് വ്യത്യാസപ്പെടാം. അടുത്ത വിഭാഗം അവയുടെ കോൺഫിഗറേഷൻ വിവരിക്കും.

എന്തുകൊണ്ടാണ് ഞങ്ങൾ ഫിയോ തിരഞ്ഞെടുത്തത്, അത് എങ്ങനെ സജ്ജീകരിക്കാമെന്ന് ഞങ്ങൾ പഠിച്ചു

ഞങ്ങൾ നേരിട്ട ഒരു യഥാർത്ഥ കേസിൽ നിന്നാണ് ഈ കുറിപ്പ്. പ്രോമിത്യൂസിനെ നിരീക്ഷിക്കുന്ന കുബർനെറ്റസ് v1.13-ൽ ഞങ്ങൾക്ക് ഒരു ക്ലസ്റ്റർ ഉണ്ടായിരുന്നു. etcd v3.2.24 ന്റെ സംഭരണമായി SSD-കൾ ഉപയോഗിച്ചു. Etcd മെട്രിക്കുകൾ വളരെ ഉയർന്ന ലേറ്റൻസികൾ കാണിച്ചു fdatasync, ക്ലസ്റ്റർ നിഷ്ക്രിയമായിരുന്നപ്പോഴും. ഞങ്ങൾക്ക്, ഈ അളവുകൾ വളരെ സംശയാസ്പദമായി തോന്നി, അവ കൃത്യമായി പ്രതിനിധീകരിക്കുന്നത് എന്താണെന്ന് ഞങ്ങൾക്ക് ഉറപ്പില്ല. കൂടാതെ, ക്ലസ്റ്ററിൽ വെർച്വൽ മെഷീനുകൾ അടങ്ങിയിരുന്നു, അതിനാൽ കാലതാമസം വിർച്ച്വലൈസേഷൻ കാരണമാണോ അതോ എസ്എസ്ഡി കുറ്റപ്പെടുത്തലാണോ എന്ന് പറയാൻ കഴിയില്ല.

കൂടാതെ, ഹാർഡ്‌വെയർ, സോഫ്‌റ്റ്‌വെയർ കോൺഫിഗറേഷനിലെ വിവിധ മാറ്റങ്ങൾ ഞങ്ങൾ പരിഗണിച്ചു, അതിനാൽ അവ വിലയിരുത്തുന്നതിന് ഞങ്ങൾക്ക് ഒരു മാർഗം ആവശ്യമാണ്. തീർച്ചയായും, ഓരോ കോൺഫിഗറേഷനിലും etcd പ്രവർത്തിപ്പിക്കാനും അനുബന്ധ പ്രോമിത്യൂസ് മെട്രിക്‌സ് നോക്കാനും കഴിയും, പക്ഷേ അതിന് കാര്യമായ പരിശ്രമം ആവശ്യമാണ്. ഒരു നിർദ്ദിഷ്‌ട കോൺഫിഗറേഷൻ വിലയിരുത്തുന്നതിനുള്ള ഒരു ലളിതമായ മാർഗമാണ് ഞങ്ങൾക്ക് വേണ്ടത്. etcd-ൽ നിന്ന് വരുന്ന പ്രോമിത്യൂസ് മെട്രിക്‌സിനെക്കുറിച്ചുള്ള ഞങ്ങളുടെ ധാരണ പരിശോധിക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു.

ഇതിന് രണ്ട് പ്രശ്നങ്ങൾ പരിഹരിക്കേണ്ടതുണ്ട്:

• ആദ്യം, WAL ഫയലുകളിലേക്ക് എഴുതുമ്പോൾ etcd സൃഷ്ടിക്കുന്ന I/O ലോഡ് എങ്ങനെയിരിക്കും? ഏത് സിസ്റ്റം കോളുകളാണ് ഉപയോഗിക്കുന്നത്? റെക്കോർഡ് ബ്ലോക്കുകളുടെ വലുപ്പം എന്താണ്?
• രണ്ടാമതായി, മേൽപ്പറഞ്ഞ ചോദ്യങ്ങൾക്ക് നമുക്ക് ഉത്തരം ഉണ്ടെന്ന് പറയാം. അനുബന്ധ ലോഡ് എങ്ങനെ പുനർനിർമ്മിക്കാം fio? എല്ലാത്തിനുമുപരി fio - ധാരാളം പാരാമീറ്ററുകൾ ഉള്ള വളരെ ഫ്ലെക്സിബിൾ യൂട്ടിലിറ്റി (ഇത് സ്ഥിരീകരിക്കാൻ എളുപ്പമാണ്, ഉദാഹരണത്തിന്, ഇവിടെ - ഏകദേശം. വിവർത്തനം.).

ഒരേ കമാൻഡ് അധിഷ്‌ഠിത സമീപനത്തിലൂടെ ഞങ്ങൾ രണ്ട് പ്രശ്‌നങ്ങളും പരിഹരിച്ചു lsof и strace:

• സഹായത്തോടെ lsof പ്രോസസ്സ് ഉപയോഗിക്കുന്ന എല്ലാ ഫയൽ ഡിസ്ക്രിപ്റ്ററുകളും അവ പരാമർശിക്കുന്ന ഫയലുകളും നിങ്ങൾക്ക് കാണാൻ കഴിയും.
• സഹായത്തോടെ strace നിങ്ങൾക്ക് ഇതിനകം പ്രവർത്തിക്കുന്ന ഒരു പ്രക്രിയ വിശകലനം ചെയ്യാം അല്ലെങ്കിൽ ഒരു പ്രോസസ്സ് പ്രവർത്തിപ്പിച്ച് അത് കാണുക. ഈ പ്രക്രിയ വഴിയുള്ള എല്ലാ സിസ്റ്റം കോളുകളും, ആവശ്യമെങ്കിൽ, അതിന്റെ പിൻഗാമികളും കമാൻഡ് പ്രദർശിപ്പിക്കുന്നു. ഫോർക്കിംഗ് ചെയ്യുന്ന പ്രക്രിയകൾക്ക് രണ്ടാമത്തേത് പ്രധാനമാണ്, കൂടാതെ etcd അത്തരത്തിലുള്ള ഒരു പ്രക്രിയയാണ്.

ഞങ്ങൾ ആദ്യം ചെയ്തത് ഉപയോഗിക്കുക എന്നതാണ് strace കുബർനെറ്റസ് ക്ലസ്റ്ററിലെ etcd സെർവർ നിഷ്‌ക്രിയമായിരുന്നപ്പോൾ പരിശോധിക്കാൻ.

അതിനാൽ, WAL റെക്കോർഡ് ബ്ലോക്കുകൾ വളരെ സാന്ദ്രമായി ഗ്രൂപ്പുചെയ്‌തിരിക്കുന്നതായി കണ്ടെത്തി, ഭൂരിപക്ഷത്തിന്റെ വലുപ്പം 2200-2400 ബൈറ്റുകളുടെ പരിധിയിലായിരുന്നു. അതുകൊണ്ടാണ് ഈ ലേഖനത്തിന്റെ തുടക്കത്തിലെ കമാൻഡ് ഫ്ലാഗ് ഉപയോഗിക്കുന്നത് --bs=2300 (bs ഓരോ റൈറ്റ് ബ്ലോക്കിന്റെയും ബൈറ്റിലെ വലുപ്പമാണ് fio).

പതിപ്പ്, വിന്യാസം, പാരാമീറ്റർ മൂല്യങ്ങൾ മുതലായവയെ ആശ്രയിച്ച് etcd റൈറ്റ് ബ്ലോക്കുകളുടെ വലുപ്പം വ്യത്യാസപ്പെടാം എന്നത് ശ്രദ്ധിക്കുക. - ഇത് ദൈർഘ്യത്തെ ബാധിക്കുന്നു fdatasync. നിങ്ങൾക്ക് സമാനമായ ഉപയോഗ കേസ് ഉണ്ടെങ്കിൽ, ഉപയോഗിച്ച് വിശകലനം ചെയ്യുക strace കാലികമായ മൂല്യങ്ങൾ ലഭിക്കുന്നതിന് നിങ്ങളുടെ etcd പ്രക്രിയകൾ.

തുടർന്ന്, ഫയൽ സിസ്റ്റത്തിൽ etcd എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള വ്യക്തവും സമഗ്രവുമായ ആശയം ലഭിക്കുന്നതിന്, ഞങ്ങൾ അത് താഴെ നിന്ന് ആരംഭിച്ചു. strace പതാകകൾ കൊണ്ട് -ffttT. ചൈൽഡ് പ്രോസസുകൾ ക്യാപ്‌ചർ ചെയ്യാനും ഓരോന്നിന്റെയും ഔട്ട്‌പുട്ട് ഒരു പ്രത്യേക ഫയലിലേക്ക് എഴുതാനും ഇത് സാധ്യമാക്കി. കൂടാതെ, ഓരോ സിസ്റ്റം കോളിന്റെയും ആരംഭ സമയത്തെയും ദൈർഘ്യത്തെയും കുറിച്ചുള്ള വിശദമായ വിവരങ്ങൾ ലഭിച്ചു.

ഞങ്ങൾ കമാൻഡും ഉപയോഗിച്ചു lsofഔട്ട്പുട്ടിനെക്കുറിച്ചുള്ള നിങ്ങളുടെ ധാരണ സ്ഥിരീകരിക്കാൻ strace ഏത് ആവശ്യത്തിനായി ഏത് ഫയൽ ഡിസ്ക്രിപ്റ്റർ ഉപയോഗിച്ചു എന്നതിന്റെ അടിസ്ഥാനത്തിൽ. എനിക്ക് നിഗമനം ലഭിച്ചു strace, മുകളിൽ പറഞ്ഞതിന് സമാനമാണ്. സിൻക്രൊണൈസേഷൻ സമയങ്ങളുള്ള സ്റ്റാറ്റിസ്റ്റിക്കൽ കൃത്രിമങ്ങൾ മെട്രിക് ആണെന്ന് സ്ഥിരീകരിച്ചു wal_fsync_duration_seconds etcd പൊരുത്ത കോളുകളിൽ നിന്ന് fdatasync WAL ഫയൽ ഡിസ്ക്രിപ്റ്ററുകൾക്കൊപ്പം.

ഉപയോഗിച്ച് സൃഷ്ടിക്കാൻ fio etcd-ൽ നിന്നുള്ളതിന് സമാനമായ ഒരു ജോലിഭാരം, യൂട്ടിലിറ്റിയുടെ ഡോക്യുമെന്റേഷൻ പഠിക്കുകയും ഞങ്ങളുടെ ടാസ്ക്കിന് അനുയോജ്യമായ പാരാമീറ്ററുകൾ തിരഞ്ഞെടുക്കുകയും ചെയ്തു. ശരിയായ സിസ്റ്റം കോളുകൾ പുരോഗതിയിലാണെന്ന് ഞങ്ങൾ പരിശോധിച്ചുറപ്പിക്കുകയും റൺ ചെയ്തുകൊണ്ട് അവയുടെ ദൈർഘ്യം സ്ഥിരീകരിക്കുകയും ചെയ്തു fio നിന്ന് strace (ഇത് മുതലായവയുടെ കാര്യത്തിൽ ചെയ്തതുപോലെ).

പരാമീറ്ററിന്റെ മൂല്യം നിർണ്ണയിക്കുന്നതിൽ പ്രത്യേക ശ്രദ്ധ ചെലുത്തി --size. ഇത് ഫിയോ യൂട്ടിലിറ്റി സൃഷ്ടിച്ച മൊത്തം I/O ലോഡിനെ പ്രതിനിധീകരിക്കുന്നു. ഞങ്ങളുടെ കാര്യത്തിൽ, ഇത് മീഡിയയ്ക്ക് എഴുതിയ മൊത്തം ബൈറ്റുകളുടെ എണ്ണമാണ്. ഇത് കോളുകളുടെ എണ്ണത്തിന് നേരിട്ട് ആനുപാതികമാണ് write (ഒപ്പം fdatasync). ഒരു പ്രത്യേക കാര്യത്തിനായി bs കോളുകളുടെ എണ്ണം fdatasync തുല്യമാണ് size / bs.

ശതമാനത്തിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമുള്ളതിനാൽ, സാമ്പിളുകളുടെ എണ്ണം സ്ഥിതിവിവരക്കണക്കനുസരിച്ച് പ്രാധാന്യമുള്ളതായിരിക്കണം. അത് തീരുമാനിക്കുകയും ചെയ്തു 10^4 (ഇത് 22 MB വലുപ്പവുമായി യോജിക്കുന്നു) മതിയാകും. ചെറിയ പാരാമീറ്റർ മൂല്യങ്ങൾ --size കൂടുതൽ വ്യക്തമായ ശബ്ദം നൽകി (ഉദാഹരണത്തിന്, കോളുകൾ fdatasync, ഇത് സാധാരണയേക്കാൾ കൂടുതൽ സമയമെടുക്കുകയും 99-ാം ശതമാനത്തെ ബാധിക്കുകയും ചെയ്യുന്നു).

ഇത് നിങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു

എങ്ങനെ ഉപയോഗിക്കണമെന്ന് ലേഖനം കാണിക്കുന്നു fio etcd ഉപയോഗിച്ച് ഉപയോഗിക്കാൻ ഉദ്ദേശിക്കുന്ന മീഡിയ വേണ്ടത്ര വേഗതയുള്ളതാണോ എന്ന് ഒരാൾക്ക് വിലയിരുത്താം. ഇപ്പോൾ അത് നിങ്ങളുടേതാണ്! സേവനത്തിൽ നിങ്ങൾക്ക് SSD-അധിഷ്ഠിത സ്റ്റോറേജ് ഉള്ള വെർച്വൽ മെഷീനുകൾ പര്യവേക്ഷണം ചെയ്യാം IBM ക്ലൗഡ്.

വിവർത്തകനിൽ നിന്ന് പി.എസ്

റെഡിമെയ്ഡ് ഉപയോഗ കേസുകൾക്കൊപ്പം fio മറ്റ് ജോലികൾക്കായി, കാണുക പ്രമാണീകരണം അല്ലെങ്കിൽ നേരിട്ട് പദ്ധതി ശേഖരങ്ങൾ (ഡോക്യുമെന്റേഷനിൽ പറഞ്ഞിരിക്കുന്നതിനേക്കാൾ കൂടുതൽ അവയിൽ പലതും ഉണ്ട്).

വിവർത്തകനിൽ നിന്നുള്ള PPS

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «etcd 3.4.3: സംഭരണ ​​വിശ്വാസ്യതയും സുരക്ഷാ പഠനവും";
• «etcd Kubernetes ക്ലസ്റ്ററിലെ ഡാറ്റയുമായി നേരിട്ടുള്ള ഞങ്ങളുടെ അനുഭവം (K8s API ഇല്ലാതെ)";
• «കുബെർനെറ്റസിന്റെ പ്രവർത്തനത്തിലെ 6 രസകരമായ സിസ്റ്റം ബഗുകളും [അവയുടെ പരിഹാരവും]".

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