eBPF/BCC નો ઉપયોગ કરીને ઉચ્ચ Ceph લેટન્સીથી કર્નલ પેચ સુધી

Linux પાસે કર્નલ અને એપ્લીકેશનને ડીબગ કરવા માટે મોટી સંખ્યામાં સાધનો છે. તેમાંના મોટા ભાગના એપ્લિકેશનની કામગીરી પર નકારાત્મક અસર કરે છે અને ઉત્પાદનમાં તેનો ઉપયોગ કરી શકાતો નથી.

વર્ષો પહેલા ત્યાં હતો બીજું સાધન વિકસાવવામાં આવ્યું છે - eBPF. તે કર્નલ અને યુઝર એપ્લીકેશનને ઓછા ઓવરહેડ સાથે અને પ્રોગ્રામને ફરીથી બનાવવાની અને કર્નલમાં તૃતીય-પક્ષ મોડ્યુલો લોડ કરવાની જરૂર વગર ટ્રેસ કરવાનું શક્ય બનાવે છે.

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

સેફ ધીમું છે

Ceph ક્લસ્ટરમાં એક નવું હોસ્ટ ઉમેરવામાં આવ્યું છે. કેટલાક ડેટાને તેમાં સ્થાનાંતરિત કર્યા પછી, અમે નોંધ્યું કે તેના દ્વારા લખવાની વિનંતીઓ પર પ્રક્રિયા કરવાની ઝડપ અન્ય સર્વર્સ કરતાં ઘણી ઓછી હતી.

અન્ય પ્લેટફોર્મથી વિપરીત, આ હોસ્ટ bcache અને નવા linux 4.15 કર્નલનો ઉપયોગ કરે છે. આ રૂપરેખાંકનના યજમાનનો અહીં ઉપયોગ પ્રથમ વખત થયો હતો. અને તે ક્ષણે તે સ્પષ્ટ હતું કે સમસ્યાનું મૂળ સૈદ્ધાંતિક રીતે કંઈપણ હોઈ શકે છે.

યજમાનની તપાસ

ચાલો ceph-osd પ્રક્રિયાની અંદર શું થાય છે તે જોઈને શરૂ કરીએ. આ માટે આપણે ઉપયોગ કરીશું પરફ и ફ્લેમસ્કોપ (જેના વિશે વધુ તમે વાંચી શકો છો અહીં):

ચિત્ર અમને કહે છે કે કાર્ય fdatasync() કાર્યોને વિનંતી મોકલવામાં ઘણો સમય પસાર કર્યો generic_make_request(). આનો અર્થ એ છે કે મોટાભાગે સમસ્યાઓનું કારણ osd ડિમનની બહાર ક્યાંક છે. આ કર્નલ અથવા ડિસ્ક હોઈ શકે છે. iostat આઉટપુટ bcache ડિસ્ક દ્વારા વિનંતીઓની પ્રક્રિયામાં ઉચ્ચ વિલંબ દર્શાવે છે.

યજમાનને તપાસતી વખતે, અમે જોયું કે systemd-udevd ડિમન મોટા પ્રમાણમાં CPU સમય વાપરે છે - કેટલાક કોરો પર લગભગ 20%. આ વિચિત્ર વર્તન છે, તેથી તમારે તેનું કારણ શોધવાની જરૂર છે. Systemd-udevd યુઇવેન્ટ્સ સાથે કામ કરતું હોવાથી, અમે તેમને જોવાનું નક્કી કર્યું udevadm મોનિટર. તે તારણ આપે છે કે સિસ્ટમમાં દરેક બ્લોક ઉપકરણ માટે મોટી સંખ્યામાં ફેરફારની ઘટનાઓ જનરેટ કરવામાં આવી હતી. આ તદ્દન અસામાન્ય છે, તેથી આપણે આ બધી ઘટનાઓ શું પેદા કરે છે તે જોવાનું રહેશે.

BCC ટૂલકીટનો ઉપયોગ કરવો

જેમ આપણે પહેલેથી જ શોધી કાઢ્યું છે, કર્નલ (અને સિસ્ટમ કોલમાં સેફ ડિમન) ઘણો સમય વિતાવે છે. generic_make_request(). ચાલો આ કાર્યની ઝડપને માપવાનો પ્રયાસ કરીએ. IN બીસીસી પહેલેથી જ એક અદ્ભુત ઉપયોગિતા છે - ફંકલેટન્સી. અમે આઉટપુટ વચ્ચે 1 સેકન્ડના અંતરાલ સાથે તેના PID દ્વારા ડિમનને ટ્રેસ કરીશું અને પરિણામ મિલિસેકન્ડમાં આઉટપુટ કરીશું.

આ સુવિધા સામાન્ય રીતે ઝડપથી કામ કરે છે. તે ફક્ત ઉપકરણ ડ્રાઇવર કતારમાં વિનંતી પસાર કરે છે.

Bcache એક જટિલ ઉપકરણ છે જે વાસ્તવમાં ત્રણ ડિસ્ક ધરાવે છે:

• બેકિંગ ડિવાઇસ (કેશ્ડ ડિસ્ક), આ કિસ્સામાં તે ધીમી HDD છે;
• કેશીંગ ઉપકરણ (કેશીંગ ડિસ્ક), અહીં આ NVMe ઉપકરણનું એક પાર્ટીશન છે;
• bcache વર્ચ્યુઅલ ઉપકરણ કે જેની સાથે એપ્લિકેશન ચાલે છે.

અમે જાણીએ છીએ કે વિનંતી ટ્રાન્સમિશન ધીમું છે, પરંતુ આમાંથી કયા ઉપકરણો માટે? અમે થોડા સમય પછી આ સાથે વ્યવહાર કરીશું.

અમે હવે જાણીએ છીએ કે uevents સમસ્યાઓનું કારણ બની શકે છે. તેમની પેઢીનું ચોક્કસ કારણ શું છે તે શોધવું એટલું સરળ નથી. ચાલો માની લઈએ કે આ અમુક પ્રકારનું સોફ્ટવેર છે જે સમયાંતરે લોન્ચ થાય છે. ચાલો જોઈએ કે સ્ક્રિપ્ટનો ઉપયોગ કરીને સિસ્ટમ પર કયા પ્રકારનું સોફ્ટવેર ચાલે છે 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():
  • અમે ડિસ્ક નામને મેમરીમાં સાચવીએ છીએ, ફંક્શન દલીલ દ્વારા સુલભ;
  • અમે ટાઇમસ્ટેમ્પ સાચવીએ છીએ.

• નોંધણી કરો kretprobe થી પરત કરવા માટે generic_make_request():
  • અમને વર્તમાન ટાઇમસ્ટેમ્પ મળે છે;
  • અમે સાચવેલ ટાઇમસ્ટેમ્પ શોધીએ છીએ અને તેની વર્તમાન સાથે સરખામણી કરીએ છીએ;
  • જો પરિણામ ઉલ્લેખિત કરતા વધારે હોય, તો અમે સાચવેલ ડિસ્ક નામ શોધીએ છીએ અને તેને ટર્મિનલ પર પ્રદર્શિત કરીએ છીએ.

Kprobes и kretprobes ફ્લાય પર ફંક્શન કોડ બદલવા માટે બ્રેકપોઇન્ટ મિકેનિઝમનો ઉપયોગ કરો. તમે વાંચી શકો છો દસ્તાવેજીકરણ и સારું આ વિષય પર લેખ. જો તમે માં વિવિધ ઉપયોગિતાઓના કોડ જુઓ બીસીસી, પછી તમે જોઈ શકો છો કે તેમની પાસે સમાન માળખું છે. તેથી આ લેખમાં આપણે સ્ક્રિપ્ટ દલીલોનું વિશ્લેષણ કરવાનું છોડી દઈશું અને 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 અને પ્રકારનું મૂલ્ય સ્ટ્રક્ચર ડેટા_ટી. ટેબલ અમારા 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 અને નેનોસેકન્ડમાં વર્તમાન ટાઈમસ્ટેમ્પ મેળવીએ છીએ. અમે તે બધું તાજી પસંદ કરેલામાં લખીએ છીએ સ્ટ્રક્ચર ડેટા_ટી ડેટા. અમને સ્ટ્રક્ચરમાંથી ડિસ્કનું નામ મળે છે બાયો, જે કૉલ કરતી વખતે પસાર થાય છે 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"

હવે આપણે BPF પ્રોગ્રામ મારફતે તૈયાર કરવાની જરૂર છે BPF મેક્રો અને નમૂનાઓ રજીસ્ટર કરો:

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")

આપણે પણ નક્કી કરવું પડશે સ્ટ્રક્ચર ડેટા_ટી અમારી સ્ક્રિપ્ટમાં, અન્યથા અમે કંઈપણ વાંચી શકીશું નહીં:

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(), જે એક રસપ્રદ પડકાર ધરાવે છે રાહ_ઘટના_વિક્ષેપકારક():

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