GÜNCELLEME: Aşağıdaki cevabın RHEL 6 için geçerli olduğuna dikkat edin. RHEL 7'de, çoğu grup sistem tarafından yönetilir ve libcgroup kullanımdan kaldırılmıştır.
Bu soruyu yayınladığımdan beri, yukarıda belirtilen bağlantıların tamamını ve ayrıca cgroups.txt dokümantasyonunu ve cpusets.txt dosyasını çalıştım . Artık gruplarla ilgili öğrenmeyi umduğumdan daha fazlasını biliyorum, bu yüzden burada kendi soruma cevap vereceğim.
Alabileceğiniz birden fazla yaklaşım var. Şirketimizin Red Hat'ta (Teknik Mimar) teması, tüm süreçlerin daha kısıtlayıcı bir yaklaşıma tercih edilmeksizin, sadece özel olarak sınırlandırılmasını istediğimiz süreçleri kısıtlayan bir battaniyeyle sınırlandırılmaması yönünde tavsiye edilmiştir. Bunun nedeni, konuyla ilgili ifadelerine göre, sistem çağrılarının, kısıtlandığında sistemi yavaşlatabilecek kullanıcı hedef koduna (LVM işlemleri gibi) bağlı kalmasının mümkün olması - amaçlanan etkinin tersidir. Bu yüzden, özellikle isimlendirilmiş birkaç süreci kısıtlamak ve her şeyi yalnız bırakmakla bitirdim.
Ek olarak, sorumu yayınladığımda eksik olan bazı grup temel verilerinden bahsetmek istiyorum .
Gruplar kuruluma bağlı değildirlibcgroup . Bununla birlikte, bu, otomatik olarak grup konfigürasyonunu ve gruplara proses atamalarını idare etmek için kullanılan bir araç setidir ve çok faydalı olabilir.
Ayrıca, libcgroup paketinin yanıltıcı olabileceğini keşfettim, çünkü libcgroup paketi, kendi gruplarının gerçek çekirdek seviyesindeki uygulamasından biraz farklı olan cgroups kullanımınızla ilgili kendi soyutlamaları ve varsayımları üzerine kuruludur. (Örnekler koyabilirim ama biraz çalışmam gerekir; ilgilenirseniz yorum yapın.)
Bu nedenle, libcgroup araçlarını kullanmadan önce (örneğin /etc/cgconfig.conf, /etc/cgrules.conf, cgexec, cgcreate, cgclassify, vb) Ben son derece aşina almak tavsiye /cgroupsanal dosya sistemi kendisi ve elle sinsice libcgroup cgroups ekli birden alt sistemleri ile hiyerarşileri dahil CGroup hiyerarşileri (ve leakily özetleri oluşturarak uzakta), işlemleri çalıştırarak farklı gruplara ve başlık altında gerçekleştirilen echo $the_pid > /cgroup/some_cgroup_hierarchy/a_cgroup_within_that_hierarchy/tasksdiğer görünüşte sihirli görevleri yeniden atama libcgroup.
Ben eksikti başka temel kavram olduğunu eğer /cgroupsanal dosya sistemi hiç sisteminizde monte edilir (veya daha doğrusu, namı diğer "kontrolörleri" Tüm monte edilir CGroup alt sistemlerin varsa), o zaman her tüm sistem üzerinde işlem olduğunu a CGroup. "Bazı işlemler grup içinde, bazıları değil" diye bir şey yoktur.
Ekli alt sistemler için tüm sistem kaynaklarının sahibi olan belirli bir hiyerarşi için kök grup adı verilen şey var. Örneğin, cpuset ve blkio alt sistemlerine bağlı bir grup hiyerarşisi, sistemdeki tüm cpuslara ve sistemdeki tüm blkiolara sahip olacak ve bu kaynakların bir kısmını alt gruplarla paylaşabilecek bir kök grubuna sahip olacaktır . Kök grubunu kısıtlayamazsınız çünkü tüm sisteminizin kaynaklarına sahiptir, bu nedenle kısıtlamak mantıklı olmaz.
Libcgroup hakkında eksik olan bazı basit veriler:
Eğer kullanırsanız /etc/cgconfig.conf, bunu sağlamalıdır chkconfig --list cgconfiggösterileri cgconfigsistem açılışta çalışacak şekilde ayarlandı.
Eğer değiştirirseniz /etc/cgconfig.conf, çalıştırmak için gereken service cgconfig restartdeğişiklikleri yüke. (Ve hizmetini durdurma veya koşu ile ilgili sorunlar cgclearolduğunda kandırmak test etrafında çok yaygındır. Ayıklama için tavsiye, örneğin, lsof /cgroup/cpuseteğer cpusetkullandığınız CGroup hiyerarşisinin adıdır.)
Kullanmak isterseniz /etc/cgrules.conf, siz ( "CGroup kuralları motoru cini" sağlamak için gereken cgrulesengdçalışıyorsa): service cgred startve chkconfig cgred on. ( Sayfanın altındaki Bölüm 2.8.1'deki Red Hat Kaynak Yönetim Kılavuzu'nda açıklandığı gibi, bu hizmetle ilgili olası ancak olası olmayan bir yarış koşulunun farkında olmalısınız .)
Manüel olarak kandırmak ve sanal dosya sistemini kullanarak (ilk kullanım için önerdiğim) gruplarınızı cgconfig.confayarlamak isterseniz cgsnapshot, çeşitli seçenekleriyle ayarlarınızı yansıtacak bir dosya oluşturabilirsiniz .
Ve son olarak, aşağıdakileri yazarken eksik olan bilgi parçası:
Bununla birlikte, bunun ihmali, benim işlem adımın çocuklarının sınırlı cpu0sly cgroup'a atanacakları anlaşılıyor.
Haklıydım ama farkında olmadığım bir seçenek var.
cgexec Bir işlemi başlatmak / komutu çalıştırmak ve onu bir cgroup'a atamak için kullanılan komuttur.
cgclassify zaten çalışan bir işlemi bir gruba atamak için verilen komuttur.
Bunların her ikisi de cgred( cgrulesengd) 'nin belirtilen işlemi, farklı bir gruba dayanarak belirtilen işlemi yeniden tayin etmesini önleyecektir /etc/cgrules.conf.
Her ikisi de cgexecve ayrıca , temel olarak alt süreçleri yeniden atamasını engelleyen bayrağını cgclassifydestekliyor .--stickycgred/etc/cgrules.conf
Dolayısıyla, yazdığım soruya verilen cevap (yukarıda belirtilen Red Hat Teknik Mimarımızın tavsiyesi nedeniyle uygulamaya koyduğum kurulum olmasa da):
Sorumu açıklandığı gibi cpu0onlyve anycpucgroup olun . ( cgconfigÖnyüklemede çalışacak şekilde ayarlandığından emin olun .)
Sorumu * cpuset cpu0onlysorumumda açıklandığı gibi yapın . (Ve cgredaçılışta çalışacak şekilde ayarlandığından emin olun .)
Ben istiyorum tüm işlemleri başlatın sınırlanmayan ile: cgexec -g cpuset:anycpu --sticky myprocessname.
Bu süreçler sınırlandırılmayacak ve tüm çocuk süreçleri de sınırlandırılmayacak. Sistemdeki diğer her şey CPU 0 ile sınırlandırılacak (yeniden cgredbaşlattığınızda , çünkü EUID'lerini değiştirmedilerse zaten çalışmakta olan işlemlere cgrüller uygulanmaz). Bu tamamen tavsiye edilmez, ama ben başlangıçta istenen ve ne olduğunu olabilir cgroups ile yapılabilir.