Linux artalanını sınırlandır (kirli sayfalar)


26

Çok fazla yazılı veri beklemede olduğunda (/ proc / sys / vm / dirty_background_ratio aracılığıyla ayarlanabilir) veya bekleyen yazmalar için zaman aşımına ulaşıldığında (/ proc / sys / vm / dirty_expire_centisecs) Linux'ta arka plan temizleme işlemi gerçekleşir. Başka bir sınıra ulaşılmadıkça (/ proc / sys / vm / dirty_ratio), daha fazla yazılı veri önbelleğe alınabilir. Diğer yazarlar engeller.

Teorik olarak, bu, diğer süreçleri rahatsız etmeden kirli sayfalar yazan bir arka plan süreci oluşturmalıdır. Uygulamada, önbelleğe alınmamış okuma veya eşzamanlı yazma yapan herhangi bir işlemi rahatsız eder. Kötü. Bunun nedeni arkaplan yıkamasının aslında% 100 cihaz hızında yazmasıdır ve şu anda diğer tüm cihaz talepleri ertelenecektir (çünkü yoldaki tüm sıralar ve yazma önbellekleri doldurulur).

Yıkama işleminin gerçekleştirdiği saniye başına istek miktarını sınırlandırmanın veya başka aygıt G / Ç'lerini etkili bir şekilde önceliklendirmenin bir yolu var mı?


Belki bu, linux çekirdeği posta listesine göndermek için iyi bir soru olabilir vger.kernel.org/vger-lists.html#linux-kernel

Hangi GÇ zamanlayıcısı kullanıyorsunuz?
3dinfluence

Çeşitli denedim (CFQ, son tarih), ancak bunlar yalnızca batarya destekli yazma önbelleği bulunmadığında güvenilir bir şekilde çalıştığını düşünüyorum. Bir disk dizisi gibi, PCIe veri yolu hızında (RAM) 1 GiB veri yedim ve ardından gerçeklik duvarına çarptı. Tüm LUN'lar için birkaç saniye sıfır G / Ç. Kısma, (en azından arka plan olanları) gerçek cihaz hızının kabaca bir tahminde bulunur. Bu tıkanıklık sorununu çözer.
korkman

1
Geçenlerde / sys / block / sdX / queue / nr_request'lerin önemli bir ayarlanabilir olduğunu fark ettim. Minimuma düşürmek (benim durumumda = 4) eşzamanlı yük gecikme süresini çok geliştirir: dd ile veri yolu hızında yazarken, Sysbench fsync saniyede 4 (!) 'Den 80-90' a sıçrayan rastgele yazma. Yüklenmemiş performans etkilenmemiş gibi görünüyor. Zamanlayıcıların hepsi aynı, noop veya son tarih en uygun görünüyor. Bu çoğu BBWC konfigürasyonu için geçerli olabilir.
korkman

Yanıtlar:


20

Sysbench ile çok kıyaslama yaptıktan sonra şu sonuca vardım:

Hayatta kalmak için (performans açısından) bir durum

  • kötü bir kopyalama işlemi kirli sayfaları siler
  • ve donanım yazma önbelleği var (muhtemelen bu olmadan da)
  • ve saniyede senkronize okuma veya yazma (IOPS) çok önemlidir

sadece tüm asansörleri, kuyrukları ve kirli sayfa önbelleklerini boşaltın. Kirli sayfalar için doğru yer o donanım yazma önbelleğinin RAM'inde bulunur.

Dirty_ratio'yu (veya yeni dirty_bytes) olabildiğince düşük olarak ayarlayın, ancak sıralı verime dikkat edin. Benim özel durumumda, 15 MB optimum idi ( echo 15000000 > dirty_bytes).

Bu, bir çözümden çok bir hack, çünkü RAM gigabaytları artık yalnızca kirli önbellek yerine okuma önbelleği için kullanılıyor. Kirli önbelleğin bu durumda iyi çalışması için, Linux çekirdeği arka plan temizleyicisinin, temel alınan aygıtın istekleri kabul ettiği hızda ortalama alması ve arka plandaki temizlemeyi buna göre ayarlaması gerekir. Kolay değil.


Karşılaştırma için özellikler ve kriterler:

ddDiske sıfırlar yapılırken test edilen sysbench , fsync yazarken 10 iş parçacığını 16 kB'de 33 ila 700 IOPS (boşta sınırı: 1500 IOPS) ve tek iş parçacığı 8 ila 400 IOPS arasında arttırırken büyük başarı gösterdi .

Yük olmadan, IOPS etkilenmedi (~ 1500) ve verim biraz azaltıldı (251 MB / s'den 216 MB / s'ye).

dd aramak:

dd if=/dev/zero of=dumpfile bs=1024 count=20485672

sysbench için, test_dosyası.0 aşağıdakilerle birlikte görülmemiş şekilde hazırlanmıştır:

dd if=/dev/zero of=test_file.0 bs=1024 count=10485672

10 konu için sysbench çağrısı:

sysbench --test=fileio --file-num=1 --num-threads=10 --file-total-size=10G --file-fsync-all=on --file-test-mode=rndwr --max-time=30 --file-block-size=16384 --max-requests=0 run

Bir iş parçacığı için sysbench çağrısı:

sysbench --test=fileio --file-num=1 --num-threads=1 --file-total-size=10G --file-fsync-all=on --file-test-mode=rndwr --max-time=30 --file-block-size=16384 --max-requests=0 run

Küçük blok boyutları daha sert rakamlar gösterdi.

--file-block-size = 4096, 1 ​​GB dirty_bytes ile:

sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.

Operations performed:  0 Read, 30 Write, 30 Other = 60 Total
Read 0b  Written 120Kb  Total transferred 120Kb  (3.939Kb/sec)
      0.98 Requests/sec executed

Test execution summary:
      total time:                          30.4642s
      total number of events:              30
      total time taken by event execution: 30.4639
      per-request statistics:
           min:                                 94.36ms
           avg:                               1015.46ms
           max:                               1591.95ms
           approx.  95 percentile:            1591.30ms

Threads fairness:
      events (avg/stddev):           30.0000/0.00
      execution time (avg/stddev):   30.4639/0.00

--file-block-size = 4096 ile 15 MB dirty_bytes:

sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.

Operations performed:  0 Read, 13524 Write, 13524 Other = 27048 Total
Read 0b  Written 52.828Mb  Total transferred 52.828Mb  (1.7608Mb/sec)
    450.75 Requests/sec executed

Test execution summary:
      total time:                          30.0032s
      total number of events:              13524
      total time taken by event execution: 29.9921
      per-request statistics:
           min:                                  0.10ms
           avg:                                  2.22ms
           max:                                145.75ms
           approx.  95 percentile:              12.35ms

Threads fairness:
      events (avg/stddev):           13524.0000/0.00
      execution time (avg/stddev):   29.9921/0.00

--file-block-size = 4096 boşta sistemde 15 MB dirty_bayt ile:

sysbench 0.4.12: çok iş parçacıklı sistem değerlendirme testi

Running the test with following options:
Number of threads: 1

Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.

Operations performed:  0 Read, 43801 Write, 43801 Other = 87602 Total
Read 0b  Written 171.1Mb  Total transferred 171.1Mb  (5.7032Mb/sec)
 1460.02 Requests/sec executed

Test execution summary:
      total time:                          30.0004s
      total number of events:              43801
      total time taken by event execution: 29.9662
      per-request statistics:
           min:                                  0.10ms
           avg:                                  0.68ms
           max:                                275.50ms
           approx.  95 percentile:               3.28ms

Threads fairness:
      events (avg/stddev):           43801.0000/0.00
      execution time (avg/stddev):   29.9662/0.00

Deneme sistemi:

  • Adaptec 5405Z (korumalı 512 MB yazma önbelleği)
  • Intel Xeon L5520
  • 1066 MHz'de 6 GiB RAM
  • Anakart Supermicro X8DTN (5520 yongaseti)
  • 12 Seagate Barracuda 1 TB diskleri
    • 10 Linux yazılımında RAID 10
  • Çekirdek 2.6.32
  • Dosya sistemi xfs
  • Debian kararsız

Özetle, artık bu konfigürasyonun, sıralı trafikten dolayı aç bırakılacak olan veritabanı trafiği için boşta, yüksek yükte ve hatta tam yük durumlarında iyi performans göstereceğinden eminim. Sıralı verim yine de iki gigabit bağlantısının verebileceğinden daha yüksektir, bu yüzden onu biraz azaltmakta sorun yoktur.


'Kirli_büfeler için 15 MB'lık en iyi yöntem' kısmına ulaşmak için metodolojiniz nedir?
Marcin

1
Deneme ve hata. Gibi, sadece 15 MB ve Tamam IOPS ile sona erene kadar, bir dahaki sefere, miktarın yarısını değiştirin. Akım çekirdeği 3.2 çok farklı olabilir, BTW.
korkman

2
Beni doğru yola koyduğun için teşekkür etmek istedim. Bir XenServer düğümü ile benzer sorunları vardı. Kirli sayfalara neden olan PHP-FPM / APC önbelleği olduğu ortaya çıktı. APC önbellek bellek modelini ayarlamak bizim için sorunu çözdü. DiskIO% 20 kullanımından 0'a
yükseldi

Mantıken dirty_bytessüreçler süreç yazıyor eğer yazarken değil durak CPU'lar için ancak yeterince yüksek olmalıdır ortalama cihazın verimlilik ile. Eğer uygulama kodunuz muazzam hesaplama çevrimleri yapıyor ve ardından çok miktarda veri yazıyorsa, kısa zaman ortalamaları uzun zaman ortalamalarından çok farklı olduğu için optimize etmek çok zor olacaktır. Doğru çözüm sürece özel dirty_bytesayarları yapmak olacaktır ancak Linux bildiğim kadarıyla böyle bir şeyi desteklememektedir.
Mikko Rantalainen

3

Çekirdek parametrelerinin ayarlanması sorunu durdursa da, aslında performans sorunlarınız 1 Şubat 2012'deki üretici yazılımı güncellemesinde düzeltilen Adaptec 5405Z denetleyicisindeki bir hatadan kaynaklanıyor olabilir. Sürüm notları "Ürün yazılımının yüksek G / Ç stresi sırasında askıda kalmasına neden olan bir sorun düzeltildi." Belki de yaptığınız gibi G / Ç'yi yaymak, bu hatanın tetiklenmesini engellemek için yeterliydi, ama bu sadece bir tahmin.

İşte sürüm notları: http://download.adaptec.com/pdfs/readme/relnotes_arc_fw-b18937_asm-18837.pdf

Bu sizin durumunuz için geçerli olmasa bile, bunun gelecekte bu gönderiyle karşılaşan kullanıcılara fayda sağlayabileceğini düşündüm. Sonunda bizi ürün yazılımı güncellemesine götüren dmesg çıktımızda aşağıdaki gibi bazı mesajlar gördük:

aacraid: Host adapter abort request (0,0,0,0)
[above was repeated many times]
AAC: Host adapter BLINK LED 0x62
AAC0: adapter kernel panic'd 62.
sd 0:0:0:0: timing out command, waited 360s
sd 0:0:0:0: Unhandled error code
sd 0:0:0:0: SCSI error: return code = 0x06000000
Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK
sd 0:0:0:0: timing out command, waited 360s
sd 0:0:0:0: Unhandled error code
sd 0:0:0:0: SCSI error: return code = 0x06000028
Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK
sd 0:0:0:0: timing out command, waited 360s
sd 0:0:0:0: Unhandled error code
sd 0:0:0:0: SCSI error: return code = 0x06000028

Aşağıda, yüksek G / Ç bağlantı sabitlemesi olan ürün yazılımı sürüm notlarında listelenen Adaptec RAID denetleyicilerinin model numaraları verilmiştir: 2045, 2405, 2405Q, 2805, 5085, 5405, 5405Z, 5445, 5445Z, 5805, 5805Q, 5805Z, 5805ZQ, 51245, 51645, 52445.


1
Vay, girişin için teşekkürler. Benim için durum böyle olmasa da, HW RAID'i tamamen önlemek ve HBA kurulumlarına devam etmek için bana başka bir neden daha veriyorsun. HW RAID hala BBWC avantajına sahip, ancak çekirdeğe hareket eden bcache gibi şeyler bile yok oluyor. HW RAID'in aleyhtarı tam olarak tanımladığınız donanım yazılımı hatalarının türüdür. DRBD kurulumlu ve yüksek G / Ç yüklü bellenim sıfırlamalarına neden olan başka bir sisteme sahiptim, bu nedenle rastlamak nadir değil (tam olarak bu hata olmuş olabilir).
korkman

1

"WBT" içeren bir çekirdek:

Blok katmanındaki iyileştirmeler , LWN.net

Geri yazma kısma ile [blok katmanı], CoDel ağ programlayıcısından ödünç alınan bir strateji kullanarak aşırı G / Ç gecikmesi olmadan maksimum performans elde etmeye çalışır. CoDel, gözlenen minimum ağ paket gecikme gecikmesini izler ve eğer bu bir eşik değerini aşarsa paketleri atmaya başlar. Bırakma yazıları G / Ç alt sisteminde kaşlarını çattı, ancak benzer bir stratejinin ardından çekirdeğin hem okuma hem de yazma işlemlerinin minimum gecikmesini izlemesi ve bu bir eşik değerini aşması durumunda, arka plan geri yazma miktarını azaltmaya başlamasıyla benzer bir strateji izleniyor. Bu yapılıyor. Bu davranış 4.10'da eklendi; Axboe oldukça iyi sonuçlar alındığını söyledi.

WBT, yeni blk-mq blok katmanına geçmeyi gerektirmez. Bu, CFQ veya BFQ I / O zamanlayıcıları ile çalışmadığını söyledi. WBT'yi son tarih / mq-son tarih / noop / hiç zamanlayıcı ile birlikte kullanabilirsiniz. Aynı zamanda yeni "kyber" I / O zamanlayıcı ile de çalıştığına inanıyorum.

Gecikmeyi kontrol etmek için kuyruk boyutunu ölçeklemenin yanı sıra, WBT kodu , hesaplanan kuyruk sınırının bir oranı olarak arka plan geri dönüş isteklerinin sayısını sınırlar.

Çalışma zamanı yapılandırması içinde /sys/class/block/*/queue/wbt_lat_usec.

Aranacak yapı yapılandırma seçenekleri

/boot/config-4.20.8-200.fc29.x86_64:CONFIG_BLK_WBT=y
/boot/config-4.20.8-200.fc29.x86_64:# CONFIG_BLK_WBT_SQ is not set
/boot/config-4.20.8-200.fc29.x86_64:CONFIG_BLK_WBT_MQ=y

Sorun beyanınız WBT'nin yazarı tarafından% 100 doğrulanmıştır - aferin :-).

[PATCHSET] blok: tamponlanmış geri yazma kısıtlaması

Zamanın başlangıcından beri, arka plan tamponlu geri yazma işlemimiz berbat oldu. Arka plan tamponlu geri yazma yaptığımızda, ön plan etkinliği üzerinde çok az etkisi olması gerekir. Arka plan aktivitesinin tanımı budur ... Fakat hatırlayabildiğim kadarıyla, ağır tamponlanmış yazarlar böyle davranmadı. Örneğin, böyle bir şey yaparsam:

$ dd if=/dev/zero of=foo bs=1M count=10k

dizüstü bilgisayarımda ve ardından kromu başlatmaya çalışın; arabellek yazması yapılmadan önce temelde başlamaz. Veya büyük bir RPM (veya benzeri) kurulumunun veritabanı okumalarını veya senkronizasyonunu olumsuz yönde etkilediği sunucu odaklı iş yükleri için. Bu olduğunda insanların bana bağırmasını sağlarım.

Bazı yeni testlerin sonuçları burada bulunabilir:

https://www.facebook.com/axboe/posts/10154074651342933

Yama setinin daha büyük açıklaması için önceki kayıtlara bakın.


Sorunun artık çekirdeğin içinde tanındığını ve ele alındığını görmekten mutluyum. Aklınızda bulundurun blk-mq oldukça yeni ve henüz o kadar olgun değil .
korkman

korkman iç çekiş, sanırım yanlış imalardan kaçınmak için teklifi değiştireceğim. Bunun son birkaç yılda eklenen şeyler olduğuna katılıyorum, yine de performans gerilemeleri olabilir veya daha kötüsü olabilir. AFAIR, bakım görevlisi, veri bozulma ihtimalini bir şans eseri olarak reddeder. Eğer blk-mq'nin geliştirildiği çekirdek sürümlerini kullanıyorsanız, "eski" blok katmanının kullanılmasının hatalardan kaçınacağı tartışılabilir. Düzeltdiğim askıya alma hatası blk-mq kaynaklı bir hataydı, sonra yeniden düzenlendi ya da bir şey oldu ve her ikisini de etkiledi. github.com/torvalds/linux/commit/1dc3039bc87a
sourcejedi

0

/ Proc / meminfo içindeki Kirli ortalaması nedir? Bu normalde / proc / sys / vm / dirty_ratio'nuzu geçmemelidir. Tahsis edilmiş bir dosya sunucusunda dirty_ratio çok yüksek bir hafıza yüzdesine (90) ayarlı olarak ayarlıyorum, çünkü onu asla aşmayacağım. Kirli kuruşun çok düşük, vurduğun zaman her şey yolunda gider, yükseltir.


Sorun dirty_ratio'ya çarptığında engellenen süreçler değildir. Ben bununla iyiyim. Ancak, disklere kirli veri yazan "arkaplan" süreci, merhamet olmadan sıraları doldurur ve IOPS performansını düşürür. Buna sanırım IO açlığı denir. Aslında, dirty_ratio_bytes değerinin çok düşük olması (1 MB gibi) çok yardımcı olur, çünkü temizleme işlemi hemen gerçekleşecek ve sıralar boş kalacaktır. Dezavantajı sıralı için muhtemelen düşük verim, ama sorun değil.
korkman

Tüm asansörleri kapattın mı? Vanilya sisteminden başka ne ayarladın?
Luke,

1
Benim kendi cevabımı gör. Hikayenin sonu kirli önbelleklemeyi kaldırmak ve bu bölümü HW denetleyicisine bırakmaktı. Asansörler, mevcut HW yazma önbelleği ile bir ilgisi yoktur. Kontrolörün kendi asansör algoritmaları vardır, bu nedenle yazılımdaki herhangi bir asansöre sahip olmak yalnızca ek yükü ekler.
korkman

Yazılımdaki Elevevator bir değişimdir: bant genişliğini iyileştirmek için gecikmeyi feda edin. Örneğin, rastgele sırayla gönderilen yazılım kuyruğunda 100K yazma ops; Yazılım asansörü bu işlemleri büyük bir tampon kullanarak sipariş edebiliyorsa, cihaza sadece 5K daha büyük talepler gönderebilir. Bununla birlikte, gecikme süresinin 100 K op artması gerekir çünkü ilk 2 K op ve son 1 K op aslında gerçekte cihazda birbirine yakın olabilir. Ek gecikme olmadan, bunları birleştirmek mümkün olmayacaktır.
Mikko Rantalainen
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.