Menggunakan dan memahami opsi terkait penjadwalan systemd dalam konteks desktop

Dalam file layanan systemd, seseorang dapat mengatur opsi terkait penjadwalan berikut (dari systemd.exechalaman manual , koreksi saya jika saya salah):

Nice Mengatur level nice default (prioritas penjadwalan) untuk proses yang dijalankan. Mengambil bilangan bulat antara -20 (prioritas tertinggi) dan 19 (prioritas terendah). Lihat setpriority (2) untuk detailnya.

Yang merupakan level bagus yang akrab. Sepertinya pengaruhnya 'subverted' agak karena fitur 'autogroup' dari kernel linux baru-baru ini. Jadi opsi di bawah ini mungkin yang ingin saya setel agar proses berjalan dengan baik untuk pengalaman desktop saya.

CPUSchedulingPolicy Menetapkan kebijakan penjadwalan CPU untuk proses yang dijalankan. Mengambil salah satu dari yang lain, batch, idle, fifo atau rr. Lihat sched_setscheduler (2) untuk detailnya.

CPUSchedulingPriority Menetapkan prioritas penjadwalan CPU untuk proses yang dijalankan. Kisaran prioritas yang tersedia tergantung pada kebijakan penjadwalan CPU yang dipilih (lihat di atas). Untuk kebijakan penjadwalan waktu nyata, integer antara 1 (prioritas terendah) dan 99 (prioritas tertinggi) dapat digunakan. Lihat sched_setscheduler (2) untuk detailnya.

CPUSchedulingResetOnFork Membawa argumen boolean. Jika benar, prioritas dan kebijakan penjadwalan CPU yang meningkat akan diatur ulang saat proses dieksekusi bercabang, dan karenanya tidak dapat bocor ke proses anak. Lihat sched_setscheduler (2) untuk detailnya. Default ke false.

Saya mengerti pilihan terakhir. Saya mengumpulkan dari penjelasan dua yang pertama bahwa saya dapat memilih kebijakan penjadwalan dan kemudian, mengingat kebijakan itu, menjadi prioritas. Tidak sepenuhnya jelas bagi saya apa yang harus saya pilih untuk jenis tugas apa. Sebagai contoh, apakah aman untuk memilih 'idle' untuk tugas cadangan (relatif intensif CPU, karena deduplicating), atau yang lain lebih cocok?

Secara umum, mendapatkan gambaran umum yang dapat dipahami dari setiap kebijakan, dengan masing-masing prioritas dan kesesuaian untuk tujuan tertentu adalah apa yang saya cari. Juga interaksi dengan level yang bagus menarik.

Di samping penjadwalan CPU, ada penjadwalan IO. Saya kira ini sesuai dengan ionice(koreksi saya jika saya salah).

IOSchedulingClass Menetapkan kelas penjadwalan I / O untuk proses yang dieksekusi. Mengambil bilangan bulat antara 0 dan 3 atau salah satu dari string tidak ada, realtime, usaha terbaik atau idle. Lihat ioprio_set (2) untuk detailnya.

IOSchedulingPriority Menetapkan prioritas penjadwalan I / O untuk proses yang dieksekusi. Mengambil bilangan bulat antara 0 (prioritas tertinggi) dan 7 (prioritas terendah). Prioritas yang tersedia tergantung pada kelas penjadwalan I / O yang dipilih (lihat di atas). Lihat ioprio_set (2) untuk detailnya.

Kami di sini melihat struktur yang sama dengan penjadwalan CPU. Saya mencari jenis informasi yang sama juga.

Untuk semua opsi 'Penjadwalan', halaman manual yang dirujuk tidak cukup jelas bagi saya, kebanyakan dalam menerjemahkan hal-hal ke sudut pandang pengguna desktop yang cenderung teknis.

— Equaeghe
sumber

Apa masalah kinerja tertentu yang Anda coba selesaikan? Apakah sesuatu berjalan terlalu lambat atau terlalu lambat untuk Anda? Saya menggunakan Ubuntu 16.04 dengan systemd sebagai desktop, dengan cadangan berjalan di latar belakang dan tidak memiliki masalah kinerja yang terkait dengan prioritas relatif.

— Mark Stosberg

@MarkStosberg Pertanyaan ini ditanyakan oleh latar belakang pekerjaan cadangan yang berjalan sementara tugas komputasi latar depan pada sistem dual-core membuat antarmuka tidak responsif. Saya kemudian menambahkan opsi Nice ke skrip cadangan dan pada saat yang sama melihat opsi lain. Mereka mungkin relevan dengan masalah yang disebabkan cadangan atau masalah lain yang saya temui di masa depan. Jadi saya ingin belajar lebih banyak tentang opsi-opsi lain, tanpa itu terkait dengan masalah nyata.

— Equaeghe

Setiap bit dokumentasi merujuk halaman manual di mana Anda dapat menemukan lebih banyak dokumentasi jika Anda tertarik. Apakah membaca halaman manual yang dirujuk untuk ioprio_set (2) dan sched_setscheduler (2) membantu menjawab pertanyaan Anda?

— Mark Stosberg

@ Markarkosberg Tidak, seperti yang ditunjukkan dalam pertanyaan saya. Halaman manual tidak buruk, tetapi tidak selalu membantu saya memutuskan apa yang harus dilakukan (apakah menyesuaikan nilai bagus masih aman / benar untuk dilakukan saat ini?). balasan dari pengguna berpengalaman dari opsi ini yang dapat memberikan contoh nyata dan mengetahui dampak autogroup dalam kasus konkret seperti itulah yang saya harapkan.

— Equaeghe

Saya baru saja menemukan arahan ini dalam konteks yang hampir sama (backup latar belakang menyebabkan lag). Saya menemukan bahwa man sched (7) memiliki deskripsi yang jauh lebih komprehensif dari dua halaman manual lainnya. (Ini juga menyebutkan kapan nicenilainya berlaku).

— Wisperwind

Jawaban:

CPUScheduling {Kebijakan | Prioritas}

Tautan memberi tahu Anda bahwa CPUSchedulingPriorityhanya boleh ditetapkan untuk fifoatau rr("real-time") tugas. Anda tidak ingin memaksakan penjadwalan waktu nyata pada layanan.

CPUSchedulingPolicy=other adalah standarnya.

Itu pergi batchdan idle. Perbedaan di antara mereka hanya relevan jika Anda memiliki banyak tugas idle-mengkonsumsi CPU pada saat yang sama. Secara teori batchmemberikan throughput yang lebih tinggi (dengan imbalan latensi yang lebih lama). Tapi ini bukan kemenangan besar, jadi itu tidak benar-benar relevan dalam kasus ini.

idlebenar-benar kelaparan jika ada hal lain yang menginginkan CPU. Prioritas CPU agak kurang signifikan daripada sebelumnya, untuk sistem UNIX lama dengan satu inti. Saya akan lebih bahagia memulai dengan nice, misalnya level 10 atau 14 yang bagus, sebelum beralih ke idle. Lihat bagian selanjutnya.

Namun sebagian besar desktop relatif idle sebagian besar waktu. Dan ketika Anda memiliki CPU babi yang akan mencegah tugas latar belakang, itu umum untuk babi hanya menggunakan salah satu CPU Anda. Dengan pemikiran itu, saya tidak akan merasa terlalu berisiko menggunakan idledalam konteks desktop atau laptop biasa. Kecuali jika memiliki CPU Atom / Celeron / ARM dengan atau di bawah sekitar 15 watt ; maka saya ingin melihat hal-hal sedikit lebih hati-hati.

Apakah level bagus 'disubversi' oleh fitur kernel 'autogroup'?

Ya.

Autogrouping sedikit aneh. Penulis systemdtidak suka heuristik, bahkan untuk desktop. Jika Anda ingin menguji penonaktifan autogrouping, Anda dapat mengatur sysctl kernel.sched_autogroup_enabled menjadi 0. Saya kira itu yang terbaik untuk menguji dengan mengatur sysctl di konfigurasi permanen dan me-reboot, untuk memastikan Anda menyingkirkan semua autogroup.

Maka Anda harus dapat tingkat yang bagus untuk layanan Anda tanpa masalah. Setidaknya dalam versi systemd saat ini - lihat bagian selanjutnya.

Misalnya level 10 yang bagus akan mengurangi bobot setiap utas dalam penjadwal CPU Linux, menjadi sekitar 10%. Level 14 bagus di bawah 5%. (Tautan: rumus lengkap )

Lampiran: apakah level bagus 'ditumbangkan' oleh cgroup systemd?

DefaultCPUAccounting= Pengaturan saat ini secara default dimatikan, kecuali jika dapat diaktifkan tanpa juga mengaktifkan kontrol CPU berdasarkan per layanan. Jadi itu harus baik-baik saja. Anda dapat memeriksa ini di dokumentasi Anda saat ini:man systemd-system.conf

Ketahuilah bahwa kontrol CPU per layanan juga akan diaktifkan ketika layanan mana pun menetapkan CPUAccounting / CPUWeight / StartupCPUWeight / CPUShares / StartupCPUShares.

Ekstrak blog berikut kedaluwarsa (tetapi masih online). Perilaku default telah berubah, dan dokumentasi referensi telah diperbarui.

Sebagai default yang bagus, jika cpu controller diaktifkan di kernel, systemd akan membuat cgroup untuk setiap layanan ketika memulai. Tanpa konfigurasi lebih lanjut ini sudah memiliki satu efek yang bagus: pada sistem systemd setiap layanan sistem akan mendapatkan jumlah CPU yang merata, terlepas dari berapa banyak proses yang ada. Atau dengan kata lain: di server web Anda MySQL akan mendapatkan jumlah CPU yang kira-kira sama dengan Apache, bahkan jika yang terakhir terdiri dari 1000 proses skrip CGI, tetapi yang sebelumnya hanya dari beberapa tugas pekerja. (Perilaku ini dapat dimatikan, lihat DefaultControllers = di /etc/systemd/system.conf.)

Di atas default ini, dimungkinkan untuk secara eksplisit mengkonfigurasi pembagian CPU yang didapat layanan dengan pengaturan CPUShares =. Nilai defaultnya adalah 1024, jika Anda menambah angka ini, Anda akan menetapkan lebih banyak CPU untuk layanan daripada yang tidak diubah pada 1024, jika Anda menguranginya, lebih sedikit.

http://0pointer.de/blog/projects/resources.html

— sourcejedi
sumber

-3

Saran penyetelan performa klasik adalah "Jangan Optimalkan, Tolok Ukur".

Alih-alih prihatin dengan saran umum, mulailah dengan kasus khusus yang Anda khawatirkan ditingkatkan dan telah dijadikan tolok ukur untuk memiliki masalah kinerja tertentu . Biarkan data membiarkan Anda ke arah kanan untuk menyetel. Dengan data, mungkin jelas jika proses Anda mengalami prioritas yang buruk, memonopoli CPU atau memiliki masalah lain.

Desktop modern sering kali cepat bekerja tanpa penyetelan apa pun.

— Mark Stosberg
sumber

Maaf, tapi ini bukan jawaban untuk pertanyaan itu. Intinya adalah bahwa mencoba sesuatu itu sulit jika seseorang tidak benar-benar memahami efeknya. Dan pertanyaan ini dipicu oleh (tetapi bukan tentang!) Masalah kinerja pada desktop modern.

— Equaeghe

Hanya perlu beberapa menit untuk mencoba salah satu opsi. Jika Anda memiliki tolok ukur dasar dan sasaran kinerja, Anda dapat dengan mudah memeriksa apakah opsi yang Anda coba menggerakkan Anda ke arah yang Anda inginkan.

— Mark Stosberg

@ Eeeghe, tombol-tombol acak yang acak-acakan tanpa mengetahui apa yang mereka lakukan tidak akan menyelesaikan masalah juga.

— vonbrand

Banyak saran, tetapi bukan jawaban. Ini seharusnya menjadi komentar. Terkadang firasat "ini terlalu lambat" cukup menjadi tolok ukur untuk tindakan cepat. Misalnya menggunakan systemd-analyzedengan blamedan plotsaya bisa mengurangi waktu boot pada RPi yang lebih lama lebih dari satu menit. Tentu, ketika sampai pada analisis masalah maka diperlukan untuk mengukur alih-alih memulai "optimasi" sebelum waktunya.

— 0xC0000022L