g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Docker kaynak yönetiminin temel ilkelerini ve uygulamasını tek bir makalede okuyun

1. Kaynak yönetimi ve Cgroup bilgisi

Linux sistemlerinin kullanımında, genellikle "belirli bir sürecin veya belirli işlemlerin kaynak tahsisini sınırlamayı ummak" olarak bahsedilen bir gereklilik vardır. Şu anda, yeni bir Cgroups terimi ortaya çıktı.

Cgroups, Kontrol Gruplarının kısaltmasıdır.Linux çekirdeği tarafından, işlem grupları tarafından kullanılan fiziksel kaynakları (cpu, bellek, IO vb.) Sınırlamak, kaydetmek ve izole etmek için sağlanan bir mekanizmadır ve süreçleri katmanlar halinde gruplandırır. , Ve özel bir dosya sistemiyle açın.

Başlangıçta Google mühendisleri tarafından önerildi, daha sonra Linux çekirdeğine entegre edildi.

İki, Docker-Cgroup ilkesi ve mekanizması

2.1 İlke ve işlev

Docker, ortamın izolasyonunu tamamlamak için Namespace'i kullanır. Ancak kapsayıcılar için, tüm kapsayıcılar ana bilgisayarın tüm CPU, bellek ve IO kaynaklarını paylaşabilir.Bu kaynakların izolasyonunu tamamlamak için Docker'ın Cgroups'a güvenmesi gerekir. Gruplardaki önemli kavram, "alt sistem", yani kaynak denetleyicidir.Her alt sistem bir kaynak ayırıcıdır.Örneğin, CPU alt sistemi CPU zamanının tahsisini kontrol eder.

2.2 Cgroup'un temel kavramları

1) Alt Sistemler : Buna bir alt sistem deyin Bir alt sistem bir kaynak denetleyicidir Örneğin, CPU alt sistemi CPU zaman tahsisini kontrol eden bir denetleyicidir.

2) Hiyerarşiler : Aranabilir Hiyerarşik sistem Ayrıca aranabilir Kalıtım sistemi , Kontrol Gruplarını ifade eder, hiyerarşi sisteminin ilişkisine göre düzenlenir.

3) Kontrol Grupları : Belirli bir standarda göre bölünmüş bir dizi süreç. Süreçler bir Kontrol Grubundan başka bir Kontrol Grubuna taşınabilir ve Kontrol Gruplarındaki süreçler de bu grubun kaynakları tarafından kısıtlanacaktır.

4) Görevler : Gruplarda Görevler sistemden biridir süreç .

2.3 Cgroup alt sistemi

Cgroup alt sisteminin adı ve amacı şunları içerir:

Alt sistemin dokümantasyonu:

Rpm paketini kurmak için yum install kernel-doc komutunu kullanın.

Belgelerin tümü / usr / share / doc / kernel-doc- dizinindedir. < Çekirdek sürümü > / Documentation / cgroups / dizininde, tümü txt formatındadır.

CPU alt sistemi hakkında daha fazla bilgi aşağıdaki gibidir:

Gerçek zamanlı planlama

/ usr / share / doc / kernel-doc- < Çekirdek sürümü > /Documentation/scheduler/sched-rt-group.txt

CFS planlaması

/ usr / share / doc / kernel-doc- < Çekirdek sürümü > /Documentation/scheduler/sched-bwc.txt

2.4 Varsayılan Cgroup seviyesi

Centos / red_hat 7 sisteminde, varsayılan olarak systemd, Cgroup ağacı için birleşik bir yapı sağlamak için otomatik olarak bir dilim, kapsam ve hizmet birimleri hiyerarşisi oluşturacaktır.

Systemd birim türü, sistemde çalışan tüm işlemler systemd init sürecinin alt süreçleridir. Kaynak yönetimi ve denetimi açısından systemd üç tip birim sağlar.

hizmet-bir işlem veya birim yapılandırma dosyasına göre systemd tarafından başlatılan bir süreçler grubu. hizmet, işlemin bir bütün olarak başlatılabilmesi veya sonlandırılabilmesi için belirtilen işlemi kapsüller. (Sistemdeki hizmet xxxx.service)
kapsam-Harici olarak oluşturulan süreçler kümesi. Fork () işlevi aracılığıyla zorunlu bir işlem tarafından başlatılan ve sonlandırılan ve ardından çalışma zamanında systemd tarafından kaydedilen bir işlem kapsam tarafından kapsüllenir. Örneğin: kullanıcı oturumları, kapsayıcılar ve sanal makineler kapsam olarak kabul edilir.
dilim-bir hiyerarşi içinde düzenlenmiş birimler kümesi. Bir dilim süreçler içermez, ancak bir hiyerarşi oluşturur ve içine hem kapsamı hem de hizmeti koyar. Gerçek süreç kapsam veya hizmetin içindedir.

Systemd-cgls komutunu kullanarak şunları görüntüleyebilirsiniz:

# systemd-cgls

User.slice altındaki iki kapsam, kullanıcının oturum açtığı tty'dir ve ortadaki sayı, kullanıcının kullanıcı kimliğini temsil eder.

Service.slice, sistemin tüm hizmetlerini temsil eder.

Tüm hiyerarşi ayrıca / sys / fs / cgroup / systemd altında da görülebilir.

2.5 Düzeyler ve alt sistemler arasındaki ilişkinin şeması

Sistemde oluşturulan ilk cgroup, root Cgroup olarak adlandırılır ve bu Cgroup'un üyeleri sistemdeki tüm işlemleri içerir.
Bir alt sistem birden çok seviyede konumlandırılabilir. Ancak, ancak ve ancak bu seviyelerin başka alt sistemleri yoksa, örneğin, 2 Hiyerarşinin aynı anda yalnızca bir CPU alt sistemi olabilirse, kısıtlamalar vardır.

Her seviyede birden fazla alt sistem ilişkilendirilebilir

Bir süreç, farklı Cgroup seviyelerinde bulunabilir

Bir süreç bir alt süreç oluşturduktan sonra, alt süreç varsayılan olarak üst sürecin bulunduğu Cgroup üyesine döner. Bu alt süreç manuel olarak Cgroup grubunu değiştirebilir.

Üç, Docker-Cgroup uygulaması

3.1 Bir kontrol grubu oluşturun

1. Geçici bir Cgroup oluşturmak için systemd-run kullanın

Kök kullanıcı olarak çalıştır

systemd-run --unit = name --scope --slice = dilim_adı komutu

Uyarılar:

ad, bu kuruluşun tanınmasını istediğiniz adı temsil eder. --Unit belirtilmezse, birim adı otomatik olarak üretilecektir.
Varsayılan olarak oluşturulan servis birimini değiştirmek üzere geçici bir osiloskop birimi oluşturmak için isteğe bağlı --scope parametresini kullanın.
--Slice seçeneği, yeni oluşturulan hizmet veya kapsam biriminizin belirtilen dilimin bir parçası olmasına izin verir.
komutu, servis ünitesinde çalıştırmak istediğiniz komutla değiştirin. Bu komutu systemd-run sözdiziminin en sonuna yerleştirin.

Misal:

Burada CPU'yu dolduran, kendisi sonsuz döngü olan bir sh betiği yazdım

# cat /root/1.sh doğru iken yapmak x = + 1 bitti

Kontrol grubunun oluşturulmasını tamamlamak için aşağıdaki komutu yürütün.

systemd-run --unit = 1.sh --slice = test sh /root/1.sh

Hizmetin çalışma durumunu sorgulamak için aşağıdaki komutu kullanın

systemctl durumu 1.sh

Servis işletim parametrelerini görüntülemek için show komutunu kullanın

systemctl gösterisi 1.sh

Dizin yapısını görüntüleyin:

ağaç / sys / fs / cgroup / systemd /

Bir test.slice dizininin yaratıldığını ve bu dizinin altına 1.sh.service dizininin yerleştirildiğini göreceksiniz. Tümü oluşturma sırasında belirtilir.

2. Kalıcı bir Grup oluşturun

Sistem başladığında bir otomatik başlatma birimini yapılandırmak için, birleşik dosyanın yazılmış olması koşuluyla systemctl enable komutunu çalıştırın.

3.2 Kontrol grubunu sil

1. Geçici kontrol grubunda yer alan süreç sona erdiğinde, geçici Cgroup otomatik olarak serbest bırakılacaktır.

Hizmet grubundaki tüm işlemleri durdurun:

systemctl stop 1.sh

Systemd altındaki test.slice dizinini kontrol edin

ls /sys/fs/cgroup/systemd/test.slice

1.sh hizmetinin artık mevcut olmadığını ve piyasaya sürüldüğünü göreceksiniz

2. Kalıcı kontrol grubu, sil

gerçekleştirillen

systemctl xxxxx devre dışı bırak

3.3 Cgroup parametrelerini değiştirin (kaynak kontrolü)

Komutu kullan

systemctl set-özellik adı parametresi = değer

Burada ad, kontrol grubu adını ve parametre, parametre adını temsil eder

1. CPU kaynaklarının kontrolü-CPUQUOTA (cpu birimi döngü süresi)

Bir kontrol grubu oluşturmak için yukarıdaki 1.sh'yi kullanın (1.sh, cpu'yu doldurabilecek sonsuz bir döngü yazar)

# systemd-run --unit = 2.sh --slice = test sh /root/1.sh Unit 2.sh.service olarak çalışıyor.

Cpu yükünü görüntülemek için üst kısmını kullanın

2.sh hizmetinin% 100'de çalıştığı bulundu

CPU kota değerini ayarlamak için systemctl kullanın

# systemctl set-property 2.sh.service CPUQuota =% 50

Ardından en yüksek değeri kontrol edin

Sürecin% 50'ye düştüğünü görecek

/ Sys / fs / cgroup / cpu / dizini görüntüle

# cd / sys / fs / cgroup / cpu / # ls cgroup.clone_children cgroup.sane_behavior cpuacct.usage_percpu cpu.rt_period_us cpu.stat system.slice user.slice cgroup.event_control cpuacct.stat cpu.cfs_period_us cpu.rt_runtime_us notify_on_release görevleri cgroup.procs cpuacct.usage cpu.cfs_quota_us cpu.shares release_agent test.slice # cd test.slice / # ls 2.sh.service cgroup.procs cpuacct.usage_percpu cpu.rt_period_us cpu.stat cgroup.clone_children cpuacct.stat cpu.cfs_period_us cpu.rt_runtime_us notify_on_release cgroup.event_control cpuacct.usage cpu.cfs_quota_us cpu.shares görevleri # cd 2.sh.service / # ls cgroup.clone_children cgroup.procs cpuacct.usage cpu.cfs_period_us cpu.rt_period_us cpu.shares notify_on_release cgroup.event_control cpuacct.stat cpuacct.usage_percpu cpu.cfs_quota_us cpu.rt_runtime_us cpu.stat görevleri

Test.slice ve 2.sh.service dizinlerinin yaratıldığını ve cpu kurallarının 2.sh.service dizinine kaydedildiğini göreceksiniz.

Bu dizindeki cfs yapılandırmasını görüntüleyin

# cat cpu.cfs_period_us 100.000 # cat cpu.cfs_quota_us 50000

Periyot 100000 (mikrosaniye birimleri ve 0,1 saniye), kota 50000 (mikrosaniye birimleri ve 0,05 saniye) olarak ayarlanmıştır, dönem dönemi temsil eder ve kota, işlemin dönem içinde CPU'yu işgal ettiği süreyi temsil eder. Bu kontrol grubundaki tüm işlemler, cpu döngüsünün 0.1 saniyesinde yalnızca 0.05 saniye sürdü. 2 CPU varsa, kota 200000 olarak ayarlanabilir, böylece 0,1 saniyelik döngü işlemi 0,2 saniye kullanır ve 2 CPU alır

Not: Bu cfs'nin ayarı mutlak bir değerdir

2. CPU kaynaklarının kontrolü-CPUSHARES (cpu kullanım ağırlığı)

Açıklama:

· Ana bilgisayarda başka hiçbir işlemin yürütülmediğini ve eklenen işlemin cpu'yu varsayılan olarak tam kapasite kullandığını varsayın.
Ana bilgisayarda 3 A, B ve C işlemi vardır. A işleminin ağırlığının 1024 (varsayılan), B işleminin 512 ve C işleminin 512 ağırlığının olduğunu varsayalım.
Sonra A% 50 cpu zaman dilimi alacak, B C sırasıyla% 25 zaman dilimi alacak.
Bu sefer bir D süreci eklenirse, ağırlık 1024'tür.
Daha sonra AD, CPU zaman diliminin% 33'ünü kaplar ve B C, zaman diliminin% 16,5'ini kaplar.
Çok çekirdekli sistemler için, CPU zaman dilimi tüm cpu çekirdeklerinin toplam süresidir ve bir işlem CPU'nun% 100'ünden daha az olacak şekilde ayarlanırsa, tek bir çekirdeğin% 100'ünü de alabilir.

İzlenecek yol (bu sefer sistem 2 cpu'dur)

Geçici olarak 2 grup oluşturun:

# systemd-run --unit = 1.sh --slice = test sh /root/1.sh Unit 1.sh.service olarak çalışıyor. # systemd-run --unit = 2.sh --slice = test sh /root/1.sh Unit 2.sh.service olarak çalışıyor.

Ardından cpu yükünü kontrol edin:

İki hizmetin yükü benzerdir, 1.sh paylaşım değerini indirin ve 512'ye ayarlayın

# systemctl set-property 1.sh.service CPUShares = 512

1.sh 2.sh c grubunun yapılandırmasını görüntüleyin

# pwd /sys/fs/cgroup/cpu/test.slice # cat 1.sh.service / cpu.shares 512 # cat 2.sh.service / cpu.shares 1024

Cpu yükünün hala çok ortalama olduğunu göreceksiniz, ancak paylaşım değeri 512 ve 1024 olarak ayarlanmıştır, bu da çok çekirdekli ayar% 100'den az olsa bile% 100 yük olabileceği anlamına gelir.

Şimdi bir 3.sh hizmetine katılıyor

# systemd-run --unit = 3.sh --slice = test sh /root/1.sh Unit 3.sh.service olarak çalışıyor.

Sonra yükü kontrol edin

Cpushares değeri esnek olduğu için, cpu yük oranının ayar ile kabaca aynı olduğunu göreceksiniz.

Her cg'nin cpu kullanımını görüntülemek için systemd-cgtop -c komutunu kullanın. Her cg'nin belirli değeri göstermesi için cpu seviyesinin altında systemd.slice bulunmalıdır, aksi takdirde yalnızca kökün toplam değeri görüntülenecektir.

3. MEM kaynak kontrolü

Bellek paylaşılamayan bir kaynaktır, bu nedenle en çok kullanılan ve ne kadar bellek ayrıldığı.

Çok fazla bellek tüketen bir servis oluşturun.

# kedi 2.sh x = a doğru iken yapmak x = $ x $ x echo $ x bitti

Oluşturmak

# systemd-run --unit = mem-test --slice = test sh /root/2.sh Unit mem-test.service olarak çalışıyor.

Bellek değerini ayarla

# systemctl set-property mem-test MemoryLimit = 10 milyon

Bu hizmet tarafından kullanılan belleği görüntülemek için systemctl status mem-test kullanın

# systemctl durumu mem-test