eBPF/BCC प्रयोग गरेर उच्च Ceph लेटन्सी देखि कर्नेल प्याच सम्म

लिनक्ससँग कर्नेल र अनुप्रयोगहरू डिबग गर्नका लागि ठूलो संख्यामा उपकरणहरू छन्। तिनीहरूमध्ये धेरैले अनुप्रयोग प्रदर्शनमा नकारात्मक प्रभाव पार्छ र उत्पादनमा प्रयोग गर्न सकिँदैन।

केही वर्ष पहिले त्यहाँ थियो अर्को उपकरण विकास गरिएको छ - eBPF। यसले कर्नेल र प्रयोगकर्ता अनुप्रयोगहरूलाई कम ओभरहेडको साथ र कार्यक्रमहरू पुन: निर्माण गर्न र कर्नेलमा तेस्रो-पक्ष मोड्युलहरू लोड गर्न आवश्यक बिना ट्रेस गर्न सम्भव बनाउँछ।

त्यहाँ पहिले नै धेरै अनुप्रयोग उपयोगिताहरू छन् जुन eBPF प्रयोग गर्दछ, र यस लेखमा हामी पुस्तकालयमा आधारित तपाइँको आफ्नै प्रोफाइलिङ उपयोगिता कसरी लेख्ने भनेर हेर्नेछौं। PythonBCC। लेख वास्तविक घटनामा आधारित छ। अवस्थित उपयोगिताहरू विशिष्ट परिस्थितिहरूमा कसरी प्रयोग गर्न सकिन्छ भनेर देखाउन हामी समस्याबाट समाधान गर्न जान्छौं।

Ceph ढिलो छ

Ceph क्लस्टरमा नयाँ होस्ट थपिएको छ। यसमा केही डाटा माइग्रेट गरेपछि, हामीले यो द्वारा लेखिएका अनुरोधहरू प्रशोधन गर्ने गति अन्य सर्भरहरूको तुलनामा धेरै कम भएको देख्यौं।

अन्य प्लेटफर्महरूको विपरीत, यो होस्टले bcache र नयाँ लिनक्स 4.15 कर्नेल प्रयोग गर्यो। यो कन्फिगरेसनको होस्ट यहाँ प्रयोग गरिएको यो पहिलो पटक थियो। र त्यस क्षणमा यो स्पष्ट थियो कि समस्याको जरा सैद्धान्तिक रूपमा केहि पनि हुन सक्छ।

आयोजकको खोजी गर्दै

ceph-osd प्रक्रिया भित्र के हुन्छ हेरेर सुरु गरौं। यसका लागि हामी प्रयोग गर्नेछौं perf и फ्लेमस्कोप (जसको बारेमा तपाईले पढ्न सक्नुहुन्छ यहाँ):

तस्विरले हामीलाई बताउँछ कि कार्य fdatasync() कार्यहरूमा अनुरोध पठाउन धेरै समय खर्च भयो generic_make_request()। यसको मतलब यो हो कि सम्भवतः समस्या को कारण कतै osd डेमन बाहिर नै छ। यो या त कर्नेल वा डिस्क हुन सक्छ। iostat आउटपुटले bcache डिस्कहरू द्वारा प्रशोधन अनुरोधहरूमा उच्च विलम्बता देखायो।

होस्ट जाँच गर्दा, हामीले पत्ता लगायौं कि systemd-udevd डेमनले CPU समयको ठूलो मात्रा खपत गर्छ - धेरै कोरहरूमा लगभग 20%। यो अनौठो व्यवहार हो, त्यसैले तपाईंले किन पत्ता लगाउन आवश्यक छ। Systemd-udevd ले uevents संग काम गरेको हुनाले, हामीले तिनीहरूलाई हेर्ने निर्णय गर्यौं udevadm मनिटर। यो बाहिर जान्छ कि प्रणालीमा प्रत्येक ब्लक उपकरणको लागि परिवर्तन घटनाहरूको ठूलो संख्या उत्पन्न भएको थियो। यो एकदम असामान्य छ, त्यसैले हामीले यी सबै घटनाहरू के उत्पन्न गर्छ भनेर हेर्नु पर्छ।

BCC Toolkit प्रयोग गर्दै

हामीले पहिले नै पत्ता लगाएका छौं, कर्नेल (र प्रणाली कलमा सेफ डेमन) धेरै समय खर्च गर्दछ। generic_make_request()। यस प्रकार्यको गति नाप्ने प्रयास गरौं। IN बीसीसी त्यहाँ पहिले नै एक अद्भुत उपयोगिता छ - funclatency। हामी डेमोनलाई यसको PID द्वारा आउटपुटहरू बीचको 1 सेकेन्ड अन्तरालमा ट्रेस गर्नेछौं र परिणाम मिलिसेकेन्डमा आउटपुट गर्नेछौं।

यो सुविधा सामान्यतया छिटो काम गर्दछ। सबै यो गर्छ कि यन्त्र चालक लाममा अनुरोध पास गर्दछ।

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 चलाएर समस्या पुन: उत्पादन गर्ने प्रयास गर्यौं, आवधिक रूपमा uevadm ट्रिगर चलाएर uevents उत्पन्न गर्न।

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 र प्रकारको मूल्य संरचना डेटा_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() एकल 64-बिट मानमा थ्रेडको GID र PID दुवै फर्काउँछ।

टर्मिनलमा आउटपुट गर्दा, हामी हाल थ्रेडमा रुचि राख्दैनौं, तर हामी मुख्य प्रक्रियामा रुचि राख्छौं। दिइएको थ्रेसहोल्डसँग नतिजा ढिलाइ तुलना गरेपछि, हामी हाम्रो संरचना पास गर्छौं डाटा तालिका मार्फत प्रयोगकर्ता ठाउँमा घटनाहरू, जस पछि हामी प्रविष्टि मेटाउँछौं 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")

हामीले पनि निर्धारण गर्नुपर्छ संरचना डेटा_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(), जसमा रोचक चुनौती छ प्रतीक्षा_घटना_अवरोधीय():

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