ከ High Ceph Latency ወደ Kernel Patch eBPF/BCC በመጠቀም

ሊኑክስ ከርነልን እና አፕሊኬሽኖችን ለማረም ብዙ መሳሪያዎች አሉት። አብዛኛዎቹ በመተግበሪያ አፈፃፀም ላይ አሉታዊ ተፅእኖ አላቸው እና በምርት ውስጥ ጥቅም ላይ ሊውሉ አይችሉም.

ከጥቂት አመታት በፊት ነበር ሌላ መሳሪያ ተዘጋጅቷል - ኢቢፒኤፍ የከርነል እና የተጠቃሚ አፕሊኬሽኖችን በዝቅተኛ ወጪ እና ፕሮግራሞችን እንደገና መገንባት እና የሶስተኛ ወገን ሞጁሎችን ወደ ከርነል መጫን ሳያስፈልግ ለመፈለግ ያስችላል።

eBPF ን የሚጠቀሙ ብዙ የመተግበሪያ መገልገያዎች አሉ ፣ እና በዚህ ጽሑፍ ውስጥ በቤተ-መጽሐፍት ላይ በመመስረት የራስዎን የመገለጫ መገልገያ እንዴት እንደሚጽፉ እንመለከታለን PythonBCC. ጽሑፉ በእውነተኛ ክስተቶች ላይ የተመሰረተ ነው. አሁን ያሉ መገልገያዎችን በልዩ ሁኔታዎች ውስጥ እንዴት መጠቀም እንደሚቻል ለማሳየት ከችግሩ ወደ ማስተካከል እንሄዳለን።

ሴፍ ቀርፋፋ ነው።

አዲስ አስተናጋጅ ወደ ሴፍ ክላስተር ታክሏል። አንዳንድ መረጃዎችን ወደ እሱ ከተዛወርን በኋላ፣ በሱ የሚደረጉ የጽሁፍ ጥያቄዎችን የማዘጋጀት ፍጥነት ከሌሎች አገልጋዮች በጣም ያነሰ መሆኑን አስተውለናል።

ከሌሎች የመሣሪያ ስርዓቶች በተለየ ይህ አስተናጋጅ bcache እና አዲሱን ሊኑክስ 4.15 ከርነል ተጠቅሟል። የዚህ ውቅር አስተናጋጅ እዚህ ጥቅም ላይ ሲውል ይህ የመጀመሪያው ነው። እናም በዚያን ጊዜ የችግሩ መንስኤ በንድፈ ሀሳብ ማንኛውም ሊሆን እንደሚችል ግልጽ ነበር.

አስተናጋጁን መመርመር

በ ceph-osd ሂደት ውስጥ ምን እንደሚፈጠር በመመልከት እንጀምር። ለዚህ እንጠቀማለን ፐርፍ и flamescope (ስለ እሱ ማንበብ እንደሚችሉ የበለጠ እዚህ):

ስዕሉ ተግባሩን ይነግረናል fdatasync() ወደ ተግባራት ጥያቄ በመላክ ብዙ ጊዜ አሳልፈዋል አጠቃላይ_የጥያቄ_ጥያቄ(). ይህ ማለት የችግሮቹ መንስኤ ምናልባት ከራሱ osd ዴሞን ውጪ የሆነ ቦታ ነው። ይህ ከርነል ወይም ዲስኮች ሊሆን ይችላል. የiostat ውፅዓት በ bcache ዲስኮች ጥያቄዎችን በማስተናገድ ረገድ ከፍተኛ መዘግየት አሳይቷል።

አስተናጋጁን ስንፈትሽ ሲስተምድ-ኡድቪድ ዴሞን ከፍተኛ መጠን ያለው ሲፒዩ ጊዜ እንደሚወስድ ደርሰንበታል - 20% ገደማ በበርካታ ኮሮች። ይህ እንግዳ ባህሪ ነው, ስለዚህ ለምን እንደሆነ ማወቅ ያስፈልግዎታል. Systemd-udevd ከ uevents ጋር ስለሚሰራ፣ እነሱን ለማየት ወሰንን። udevadm ማሳያ. በስርዓቱ ውስጥ ላለው እያንዳንዱ የማገጃ መሳሪያ ብዙ ቁጥር ያላቸው የለውጥ ክስተቶች መፈጠሩን ለማወቅ ተችሏል። ይህ በጣም ያልተለመደ ነው፣ ስለዚህ እነዚህን ሁሉ ክስተቶች የሚያመነጨውን ነገር ማየት አለብን።

BCC Toolkit በመጠቀም

አስቀድመን እንዳወቅነው ከርነል (እና በሲስተሙ ጥሪ ውስጥ ያለው ሴፍ ዴሞን) ብዙ ጊዜ ያሳልፋል። አጠቃላይ_የጥያቄ_ጥያቄ(). የዚህን ተግባር ፍጥነት ለመለካት እንሞክር. ውስጥ ቢ.ሲ.ሲ. ቀድሞውኑ አስደናቂ መገልገያ አለ - አዝናኝነት. ዲሞንን በ PID በ 1 ሰከንድ በውጤቶች መካከል ፈለግን እና ውጤቱን በሚሊሰከንዶች እናወጣለን።

ይህ ባህሪ በአብዛኛው በፍጥነት ይሰራል. የሚያደርገው ጥያቄውን ወደ መሳሪያው ሾፌር ወረፋ ማለፍ ብቻ ነው።

Bcache ሶስት ዲስኮችን ያቀፈ ውስብስብ መሣሪያ ነው-

• የመጠባበቂያ መሳሪያ (የተሸጎጠ ዲስክ), በዚህ አጋጣሚ ቀርፋፋ HDD ነው;
• መሸጎጫ መሳሪያ (መሸጎጫ ዲስክ), እዚህ ይህ የ NVMe መሣሪያ አንድ ክፍል ነው;
• አፕሊኬሽኑ የሚሰራበት bcache ምናባዊ መሳሪያ።

የጥያቄ ስርጭቱ ቀርፋፋ መሆኑን እናውቃለን፣ ግን ከእነዚህ መሳሪያዎች ውስጥ የትኛው ነው? ይህንን ትንሽ ቆይተን እናስተናግዳለን።

አሁን የሚከሰቱ ክስተቶች ችግር ሊፈጥሩ እንደሚችሉ እናውቃለን። በትክክል የትውልዳቸው መንስኤ ምን እንደሆነ መፈለግ በጣም ቀላል አይደለም. ይህ በየጊዜው የሚጀመር ሶፍትዌር ነው ብለን እናስብ። ስክሪፕት በመጠቀም በስርዓቱ ላይ ምን አይነት ሶፍትዌር እንደሚሰራ እንይ ኤክሰኖፕ ከተመሳሳይ 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/'

ሦስተኛው ዓምድ የሂደቱ ፒፒአይዲ (የወላጅ PID) ነው። የ PID 5802 ሂደት ከክትትል ስርዓታችን ውስጥ አንዱ ሆኖ ተገኝቷል። የክትትል ስርዓቱን ውቅር ሲፈትሹ የተሳሳቱ መለኪያዎች ተገኝተዋል. የ HBA አስማሚው ሙቀት በየ 30 ሰከንድ ተወስዷል, ይህም ከሚያስፈልገው በላይ ብዙ ጊዜ ነው. የፍተሻ ክፍተቱን ወደ ረዘም ያለ ጊዜ ከቀየርን በኋላ፣ በዚህ አስተናጋጅ ላይ ያለው የጥያቄ ሂደት መዘግየት ከሌሎች አስተናጋጆች ጋር ሲወዳደር ጎልቶ የወጣ ሆኖ አግኝተናል።

ነገር ግን የ bcache መሳሪያው ለምን በጣም ቀርፋፋ እንደነበረ አሁንም ግልጽ አይደለም. ተመሳሳይ ውቅር ያለው የሙከራ መድረክ አዘጋጀን እና በ bcache ላይ fio ን በማስኬድ፣ አልፎ አልፎ udevadm ቀስቅሴን በመፍጠር ችግሩን ለማባዛት ሞክረናል።

BCC ላይ የተመሰረቱ መሣሪያዎችን መጻፍ

በጣም ቀርፋፋ ጥሪዎችን ለመፈለግ እና ለማሳየት ቀላል መገልገያ ለመጻፍ እንሞክር አጠቃላይ_የጥያቄ_ጥያቄ(). እንዲሁም ይህ ተግባር የተጠራበትን ድራይቭ ስም እንፈልጋለን።

እቅዱ ቀላል ነው፡-

• ይመዝገቡ kprobe ላይ አጠቃላይ_የጥያቄ_ጥያቄ():
  • የዲስክን ስም ወደ ማህደረ ትውስታ እናስቀምጠዋለን, በተግባራዊ ክርክር በኩል ተደራሽ;
  • የጊዜ ማህተሙን እናስቀምጣለን.

• ይመዝገቡ kretprobe ከ ለመመለስ አጠቃላይ_የጥያቄ_ጥያቄ():
  • የአሁኑን የጊዜ ማህተም እናገኛለን;
  • የተቀመጠ የጊዜ ማህተም እንፈልጋለን እና አሁን ካለው ጋር እናነፃፅራለን;
  • ውጤቱ ከተጠቀሰው በላይ ከሆነ, ከዚያም የተቀመጠውን የዲስክ ስም እናገኛለን እና በተርሚናል ላይ እናሳያለን.

Kprobes и kretprobes በበረራ ላይ የተግባር ኮድ ለመቀየር የመግቻ ነጥብ ዘዴን ይጠቀሙ። ማንበብ ትችላለህ ሰነዶች и ጥሩ በዚህ ርዕስ ላይ ጽሑፍ. በ ውስጥ የተለያዩ መገልገያዎችን ኮድ ከተመለከቱ ቢ.ሲ.ሲ., ከዚያም አንድ አይነት መዋቅር እንዳላቸው ማየት ይችላሉ. ስለዚህ በዚህ ጽሑፍ ውስጥ የስክሪፕት ክርክሮችን መተንተንን እና ወደ ራሱ BPF ፕሮግራም እንቀጥላለን።

በ python ስክሪፕት ውስጥ ያለው የኢቢፒኤፍ ጽሑፍ ይህን ይመስላል፡-

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

በተግባሮች መካከል ውሂብ ለመለዋወጥ የኢቢፒኤፍ ፕሮግራሞች ይጠቀማሉ የሃሽ ጠረጴዛዎች. እኛም እንዲሁ እናደርጋለን። የሂደቱን 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);
}

እዚህ የተጠራው ተግባር የመጀመሪያ ነጋሪ እሴት እንደ ሁለተኛው ክርክር ይተካል አጠቃላይ_የጥያቄ_ጥያቄ(). ከዚህ በኋላ እኛ በምንሰራበት አውድ ውስጥ የሂደቱን PID እና የአሁኑን የጊዜ ማህተም በ nanoseconds ውስጥ እናገኛለን። ሁሉንም አዲስ በተመረጠው ውስጥ እንጽፋለን struct data_t ውሂብ. የዲስክን ስም ከመዋቅሩ እናገኛለን የህይወት ታሪክ, በሚደወልበት ጊዜ የሚያልፍ አጠቃላይ_የጥያቄ_ጥያቄ(), እና በተመሳሳይ መዋቅር ውስጥ ያስቀምጡት መረጃ. የመጨረሻው እርምጃ ቀደም ሲል በተጠቀሰው የሃሽ ጠረጴዛ ላይ ግቤት ማከል ነው.

የሚከተለው ተግባር ከተመለሰ በኋላ ይጠራል አጠቃላይ_የጥያቄ_ጥያቄ():

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_የአሁኑን_pid_tgid() አግኝ ሁለቱንም የክሩ GID እና ፒአይዲውን በአንድ ባለ 64-ቢት እሴት ይመልሳል።

ወደ ተርሚናል በሚወጣበት ጊዜ በአሁኑ ጊዜ በክር ላይ ፍላጎት የለንም ፣ ግን ለዋናው ሂደት ፍላጎት አለን ። የተፈጠረውን መዘግየት ከተወሰነው ገደብ ጋር ካነፃፅር በኋላ የእኛን መዋቅር እናልፋለን መረጃ በጠረጴዛ በኩል ወደ ተጠቃሚ ቦታ ክስተቶች, ከዚያ በኋላ ግቤትን እንሰርዛለን p.

ይህንን ኮድ በሚጭን የpython ስክሪፕት ውስጥ፣ 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()

ስክሪፕቱ ራሱ በ ላይ ይገኛል። ጂትሃብ. ፊዮ በሚሰራበት የሙከራ መድረክ ላይ፣ ወደ bcache በመፃፍ እና ወደ udevadm ሞኒተር ለመደወል እንሞክር፡-

በመጨረሻ! አሁን የቆመ የ bcache መሣሪያ የሚመስለው የማይቀር ጥሪ መሆኑን አይተናል አጠቃላይ_የጥያቄ_ጥያቄ() ለተሸጎጠ ዲስክ.

ወደ ከርነል ቆፍሩ

ጥያቄ በሚተላለፍበት ጊዜ በትክክል ምን እየቀዘቀዘ ነው? መዘግየቱ የጥያቄ ሒሳብ ከመጀመሩ በፊት እንኳን ሲከሰት እናያለን፣ ማለትም. በእሱ ላይ (/proc/diskstats ወይም iostat) ላይ ለተጨማሪ ውፅዓት የአንድ የተወሰነ ጥያቄ የሂሳብ አያያዝ ገና አልተጀመረም። ይህ በቀላሉ ችግሩን በሚባዙበት ጊዜ iostat ን በማስኬድ ወይም BCC ስክሪፕት ባዮላቴሽንበጥያቄ ሂሳብ መጀመሪያ እና መጨረሻ ላይ የተመሰረተ። ከእነዚህ መገልገያዎች ውስጥ አንዳቸውም ቢሆኑ ለተሸጎጠው ዲስክ ለሚቀርቡ ጥያቄዎች ችግር አያሳዩም።

ተግባሩን ከተመለከትን አጠቃላይ_የጥያቄ_ጥያቄ(), ከዚያም ጥያቄው የሂሳብ አያያዝ ከመጀመሩ በፊት ሁለት ተጨማሪ ተግባራት እንደሚጠሩ እናያለን. አንደኛ - አጠቃላይ_የጥያቄ_ቼኮች(), የዲስክ ቅንጅቶችን በተመለከተ የጥያቄውን ትክክለኛነት ያረጋግጣል. ሁለተኛ - blk_queue_አስገባ(), ይህም አስደሳች ፈተና አለው መጠበቅ_ክስተት_የሚቋረጥ():

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_አስገባ():

~# /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_የቀዘቀዘ_ወረፋ и blk_mq_የማይቀዘቅዝ_ወረፋ. በዚህ ወረፋ ውስጥ ላሉ ጥያቄዎች አደገኛ ሊሆኑ የሚችሉትን የጥያቄ ወረፋ ቅንብሮችን ለመለወጥ አስፈላጊ በሚሆንበት ጊዜ ጥቅም ላይ ይውላሉ። ሲደውሉ blk_mq_የቀዘቀዘ_ወረፋ() ተግባር blk_frize_ወረፋ_ጀምር() ቆጣሪው ተጨምሯል q->mq_freeze_ጥልቀት. ከዚህ በኋላ ኮርነሉ ወረፋው እስኪገባ ድረስ ይጠብቃል። blk_mq_በረዶ_ወረፋ_ይጠብቅ().

ይህንን ወረፋ ለማጽዳት የሚፈጀው ጊዜ ከዲስክ መዘግየት ጋር እኩል ነው ምክንያቱም ከርነሉ ሁሉም የተሰለፉ ስራዎች እስኪጠናቀቁ ድረስ ይጠብቃል። አንዴ ወረፋው ባዶ ከሆነ, የቅንብሮች ለውጦች ይተገበራሉ. ከዚያ በኋላ ይባላል blk_mq_ከማይቀዘቅዝ_ወረፋ(), ቆጣሪውን መቀነስ የቀዘቀዘ_ጥልቀት.

አሁን ሁኔታውን ለማስተካከል በቂ እናውቃለን. የ udevadm ቀስቅሴ ትዕዛዝ የማገጃ መሳሪያው እንዲተገበር ያደርገዋል. እነዚህ ቅንብሮች በ udev ደንቦች ውስጥ ተገልጸዋል. በ sysfs በኩል ለመለወጥ በመሞከር ወይም የከርነል ምንጭ ኮድን በመመልከት የትኞቹ መቼቶች ወረፋውን እየቀዘቀዙ እንዳሉ ማግኘት እንችላለን። እንዲሁም የቢሲሲ አገልግሎትን መሞከር እንችላለን ዱካ, ይህም ለእያንዳንዱ ወደ ተርሚናል ጥሪ የከርነል እና የተጠቃሚ ቦታ ቁልል ዱካዎችን ያወጣል። blk_በረዶ_ወረፋ, ለምሳሌ:

~# /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 ክስተቶችን ማመንጨት (ለምሳሌ, መሳሪያው አልተሰካም / አይቋረጥም) ጥሩ ልምምድ አይደለም. ነገር ግን አስኳል አላስፈላጊ ስራ እንዳይሰራ እና አስፈላጊ ካልሆነ የጥያቄውን ወረፋ እንዲቀር ማድረግ እንችላለን። ሶስት ትንሽ መፈጸም ሁኔታውን አስተካክል.

መደምደሚያ

eBPF በጣም ተለዋዋጭ እና ኃይለኛ መሳሪያ ነው. በአንቀጹ ውስጥ አንድ ተግባራዊ ጉዳይ ተመልክተናል እና ምን ማድረግ እንደሚቻል ትንሽ ክፍል አሳይተናል. የBCC መገልገያዎችን ለማዳበር ፍላጎት ካለህ መመልከት ተገቢ ነው። ኦፊሴላዊ አጋዥ ስልጠና, እሱም መሰረታዊውን በደንብ ይገልፃል.

በ eBPF ላይ የተመሰረቱ ሌሎች አስደሳች የማረም እና የመገለጫ መሳሪያዎች አሉ። ከእነርሱ መካከል አንዱ - bpftrace, ይህም ኃይለኛ አንድ-መስመር እና ትናንሽ ፕሮግራሞችን በአስቸጋሪ ቋንቋ እንዲጽፉ ያስችልዎታል. ሌላ - ebpf_exporter, በኋላ ላይ የሚያምሩ ምስሎችን እና ሌላው ቀርቶ ማንቂያዎችን የማግኘት ችሎታ ያለው ዝቅተኛ ደረጃ እና ከፍተኛ ጥራት መለኪያዎችን በቀጥታ ወደ ፕሮሜቲየስ አገልጋይዎ እንዲሰበስቡ ያስችልዎታል።

ምንጭ: hab.com