eBPF/BCC ഉപയോഗിച്ച് ഉയർന്ന സെഫ് ലേറ്റൻസി മുതൽ കേർണൽ പാച്ച് വരെ

കേർണലും ആപ്ലിക്കേഷനുകളും ഡീബഗ്ഗ് ചെയ്യുന്നതിനായി ലിനക്സിന് ധാരാളം ഉപകരണങ്ങൾ ഉണ്ട്. അവയിൽ മിക്കതും ആപ്ലിക്കേഷൻ പ്രകടനത്തെ പ്രതികൂലമായി ബാധിക്കുന്നു, മാത്രമല്ല ഉൽപ്പാദനത്തിൽ ഉപയോഗിക്കാൻ കഴിയില്ല.

കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ് ഉണ്ടായിരുന്നു മറ്റൊരു ഉപകരണം വികസിപ്പിച്ചെടുത്തിട്ടുണ്ട് - ഇ.ബി.പി.എഫ്. പ്രോഗ്രാമുകൾ പുനർനിർമ്മിക്കാതെയും കേർണലിലേക്ക് മൂന്നാം കക്ഷി മൊഡ്യൂളുകൾ ലോഡ് ചെയ്യാതെയും കുറഞ്ഞ ഓവർഹെഡിൽ കേർണലും ഉപയോക്തൃ ആപ്ലിക്കേഷനുകളും കണ്ടെത്തുന്നത് സാധ്യമാക്കുന്നു.

ഇബിപിഎഫ് ഉപയോഗിക്കുന്ന നിരവധി ആപ്ലിക്കേഷൻ യൂട്ടിലിറ്റികൾ ഇതിനകം ഉണ്ട്, ഈ ലേഖനത്തിൽ ലൈബ്രറിയെ അടിസ്ഥാനമാക്കി നിങ്ങളുടെ സ്വന്തം പ്രൊഫൈലിംഗ് യൂട്ടിലിറ്റി എങ്ങനെ എഴുതാമെന്ന് ഞങ്ങൾ നോക്കും. പൈത്തൺബിസിസി. യഥാർത്ഥ സംഭവങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് ലേഖനം. നിർദ്ദിഷ്ട സാഹചര്യങ്ങളിൽ നിലവിലുള്ള യൂട്ടിലിറ്റികൾ എങ്ങനെ ഉപയോഗിക്കാമെന്ന് കാണിക്കാൻ ഞങ്ങൾ പ്രശ്നത്തിൽ നിന്ന് പരിഹരിക്കാൻ പോകും.

സെഫ് ഈസ് സ്ലോ

സെഫ് ക്ലസ്റ്ററിലേക്ക് ഒരു പുതിയ ഹോസ്റ്റ് ചേർത്തു. അതിലേക്ക് കുറച്ച് ഡാറ്റ മൈഗ്രേറ്റ് ചെയ്‌തതിന് ശേഷം, അത് വഴിയുള്ള റൈറ്റ് അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്ന വേഗത മറ്റ് സെർവറുകളെ അപേക്ഷിച്ച് വളരെ കുറവാണെന്ന് ഞങ്ങൾ ശ്രദ്ധിച്ചു.

മറ്റ് പ്ലാറ്റ്‌ഫോമുകളിൽ നിന്ന് വ്യത്യസ്തമായി, ഈ ഹോസ്റ്റ് bcache ഉം പുതിയ linux 4.15 കേർണലും ഉപയോഗിച്ചു. ഇതാദ്യമായാണ് ഈ കോൺഫിഗറേഷന്റെ ഒരു ഹോസ്റ്റ് ഇവിടെ ഉപയോഗിക്കുന്നത്. പ്രശ്നത്തിന്റെ മൂലകാരണം സൈദ്ധാന്തികമായി എന്തും ആയിരിക്കാമെന്ന് ആ നിമിഷം വ്യക്തമായി.

ഹോസ്റ്റിനെ അന്വേഷിക്കുന്നു

ceph-osd പ്രക്രിയയ്ക്കുള്ളിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് നോക്കിക്കൊണ്ട് നമുക്ക് ആരംഭിക്കാം. ഇതിനായി ഞങ്ങൾ ഉപയോഗിക്കും perf и ഫ്ലേംസ്കോപ്പ് (ഇതിനെക്കുറിച്ച് നിങ്ങൾക്ക് കൂടുതൽ വായിക്കാൻ കഴിയും ഇവിടെ):

ചിത്രം നമ്മോട് പറയുന്നു ഫങ്ഷൻ fdatasync() ഫംഗ്‌ഷനുകളിലേക്ക് ഒരു അഭ്യർത്ഥന അയയ്‌ക്കാൻ ധാരാളം സമയം ചെലവഴിച്ചു generic_make_request(). ഇതിനർത്ഥം മിക്കവാറും പ്രശ്നങ്ങളുടെ കാരണം osd ഡെമണിന് പുറത്ത് എവിടെയോ ആയിരിക്കും എന്നാണ്. ഇത് കേർണലോ ഡിസ്കുകളോ ആകാം. bcache ഡിസ്കുകൾ വഴിയുള്ള അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നതിൽ iostat ഔട്ട്പുട്ട് ഉയർന്ന ലേറ്റൻസി കാണിച്ചു.

ഹോസ്റ്റ് പരിശോധിക്കുമ്പോൾ, systemd-udevd ഡെമൺ വലിയ അളവിൽ സിപിയു സമയം ചെലവഴിക്കുന്നതായി ഞങ്ങൾ കണ്ടെത്തി - നിരവധി കോറുകളിൽ ഏകദേശം 20%. ഇതൊരു വിചിത്രമായ പെരുമാറ്റമാണ്, എന്തുകൊണ്ടെന്ന് നിങ്ങൾ കണ്ടെത്തേണ്ടതുണ്ട്. Systemd-udevd uevents-ൽ പ്രവർത്തിക്കുന്നതിനാൽ, ഞങ്ങൾ അവ പരിശോധിക്കാൻ തീരുമാനിച്ചു udevadm മോണിറ്റർ. സിസ്റ്റത്തിലെ ഓരോ ബ്ലോക്ക് ഉപകരണത്തിനും ധാരാളം മാറ്റ പരിപാടികൾ സൃഷ്ടിച്ചതായി ഇത് മാറുന്നു. ഇത് തികച്ചും അസാധാരണമാണ്, അതിനാൽ ഈ ഇവന്റുകളെല്ലാം സൃഷ്ടിക്കുന്നത് എന്താണെന്ന് നമ്മൾ നോക്കേണ്ടതുണ്ട്.

BCC ടൂൾകിറ്റ് ഉപയോഗിക്കുന്നു

ഞങ്ങൾ ഇതിനകം കണ്ടെത്തിയതുപോലെ, കേർണൽ (സിസ്റ്റം കോളിലെ സെഫ് ഡെമൺ) ധാരാളം സമയം ചെലവഴിക്കുന്നു generic_make_request(). ഈ ഫംഗ്ഷന്റെ വേഗത അളക്കാൻ ശ്രമിക്കാം. IN ബി.സി.സി. ഇതിനകം ഒരു അത്ഭുതകരമായ യൂട്ടിലിറ്റി ഉണ്ട് - ഫൺക്ലേറ്റൻസി. ഔട്ട്‌പുട്ടുകൾക്കിടയിലുള്ള 1 സെക്കൻഡ് ഇടവേളയിൽ ഞങ്ങൾ ഡെമനെ അതിന്റെ PID ഉപയോഗിച്ച് കണ്ടെത്തുകയും ഫലം മില്ലിസെക്കൻഡിൽ ഔട്ട്പുട്ട് ചെയ്യുകയും ചെയ്യും.

ഈ സവിശേഷത സാധാരണയായി വേഗത്തിൽ പ്രവർത്തിക്കുന്നു. ഡിവൈസ് ഡ്രൈവർ ക്യൂവിലേക്ക് അഭ്യർത്ഥന കൈമാറുക മാത്രമാണ് ഇത് ചെയ്യുന്നത്.

Bcache യഥാർത്ഥത്തിൽ മൂന്ന് ഡിസ്കുകൾ ഉൾക്കൊള്ളുന്ന ഒരു സങ്കീർണ്ണ ഉപകരണമാണ്:

• ബാക്കിംഗ് ഉപകരണം (കാഷെഡ് ഡിസ്ക്), ഈ സാഹചര്യത്തിൽ ഇത് ഒരു വേഗത കുറഞ്ഞ HDD ആണ്;
• കാഷിംഗ് ഉപകരണം (കാഷിംഗ് ഡിസ്ക്), ഇവിടെ ഇത് NVMe ഉപകരണത്തിന്റെ ഒരു പാർട്ടീഷൻ ആണ്;
• ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്ന bcache വെർച്വൽ ഉപകരണം.

അഭ്യർത്ഥന സംപ്രേക്ഷണം മന്ദഗതിയിലാണെന്ന് ഞങ്ങൾക്കറിയാം, എന്നാൽ ഈ ഉപകരണങ്ങളിൽ ഏതാണ്? ഞങ്ങൾ ഇത് കുറച്ച് കഴിഞ്ഞ് കൈകാര്യം ചെയ്യും.

ഇവന്റുകൾ പ്രശ്നങ്ങൾ ഉണ്ടാക്കാൻ സാധ്യതയുണ്ടെന്ന് ഇപ്പോൾ നമുക്കറിയാം. അവരുടെ തലമുറയ്ക്ക് എന്താണ് കാരണമാകുന്നതെന്ന് കണ്ടെത്തുന്നത് അത്ര എളുപ്പമല്ല. ഇത് ആനുകാലികമായി സമാരംഭിക്കുന്ന ഒരുതരം സോഫ്‌റ്റ്‌വെയർ ആണെന്ന് കരുതുക. സ്ക്രിപ്റ്റ് ഉപയോഗിച്ച് ഏത് തരത്തിലുള്ള സോഫ്റ്റ്വെയറാണ് സിസ്റ്റത്തിൽ പ്രവർത്തിക്കുന്നതെന്ന് നോക്കാം execsnoop അതിൽ നിന്ന് BCC യൂട്ടിലിറ്റി കിറ്റ്. നമുക്ക് അത് പ്രവർത്തിപ്പിച്ച് ഔട്ട്പുട്ട് ഒരു ഫയലിലേക്ക് അയയ്ക്കാം.

ഉദാഹരണത്തിന് ഇതുപോലെ:

/usr/share/bcc/tools/execsnoop  | tee ./execdump

execsnoop-ന്റെ മുഴുവൻ ഔട്ട്‌പുട്ടും ഞങ്ങൾ ഇവിടെ കാണിക്കില്ല, എന്നാൽ ഞങ്ങൾക്ക് താൽപ്പര്യമുള്ള ഒരു വരി ഇതുപോലെ കാണപ്പെട്ടു:

sh 1764905 5802 0 sudo arcconf getconfig 1 AD | grep Temperature | awk -F '[:/]' '{print $2}' | sed 's/^ ([0-9]*) C.*/1/'

മൂന്നാമത്തെ കോളം പ്രക്രിയയുടെ PPID (രക്ഷാകർതൃ PID) ആണ്. PID 5802 ഉപയോഗിച്ചുള്ള പ്രക്രിയ ഞങ്ങളുടെ മോണിറ്ററിംഗ് സിസ്റ്റത്തിന്റെ ത്രെഡുകളിലൊന്നായി മാറി. മോണിറ്ററിംഗ് സിസ്റ്റത്തിന്റെ കോൺഫിഗറേഷൻ പരിശോധിക്കുമ്പോൾ, തെറ്റായ പാരാമീറ്ററുകൾ കണ്ടെത്തി. HBA അഡാപ്റ്ററിന്റെ താപനില ഓരോ 30 സെക്കൻഡിലും എടുക്കുന്നു, ഇത് ആവശ്യമുള്ളതിനേക്കാൾ വളരെ കൂടുതലാണ്. ചെക്ക് ഇടവേള ദൈർഘ്യമേറിയ ഒന്നാക്കി മാറ്റിയതിന് ശേഷം, മറ്റ് ഹോസ്റ്റുകളുമായി താരതമ്യം ചെയ്യുമ്പോൾ ഈ ഹോസ്റ്റിലെ അഭ്യർത്ഥന പ്രോസസ്സിംഗ് ലേറ്റൻസി വേറിട്ട് നിൽക്കുന്നില്ലെന്ന് ഞങ്ങൾ കണ്ടെത്തി.

എന്നാൽ bcache ഉപകരണം ഇത്ര മന്ദഗതിയിലായത് എന്തുകൊണ്ടാണെന്ന് ഇപ്പോഴും വ്യക്തമല്ല. സമാനമായ കോൺഫിഗറേഷനുള്ള ഒരു ടെസ്റ്റ് പ്ലാറ്റ്‌ഫോം ഞങ്ങൾ തയ്യാറാക്കി, bcache-ൽ fio പ്രവർത്തിപ്പിച്ച് പ്രശ്‌നം പുനർനിർമ്മിക്കാൻ ശ്രമിച്ചു, uevents സൃഷ്‌ടിക്കാൻ udevadm ട്രിഗർ ഇടയ്‌ക്കിടെ പ്രവർത്തിപ്പിക്കുന്നു.

BCC അടിസ്ഥാനമാക്കിയുള്ള ഉപകരണങ്ങൾ എഴുതുന്നു

വേഗത കുറഞ്ഞ കോളുകൾ കണ്ടെത്താനും പ്രദർശിപ്പിക്കാനും ലളിതമായ ഒരു യൂട്ടിലിറ്റി എഴുതാൻ ശ്രമിക്കാം generic_make_request(). ഈ ഫംഗ്‌ഷൻ വിളിച്ച ഡ്രൈവിന്റെ പേരിലും ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ട്.

പദ്ധതി ലളിതമാണ്:

• രജിസ്റ്റർ ചെയ്യുക kprobe ഓൺ generic_make_request():
  • ഞങ്ങൾ ഡിസ്കിന്റെ പേര് മെമ്മറിയിലേക്ക് സംരക്ഷിക്കുന്നു, ഫംഗ്ഷൻ ആർഗ്യുമെന്റിലൂടെ ആക്സസ് ചെയ്യാൻ കഴിയും;
  • ഞങ്ങൾ ടൈംസ്റ്റാമ്പ് സംരക്ഷിക്കുന്നു.

• രജിസ്റ്റർ ചെയ്യുക ക്രെറ്റ്പ്രോബ് നിന്ന് മടങ്ങിവരുന്നതിന് generic_make_request():
  • ഞങ്ങൾക്ക് നിലവിലെ ടൈംസ്റ്റാമ്പ് ലഭിക്കും;
  • ഞങ്ങൾ സംരക്ഷിച്ച ടൈംസ്റ്റാമ്പിനായി നോക്കുകയും നിലവിലെ സമയവുമായി താരതമ്യം ചെയ്യുകയും ചെയ്യുന്നു;
  • ഫലം വ്യക്തമാക്കിയതിനേക്കാൾ വലുതാണെങ്കിൽ, ഞങ്ങൾ സംരക്ഷിച്ച ഡിസ്കിന്റെ പേര് കണ്ടെത്തി ടെർമിനലിൽ പ്രദർശിപ്പിക്കും.

കെപ്രോബ്സ് и ക്രെറ്റ്പ്രോബ്സ് ഫ്ലൈയിൽ ഫംഗ്‌ഷൻ കോഡ് മാറ്റാൻ ബ്രേക്ക്‌പോയിന്റ് മെക്കാനിസം ഉപയോഗിക്കുക. നിങ്ങൾക്ക് വായിക്കാം പ്രമാണീകരണം и ഒരു നല്ല ഈ വിഷയത്തെക്കുറിച്ചുള്ള ലേഖനം. നിങ്ങൾ വിവിധ യൂട്ടിലിറ്റികളുടെ കോഡ് നോക്കുകയാണെങ്കിൽ ബി.സി.സി., അപ്പോൾ അവയ്ക്ക് സമാനമായ ഒരു ഘടനയുണ്ടെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും. അതിനാൽ ഈ ലേഖനത്തിൽ ഞങ്ങൾ സ്‌ക്രിപ്റ്റ് ആർഗ്യുമെന്റുകൾ പാഴ്‌സിംഗ് ഒഴിവാക്കി BPF പ്രോഗ്രാമിലേക്ക് തന്നെ പോകും.

പൈത്തൺ സ്ക്രിപ്റ്റിനുള്ളിലെ eBPF ടെക്സ്റ്റ് ഇതുപോലെ കാണപ്പെടുന്നു:

bpf_text = “”” # Here will be the bpf program code “””

ഫംഗ്‌ഷനുകൾക്കിടയിൽ ഡാറ്റ കൈമാറ്റം ചെയ്യുന്നതിന്, eBPF പ്രോഗ്രാമുകൾ ഉപയോഗിക്കുന്നു ഹാഷ് പട്ടികകൾ. ഞങ്ങളും അങ്ങനെ തന്നെ ചെയ്യും. ഞങ്ങൾ പ്രോസസ് PID കീ ആയി ഉപയോഗിക്കുകയും ഘടനയെ മൂല്യമായി നിർവചിക്കുകയും ചെയ്യും:

struct data_t {
	u64 pid;
	u64 ts;
	char comm[TASK_COMM_LEN];
	u64 lat;
	char disk[DISK_NAME_LEN];
};

BPF_HASH(p, u64, struct data_t);
BPF_PERF_OUTPUT(events);

ഇവിടെ നമ്മൾ ഒരു ഹാഷ് ടേബിൾ രജിസ്റ്റർ ചെയ്യുന്നു p, കീ തരം ഉപയോഗിച്ച് u64 തരം മൂല്യവും struct data_t. ഞങ്ങളുടെ BPF പ്രോഗ്രാമിന്റെ പശ്ചാത്തലത്തിൽ പട്ടിക ലഭ്യമാകും. BPF_PERF_OUTPUT മാക്രോ മറ്റൊരു പട്ടിക രജിസ്റ്റർ ചെയ്യുന്നു ഇവന്റുകൾ, ഇതിനായി ഉപയോഗിക്കുന്നു ഡാറ്റ ട്രാൻസ്മിഷൻ ഉപയോക്തൃ സ്ഥലത്തേക്ക്.

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

അടുത്തതായി, പഠനത്തിൻ കീഴിലുള്ള ഫംഗ്‌ഷൻ വിളിക്കുമ്പോൾ റൺ ചെയ്യുന്ന കോഡ് ഞങ്ങൾ എഴുതേണ്ടതുണ്ട്:

void start(struct pt_regs *ctx, struct bio *bio) {
	u64 pid = bpf_get_current_pid_tgid();
	struct data_t data = {};
	u64 ts = bpf_ktime_get_ns();
	data.pid = pid;
	data.ts = ts;
	bpf_probe_read_str(&data.disk, sizeof(data.disk), (void*)bio->bi_disk->disk_name);
	p.update(&pid, &data);
}

ഇവിടെ വിളിക്കപ്പെടുന്ന ഫംഗ്‌ഷന്റെ ആദ്യ ആർഗ്യുമെന്റ് രണ്ടാമത്തെ ആർഗ്യുമെന്റായി മാറ്റിസ്ഥാപിക്കും generic_make_request(). ഇതിനുശേഷം, ഞങ്ങൾ പ്രവർത്തിക്കുന്ന പശ്ചാത്തലത്തിലുള്ള പ്രക്രിയയുടെ PID, നാനോ സെക്കൻഡിൽ നിലവിലെ ടൈംസ്റ്റാമ്പ് എന്നിവ ലഭിക്കും. ഞങ്ങൾ അതെല്ലാം പുതുതായി തിരഞ്ഞെടുത്തതിൽ എഴുതുന്നു struct data_t ഡാറ്റ. ഘടനയിൽ നിന്നാണ് നമുക്ക് ഡിസ്കിന്റെ പേര് ലഭിക്കുന്നത് ബയോ, വിളിക്കുമ്പോൾ കടന്നുപോകുന്നത് generic_make_request(), അതേ ഘടനയിൽ അത് സംരക്ഷിക്കുക ഡാറ്റ. നേരത്തെ സൂചിപ്പിച്ച ഹാഷ് ടേബിളിലേക്ക് ഒരു എൻട്രി ചേർക്കുക എന്നതാണ് അവസാന ഘട്ടം.

ഇനിപ്പറയുന്ന ഫംഗ്‌ഷൻ തിരികെ വരുമ്പോൾ വിളിക്കപ്പെടും generic_make_request():

void stop(struct pt_regs *ctx) {
    u64 pid = bpf_get_current_pid_tgid();
    u64 ts = bpf_ktime_get_ns();
    struct data_t* data = p.lookup(&pid);
    if (data != 0 && data->ts > 0) {
        bpf_get_current_comm(&data->comm, sizeof(data->comm));
        data->lat = (ts - data->ts)/1000;
        if (data->lat > MIN_US) {
            FACTOR
            data->pid >>= 32;
            events.perf_submit(ctx, data, sizeof(struct data_t));
        }
        p.delete(&pid);
    }
}

ഈ ഫംഗ്‌ഷൻ മുമ്പത്തേതിന് സമാനമാണ്: പ്രോസസ്സിന്റെ PID, ടൈംസ്റ്റാമ്പ് എന്നിവ ഞങ്ങൾ കണ്ടെത്തുന്നു, പക്ഷേ പുതിയ ഡാറ്റാ ഘടനയ്‌ക്കായി മെമ്മറി അനുവദിക്കരുത്. പകരം, == നിലവിലുള്ള PID എന്ന കീ ഉപയോഗിച്ച് ഞങ്ങൾ ഇതിനകം നിലവിലുള്ള ഘടനയ്ക്കായി ഹാഷ് ടേബിളിൽ തിരയുന്നു. ഘടന കണ്ടെത്തിയാൽ, പ്രവർത്തിക്കുന്ന പ്രക്രിയയുടെ പേര് ഞങ്ങൾ കണ്ടെത്തി അതിൽ ചേർക്കുക.

ത്രെഡ് GID ലഭിക്കാൻ നമ്മൾ ഇവിടെ ഉപയോഗിക്കുന്ന ബൈനറി ഷിഫ്റ്റ് ആവശ്യമാണ്. ആ. ഞങ്ങൾ പ്രവർത്തിക്കുന്ന പശ്ചാത്തലത്തിൽ ത്രെഡ് ആരംഭിച്ച പ്രധാന പ്രക്രിയയുടെ PID. ഞങ്ങൾ വിളിക്കുന്ന പ്രവർത്തനം bpf_get_current_pid_tgid() ത്രെഡിന്റെ GID-യും PID-യും ഒരൊറ്റ 64-ബിറ്റ് മൂല്യത്തിൽ നൽകുന്നു.

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

ഈ കോഡ് ലോഡുചെയ്യുന്ന പൈത്തൺ സ്‌ക്രിപ്റ്റിൽ, ഞങ്ങൾ MIN_US, FACTOR എന്നിവയ്ക്ക് പകരം കാലതാമസ പരിധികളും സമയ യൂണിറ്റുകളും നൽകേണ്ടതുണ്ട്, അത് ഞങ്ങൾ ആർഗ്യുമെന്റുകളിലൂടെ കടന്നുപോകും:

bpf_text = bpf_text.replace('MIN_US',str(min_usec))
if args.milliseconds:
	bpf_text = bpf_text.replace('FACTOR','data->lat /= 1000;')
	label = "msec"
else:
	bpf_text = bpf_text.replace('FACTOR','')
	label = "usec"

ഇപ്പോൾ നമ്മൾ ബിപിഎഫ് പ്രോഗ്രാം തയ്യാറാക്കേണ്ടതുണ്ട് ബിപിഎഫ് മാക്രോ കൂടാതെ സാമ്പിളുകൾ രജിസ്റ്റർ ചെയ്യുക:

b = BPF(text=bpf_text)
b.attach_kprobe(event="generic_make_request",fn_name="start")
b.attach_kretprobe(event="generic_make_request",fn_name="stop")

നമുക്കും നിശ്ചയിക്കേണ്ടി വരും struct data_t ഞങ്ങളുടെ സ്ക്രിപ്റ്റിൽ, അല്ലാത്തപക്ഷം ഞങ്ങൾക്ക് ഒന്നും വായിക്കാൻ കഴിയില്ല:

TASK_COMM_LEN = 16	# linux/sched.h
DISK_NAME_LEN = 32	# linux/genhd.h
class Data(ct.Structure):
	_fields_ = [("pid", ct.c_ulonglong),
            	("ts", ct.c_ulonglong),
            	("comm", ct.c_char * TASK_COMM_LEN),
            	("lat", ct.c_ulonglong),
            	("disk",ct.c_char * DISK_NAME_LEN)]

ടെർമിനലിലേക്ക് ഡാറ്റ ഔട്ട്പുട്ട് ചെയ്യുക എന്നതാണ് അവസാന ഘട്ടം:

def print_event(cpu, data, size):
    global start
    event = ct.cast(data, ct.POINTER(Data)).contents
    if start == 0:
        start = event.ts
    time_s = (float(event.ts - start)) / 1000000000
    print("%-18.9f %-16s %-6d   %-1s %s   %s" % (time_s, event.comm, event.pid, event.lat, label, event.disk))

b["events"].open_perf_buffer(print_event)
# format output
start = 0
while 1:
    try:
        b.perf_buffer_poll()
    except KeyboardInterrupt:
        exit()

സ്ക്രിപ്റ്റ് തന്നെ ഇവിടെ ലഭ്യമാണ് GITHub. fio പ്രവർത്തിക്കുന്ന ഒരു ടെസ്റ്റ് പ്ലാറ്റ്‌ഫോമിൽ ഇത് പ്രവർത്തിപ്പിക്കാൻ ശ്രമിക്കാം, bcache-ലേക്ക് എഴുതുക, കൂടാതെ udevadm മോണിറ്ററിനെ വിളിക്കുക:

ഒടുവിൽ! സ്റ്റാളിംഗ് bcache ഉപകരണം പോലെ കാണപ്പെടുന്നത് യഥാർത്ഥത്തിൽ ഒരു സ്റ്റാളിംഗ് കോൾ ആണെന്ന് ഇപ്പോൾ നമ്മൾ കാണുന്നു generic_make_request() ഒരു കാഷെ ചെയ്ത ഡിസ്കിനായി.

കേർണലിലേക്ക് കുഴിക്കുക

അഭ്യർത്ഥന ട്രാൻസ്മിഷൻ സമയത്ത് വേഗത കുറയ്ക്കുന്നത് എന്താണ്? അഭ്യർത്ഥന അക്കൗണ്ടിംഗ് ആരംഭിക്കുന്നതിന് മുമ്പുതന്നെ കാലതാമസം സംഭവിക്കുന്നതായി ഞങ്ങൾ കാണുന്നു, അതായത്. അതിലെ സ്ഥിതിവിവരക്കണക്കുകളുടെ (/proc/diskstats അല്ലെങ്കിൽ iostat) കൂടുതൽ ഔട്ട്‌പുട്ടിനായുള്ള ഒരു നിർദ്ദിഷ്ട അഭ്യർത്ഥനയുടെ അക്കൗണ്ടിംഗ് ഇതുവരെ ആരംഭിച്ചിട്ടില്ല. പ്രശ്നം പുനർനിർമ്മിക്കുമ്പോൾ iostat പ്രവർത്തിപ്പിക്കുന്നതിലൂടെ ഇത് എളുപ്പത്തിൽ പരിശോധിക്കാവുന്നതാണ്, അല്ലെങ്കിൽ BCC സ്ക്രിപ്റ്റ് ബയോലേറ്റൻസി, ഇത് അഭ്യർത്ഥന അക്കൗണ്ടിംഗിന്റെ തുടക്കവും അവസാനവും അടിസ്ഥാനമാക്കിയുള്ളതാണ്. ഈ യൂട്ടിലിറ്റികളൊന്നും കാഷെ ചെയ്ത ഡിസ്കിലേക്കുള്ള അഭ്യർത്ഥനകൾക്ക് പ്രശ്നങ്ങൾ കാണിക്കില്ല.

നമ്മൾ ഫംഗ്ഷൻ നോക്കിയാൽ generic_make_request(), അഭ്യർത്ഥന അക്കൗണ്ടിംഗ് ആരംഭിക്കുന്നതിന് മുമ്പ്, രണ്ട് ഫംഗ്ഷനുകൾ കൂടി വിളിക്കുന്നത് ഞങ്ങൾ കാണും. ആദ്യം - generic_make_request_checks(), ഡിസ്ക് ക്രമീകരണങ്ങൾ സംബന്ധിച്ച അഭ്യർത്ഥനയുടെ നിയമസാധുത പരിശോധിക്കുന്നു. രണ്ടാമത്തേത് - blk_queue_enter(), രസകരമായ ഒരു വെല്ലുവിളിയുണ്ട് കാത്തിരിക്കുക_event_interruptible():

ret = wait_event_interruptible(q->mq_freeze_wq,
	(atomic_read(&q->mq_freeze_depth) == 0 &&
	(preempt || !blk_queue_preempt_only(q))) ||
	blk_queue_dying(q));

അതിൽ, ക്യൂ അൺഫ്രീസ് ചെയ്യുന്നതിനായി കേർണൽ കാത്തിരിക്കുന്നു. കാലതാമസം അളക്കാം blk_queue_enter():

~# /usr/share/bcc/tools/funclatency  blk_queue_enter -i 1 -m               	 
Tracing 1 functions for "blk_queue_enter"... Hit Ctrl-C to end.

 	msecs           	: count 	distribution
     	0 -> 1      	: 341  	|****************************************|

 	msecs           	: count 	distribution
     	0 -> 1      	: 316  	|****************************************|

 	msecs           	: count 	distribution
     	0 -> 1      	: 255  	|****************************************|
     	2 -> 3      	: 0    	|                                    	|
     	4 -> 7      	: 0    	|                                    	|
     	8 -> 15     	: 1    	|                                    	|

ഞങ്ങൾ ഒരു പരിഹാരത്തിനടുത്തെത്തിയതായി തോന്നുന്നു. ഒരു ക്യൂ ഫ്രീസ്/അൺഫ്രീസ് ചെയ്യാൻ ഉപയോഗിക്കുന്ന ഫംഗ്‌ഷനുകൾ ഇവയാണ് blk_mq_freeze_queue и blk_mq_unfreeze_queue. ഈ ക്യൂവിലെ അഭ്യർത്ഥനകൾക്ക് അപകടകരമായേക്കാവുന്ന, അഭ്യർത്ഥന ക്യൂ ക്രമീകരണങ്ങൾ മാറ്റേണ്ടിവരുമ്പോൾ അവ ഉപയോഗിക്കുന്നു. വിളിക്കുമ്പോൾ blk_mq_freeze_queue() പ്രവർത്തനം blk_freeze_queue_start() കൗണ്ടർ വർദ്ധിപ്പിച്ചു q->mq_freeze_depth. ഇതിനുശേഷം, ക്യൂ ശൂന്യമാകുന്നതിനായി കേർണൽ കാത്തിരിക്കുന്നു blk_mq_freeze_queue_wait().

ക്യൂവിലുള്ള എല്ലാ പ്രവർത്തനങ്ങളും പൂർത്തിയാകുന്നതിനായി കേർണൽ കാത്തിരിക്കുന്നതിനാൽ ഈ ക്യൂ മായ്ക്കാൻ എടുക്കുന്ന സമയം ഡിസ്ക് ലേറ്റൻസിക്ക് തുല്യമാണ്. ക്യൂ ശൂന്യമായാൽ, ക്രമീകരണ മാറ്റങ്ങൾ ബാധകമാകും. അതിനുശേഷം വിളിക്കപ്പെടുന്നു blk_mq_unfreeze_queue(), കൌണ്ടർ കുറയ്ക്കുന്നു ഫ്രീസ്_ഡെപ്ത്.

സാഹചര്യം ശരിയാക്കാൻ ഇപ്പോൾ ഞങ്ങൾക്ക് വേണ്ടത്ര അറിയാം. udevadm ട്രിഗർ കമാൻഡ് ബ്ലോക്ക് ഉപകരണത്തിനായുള്ള ക്രമീകരണങ്ങൾ പ്രയോഗിക്കുന്നതിന് കാരണമാകുന്നു. ഈ ക്രമീകരണങ്ങൾ udev നിയമങ്ങളിൽ വിവരിച്ചിരിക്കുന്നു. ഏതൊക്കെ ക്രമീകരണങ്ങളാണ് ക്യൂ ഫ്രീസ് ചെയ്യുന്നതെന്ന് sysfs വഴിയോ കേർണൽ സോഴ്‌സ് കോഡ് നോക്കിയോ മാറ്റാൻ ശ്രമിച്ചുകൊണ്ട് നമുക്ക് കണ്ടെത്താനാകും. നമുക്ക് BCC യൂട്ടിലിറ്റിയും പരീക്ഷിക്കാം പിന്തുടരുക, ഇത് ടെർമിനലിലേക്കുള്ള ഓരോ കോളിനും കേർണലും യൂസർസ്‌പേസ് സ്റ്റാക്ക് ട്രെയ്‌സുകളും ഔട്ട്‌പുട്ട് ചെയ്യും blk_freeze_queueഉദാഹരണത്തിന്:

~# /usr/share/bcc/tools/trace blk_freeze_queue -K -U
PID 	TID 	COMM        	FUNC        	 
3809642 3809642 systemd-udevd   blk_freeze_queue
    	blk_freeze_queue+0x1 [kernel]
    	elevator_switch+0x29 [kernel]
    	elv_iosched_store+0x197 [kernel]
    	queue_attr_store+0x5c [kernel]
    	sysfs_kf_write+0x3c [kernel]
    	kernfs_fop_write+0x125 [kernel]
    	__vfs_write+0x1b [kernel]
    	vfs_write+0xb8 [kernel]
    	sys_write+0x55 [kernel]
    	do_syscall_64+0x73 [kernel]
    	entry_SYSCALL_64_after_hwframe+0x3d [kernel]
    	__write_nocancel+0x7 [libc-2.23.so]
    	[unknown]

3809631 3809631 systemd-udevd   blk_freeze_queue
    	blk_freeze_queue+0x1 [kernel]
    	queue_requests_store+0xb6 [kernel]
    	queue_attr_store+0x5c [kernel]
    	sysfs_kf_write+0x3c [kernel]
    	kernfs_fop_write+0x125 [kernel]
    	__vfs_write+0x1b [kernel]
    	vfs_write+0xb8 [kernel]
    	sys_write+0x55 [kernel]
    	do_syscall_64+0x73 [kernel]
    	entry_SYSCALL_64_after_hwframe+0x3d [kernel]
    	__write_nocancel+0x7 [libc-2.23.so]
    	[unknown]

Udev നിയമങ്ങൾ വളരെ അപൂർവ്വമായി മാത്രമേ മാറുന്നുള്ളൂ, സാധാരണയായി ഇത് നിയന്ത്രിത രീതിയിലാണ് സംഭവിക്കുന്നത്. അതിനാൽ, ഇതിനകം സജ്ജീകരിച്ച മൂല്യങ്ങൾ പ്രയോഗിക്കുന്നത് പോലും ആപ്ലിക്കേഷനിൽ നിന്ന് ഡിസ്കിലേക്ക് അഭ്യർത്ഥന കൈമാറുന്നതിനുള്ള കാലതാമസത്തിന് കാരണമാകുമെന്ന് ഞങ്ങൾ കാണുന്നു. തീർച്ചയായും, ഡിസ്ക് കോൺഫിഗറേഷനിൽ മാറ്റങ്ങളൊന്നും ഇല്ലാത്തപ്പോൾ udev ഇവന്റുകൾ സൃഷ്ടിക്കുന്നത് (ഉദാഹരണത്തിന്, ഉപകരണം മൌണ്ട് ചെയ്തിട്ടില്ല/വിച്ഛേദിച്ചിട്ടില്ല) ഒരു നല്ല രീതിയല്ല. എന്നിരുന്നാലും, കേർണലിനെ അനാവശ്യമായി പ്രവർത്തിക്കാതിരിക്കാനും ആവശ്യമില്ലെങ്കിൽ അഭ്യർത്ഥന ക്യൂ മരവിപ്പിക്കാനും നമുക്ക് സഹായിക്കാനാകും. മൂന്ന് ചെറിയ പ്രതിബദ്ധത സാഹചര്യം ശരിയാക്കുക.

തീരുമാനം

eBPF വളരെ വഴക്കമുള്ളതും ശക്തവുമായ ഒരു ഉപകരണമാണ്. ലേഖനത്തിൽ ഞങ്ങൾ ഒരു പ്രായോഗിക കേസ് നോക്കുകയും എന്തുചെയ്യാൻ കഴിയുമെന്നതിന്റെ ഒരു ചെറിയ ഭാഗം പ്രകടിപ്പിക്കുകയും ചെയ്തു. BCC യൂട്ടിലിറ്റികൾ വികസിപ്പിക്കാൻ നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ, അത് നോക്കേണ്ടതാണ് ഔദ്യോഗിക ട്യൂട്ടോറിയൽ, ഇത് അടിസ്ഥാനകാര്യങ്ങൾ നന്നായി വിവരിക്കുന്നു.

eBPF അടിസ്ഥാനമാക്കിയുള്ള മറ്റ് രസകരമായ ഡീബഗ്ഗിംഗ്, പ്രൊഫൈലിംഗ് ടൂളുകൾ ഉണ്ട്. അവരിൽ ഒരാൾ - bpftrace, ഇത് awk പോലുള്ള ഭാഷയിൽ ശക്തമായ വൺ-ലൈനറുകളും ചെറിയ പ്രോഗ്രാമുകളും എഴുതാൻ നിങ്ങളെ അനുവദിക്കുന്നു. മറ്റൊന്ന് - ebpf_exporter, പിന്നീട് മനോഹരമായ വിഷ്വലൈസേഷനുകളും അലേർട്ടുകളും നേടാനുള്ള കഴിവിനൊപ്പം താഴ്ന്ന-ലെവൽ, ഉയർന്ന റെസല്യൂഷൻ മെട്രിക്‌സ് നേരിട്ട് നിങ്ങളുടെ പ്രോമിത്യൂസ് സെർവറിലേക്ക് ശേഖരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

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