Di bagian pertama seri ini, saya membahas konsep dasar cgroups dan bagaimana cgroups membantu mengelola kinerja dan keamanan di server Linux. Di sini di bagian dua, saya membahas nilai CPUShares dan bagaimana itu digunakan oleh cgroups. Jangan lupa bahwa di bagian tiga saya melihat administrasi cgroup dan di bagian empat saya menyimpulkan dengan cgroups saat mereka berinteraksi dengan systemd.
Sedikit tentang Linux Elevator
Saya akan mengambil fokus yang sangat sempit pada Red Hat Enterprise Linux (RHEL) untuk bagian ini. Namun, dalam pandangan sekilas saya pada beberapa kotak Ubuntu di lab saya, saya melihat kesamaan dengan penjadwal I/O. Oleh karena itu, beberapa poin saya dapat berlaku untuk distribusi lain juga. Sebagian besar produk keluarga Red Hat (Fedora, CentOS, dan RHEL) menggunakan deadline atau cfq sebagai penjadwal default.
- Antrian Sepenuhnya Adil (CFQ):Menekankan I/O yang berasal dari proses waktu nyata dan menggunakan data historis untuk memutuskan apakah aplikasi akan mengeluarkan lebih banyak permintaan I/O dalam waktu dekat.
- Batas waktu:Upaya untuk memberikan jaminan latensi untuk permintaan dan sangat cocok ketika operasi baca lebih sering terjadi daripada operasi tulis. Ada satu antrian untuk membaca dan satu untuk menulis. Operasi diselesaikan berdasarkan waktu yang dihabiskan dalam antrian, dan kernel akan selalu mencoba memproses permintaan sebelum waktu maksimumnya berlalu. Operasi baca lebih diutamakan daripada kumpulan tulis secara default.
Dengan mengingat hal itu, RHEL cenderung menggunakan cfq untuk drive berbasis SATA dan deadline untuk semua kasus lain secara default. Ini memainkan peran penting dalam menyetel sistem Anda. Penjadwal ini dapat diubah, tentu saja, dan Anda harus menyelidiki beban kerja Anda dan memilih penjadwal yang paling sesuai dengan tugas Anda. Perlu juga dicatat bahwa penjadwal dapat dipilih per perangkat blok . Ini berarti bahwa Anda dapat memiliki beberapa penjadwal pada satu sistem, tergantung pada bagaimana disk Anda dikonfigurasi.
[ Anda mungkin juga menyukai:Menyiapkan server SSH dalam wadah untuk perekaman sesi dengan tlog ]
CPUBerbagi
CPUBerbagi value menyediakan tugas dalam cgroup dengan jumlah waktu CPU yang relatif. Setelah sistem memasang pengontrol cpu cgroup, Anda dapat menggunakan file cpu.shares untuk menentukan jumlah saham yang dialokasikan ke cgroup. Waktu CPU ditentukan dengan membagi CPUShares cgroup dengan jumlah total CPUShares yang ditentukan pada sistem. Perhitungan waktu CPU ini menjadi cukup rumit, jadi mari kita lihat beberapa diagram untuk memperjelas beberapa hal.
Diagram di atas mewakili beberapa elemen paling umum pada server bidang kontrol RHEL 7 OpenShift Container Platform. Setiap proses pada sistem ini dimulai dengan / cgrup.
Di RHEL, ini dimulai dengan root / cgroup dengan 1024 share dan 100% resource CPU. Sumber daya lainnya dibagi rata di antara grup /system.slice , /user.slice , dan /kubepod.slice , masing-masing dengan bobot yang sama 1024 secara default, seperti yang terlihat di bawah ini:
Dalam skenario ini, logikanya cukup lurus ke depan:Setiap irisan hanya dapat menggunakan 33% dari CPUShares jika semua cgroup menuntut pembagian secara bersamaan. Perhitungannya cukup sederhana:
Dan saat Anda memasukkan angka:
Namun, bagaimana jika Anda memutuskan untuk membuat kelompok atau mengubah bobot kelompok pada tingkat yang sama? Di bawah ini adalah contoh grup bersarang:
Dalam contoh ini, Anda melihat bahwa saya telah membuat cgroup untuk pengguna yang berbeda. Di sinilah matematika menjadi menarik. Pada awalnya, Anda akan berpikir bahwa persamaan berikut akan bekerja dengan baik:
Namun, ini hanya 23% dari 33% yang dialokasikan untuk user.slice . Itu berarti pengguna1 memiliki sekitar 7,6% dari total waktu CPU berdasarkan bobot ini jika terjadi perselisihan sumber daya.
CPUShares baru saja menjadi rumit dengan tergesa-gesa. Untungnya, sebagian besar pengontrol lain lebih mudah daripada yang ini.
[ Memulai container? Lihat kursus gratis ini. Menyebarkan aplikasi kemas:Tinjauan teknis. ]
Menutup
Nilai CPUShares dapat membuat cgroup tampak sangat kompleks. Itulah bagian dari mengapa saya ingin membahas CPUShares di sini. Namun, penggunaan CPUShares yang tepat membantu Anda mengelola sistem dengan lebih efisien dan akurat.
Dalam artikel berikutnya dari seri ini, saya membahas administrasi cgroup. Saya harap Anda akan terus mengikuti seri ini. Di bagian empat saya akan mengakhiri diskusi kita dengan systemd dan cgroups.