Temu Duga Linux: Bagaimana Anda Menerangkan dan Mendiagnosis Kependaman Penjadualan CPU?

Gesaan dan Peranan yang Berkenaan

Sebuah pelayan 16-vCPU yang menjalankan Linux 6.12 dan cgroup v2 mengehoskan API sensitif kependaman di samping tugas pemampatan luar talian. Selepas tugas luar talian bermula, p99 API meningkat daripada 45ms kepada 600ms. Pemantauan hos melaporkan kira-kira 78% penggunaan CPU agregat, dan API mengumpul sedikit masa CPU. Benang API dan tugas luar talian yang berkaitan semuanya menggunakan SCHED_OTHER.

Terangkan cara penjadual adil (fair scheduler) Linux moden memilih antara benang yang boleh dijalankan (runnable), kemudian berikan proses diagnostik yang boleh diuji untuk membezakan punca-punca ini:

• benang API boleh dijalankan (runnable) tetapi menunggu terlalu lama untuk CPU;
• cgroup API didikit oleh kuota cpu.max miliknya;
• afiniti atau cpuset mengehadkan kerja kepada beberapa CPU yang sibuk;
• benang API sebenarnya sedang tidur pada mutex, I/O, atau peristiwa lain;
• benang masa nyata berkeutamaan lebih tinggi menghalang benang normal daripada berjalan.

Soalan ini sesuai untuk peranan SRE, infrastruktur, perisian sistem, kejuruteraan prestasi, dan bahagian belakang (backend) yang memerlukan pengetahuan masa jalanan (runtime) Linux. Nilai 16, 6.12, 45ms, 600ms, dan 78% ialah input latihan rekaan, bukan kapasiti sejagat atau ambang amaran.

Perkara yang Diuji oleh Penemu Duga

Sempadan pertama ialah keadaan tugas (task state). Penjadual hanya boleh memilih benang yang boleh dijalankan (runnable). Benang yang sedang tidur pada mutex, operasi rangkaian, operasi cakera, atau pemasa tidak menunggu pada run queue CPU. Keseluruhan selang itu tidak boleh dilabelkan sebagai kelewatan penjadualan. Calon perlu menjawab terlebih dahulu sama ada benang tersebut sememangnya sudah boleh dijalankan.

Lapisan kedua ialah model penjadualan adil. Penjelasan CFS yang bersejarah menggunakan masa jalan maya (virtual runtime), atau vruntime, untuk menganggarkan “CPU berbilang tugas yang ideal” dan mengutamakan entiti dengan vruntime yang lebih kecil. Model EEVDF semasa terus menjejaki hutang keadilan yang dipanggil lag, hanya membenarkan entiti yang layak, dan memilih tarikh akhir maya (virtual deadline) paling awal dalam kalangan mereka. Nilai nice atau cgroup weight mempengaruhi bahagian relatif jangka panjang. Hirisan permintaan (request slice) dan tarikh akhir maya mempengaruhi seberapa cepat sesuatu tugas boleh mendapat peluang pelaksanaan yang lain. Tiada satu pun mekanisme menjanjikan p99 tetap untuk permintaan individu.

Lapisan ketiga ialah hierarki dan kekangan setempat. Hos dengan 22% kapasiti melahu masih boleh mempunyai cgroup sasaran yang telah menghabiskan kuota keras atau benang yang terhad kepada dua CPU yang tepu. cpu.weight ialah berat relatif dalam kalangan cgroup adik-beradik (siblings) yang aktif semasa perbalahan, manakala cpu.max mengenakan had lebar jalur keras bagi setiap tempoh. Kumpulan tugas dan cpuset boleh menyebabkan nilai agregat hos menyembunyikan kebuluran setempat.

Lapisan keempat ialah bukti langsung. Penungguan run-queue daripada /proc/12345/schedstat, kelewatan runnable-ke-running daripada perf sched timehist, serta cgroup cpu.stat dan cpu.pressure adalah lebih dekat dengan mekanisme berbanding CPU agregat atau kiraan pertukaran konteks (context-switch) semata-mata. Jawapan yang mantap juga mengehadkan keistimewaan penjejakan, overhed, dan tempoh.

Akhir sekali, calon memerlukan sempadan mitigasi. Memindahkan API ke SCHED_FIFO boleh membuatnya mendahului (preempt) kerja normal, tetapi gelung tanpa batas atau pemegang kunci kemudiannya boleh membulurkan mesin. Pembetulan mesti mengikut bukti: membetulkan kuota yang salah, melaraskan berat adik-beradik, membaiki set CPU, atau menyiasat laluan kunci atau I/O apabila benang tersebut tidak boleh dijalankan.

Soalan untuk Dijelaskan Sebelum Menjawab

• Di manakah pemasaan p99 bermula dan berakhir? Asingkan giliran masuk (ingress queueing), pelaksanaan aplikasi, penungguan hiliran, dan masa rangkaian klien, serta selaraskan sampel hos ke selang masa yang sama.
• Bilakah benang sasaran boleh dijalankan (runnable)? Dapatkan keadaan benang, sebab off-CPU, atau timbunan (stacks). Masa CPU yang sedikit boleh bermaksud kekurangan penjadualan atau tidur yang berpanjangan.
• Apakah hierarki cgroup yang mengandungi API dan tugas luar talian? Bandingkan cpu.weight, cpu.max, had induk, dan cpu.stat untuk kedua-duanya. Cgroup induk juga mengekang anak-anaknya.
• CPU manakah yang boleh menjalankan kerja tersebut? Periksa afiniti benang, cpuset.cpus.effective, penggunaan setiap CPU, dan reka letak NUMA. Hos 16-vCPU tidak bermakna benang tersebut dibenarkan menggunakan kesemua 16 CPU.
• Adakah terdapat sebarang entiti penjadualan masa nyata? Periksa keutamaan dan afiniti CPU untuk kerja SCHED_FIFO dan SCHED_RR. Gesaan hanya menyatakan bahawa benang perniagaan yang berkaitan menggunakan SCHED_OTHER; ia tidak mengecualikan benang masa nyata yang tidak berkaitan pada hos.
• Adakah tugas luar talian mengubah laluan kunci, memori, atau I/O? Pemampatan boleh mewujudkan perbalahan CPU, tetapi ia juga mungkin meningkatkan penambusuan semula (reclaim), I/O fail, atau giliran dalam kolam pekerja yang dikongsi.
• Bolehkah surihan pendek diambil? perf sched biasanya memerlukan keistimewaan tambahan dan mewujudkan overhed rakaman. Sahkan arah terlebih dahulu dengan pembilang beroverhed rendah, kemudian ambil sampel selama 15 saat dalam tetingkap terkawal.

Rangka Kerja Jawapan 30 Saat

“Saya akan terlebih dahulu menentukan sama ada benang API sememangnya sudah boleh dijalankan (runnable) semasa permintaan perlahan. Masa tidur pada kunci atau I/O ialah penungguan off-CPU. Kelewatan penjadualan ialah selang daripada runnable sehingga benar-benar berjalan (running).

Pada Linux 6.12, saya akan menerangkan kelas adil melalui EEVDF: ia menjejaki lag setiap entiti berbanding perkhidmatan adil yang ideal, mempertimbangkan entiti yang layak, dan memilih tarikh akhir maya yang paling awal. Model vruntime terkecil CFS kekal sebagai gerak hati bersejarah yang berguna, tetapi ia tidak menerangkan sepenuhnya peraturan pemilihan semasa. Nice dan cpu.weight mengubah bahagian relatif, cpu.max boleh mendikit secara langsung, dan afiniti atau cpuset mengawal CPU yang tersedia.

Saya akan memeriksa penggunaan setiap CPU, keadaan benang, dan konfigurasi cgroup. Kemudian saya akan membandingkan delta penungguan run-queue dalam /proc/12345/schedstat, delta pendikit dalam cpu.stat, dan cpu.pressure. Jika bukti masih menunjukkan kepada penjadualan, saya akan mengambil surihan pendek perf sched untuk mengukur kelewatan runnable-ke-running secara langsung. Selepas pembetulan, saya akan memainkan semula beban yang sama dan mengesahkan p99 API, taburan kelewatan penjadualan, pendikit, tekanan CPU, dan daya pemprosesan luar talian secara bersama dan bukannya membuat kesimpulan punca daripada 78% CPU agregat.”

Panduan Terperinci Langkah demi Langkah

Langkah 1: Buat Perbezaan Antara Runnable dan Sleeping

Apabila CPU memerlukan tugas lain, penjadual Linux hanya memilih entiti yang boleh dijalankan (runnable) pada CPU tersebut atau layak untuk berhijrah ke sana. Benang dasar normal mempunyai keutamaan penjadualan 0. Benang masa nyata SCHED_FIFO dan SCHED_RR menggunakan julat keutamaan statik yang lebih tinggi dan boleh mendahului (preempt) benang normal.

Masa CPU API yang sedikit oleh itu mempunyai dua penjelasan yang berbeza secara asas:

1. Benang boleh dijalankan (runnable) tetapi tidak berjalan dengan segera disebabkan perbalahan run-queue, kuota, atau sekatan CPU-set.
2. Benang tidur pada futex, soket, cakera, pemasa, atau giliran aplikasi dan menjadi runnable hanya apabila peristiwa tersebut tiba.

Mulakan dengan memeriksa keadaan benang dan dasar penjadualan:

ps -eLo state,cls,rtprio,pri,ni,psr,pid,tid,comm --sort=-rtprio,-pri
pidstat -t -w -u -p "$pid" 1 10

ps ialah tangkapan segera (snapshot), jadi satu R atau S tidak menyelesaikan persoalan. Data pertukaran konteks dan CPU daripada pidstat membantu mengenal pasti benang sasaran, tetapi kiraan pertukaran konteks yang tinggi tidak membuktikan kelewatan penjadualan yang tinggi. Jika benang kebanyakannya tidur, teruskan dengan surihan aplikasi, pemprofilan kunci, timbunan off-CPU, metrik I/O, dan kependaman hiliran untuk mencari syarat bangun (wake-up condition).

Langkah 2: Gunakan CFS untuk Gerak Hati, Kemudian Kemas Kini Model kepada EEVDF

Penjelasan CFS klasik menskalakan masa pelaksanaan sebenar setiap entiti adil mengikut beratnya ke dalam vruntime. Entiti dengan berat yang lebih tinggi mengumpul vruntime dengan lebih perlahan. Memilih entiti dengan vruntime yang lebih kecil menggerakkan perkhidmatan jangka panjang ke arah berat yang dikonfigurasikan. Itu kekal sebagai gerak hati pengajaran yang berguna dan menerangkan arah bagaimana nice mengubah bahagian adil.

Dokumentasi kernel Linux menyatakan bahawa kelas adil mula beralih kepada EEVDF dalam 6.6. Jawapan yang ringkas boleh menggunakan dua konsep:

• lag mewakili berapa banyak perkhidmatan yang terhutang atau telah diterima oleh entiti berbanding perkhidmatan adil ideal; entiti dengan lag >= 0 adalah layak;
• dalam kalangan entiti yang layak, penjadual memilih tarikh akhir maya yang paling awal. Hirisan permintaan yang lebih pendek menghasilkan tarikh akhir yang lebih awal dan meningkatkan peluang tindak balas untuk kerja yang sensitif terhadap kependaman.

EEVDF mengendalikan pertukaran antara keadilan dan kependaman, tetapi tiada SLA milisaat tetap terhasil daripada berat beban. Penungguan sebenar masih bergantung pada CPU yang tersedia, bilangan entiti, hierarki berat, kuota, pemasaan bangun, dan kelas penjadualan yang lebih tinggi. Dalam temu duga, gunakan vruntime CFS untuk gerak hati bersejarah, kemudian simpulkan dengan peraturan pemilihan EEVDF yang diperlukan oleh gesaan Linux 6.12.

Langkah 3: Asingkan Nice, Berat Relatif, Kuota Keras, dan Set CPU

Untuk SCHED_OTHER, julat nice normal ialah -20 hingga 19, dan Linux mengekalkan nilai nice bagi setiap benang. Nice mengubah berat relatif dalam kelas adil. Ia tidak merizabkan sebarang CPU dan tidak boleh mengalih keluar had cgroup. Dengan penjadualan kumpulan tugas, entiti dalam cgroup yang berbeza terlebih dahulu bersaing pada peringkat kumpulan. Menukar nilai nice satu benang dalam sesuatu kumpulan mungkin tidak banyak mengubah perkongsian antara dua cgroup.

Tiga kawalan cgroup v2 menjawab soalan yang berbeza:

• cpu.weight secara lalai ialah 100 dan berjulat daripada 1 hingga 10000; ia mengagihkan kitaran CPU yang dipertikaikan secara berkadar dalam kalangan adik-beradik yang aktif;
• cpu.max mempunyai format $MAX $PERIOD dan lalai kepada max 100000; nilai maksimum berangka mendikit keseluruhan cgroup selepas ia menghabiskan belanjawan tempoh;
• cpuset.cpus.effective ialah set CPU yang sebenarnya tersedia selepas hierarki dan keadaan sistem digunakan.

Baca kekangan hos, benang, dan cgroup sasaran:

mpstat -P ALL 1 10
taskset -pc "$pid"
cat /sys/fs/cgroup/api/cpuset.cpus.effective
cat /sys/fs/cgroup/api/cpu.weight
cat /sys/fs/cgroup/api/cpu.max
cat /sys/fs/cgroup/api/cpu.stat
cat /sys/fs/cgroup/api/cpu.pressure

Jika nr_throttled dan throttled_usec dalam cpu.stat meningkat semasa selang permintaan perlahan, cgroup tersebut sememangnya telah mencapai had lebar jalurnya. Belanjawan kumpulan keras boleh menghentikan kumpulan tersebut walaupun CPU hos lain melahu; kedua-dua metrik mempunyai skop yang berbeza. Jika pembilang kuota kekal mendatar tetapi cpuset.cpus.effective hanyalah 2-3 dan CPU 2 serta 3 tepu, purata hos 78% adalah sama mengelirukan.

Langkah 4: Ukur Penungguan daripada Runnable ke Running Secara Langsung

Selepas memilih benang perlahan yang representatif, baca pembilang penjadualannya sebanyak dua kali:

cat /proc/"$tid"/schedstat
sleep 5
cat /proc/"$tid"/schedstat

Tiga medan tersebut ialah kumulatif nanosaat berjalan pada CPU, kumulatif nanosaat menunggu pada run queue, dan bilangan hirisan masa (timeslices) yang diperoleh. Gunakan delta antara bacaan dan bukannya jumlah sepanjang hayat. Pertumbuhan pantas dalam medan kedua dengan masa jalanan yang sedikit menyokong "runnable tetapi tidak berjalan dengan segera," walaupun kuota, afiniti, dan benang berkeutamaan lebih tinggi masih diperlukan untuk menerangkan sebabnya.

Apabila taburan dan garis masa diperlukan, ambil surihan ringkas di seluruh sistem:

sudo perf sched record -a -- sleep 15
sudo perf sched timehist --state --summary

perf sched timehist boleh menunjukkan masa menunggu, kelewatan penjadualan daripada runnable ke running, dan masa jalanan, sambil meletakkan keadaan bangun, penghijrahan, dan CPU pada garis masa. Dalam pengeluaran, sahkan terlebih dahulu sokongan kernel, keistimewaan, ruang cakera, dan overhed yang boleh diterima. Hadkan tetingkap pengumpulan dan alih keluar data surihan yang tidak lagi diperlukan. Satu sampel 15 saat yang terlepas peristiwa ekor tidak membersihkan penjadual daripada kesalahan; bandingkan taburan merentas larian sebelum dan selepas yang boleh diulang.

Langkah 5: Menumpu kepada Lima Punca dengan Bukti yang Membezakan

Gunakan matriks berikut untuk mengecilkan punca:

cpu.pressure mengukur masa di mana kerja yang boleh dijalankan (runnable) tidak dapat membuat kemajuan disebabkan oleh perbalahan CPU. Ia merupakan bukti berguna bahawa persaingan CPU menjejaskan beban kerja, tetapi ia tidak membezakan berat relatif yang tidak mencukupi daripada pendikit kuota atau pematrian yang salah. cpu.stat, afiniti, dan surihan penjadual melengkapkan perbezaan tersebut.

Kerja masa nyata mengikut laluan keutamaan yang berasingan. Benang SCHED_FIFO berjalan sehingga ia disekat, didahului (preempted) oleh benang masa nyata berkeutamaan lebih tinggi, atau menyerahkan kawalan (yields). SCHED_RR menambah kuantum hanya dalam kalangan benang pada keutamaan masa nyata yang sama. Tiada berat kelas adil yang membolehkan benang normal mengatasi benang masa nyata berkeutamaan lebih tinggi yang runnable secara berterusan.

Langkah 6: Perbaiki Mekanisme yang Terbukti dan Sahkan Kedua-dua Metrik Perniagaan dan Penjadual

Setiap mitigasi harus sepadan dengan mekanisme yang disahkan:

• kuota salah: tingkatkan atau alih keluar cpu.max yang salah selepas menilai kapasiti dan impak jiran;
• bahagian relatif tidak mencukupi: tingkatkan berat cgroup API, kurangkan berat cgroup luar talian, atau turunkan keutamaan nice tugas luar talian;
• set CPU salah: luaskan atau seimbangkan semula cpuset atau afiniti sambil memeriksa NUMA dan lokaliti cache;
• perbalahan kelas adil: hadkan keserentakan luar talian, pecahkan kelompok, atau gunakan SCHED_BATCH atau SCHED_IDLE untuk kerja luar talian yang sesuai;
• penungguan tidur: perbaiki perbalahan kunci, kolam pekerja, I/O, tekanan memori, atau perkhidmatan hiliran; penalaan penjadual biasanya tidak memberi manfaat;
• kebuluran masa nyata: alih keluar dasar masa nyata yang tidak perlu, hadkan masa jalanan, dan periksa penyongsangan keutamaan (priority inversion) serta kebergantungan kunci.

Jalankan perbandingan sebelum dan selepas pada kadar permintaan dan beban luar talian yang sama. Sahkan sekurang-kurangnya p50/p95/p99 API dan ralat, taburan kelewatan penjadualan setiap benang, delta penungguan run-queue schedstat, pendikit cgroup, tekanan CPU, penggunaan setiap CPU, dan daya pemprosesan luar talian. Memperbaiki p99 API tidak boleh membulurkan tugas luar talian secara kekal atau memindahkan tekanan ke perkhidmatan hiliran atau penyewa lain.

Contoh Jawapan yang Mantap

“Purata CPU hos 78% tidak membersihkan penjadual daripada kesalahan. Linux menjadualkan benang, dan kekangan boleh wujud pada peringkat benang, CPU, atau cgroup. Saya akan terlebih dahulu menentukan sama ada benang yang mengendalikan permintaan perlahan adalah runnable. Jika ia tidur pada futex atau I/O, masa CPU yang rendah sebahagian besarnya mencerminkan penungguan untuk bangun, jadi penjadual tidak dapat memilihnya.

Gesaan menyatakan Linux 6.12. vruntime CFS menerangkan gerak hati keadilan, tetapi pemilihan semasa harus diterangkan dengan EEVDF: penjadual menjejaki lag berbanding perkhidmatan ideal, membiarkan entiti dengan lag >= 0 bersaing, dan memilih tarikh akhir maya yang paling awal. Nice dan cpu.weight mengubah perkongsian relatif jangka panjang; cpu.max menetapkan siling berkala yang keras; afiniti dan cpuset mengehadkan CPU yang layak. Tiada satu pun daripada mekanisme tersebut menjamin p99 45ms secara automatik.

Saya akan menjalankan mpstat -P ALL, kemudian membaca cpuset.cpus.effective, cpu.weight, cpu.max, cpu.stat, dan cpu.pressure untuk cgroup API. Jika nr_throttled dan throttled_usec meningkat sepanjang selang yang perlahan, pendikit kuota diperhatikan secara langsung; kapasiti hos yang melahu tidak mengubah kesimpulan tersebut. Jika kerja dihadkan kepada CPU 2 dan 3 serta CPU tersebut penuh, saya akan membaiki set CPU tempatan terlebih dahulu.

Tanpa anomali pendikit atau pematrian, saya akan mengambil dua bacaan /proc/12345/schedstat untuk TID yang representatif dan mengira delta penungguan run-queue. Di bawah beban yang boleh dihasilkan semula, saya akan mengambil surihan perf sched record secara ringkas dan memeriksa timehist untuk kelewatan runnable-ke-running, pengejut (waker), dan CPU. Penungguan run-queue yang rendah digabungkan dengan tidur yang berpanjangan akan mengalihkan penyiasatan kepada kunci, I/O, giliran aplikasi, dan surihan hiliran.

Katakan bukti menunjukkan cgroup API dikonfigurasikan sebagai 20000 100000, dengan pendikit meningkat seiring dengan p99. Saya akan membetulkan belanjawan menggunakan kapasiti yang diukur dan mengehadkan keserentakan luar talian. Saya tidak akan memindahkan API ke SCHED_FIFO begitu sahaja. Ujian semula akan menggunakan trafik dan tugas kelompok yang sama serta memerlukan p99 API, kelewatan penjadualan, pendikit, dan tekanan CPU menurun bersama-sama manakala daya pemprosesan luar talian kekal boleh diterima dan tiada tugas yang kebuluran.”

Kesilapan Biasa

• Menganggap 78% CPU hos sebagai bukti tiada masalah CPU → purata menyembunyikan kuota cgroup dan set CPU tempatan → periksa paparan setiap CPU, cgroup, dan benang secara bersama.
• Memanggil semua masa off-CPU sebagai kelewatan penjadualan → benang yang sedang tidur belum lagi runnable → gunakan keadaan, timbunan, dan surihan untuk menetapkan titik bangun terlebih dahulu.
• Hanya membaca hafalan “CFS memilih vruntime terkecil” → kelas adil mula beralih kepada EEVDF dalam Linux 6.6 → terangkan lag yang layak dan tarikh akhir maya paling awal.
• Menganggap cpu.weight=200 merizabkan dua CPU → weight menyatakan bahagian relatif dalam kalangan adik-beradik aktif di bawah perbalahan → reka kapasiti secara berasingan dan gunakan cpu.max untuk siling keras.
• Menganggap nice menyusun semua bekas secara langsung → kumpulan tugas terlebih dahulu bersaing pada hierarki cgroup → periksa berat kumpulan sebelum memutuskan sama ada untuk menukar nice benang.
• Menyimpulkan kependaman penjadual daripada banyak pertukaran konteks → I/O normal dan keserentakan juga boleh menghasilkan pertukaran → ukur penungguan run-queue schedstat dan kelewatan perf sched.
• Menggunakan SCHED_FIFO sebagai pembetulan pantas API → benang masa nyata berkeutamaan tinggi boleh membulurkan kerja normal dan meningkatkan risiko kunci → pertimbangkan dasar masa nyata hanya untuk tarikh akhir sebenar, masa jalanan terhad, dan analisis keselamatan yang lengkap.
• Meningkatkan berat API tanpa memeriksa kuota → cgroup masih mendikit selepas mencapai cpu.max → buktikan pendikit dengan cpu.stat dan betulkan had.
• Hanya memeriksa p99 API → perubahan mungkin membulurkan tugas kelompok atau menurunkan prestasi penyewa lain → sahkan keadilan, daya pemprosesan, tekanan, dan ralat juga.

Soalan Susulan dan Maklum Balas

Susulan 1: Mengapakah cgroup Boleh Didikit Semasa Hos Masih Mempunyai CPU yang Melahu?

cpu.max mengehadkan lebar jalur CPU yang digunakan oleh cgroup tersebut semasa suatu tempoh. Selepas belanjawan habis, kumpulan tersebut menunggu untuk tempoh seterusnya walaupun CPU yang tidak digunakan oleh kumpulan lain melahu. Periksa cpu.max dan bandingkan delta dalam nr_throttled dan throttled_usec daripada cpu.stat sepanjang selang yang sama. Nilai-nilai tersebut menjawab sama ada had keras terpicu secara lebih langsung berbanding penggunaan hos agregat.

Susulan 2: Mengapakah Mengubah Nice Benang API Mungkin Memberi Sedikit Kesan?

Linux mengenakan nice bagi setiap benang, tetapi dengan penjadualan kumpulan, cgroup berbeza terlebih dahulu bersaing sebagai entiti penjadualan menggunakan berat kumpulan. Menukar nice terutamanya mengubah perkongsian benang dalam kumpulannya. Ia tidak boleh mengalih keluar cpu.max induk, dan ia mungkin tidak mengubah nisbah antara kumpulan API dan luar talian. Petakan hierarki cgroup dan berat sebelum memilih nice benang atau cpu.weight kumpulan.

Susulan 3: Adakah Memindahkan API ke SCHED_FIFO Akan Membaiki p99?

Ia mungkin memendekkan penungguan benang sasaran, tetapi ia memperkenalkan risiko yang lebih besar. Benang FIFO yang boleh dijalankan (runnable) secara berterusan boleh menindas semua kerja kelas adil yang normal. Jika ia berpusing (spins), memegang kunci, atau bergantung pada benang normal yang dibulurkannya, sistem boleh berhenti membuat kemajuan. Nilaikan dasar masa nyata hanya apabila kerja tersebut mempunyai tarikh akhir yang tulen, masa jalanan dihadkan dengan ketat, penyongsangan keutamaan dikendalikan, dan perlindungan sandaran wujud.

Susulan 4: Adakah EEVDF Menjamin Perkhidmatan CPU Dalam Satu Hirisan?

Tidak. Tarikh akhir maya menyusun entiti penjadualan yang layak, dan hirisan menyatakan keutamaan kependaman. CPU yang tersedia, kiraan entiti, berat, kuota, afiniti, dan kelas penjadualan yang lebih tinggi masih mempengaruhi masa penungguan sebenar. EEVDF menyediakan mekanisme penjadual untuk mengimbangi keadilan dan kependaman; ia bukan SLA p99 perniagaan.

Susulan 5: Bagaimana Anda Memisahkan Penungguan Mutex daripada Penungguan Run-Queue?

Benang yang menunggu mutex biasanya tidur dan menjadi runnable selepas kunci dilepaskan. Penungguan run-queue bermula selepas ia boleh dijalankan (runnable). Selaraskan timbunan off-CPU aplikasi atau eBPF dan metrik futex atau kunci dengan /proc/12345/schedstat dan perf sched timehist. Tidur futex yang berpanjangan dengan penungguan run-queue yang rendah menunjukkan masalah kunci; kelewatan runnable-ke-running yang panjang menunjukkan masalah penjadualan atau kawalan sumber.

Susulan 6: Bilakah Pematrian CPU (CPU Pinning) Benar-benar Boleh Membantu?

Pengasingan yang direka bentuk dengan baik boleh mengurangkan penghijrahan, gangguan cache, dan jiran yang bising, contohnya dengan merizabkan CPU yang diuji kapasitinya untuk benang yang sensitif terhadap kependaman. Set CPU mestilah cukup besar, sampukan dan kerja latar belakang memerlukan tadbir urus, dan giliran setiap CPU memerlukan pemantauan. Pematrian yang salah mewujudkan kesesakan setempat manakala kapasiti hos kekal melahu, jadi sahkan hasilnya dengan penggunaan setiap CPU dan kelewatan penjadualan.