Temel varsayımım, bir işlemin sadece sınırlayıcı faktörleri disk ve CPU olduğunda, toplam sistem "iowait" + CPU kullanımının bir mantıksal CPU'nun en az% 100'üne eşit olması gerektiğidir. (Diğer durumlarda bu geçerli olmayacaktır. Ör. Kullanarak bir dosyayı indirirken wget, ağ genellikle sınırlayıcı faktördür).

Bu varsayım basit bir testle ihlal edilmektedir. Bu bekleniyor mu? Beklenirse, varsayımımın geçerli olmasını beklemem gereken bir dizi koşul var mı?

Burada "iowait" hakkında bir arka plan var: Bir CPU beklemede olan IO olduğunu nasıl biliyor? Bu sorunun cevabı, sezgisel "kümülatif" beklemenin "belirli koşullarda azalabileceğini" düşünüyor. Acaba basit testimin böyle belgelenmemiş bir durumu tetikleyip tetiklemediğini merak ediyorum.

GÜNCELLEME : Lütfen cevaba atlayın .

Cevabın ilk kullandığımdan daha basit bir testi var. Aşağıdaki orijinal soruyu korudum. Orijinal soru bazı ek ayrıntılar gösterebilir.

Orijinal soru

Kısa bir testte, ddçekirdeğin rasgele bayt üretmesini ve bunları bir dosyaya yazmasını istemek için kullanıyorum . ddİçindeki komutu çalıştırıyorum perf stat, sadece çekirdeğin içinde harcanan CPU zamanını saymak için. İçinde perf trace -sgeçirdiğim zamanı bildirmek için de içeride çalıştırıyorum write(). Aynı zamanda, vmstat 5sistemi "iowait" görmek için başka bir terminal koşmak .

1. En azından bir CPU'nun boşta kaldığını, yani çalıştığı veya durduğu zamanın% 100'ünü görmeyi bekliyorum ama IO ("iowait" durumu). O değildi.
2. (Ayrıca, "iowait" zamanını kabaca write () ile harcanan zamanla eşleştirmeyi bekliyordum. Ama öyle görünmüyordu.)

Ayrıntılı sonuçlar ve test ortamı aşağıda gösterilmiştir. Ayrıca varsayımımın geçerli olduğu alternatif bir test de gösterilmiştir. Not: perf statİçine koşmak gerekiyordu, tersi perf tracedeğil. Burada ayrıntılı olarak açıklanmıştır: "perf stat" (ve "time"!) "Perf trace - s" çalıştırılırken yanlış sonuçlar veriyor mu?

"Iyowait" hakkında temel bilgiler

sarManpageden alınan tanım şöyledir :

% İowait:

CPU veya CPU'ların, sistemin olağanüstü bir disk G / Ç isteği aldığı boşta kalma yüzdesi.

Bu nedenle,% iowait, CPU açısından hiçbir görevin çalıştırılamadığı, ancak en az bir G / Ç'nin devam ettiği anlamına gelir. iowait, hiçbir şeyin programlanamayacağı boşta kalma biçimidir. Değer, bir performans sorununun gösterilmesinde yararlı olabilir veya olmayabilir, ancak kullanıcıya sistemin boşta olduğunu ve daha fazla çalışma gerektirebileceğini söyler.

https://support.hpe.com/hpsc/doc/public/display?docId=c02783994

Daha uzun bir makale de var: G / Ç Beklemesini Anlama (veya neden% 0 Boşta sorun olabilir) . Bu, tanımı çekirdek kodundan nasıl net bir şekilde görebileceğinizi açıklar. Kod biraz değişti, ancak fikir hala açık:

/*
 * Account for idle time.
 * @cputime: the CPU time spent in idle wait
 */
void account_idle_time(u64 cputime)
{
    u64 *cpustat = kcpustat_this_cpu->cpustat;
    struct rq *rq = this_rq();

    if (atomic_read(&rq->nr_iowait) > 0)
        cpustat[CPUTIME_IOWAIT] += cputime;
    else
        cpustat[CPUTIME_IDLE] += cputime;
}

Makale ayrıca tek CPU sistemindeki ilgili deneyleri de göstermektedir. Deneylerin Hatta bazıları kullanmak ddile if=/dev/urandom ! Ancak deneyler benim testimi içermiyor dd if=/dev/urandom of=test.out . Sadece kullanır dd if=/dev/urandom of=/dev/null .

"IO wait" şu an düşünmek biraz daha zor çünkü çoklu CPU sistemleri kullanıyoruz, ancak alıntı koduna dayanarak hala anlıyorum.

çevre

Dört mantıksal CPU'm var.

LVM ve ext4 dosya sistemini kullanıyorum. Diskimde veya dosya sistemimde herhangi bir şifreleme kullanmıyorum. Hiçbir ağ dosya sistemim yok, bu yüzden bir ağ dosya sistemi okumuyor veya yazmıyorum.

Aşağıdaki sonuçlar IO zamanlayıcı 4.20.15-200.fc29.x86_64kullanılarak çekirdekten alınmıştır noop. cfqIO zamanlayıcı da benzer sonuçlar vermektedir.

(Ben de benzer bir yapılandırmaya dayalı, ancak çekirdek sürüm 5.1 ve kullanarak daha yakın olan bir çekirdek yapı üzerinde benzer sonuçlar gördüm mq-deadline. Böylece yeni blk-mqkodu kullanıyordu ).

Test ve sonuçlar

$ sudo perf trace -s \
       perf stat \
       dd if=/dev/urandom of=test.out bs=1M oflag=direct count=3000

3000+0 records in
3000+0 records out
3145728000 bytes (3.1 GB, 2.9 GiB) copied, 31.397 s, 100 MB/s

 Performance counter stats for 'dd if=/dev/urandom of=test.out bs=1M oflag=direct count=3000':

         18,014.26 msec task-clock                #    0.574 CPUs utilized          
             3,199      context-switches          #    0.178 K/sec                  
                 4      cpu-migrations            #    0.000 K/sec                  
               328      page-faults               #    0.018 K/sec                  
    45,232,163,658      cycles                    #    2.511 GHz                    
    74,538,278,379      instructions              #    1.65  insn per cycle         
     4,372,725,344      branches                  #  242.737 M/sec                  
         4,650,429      branch-misses             #    0.11% of all branches        

      31.398466725 seconds time elapsed

       0.006966000 seconds user
      17.910332000 seconds sys

 Summary of events:
...
 dd (4620), 12156 events, 12.0%

   syscall            calls    total       min       avg       max      stddev
                               (msec)    (msec)    (msec)    (msec)        (%)
   --------------- -------- --------- --------- --------- ---------     ------
   read                3007 17624.985     0.002     5.861    12.345      0.21%
   write               3003 13722.837     0.004     4.570   179.928      2.63%
   openat                12     0.371     0.002     0.031     0.267     70.36%
...

iowaitRakamı wasütunundan okudum vmstat. Kolona bakarak testin ne zaman yapıldığını anlayabilirsiniz io( bo= 1K çıkışı engeller).

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 5126892 176512 1486060   0   0  1788  4072  321  414  4  4 83  9  0
 1  0      0 5126632 176520 1485988   0   0     0     7  212  405  0  1 99  0  0
 0  0      0 5126884 176520 1485988   0   0     0     0  130  283  0  0 99  0  0
 0  0      0 5126948 176520 1485908   0   0     0     1  157  325  0  0 99  0  0
 0  0      0 5126412 176520 1486412   0   0   115     0  141  284  0  0 99  0  0
 0  2      0 5115724 176548 1487056   0   0     0  6019 18737 10733  3  6 89  2  0
 1  0      0 5115708 176580 1487104   0   0     3 91840 1276  990  0 13 77  9  0
 1  0      0 5115204 176600 1487128   0   0     2 91382 1382 1014  0 14 81  4  0
 1  0      0 5115268 176636 1487084   0   0     4 88281 1257  901  0 14 83  3  0
 0  1      0 5113504 177028 1487764   0   0    77 92596 1374 1111  0 15 83  2  0
 1  0      0 5114008 177036 1487768   0   0     0 113282 1460 1060  0 16 81  2  0
 1  0      0 5113472 177044 1487792   0   0     0 110821 1489 1118  0 16 74 10  0
 0  0      0 5123852 177068 1487896   0   0     0 20537  631  714  1  3 94  2  0
 0  0      0 5123852 177076 1487856   0   0     0    10  324  529  2  1 98  0  0
 2  0      0 5123852 177084 1487872   0   0     0    70  150  299  0  0 99  0  0

Tutacağı yerlerde test sonuçları (VM içinde)

Aynı testi çekirdeği çalıştıran 5.0.9-301.fc30.x86_64ve mq-deadline(ve dolayısıyla blk-mq) kullanan 1 CPU'lu bir VM'de denedim . Bu testte, beklediğim gibi çalıştı.

$ sudo perf trace -s \
       perf stat \
       dd if=/dev/urandom of=test.out bs=1M oflag=direct count=3000
[sudo] password for alan-sysop:
3000+0 records in
3000+0 records out
3145728000 bytes (3.1 GB, 2.9 GiB) copied, 46.8071 s, 67.2 MB/s

 Performance counter stats for 'dd if=/dev/urandom of=test.out bs=1M oflag=direct count=3000':

         18,734.89 msec task-clock                #    0.400 CPUs utilized
            16,690      context-switches          #    0.891 K/sec
                 0      cpu-migrations            #    0.000 K/sec
               328      page-faults               #    0.018 K/sec
   <not supported>      cycles
   <not supported>      instructions
   <not supported>      branches
   <not supported>      branch-misses

      46.820355993 seconds time elapsed

       0.011840000 seconds user
      18.531449000 seconds sys


 Summary of events:
...
 dd (1492), 12156 events, 38.4%

   syscall            calls    total       min       avg       max      stddev
                               (msec)    (msec)    (msec)    (msec)        (%)
   --------------- -------- --------- --------- --------- ---------     ------
   write               3003 28269.070     0.019     9.414  5764.657     22.39%
   read                3007 18371.469     0.013     6.110    14.848      0.53%
   execve                 6    10.399     0.012     1.733    10.328     99.18%
...

Çıktı vmstat 5:

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----                                                                     
 r  b  swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st                                                                     
 0  0     0 726176  52128 498508    0    0  2040   231  236  731  7  5 77 11  0                                                                     
 0  0     0 726176  52136 498508    0    0     0    10   25   46  0  0 99  1  0                                                                     
 0  0     0 726208  52136 498508    0    0     0     0   29   56  0  0 100  0  0                                                                    
 0  1     0 702280  55944 511780    0    0  2260 13109 4399 9049  3 17 55 25  0                                                                     
 0  1     0 701776  56040 511960    0    0    18 129582 1406 1458 0 73  0 27  0                                                                    
 0  2     0 701524  56156 512168    0    0    22 87060  960  991  0 50  0 50  0                                                                     
 3  1     0 701524  56228 512328    0    0    14 118170 1301 1322 0 68  0 32  0                                                                    
 1  1     0 701272  56260 512392    0    0     6 86426  994  982  0 53  0 46  0                                                                     
 0  2     0 701020  56292 512456    0    0     6 56115  683  660  0 37  0 63  0                                                                     
 3  2     0 700540  56316 512504    0    0     5 33450  446  457  0 26  0 74  0                                                                     
 0  2     0 700860  56332 512536    0    0     3 16998  311  240  0 19  0 81  0                                                                     
 1  2     0 700668  56368 512616    0    0     7 32563  443  428  0 24  0 76  0                                                                     
 1  0     0 700668  56392 512648    0    0     3 20338  245  272  0 12  0 88  0                                                                   
 0  1     0 707096  56408 512920    0    0    54 20913  312  530  0 12 79  8  0                                                                     
 0  0     0 707064  56432 512920    0    0     0    49   39   64  0  0 45 55  0                                                                     
 0  0     0 707064  56432 512920    0    0     0     0   24   46  0  0 100  0  0                                                                    
 0  0     0 707064  56432 512920    0    0     0    80   28   47  0  0 100  0  0

VM'ye bir CPU eklemeyi ve tekrar test etmeyi denedim. Sonuçlar değişkendi: bazen boşta sütunda yaklaşık% 0 gösterdi ve bazen yaklaşık% 50 boşta (yani iki CPU'dan biri) gösterdi. % 0 "boşta" durumunda, "iowait" çok yüksekti, yani birden fazla CPU değerinde. Yani benim beklentim noktası 2 doğru değildi. Begudgingly çoklu CPU sistemlerinde bu iowait "görünür sınırlama kabul edebilir . (Tam olarak anlamıyorum. Birisi tam olarak açıklamak istiyorsa, bu harika olurdu). Bununla birlikte, "boşta" her iki durumda da% 50'nin üzerinde değildi, bu yüzden bu testler hala "iowait" hakkındaki ilk varsayımımla tutarlıydı.

VM'yi kapatmayı ve 4 CPU ile başlatmayı denedim. Benzer şekilde, genellikle tam olarak% 75 boşta kaldım ve bazen% 50 boşta kaldım, ancak% 75'ten fazla boşta görmedim (yani dört CPU'dan üçünden fazla).

4 CPU'lu fiziksel sistemde, yine de yukarıda gösterildiği gibi% 80'den fazla boşta sonuç üretebilirim.

İçerik bildirimi : Bu yayın çeşitli Linux tartışmaları ve kodlarına bağlantılar içerir. Bağlı bazı içerikler StackExchange veya Linux için geçerli Davranış Kurallarına uymuyor . Çoğunlukla "koda hakaret ederler (ama kişiye değil)". Bununla birlikte, sadece tekrarlanmaması gereken bir dil kullanılır. Sizden böyle bir dili taklit etmekten, papağan etmekten veya tartışmaktan kaçınmanızı rica ediyorum.

Re: iowait vs atıl muhasebe "tutarsız" - iowait çok düşük

05/07/2019 12:38, Peter Zijlstra şunu yazdı:

Cuma, 05 Temmuz 2019, 12:25:46 + 0100, Alan Jenkins şunu yazdı:

Cpu "iowait" zamanım yanlış raporlanmış gibi görünüyor. Bunun neden olabileceğini biliyor musunuz?

Çünkü iowait aklı başında anlamı olmayan sihirli bir rastgele sayıdır. Şahsen, ABI hariç her şeyi silmeyi tercih ederim : /

Ayrıca nr_iowait () yakınındaki yoruma bakın

Teşekkürler. [Mevcut belgelerde bahsedilen sorunları] farklı sorunlar olarak görüyorum, ancak sorunumu "düzeltmek" için çok fazla talep (veya nokta) olmadığı anlamına geliyor.

Sorunumu buldum. Beş yıl önce fark edildi ve düzeltilmesi önemsiz olmayacaktı.

"iowait" süresi fonksiyon tarafından güncellenir account_idle_time():

/*
 * Account for idle time.
 * @cputime: the CPU time spent in idle wait
 */
void account_idle_time(u64 cputime)
{
    u64 *cpustat = kcpustat_this_cpu->cpustat;
    struct rq *rq = this_rq();

    if (atomic_read(&rq->nr_iowait) > 0)
        cpustat[CPUTIME_IOWAIT] += cputime;
    else
        cpustat[CPUTIME_IDLE] += cputime;
}

Eğer geleneksel zamanlayıcı kesme ("tick") ile "örnekleme" ile cpu zaman yaklaşık varsa, bu beklediğim gibi çalışır . Ancak, güç tasarrufu için boşta kalma süresi boyunca kene kapatılırsa çalışmayabilir - NO_HZ_IDLE. Performans nedenleriyle kenenin kapatılmasına izin verirseniz başarısız olabilir - NO_HZ_FULL- çünkü bu başlangıç ​​gerektirir VIRT_CPU_ACCOUNTING. Çoğu Linux çekirdeği güç tasarrufu özelliğini kullanır. Bazı gömülü sistemler her iki özelliği de kullanmaz. İşte benim açıklamam:

ES tamamlandığında, cihaz bir kesinti gönderir . Çekirdek kesme işleyici işlemi kullanarak uyanır try_to_wake_up(). Sayaçtan birini çıkarır nr_iowait:

if (p->in_iowait) {
    delayacct_blkio_end(p);
    atomic_dec(&task_rq(p)->nr_iowait);
}

İşlem boş bir CPU'da uyandırılırsa, bu CPU çağırır account_idle_time(). Uygulandığı yapılandırma bağlı olarak, bu birinden denir tick_nohz_account_idle_ticks()gelen __tick_nohz_idle_restart_tick()veya gelen vtime_task_switch()gelen finish_task_switch().

Bu zamana kadar, ->nr_iowaitzaten azaltıldı. Sıfıra düşürülürse, iowait süresi kaydedilmez.

Bu etki değişebilir: işlemin hangi CPU'da uyandığına bağlıdır. İşlem, GÇ tamamlama kesmesini alan CPU'da uyandırılırsa, boşta kalma süresi daha önce hesaplanmadan önce ->nr_iowaitazaltılabilir. Benim durumumda, CPU 0'ın ahci kesmesini ele aldığını gördüm watch cat /proc/interrupts.

Bunu basit bir sıralı okuma ile test ettim:

dd if=largefile iflag=direct bs=1M of=/dev/null

Komutu kullanarak CPU 0'a taskset -c 0 ...sabitlersem iowait için "doğru" değerler görürüm. Farklı bir CPU'ya sabitlersem çok daha düşük değerler görüyorum. Komutu normal olarak çalıştırırsam, çekirdek sürümleri arasında değişen zamanlayıcı davranışına bağlı olarak değişir. Son çekirdeklerde (4.17, 5.1, 5.2-rc5-ish), komut CPU 0'da zamanın yaklaşık 1 / 4'ünü harcıyor gibi görünmektedir, çünkü "iowait" süresi bu kısma indirgenmiştir.

(Açıklanmadı: neden bu testi sanal makinemde çalıştırmak şimdi her bir (veya herhangi) CPU için "doğru" iowait üretiyor gibi görünüyor. IRQ_TIME_ACCOUNTINGBu özellik de VM dışındaki testlerimde kullanılmasına rağmen, bunun olabileceğinden şüpheleniyorum .

Ayrıca, bastırmanın neden NO_HZ_IDLE4.17+ üzerinde her CPU için "doğru" iowait verdiğini tam olarak doğrulamamıştım , ancak 4.16 veya 4.15'te değil.

Bu testi sanal makinemde çalıştırmak, her (veya herhangi bir CPU) için "doğru" iowait üretiyor gibi görünüyor. Bunun nedeni IRQ_TIME_ACCOUNTING. VM dışındaki testlerde de kullanılır, ancak VM içinde test yaparken daha fazla kesinti alırım. Özellikle, "dd" nin çalıştığı sanal CPU'da saniyede 1000'den fazla "İşlev çağrısı kesintisi" vardır.

Bu yüzden benim açıklamamın ayrıntılarına çok fazla güvenmemelisiniz :-)

Burada "iowait" hakkında bir arka plan var: Bir CPU beklemede olan IO olduğunu nasıl biliyor? Bu sorunun cevabı, sezgisel "kümülatif" beklemenin "belirli koşullarda azalabileceğini" düşünüyor. Acaba basit testimin böyle belgelenmemiş bir durumu tetikleyip tetiklemediğini merak ediyorum.

Evet.

Buna ilk baktığımda, "hıçkırık" hakkında bir konuşma buldum. Ayrıca, kümülatif "iowait" süresinin monotonik olmadığı gösterilerek sorun gösterilmiştir. Bu bazen geri atladı (azaldı). Yukarıdaki test kadar basit değildi.

Ancak araştırdıklarında aynı temel sorunu buldular. Peter Zijlstra ve Hidetoshi Seto tarafından bir çözüm önerildi ve prototiplendi. Sorun kapak mesajında ​​açıklanmıştır:

[RFC PATCH 0/8] yeniden işleme iowait muhasebesi (2014-07-07)

Bunun ötesinde bir ilerleme kanıtı bulamadım. Detaylardan birinde açık bir soru vardı. Ayrıca, tüm seri PowerPC, S390 ve IA64 CPU mimarileri için özel koda dokundu. Bu yüzden bunu düzeltmek önemsiz değil diyorum.