ពី High Ceph Latency ទៅ Kernel Patch ដោយប្រើ eBPF/BCC

លីនុចមានឧបករណ៍មួយចំនួនធំសម្រាប់បំបាត់កំហុសខឺណែល និងកម្មវិធី។ ពួកវាភាគច្រើនមានផលប៉ះពាល់អវិជ្ជមានលើការអនុវត្តកម្មវិធី និងមិនអាចប្រើប្រាស់ក្នុងផលិតកម្មបានទេ។

ពីរបីឆ្នាំមុនមាន ឧបករណ៍មួយទៀតត្រូវបានបង្កើតឡើង — eBPF ។ វាធ្វើឱ្យវាអាចតាមដានខឺណែល និងកម្មវិធីអ្នកប្រើប្រាស់ដោយចំណាយតិច និងមិនចាំបាច់បង្កើតកម្មវិធីឡើងវិញ និងផ្ទុកម៉ូឌុលភាគីទីបីទៅក្នុងខឺណែលនោះទេ។

មានឧបករណ៍ប្រើប្រាស់កម្មវិធីជាច្រើនរួចហើយដែលប្រើ eBPF ហើយនៅក្នុងអត្ថបទនេះយើងនឹងពិនិត្យមើលរបៀបសរសេរឧបករណ៍ប្រើប្រាស់ទម្រង់ផ្ទាល់ខ្លួនរបស់អ្នកដោយផ្អែកលើបណ្ណាល័យ។ PythonBCC. អត្ថបទគឺផ្អែកលើព្រឹត្តិការណ៍ពិត។ យើងនឹងចេញពីបញ្ហាដើម្បីជួសជុល ដើម្បីបង្ហាញពីរបៀបដែលឧបករណ៍ប្រើប្រាស់ដែលមានស្រាប់អាចត្រូវបានប្រើក្នុងស្ថានភាពជាក់លាក់។

Ceph គឺយឺត

ម៉ាស៊ីនថ្មីត្រូវបានបន្ថែមទៅក្រុម Ceph ។ បន្ទាប់ពីផ្ទេរទិន្នន័យមួយចំនួនទៅវា យើងសង្កេតឃើញថាល្បឿននៃដំណើរការការសរសេរសំណើដោយវាទាបជាងម៉ាស៊ីនមេផ្សេងទៀត។

មិនដូចវេទិកាផ្សេងទៀតទេ ម៉ាស៊ីននេះបានប្រើ bcache និងខឺណែល linux 4.15 ថ្មី។ នេះជាលើកដំបូងដែលម៉ាស៊ីននៃការកំណត់រចនាសម្ព័ន្ធនេះត្រូវបានប្រើនៅទីនេះ។ ហើយនៅពេលនោះ វាច្បាស់ណាស់ថាឫសគល់នៃបញ្ហាអាចជាទ្រឹស្តី។

ការស៊ើបអង្កេតម្ចាស់ផ្ទះ

ចូរចាប់ផ្តើមដោយមើលអ្វីដែលកើតឡើងនៅក្នុងដំណើរការ ceph-osd ។ សម្រាប់រឿងនេះយើងនឹងប្រើ ល្អ и កែវពង្រីក (បន្ថែមទៀតអំពីដែលអ្នកអាចអាន នៅទីនេះ):

រូបភាពប្រាប់យើងថាមុខងារ fdatasync() ចំណាយពេលច្រើនក្នុងការផ្ញើសំណើទៅកាន់មុខងារ generic_make_request(). នេះមានន័យថាភាគច្រើនទំនងជាមូលហេតុនៃបញ្ហាគឺនៅកន្លែងណាមួយនៅខាងក្រៅ osd daemon ខ្លួនវាផ្ទាល់។ នេះអាចជាខឺណែល ឬថាស។ ទិន្នផល iostat បានបង្ហាញពីភាពយឺតយ៉ាវខ្ពស់ក្នុងដំណើរការសំណើដោយថាស bcache ។

នៅពេលពិនិត្យមើលម៉ាស៊ីនយើងបានរកឃើញថាដេមិន systemd-udevd ប្រើប្រាស់ពេលវេលាស៊ីភីយូច្រើន - ប្រហែល 20% នៅលើស្នូលជាច្រើន។ នេះ​ជា​អាកប្បកិរិយា​ចម្លែក ដូច្នេះ​អ្នក​ត្រូវ​ស្វែង​រក​មូលហេតុ។ ដោយសារ Systemd-udevd ធ្វើការជាមួយ uevents យើងបានសម្រេចចិត្តមើលពួកវាតាមរយៈ ម៉ូនីទ័រ udevadm. វាប្រែថាមួយចំនួនធំនៃព្រឹត្តិការណ៍ផ្លាស់ប្តូរត្រូវបានបង្កើតឡើងសម្រាប់ឧបករណ៍ប្លុកនីមួយៗនៅក្នុងប្រព័ន្ធ។ នេះ​គឺ​ជា​រឿង​មិន​ធម្មតា ដូច្នេះ​យើង​នឹង​ត្រូវ​ពិនិត្យ​មើល​អ្វី​ដែល​បង្កើត​ព្រឹត្តិការណ៍​ទាំង​អស់​នេះ។

ការប្រើប្រាស់ BCC Toolkit

ដូចដែលយើងបានរកឃើញរួចហើយ ខឺណែល (និង ceph daemon ក្នុងការហៅប្រព័ន្ធ) ចំណាយពេលច្រើនក្នុង generic_make_request(). តោះព្យាយាមវាស់ល្បឿននៃមុខងារនេះ។ IN ចម្លងជាសម្ងាត់ជូន មានឧបករណ៍ប្រើប្រាស់ដ៏អស្ចារ្យរួចទៅហើយ - ភាពស៊ីសង្វាក់គ្នា។. យើងនឹងតាមដានដេមិនដោយ PID របស់វាជាមួយនឹងចន្លោះពេល 1 វិនាទីរវាងលទ្ធផល និងលទ្ធផលជាមីលីវិនាទី។

មុខងារនេះជាធម្មតាដំណើរការលឿន។ អ្វីទាំងអស់ដែលវាធ្វើគឺបញ្ជូនសំណើទៅជួរកម្មវិធីបញ្ជាឧបករណ៍។

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 យឺតដូច្នេះ។ យើងបានរៀបចំវេទិកាសាកល្បងជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធដូចគ្នាបេះបិទ ហើយព្យាយាមបង្កើតបញ្ហាឡើងវិញដោយដំណើរការ fio នៅលើ bcache ដោយដំណើរការ udevadm trigger ជាទៀងទាត់ដើម្បីបង្កើត uevents ។

ការសរសេរឧបករណ៍ផ្អែកលើ BCC

តោះព្យាយាមសរសេរឧបករណ៍ប្រើប្រាស់សាមញ្ញមួយដើម្បីតាមដាន និងបង្ហាញការហៅទូរសព្ទយឺតបំផុត។ generic_make_request(). យើងក៏ចាប់អារម្មណ៍លើឈ្មោះរបស់ drive ដែលមុខងារនេះត្រូវបានគេហៅថា។

ផែនការគឺសាមញ្ញ៖

• ចុះឈ្មោះ kprobe នៅលើ generic_make_request():
  • យើងរក្សាទុកឈ្មោះថាសទៅក្នុងអង្គចងចាំ អាចចូលប្រើបានតាមរយៈអាគុយម៉ង់មុខងារ។
  • យើងរក្សាទុកត្រាពេលវេលា។

• ចុះឈ្មោះ kretprobe សម្រាប់ការត្រឡប់មកវិញពី generic_make_request():
  • យើងទទួលបានត្រាពេលវេលាបច្ចុប្បន្ន;
  • យើងរកមើលត្រាពេលវេលាដែលបានរក្សាទុក ហើយប្រៀបធៀបវាជាមួយបច្ចុប្បន្ន។
  • ប្រសិនបើលទ្ធផលគឺធំជាងអ្វីដែលបានបញ្ជាក់នោះយើងរកឃើញឈ្មោះថាសដែលបានរក្សាទុកហើយបង្ហាញវានៅលើស្ថានីយ។

Kprobes и kretprobes ប្រើយន្តការបំបែកដើម្បីផ្លាស់ប្តូរកូដមុខងារភ្លាមៗ។ អ្នកអាចអាន ឯកសារ и ល្អ អត្ថបទលើប្រធានបទនេះ។ ប្រសិនបើអ្នកក្រឡេកមើលលេខកូដឧបករណ៍ប្រើប្រាស់ផ្សេងៗនៅក្នុង ចម្លងជាសម្ងាត់ជូនបន្ទាប់មក អ្នកអាចមើលឃើញថាពួកគេមានរចនាសម្ព័ន្ធដូចគ្នាបេះបិទ។ ដូច្នេះនៅក្នុងអត្ថបទនេះ យើងនឹងរំលងការញែកស្គ្រីបអាគុយម៉ង់ ហើយបន្តទៅកម្មវិធី BPF ខ្លួនឯង។

អត្ថបទ eBPF នៅខាងក្នុងស្គ្រីប python មើលទៅដូចនេះ៖

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

ដើម្បីផ្លាស់ប្តូរទិន្នន័យរវាងមុខងារ កម្មវិធី eBPF ប្រើ តារាង hash. យើងនឹងធ្វើដូចគ្នា។ យើងនឹងប្រើដំណើរការ 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);

នៅទីនេះយើងចុះឈ្មោះតារាង hash ដែលហៅថា pជាមួយនឹងប្រភេទគន្លឹះ u64 និងតម្លៃនៃប្រភេទ រចនាសម្ព័ន្ធ data_t. តារាងនឹងមាននៅក្នុងបរិបទនៃកម្មវិធី BPF របស់យើង។ ម៉ាក្រូ BPF_PERF_OUTPUT ចុះឈ្មោះតារាងមួយទៀតហៅថា ព្រឹ​ត្ត​ការណ៍ដែលត្រូវបានប្រើសម្រាប់ ការបញ្ជូនទិន្នន័យ ទៅក្នុងចន្លោះអ្នកប្រើប្រាស់។

នៅពេលវាស់ការពន្យារពេលរវាងការហៅមុខងារមួយ និងការត្រលប់ពីវា ឬរវាងការហៅទៅកាន់មុខងារផ្សេងៗ អ្នកត្រូវគិតគូរថាទិន្នន័យដែលទទួលបានត្រូវតែជារបស់បរិបទដូចគ្នា។ ម្យ៉ាងវិញទៀត អ្នកត្រូវចងចាំអំពីការបើកដំណើរការប៉ារ៉ាឡែលដែលអាចធ្វើទៅបាននៃមុខងារ។ យើងមានសមត្ថភាពក្នុងការវាស់ស្ទង់ភាពយឺតយ៉ាវរវាងការហៅមុខងារក្នុងបរិបទនៃដំណើរការមួយ និងត្រឡប់ពីមុខងារនោះក្នុងបរិបទនៃដំណើរការមួយផ្សេងទៀត ប៉ុន្តែនេះទំនងជាគ្មានប្រយោជន៍ទេ។ ឧទាហរណ៍ដ៏ល្អមួយនៅទីនេះ ឧបករណ៍ប្រើប្រាស់ biolatencyដែលជាកន្លែងដែលគ្រាប់ចុចតារាង hash ត្រូវបានកំណត់ទៅជាទ្រនិចទៅ សំណើរចនាសម្ព័ន្ធដែលឆ្លុះបញ្ចាំងពីសំណើឌីសមួយ។

បន្ទាប់មកយើងត្រូវសរសេរកូដដែលនឹងដំណើរការនៅពេលដែលមុខងារដែលកំពុងសិក្សាត្រូវបានគេហៅថា៖

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 នៃដំណើរការនៅក្នុងបរិបទដែលយើងកំពុងធ្វើការ និងត្រាពេលវេលាបច្ចុប្បន្នគិតជា nanoseconds ។ យើង​សរសេរ​វា​ទាំងអស់​ក្នុង​ការ​ជ្រើសរើស​ថ្មីៗ រចនាសម្ព័ន្ធ data_t ទិន្នន័យ. យើងទទួលបានឈ្មោះថាសពីរចនាសម្ព័ន្ធ ជីវដែលត្រូវបានឆ្លងកាត់នៅពេលហៅ generic_make_request()ហើយរក្សាទុកវាក្នុងរចនាសម្ព័ន្ធដូចគ្នា។ ទិន្នន័យ. ជំហានចុងក្រោយគឺត្រូវបន្ថែមធាតុទៅក្នុងតារាង hash ដែលត្រូវបានរៀបរាប់ពីមុន។

មុខងារខាងក្រោមនឹងត្រូវបានហៅនៅពេលត្រឡប់ពី 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 នៃដំណើរការ និងពេលវេលា ប៉ុន្តែកុំបែងចែកអង្គចងចាំសម្រាប់រចនាសម្ព័ន្ធទិន្នន័យថ្មី។ ជំនួសមកវិញ យើងស្វែងរកតារាង hash សម្រាប់រចនាសម្ព័ន្ធដែលមានស្រាប់ដោយប្រើគន្លឹះ == បច្ចុប្បន្ន PID ។ ប្រសិនបើរចនាសម្ព័ន្ធត្រូវបានរកឃើញនោះយើងរកឃើញឈ្មោះនៃដំណើរការដែលកំពុងដំណើរការហើយបន្ថែមវាទៅវា។

ការផ្លាស់ប្តូរគោលពីរដែលយើងប្រើនៅទីនេះគឺចាំបាច់ដើម្បីទទួលបាន GID ខ្សែស្រឡាយ។ ទាំងនោះ។ PID នៃដំណើរការចម្បងដែលបានចាប់ផ្តើមខ្សែស្រឡាយនៅក្នុងបរិបទដែលយើងកំពុងធ្វើការ។ មុខងារដែលយើងហៅ bpf_get_current_pid_tgid() ត្រឡប់ទាំង GID របស់ខ្សែស្រឡាយ និង PID របស់វានៅក្នុងតម្លៃ 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")

យើងក៏នឹងត្រូវកំណត់ផងដែរ។ រចនាសម្ព័ន្ធ 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()ដែលមានការប្រកួតប្រជែងគួរឱ្យចាប់អារម្មណ៍ wait_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()កាត់បន្ថយការរាប់ freeze_depth.

ឥឡូវនេះយើងដឹងគ្រប់គ្រាន់ដើម្បីកែតម្រូវស្ថានភាព។ ពាក្យបញ្ជាកេះ 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 ។ ម្នាក់​ក្នុង​ចំ​នោម​ពួកគេ - bpfraceដែលអនុញ្ញាតឱ្យអ្នកសរសេរអក្សរមួយដ៏មានអានុភាព និងកម្មវិធីតូចៗក្នុងភាសាដូច awk ។ មួយទៀត - ebpf_exporterអនុញ្ញាតឱ្យអ្នកប្រមូលរង្វាស់កម្រិតទាប គុណភាពបង្ហាញខ្ពស់ដោយផ្ទាល់ទៅក្នុងម៉ាស៊ីនមេ prometheus របស់អ្នក ជាមួយនឹងសមត្ថភាពក្នុងការទទួលបានរូបភាពដ៏ស្រស់ស្អាត និងសូម្បីតែការជូនដំណឹងនៅពេលក្រោយ។

ប្រភព: www.habr.com