Linux süreçleri farklı CPU ve IO önceliğine sahip olabilir (nice ve ionice).
Neden farklı CPU ve IO önceliğine ihtiyaç duyuluyor?
Onları farklı kılmak için gerçek dünya kullanımı var mı?
Farklı CPU ve IO önceliğine ihtiyaç duyan hangi gerçek dünya kullanım durumlarını buldunuz? Normal CPU önceliğinden daha yüksek ama normal IO önceliği veya viceversa'dan daha düşük gibi.
Yanıtlar:
'Nice' seçeneğinin varsayılan davranışı, özellik değiştiğinde de uygulamanın 'io' önceliğini ayarlamaktır.
Her şey elbette iş yükünüze bağlıdır, ancak herhangi bir işletim sisteminin temel yönlerinden biri, kaynağını nasıl ayırdığı ve çekişmeyi nasıl ele alacağıdır .
Güzelliğin ne yaptığını anlamak gerçekten önemlidir, çünkü rakip süreçlerden gelen yük altında işletim sisteminin davranış şekli iş yükünüzün geri kalanını etkileyebilir.
İçerik, farklı uygulamaların aynı kaynak için (CPU gibi) nasıl rekabet ettiğinin ölçüsüdür.
Taşıma Yükü
Tamamen adil bir zamanlayıcı piyasaya sürüldüğünden beri, nice her sürecin 'ağırlık' maddesinin sadece bir ön ucudur. Hangi proc görüntülenebilir.
$ cat /proc/self/sched
---------------------------------------------------------
...
se.load.weight : 1024
...
Güzelliği değiştirmek sadece ağırlığı değiştirir:
$ nice -n 5 cat /proc/self/sched
---------------------------------------------------------
...
se.load.weight : 335
...
CPU çekişmesi için ölçüm tamamen adil bir programlama algoritması ile yapılır. Her uygulamaya bir 'ağırlık' değeri atanır ve CPU zamanına karşı çıkma durumunda, CPU zamanına karşılık gelen tüm işlemlerin toplamı ve ağırlık değerlerine göre en düşük ortak değer CPU zamanını atayarak zamanlar süreçler arasında bölünür.
CPU zamanı kullanmak isteyen 3 uygulamam varsa, varsayılan olarak normal ağırlık olarak 1024 alırlar. Yukarıdaki gibi güzel bir +5'e sahip bir işlemim varsa, üç ağırlığın tamamı 2383'te toplanırsa, bu nedenle, eğer 3 işlemin hepsi o saniyede CPU isterse, bu işlem belirli bir saniyede cpu süresinin yaklaşık% 15'ini alacaktı. .
Neden farklı CPU ve IO önceliğine ihtiyaç duyuluyor?
Niceness gerçekten sadece sistem yük altındayken ne yapılacağı ile oynamak, yani - işletim sistemi gerekli faktörler tarafından tanımlanan rakip süreçler arasında nasıl zamanlanır.
Bunun sizi nasıl etkilediği veya size uygun olduğu, farklı uygulamaların birbirleriyle olan teslim priory'lerine ve her uygulamanın teslim süresine sahip olması gerekir.
Niceness gerçekten sadece sisteminiz yük altındayken bir şeyler yapar (CPU veya Disk'in işleyebileceğinden daha fazla dikkat isteyen şeyler vardır). Sadece çekirdeğe bu koşullar altında nasıl kaynak tahsis edileceğini öğretir.
Onları farklı kılmak için gerçek dünya kullanımı var mı?
CPU tarafından yapılabileceğinden çok daha fazla sayıda rekabet süreciniz ya da yapılacak işiniz varsa, incelik size işin önce bittiği konusunda nispeten istikrarlı garantiler verir. Söz konusu başka bir rapor tamamlanmadan önce iletilmesi gereken bir rapor üretiyorsanız, bu sizin için önemli olabilir.
Bir masaüstü sisteminde güzellik daha da önemli olabilir. Bazı uygulamalar, yük sırasında daha sık uyanmalarının veri bayatlamasını önleyen gerçek zamanlı bir davranışa sahiptir. Örneğin Pulseaudio bu kategoriye girer.
Bağımlı uygulamalar için işi tamamlamak için başka uygulamalar gerekebilir. Örneğin, MySQL gibi bir SQL sunucusunun uzun süre bloke edilebileceğini söyleyen birçok apache isteği, SQL'in yeterince hızlı sunmadığından, - başka bir raporun CPU zamanı için rekabet ettiğini söylüyor. Bu yüzden sadece SQL durmuyor, aynı zamanda Apache de duruyor. Zaman zaman SQL tarafından daha uygun bir şekilde tartılmak için bir grup olarak yarışan apache iş parçacıklarından genellikle çok daha az çalışan iş parçacığı olduğundan SQL bazen acıtabilir, bu nedenle SQL'e daha fazla CPU zamanı vermek işleri eşitler.
UpdateDB (dosyaları indeksleyen bir program) gece geç saatlerde çalışır ve disk ağırdır. IO zamanlama önceliğini azaltmak yararlı olabilir, böylece o sırada diğer uygulamalar, şeylerin sıralaması kadar önemli olmayan bir şeyden öncelik kazanır.
Farklı CPU ve IO önceliğine ihtiyaç duyan hangi gerçek dünya kullanım durumlarını buldunuz?
Çok az. Niceness çok iyi bir çaba yaklaşımıdır. Genel bir kural olarak, daha az uygulamaları ne kadar iyi performans hakkında ve bakım daha onlar ne kadar kötü üzerinde olabilir gerçekleştirin. Bu başlangıçta geri gelebilir ama benim için daha önemli olan karşılama hizmeti garantilerim var.
"Kötü bir günde bile eşyalarınız X zaman diliminde yapılacak" demenin güvenini istiyorum. Daha hızlı giderse, sadece bir bonus.
Genellikle aşağıdakiler gibi üzerinde anlaşmaya varılan şartnameler oluşturarak başlayacağım:
Ve aşağıdaki gibi karşılamak için gereksinimleri çizin:
Şartnameler doğruysa, bu hedefleri sanallaştırma yapmadan, kontrol gruplarının çok daha verimli yaklaşımını kullanarak gerçekleştiriyorum.
Kontrol grupları, uygulamanın belirtilen sınırlar dahilinde davranması koşuluyla kaynak tahsisi için oldukça güvenilir hizmet seviyesi garantileri vermemi sağlar. Bu, yük altındaki bir sistemde bile söz konusu uygulama için kaynak kullanılabilirliğini ve aynı kutudaki diğer uygulamalar için yer garanti edebileceğim anlamına gelir!
CPU ve IO örneğinizi alırsak. Bu gereksinimleri karşılayan limitler koydum:
# cd /sys/fs/cgroup/blkio/apache
# echo "253:0 100" >blkio.throttle.read_iops_device
# echo "253:0 50" >blkio.throttle.write_iops_device
# echo "253:0 102400" >blkio.throttle.read_bps_device
100 iops okumak için 100k bayt.
# cd /sys/fs/cgroup/cpu/apache
# echo 1000000 >cpu.cfs_period_us
# echo 60000 >cpu.cfs_quota_us
1 saniyelik bir zaman diliminden 0,06 saniye CPU verin.
# cd /sys/fs/cgroup/cpu/sql
# echo 1000000 >cpu.cfs_period_us
# echo 20000 >cpu.cfs_quota_us
1 saniyelik bir zaman periyodundan 0,02 saniye CPU verin.
Diğer rakip grupların aptalca bir şey yapmamalarını sağlamak, yük altında olmak hizmet sunumumda daha az bir faktördür, çünkü her uygulama için CPU'nun nasıl atıldığını biliyorum .
Bu nitelikteki kontrol grupları hala en iyi çabadır, ancak bu çaba üzerinde incelik ve iyoniklikten çok daha fazla kontrol sunarlar.