Masaüstü bağlamında sistem planlamasıyla ilgili seçenekleri kullanma ve anlama

Systemd hizmet dosyalarında, aşağıdaki zamanlama ile ilgili seçenekler ayarlanabilir ( systemd.execman sayfasından yanlışsam beni düzeltin):

Nice Yürütülen işlemler için varsayılan güzel düzeyi (zamanlama önceliği) ayarlar. -20 (en yüksek öncelik) ile 19 (en düşük öncelik) arasında bir tamsayı alır. Ayrıntılar için ayar değerine (2) bakın.

Hangi tanıdık güzel seviyedir. Son linux çekirdeklerinin 'otomatik grup' özelliği nedeniyle etkisi bir şekilde 'altüst' görünüyor. Bu nedenle, aşağıdaki seçenekler, işlemlerin masaüstü deneyimim için iyi davranmasını sağlamak için gerçekten ayarlamak istediğim şey olabilir.

CPUSchedulingPolicy Yürütülen işlemler için CPU zamanlama ilkesini ayarlar. Diğer, toplu, boşta, fifo veya rr birini alır. Ayrıntılar için sched_setscheduler (2) bölümüne bakın .

CPUSchedulingPriority Yürütülen işlemler için CPU zamanlama önceliğini ayarlar. Kullanılabilir öncelik aralığı, seçilen CPU zamanlama ilkesine bağlıdır (yukarıya bakın). Gerçek zamanlı zamanlama politikaları için 1 (en düşük öncelik) ile 99 (en yüksek öncelik) arasında bir tamsayı kullanılabilir. Ayrıntılar için sched_setscheduler (2) bölümüne bakın .

CPUSchedulingResetOnFork Bir boole argümanı alır. Doğru ise, çalıştırılan işlemler çatal olduğunda yükseltilmiş CPU zamanlama öncelikleri ve ilkeleri sıfırlanır ve bu nedenle alt süreçlere sızamaz. Ayrıntılar için sched_setscheduler (2) bölümüne bakın . Varsayılanı false değerindedir.

Son seçeneği anlıyorum. İlk iki programın açıklamasından bir zamanlama politikası seçebileceğimi ve sonra bu politika dikkate alındığında bir öncelik topladım. Hangi tür görevler için neyi seçmem gerektiği tam olarak açık değil. Örneğin, yedekleme görevleri için 'boşta' seçilmesi güvenli midir?

Genel olarak, her bir politika için öncelikleri ve belirli amaçlara uygunluğu ile anlaşılır bir genel bakış elde etmek istediğim şeydir. Ayrıca güzel düzeyle etkileşim ilgi çekicidir.

CPU zamanlamanın yanında, IO zamanlaması vardır. Sanırım bu karşılık gelir ionice(yanılıyorsam beni düzeltin).

IOSchedulingClass Yürütülen işlemler için G / Ç zamanlama sınıfını ayarlar. 0 ile 3 arasında bir tam sayı veya hiçbiri, gerçek zamanlı, en iyi çaba veya boşta dizelerden biri alır. Ayrıntılar için ioprio_set (2) 'ye bakınız.

IOSchedulingPriority Yürütülen işlemler için G / Ç zamanlama önceliğini ayarlar. 0 (en yüksek öncelik) ile 7 (en düşük öncelik) arasında bir tam sayı alır. Kullanılabilir öncelikler seçilen I / O zamanlama sınıfına bağlıdır (yukarıya bakın). Ayrıntılar için ioprio_set (2) 'ye bakınız.

Burada CPU zamanlamasıyla aynı yapıyı görüyoruz. Ben de aynı tür bilgileri arıyorum.

Tüm 'Zamanlama' seçenekleri için, atıfta bulunulan kılavuz sayfalar benim için yeterince açık değildir, çoğunlukla işleri teknik olarak eğimli bir masaüstü kullanıcısının bakış açısına çevirir.

CPUScheduling {Politikası | Öncelik}

Bağlantı, bunun CPUSchedulingPriorityyalnızca fifoveya rr("gerçek zamanlı") görevler için ayarlanması gerektiğini belirtir . Hizmetler üzerinde gerçek zamanlı zamanlamayı zorlamak istemezsiniz.

CPUSchedulingPolicy=other varsayılan değerdir.

Bırakıyor batchve idle. Aralarındaki fark, yalnızca aynı anda CPU tüketen birden fazla boşta öncelikli göreviniz varsa önemlidir. Teorik olarak batchdaha yüksek verim sağlar (daha uzun gecikmeler karşılığında). Ama bu büyük bir kazanç değil, bu yüzden bu durumda gerçekten alakalı değil.

idleCPU'yu başka bir şey isterse kelimenin tam anlamıyla açlıktan ölür. Tek çekirdekli eski UNIX sistemleri için CPU önceliği eskisinden daha az önemlidir. Ben nicebaşvurmadan önce, örneğin güzel seviye 10 veya 14 ile başlayan daha mutlu olurdu idle. Sonraki bölüme bakın.

Bununla birlikte, çoğu masaüstü bilgisayar çoğu zaman nispeten boştadır. Ve arka plan görevini önceden kaldıracak bir CPU domuzunuz olduğunda, domuzun sadece CPU'larınızdan birini kullanması yaygındır. Bunu göz önünde bulundurarak, idleortalama bir masaüstü veya dizüstü bilgisayar bağlamında kullanmak çok riskli hissetmem . Yaklaşık 15 watt veya altında bir Atom / Celeron / ARM CPU'ya sahip olmadığı sürece ; o zaman olaylara biraz daha dikkatli bakmak isterim.

Güzel düzey, çekirdek 'otomatik grup' özelliği tarafından 'altüst edildi mi?

Evet.

Otomatik gruplama biraz garip. Yazarı, systemdmasaüstü bilgisayarlar için bile sezgisel olarak beğenmedi. Otomatik gruplandırmayı devre dışı bırakmayı test etmek istiyorsanız, sysctl öğesini kernel.sched_autogroup_enabled olarak ayarlayabilirsiniz 0. Sanırım tüm otomatik gruplardan kurtulduğunuzdan emin olmak için sysctl'i kalıcı yapılandırmada ve yeniden başlatmada ayarlayarak test etmek en iyisidir.

O zaman herhangi bir sorun olmadan hizmetleriniz için güzel seviyeleri mümkün olmalıdır. En azından systemd'nin mevcut sürümlerinde - bir sonraki bölüme bakın.

Örneğin, güzel seviye 10, her bir iş parçacığının Linux CPU zamanlayıcısında sahip olduğu ağırlığı yaklaşık% 10'a düşürecektir. Güzel seviye 14% 5'in altında. (Bağlantı: tam formül )

Ek: Güzel seviye sistemd grupları tarafından 'altüst edildi' mi?

Hizmet başına CPU kontrolünü etkinleştirmeden etkinleştirilemediği sürece geçerli DefaultCPUAccounting= ayar varsayılan olarak kapalıdır. Bu yüzden iyi olmalı. Bunu mevcut belgelerinizde kontrol edebilirsiniz:man systemd-system.conf

Hizmet başına CPU kontrolünün, herhangi bir hizmet CPUAccounting / CPUWeight / StartupCPUWeight / CPUShares / StartupCPUShares ayarladığında da etkinleştirileceğini unutmayın.

Aşağıdaki blog özeti güncel değil (ancak hala çevrimiçi). Varsayılan davranış o zamandan beri değişti ve referans belgeleri buna göre güncellendi.

Güzel bir varsayılan olarak, cpu denetleyicisi çekirdeğinde etkinleştirilirse, systemd her hizmeti başlatırken bir grup oluşturur. Başka bir yapılandırma olmadan bunun zaten güzel bir etkisi vardır: bir sistemd sisteminde, her bir sistem hizmeti, kaç işlemden oluştuğuna bakılmaksızın eşit miktarda CPU alır. Ya da başka bir deyişle: web sunucunuzda MySQL, 1000 CGI komut dosyası işlemi içeriyor olsa da, yalnızca birkaç çalışan görevden oluşsa bile, Apache ile yaklaşık olarak aynı miktarda CPU alacak. (Bu davranış kapatılabilir, bkz. DefaultControllers = /etc/systemd/system.conf.)

Bu varsayılan değerin üzerine, bir hizmetin CPUShares = ayarıyla aldığı CPU paylaşımlarını açıkça yapılandırmak mümkündür. Varsayılan değer 1024'tür, bu sayıyı artırırsanız, bir hizmete değiştirilmeden 1024'ten daha fazla CPU atarsınız, azaltırsanız daha az.

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

Klasik performans ayarlama tavsiyesi "Optimize Etmeyin, Kıyaslama" dır.

Genel tavsiye konusunda endişelenmektense, iyileşme konusunda endişelendiğiniz ve belirli bir performans endişesi için karşılaştırılmış özel bir durumla başlayın . Veriler, ayarlamanız için doğru yönergeye izin verin. Verilerle, işleminizin kötü bir önceliğe sahip olması, CPU'yu çalıştırması veya başka bir sorunu olup olmadığı açık olabilir.

Modern masaüstleri, herhangi bir ayar yapmadan çalışmak için genellikle çok hızlıdır.