Konteks dan cakupan
Sebuah layanan Python asinkron multithread mengalami lonjakan CPU berkala pada beban puncak. Tim ingin mendapatkan call stack tanpa menginstrumentasi setiap pemanggilan fungsi atau menghentikan proses, kemudian menginginkan pengembang dapat memutar ulang (replay) hasilnya. Python 3.15 menambahkan profiling.sampling; PEP 799 mengorganisasi tracing dan sampling di bawah satu namespace.
Jelaskan kapan harus memilih sampling atau deterministic tracing, cara memilih jam CPU atau wall clock, dan cara mencakup thread serta build free-threaded tanpa memperlakukan estimasi sebagai penghitungan waktu yang pasti.
Hal yang dievaluasi pewawancara
Pewawancara mencari pemahaman tentang kesalahan sampling statistik serta perbedaan antara overhead-nya yang rendah dibandingkan instrumentasi dan cakupan cProfile.
Jawaban yang kuat mencakup izin attach, data sensitif, frekuensi sampling, pekerjaan berdurasi singkat, pembuatan versi profil, dan pemutaran ulang daripada hanya memberikan satu perintah.
Klarifikasi yang perlu ditanyakan terlebih dahulu
- Apakah masalahnya saturasi CPU, I/O wait, lock contention, atau lonjakan singkat?
- Berapa banyak overhead CPU, memori, dan disk yang diizinkan di produksi?
- Apakah Anda memerlukan thread, async task, status GIL, atau stack ekstensi native?
- Apakah operator diizinkan melakukan attach ke proses yang ada, dan siapa yang boleh mengakses datanya?
- Apakah tujuannya menemukan hotspot, membandingkan versi, atau membuktikan bahwa regresi telah hilang?
Jawaban 30 detik
“Saya akan menggunakan sampling dengan overhead rendah untuk menemukan hotspot yang berkelanjutan, lalu mengonfirmasi alur singkat dengan deterministic tracing pada canary kecil atau reproduksi offline. profiling.sampling melaporkan estimasi sampel, bukan waktu fungsi yang pasti. Saya akan mengumpulkan tampilan CPU dan wall, mempertahankan metadata thread dan build, mengenkripsi serta menyunting (redact) profil, dan memantau biaya profiler itu sendiri. Jika overhead atau risiko privasi tidak dapat diterima, cabut akses attach dan gunakan profiling offline.”
Solusi langkah demi langkah
Tentukan pertanyaan sampling
Sampling memperkirakan hotspot dari waktu ke waktu dengan intrusi rendah, tetapi tidak dapat menjamin fungsi yang sangat singkat dapat teramati atau memberikan waktu per panggilan yang tepat. Tentukan sinyal CPU, wall, lock-wait, dan tail-latency sebelum memilih clock dan durasi.
Pisahkan sampling dan tracing
PEP 799 menempatkan tool deterministik di bawah profiling.tracing dan mempertahankan cProfile sebagai alias kompatibilitas; sampling berada di bawah profiling.sampling. Tracing mencatat setiap pemanggilan dan cocok untuk alur singkat atau penghitungan jumlah panggilan dengan biaya lebih tinggi. Sampling mengamati stack secara berkala dan cocok untuk hotspot produksi serta permintaan yang panjang.
python -m profiling.sampling record --pid 1234 --clock cpu --duration 30 --output profile.bin
python -m profiling.sampling replay profile.bin --view flamegraphVerifikasi opsi perintah terhadap build 3.15 target; cuplikan tersebut mendeskripsikan alur kerja, bukan jaminan bahwa setiap versi beta memiliki flag yang identik.
Pilih jam CPU dan wall clock
CPU menjawab berapa banyak waktu prosesor yang dikonsumsi thread; wall mencakup waktu sleep, I/O, dan proses menunggu. Sampling khusus CPU dapat melewatkan masalah latensi end-to-end, sedangkan sampling khusus wall dapat salah melabeli proses menunggu sebagai komputasi. Simpan jenis clock dalam metadata profil.
Cakup thread, async, dan build free-threaded
Agregasikan stack berdasarkan thread atau task alih-alih hanya melihat thread utama. Untuk layanan asinkron, bedakan komputasi event-loop dari proses menunggu I/O. Build free-threaded memerlukan konteks contention dan ekstensi native. Catat pengidentifikasi instans, build interpreter, dan thread agar deployment dapat dibandingkan.
Kontrol overhead dan pekerjaan singkat yang terlewat
Frekuensi yang lebih tinggi meningkatkan resolusi tetapi meningkatkan biaya pembacaan stack dan penulisan. Tugas yang singkat dapat selesai di antara sampel; nol sampel tidak membuktikan nol eksekusi. Perpanjang jendela pengamatan, agregasikan instans, atau gunakan tracing offline untuk jalur kritis, sembari mengukur sampel yang dibuang dan CPU profiler.
Lindungi data dan izin
Attach memerlukan izin tingkat proses, dan profil dapat memuat nama modul, path, serta fungsi bisnis. Batasi operator yang dapat melakukan attach, jauhkan data permintaan dari label, enkripsi biner, tetapkan TTL, dan bagikan hanya salinan yang telah disunting. Log operasional berisi ID profil, versi, dan konfigurasi, bukan kunci atau payload.
Replay, bandingkan, dan tetapkan regression gate
Simpan clock, rate, durasi, versi interpreter, commit hash, dan jendela beban. Bandingkan proporsi hotspot, distribusi thread, perbedaan wall/CPU, dan jumlah sampel; persentase dari rate yang berbeda tidak dapat dibandingkan secara langsung. Pasangkan profil dengan beban tolok ukur yang sama dan blokir rilis hanya jika ambang batas yang telah ditentukan sebelumnya terlampaui.
Canary, hentikan, dan roll back
Aktifkan jendela singkat yang dapat dicabut pada satu instans terlebih dahulu. Jika risiko CPU, memori, izin, atau privasi melebihi batas anggaran, hentikan attach baru, cabut akses sementara, dan hapus file yang kedaluwarsa. Biarkan layanan tetap berjalan dan alihkan analisis selanjutnya ke reproduksi dan tracing offline.
Contoh jawaban berkualitas tinggi
“Sampling adalah pelacak dengan intrusi rendah, bukan penghitung waktu yang tepat. Saya akan mengumpulkan tampilan CPU dan wall dengan profiling.sampling pada satu instans, lalu mengonfirmasi jalur pendek dengan profiling.tracing atau benchmark yang terkontrol. Setiap profil membawa metadata build, commit, clock, rate, dan beban; file dienkripsi, disunting, dikontrol aksesnya, dan berumur pendek. Perbandingan menggunakan parameter yang identik dan berfokus pada proporsi hotspot, distribusi thread, dan ambang batas. Jika profiler memakan biaya terlalu tinggi atau mengekspos data, cabut akses attach dan kembali ke analisis offline.”
Kesalahan umum
- Memperlakukan waktu sampel sebagai waktu pasti → target optimasi menjadi salah → jelaskan estimasi dan batasan sampling.
- Hanya melihat CPU → waktu tunggu I/O terlewatkan → kumpulkan tampilan CPU dan wall sesuai pertanyaan.
- Hanya mengambil sampel thread utama → hotspot worker dan event-loop hilang → pertahankan metadata thread, task, dan build.
- Mengasumsikan frekuensi yang lebih tinggi selalu lebih baik → biaya pengumpulan meningkat → ukur overhead profiler.
- Membandingkan persentase dari rate yang berbeda → hasil tidak dapat dibandingkan → standarisasi parameter dan beban.
- Menyimpan profil selamanya → path dan data sensitif bocor → sunting, enkripsi, batasi, dan tetapkan masa kedaluwarsa.
Pertanyaan lanjutan dan jawaban
Pertanyaan lanjutan 1: Kapan Anda harus menggunakan tracing?
Gunakan tracing untuk penghitungan per panggilan, hubungan pemanggilan yang tepat, atau jalur yang sangat pendek, lebih disukai secara offline atau pada canary kecil. Gunakan sampling untuk hotspot produksi yang berjalan lama di mana intrusi harus tetap rendah.
Pertanyaan lanjutan 2: Bagaimana jika sampling melewatkan tugas singkat?
Jendela pengamatan yang lebih panjang atau instans yang lebih banyak meningkatkan probabilitas tetapi tidak menjamin penangkapan. Gunakan benchmark, log berstempel waktu, atau tracing offline untuk pemeriksaan silang; nol sampel tidak berarti nol eksekusi.
Pertanyaan lanjutan 3: Mengapa mencatat build free-threaded?
Penjadwalan, lock contention, dan bentuk stack dapat berubah tergantung mode build. Tanpa hal itu, perbedaan profil tidak dapat dijelaskan dan sebuah optimasi mungkin hanya tampak valid pada satu interpreter tertentu.
Pertanyaan lanjutan 4: Bagaimana profil dapat menjadi pembatas (gate) rilis?
Tetapkan beban, clock, rate, dan durasi, lalu bandingkan distribusinya alih-alih satu sampel saja. Blokir hanya jika proporsi hotspot, tail latency, atau biaya profiler melebihi ambang batas yang telah ditentukan sebelumnya; kirim perbedaan lainnya untuk ditinjau.