Batasi siram latar belakang Linux (halaman kotor)

26

Pembilasan latar belakang pada Linux terjadi ketika terlalu banyak data tertulis yang tertunda (dapat disesuaikan melalui / proc / sys / vm / dirty_background_ratio) atau batas waktu untuk penulisan yang tertunda tercapai (/ proc / sys / vm / dirty_expire_centisecs). Kecuali jika ada batasan lain yang dipukul (/ proc / sys / vm / dirty_ratio), lebih banyak data tertulis dapat di-cache. Penulisan lebih lanjut akan memblokir.

Secara teori, ini harus membuat proses latar belakang menulis halaman kotor tanpa mengganggu proses lain. Dalam praktiknya, hal itu mengganggu proses apa pun yang melakukan pembacaan yang tidak dibatasi atau penulisan yang sinkron. Sangat. Ini karena background flush benar-benar menulis pada kecepatan perangkat 100% dan permintaan perangkat lain pada saat ini akan tertunda (karena semua antrian dan cache-cache di jalan dipenuhi).

Apakah ada cara untuk membatasi jumlah permintaan per detik yang dilakukan oleh proses pembilasan, atau memprioritaskan perangkat I / O lainnya secara efektif?

korkman
sumber
Mungkin ini akan menjadi pertanyaan yang bagus untuk dikirim ke mailing list kernel linux vger.kernel.org/vger-lists.html#linux-kernel
Penjadwal IO apa yang Anda gunakan?
3dinfluence
Mencoba berbagai (cfq, tenggat waktu), tapi saya kira ini hanya bekerja dengan andal ketika tidak ada cache tulis yang didukung baterai. Seperti satu larik disk saya makan 1 GiB data pada kecepatan bus PCIe (RAM) dan kemudian menyentuh dinding kenyataan. Beberapa detik nol I / O untuk semua LUN. Throttling flushes (setidaknya yang latar belakang) ke perkiraan kasar dari kecepatan perangkat yang sebenarnya akan menyelesaikan masalah kemacetan itu.
korkman
1
Baru-baru ini saya menyadari / sys / block / sdX / queue / nr_requests sebagai tunable utama. Mengubahnya ke minimum (= 4 dalam kasus saya) meningkatkan banyak latensi beban bersamaan: Sysbench fsync acak menulis per detik melonjak dari 4 (!) Ke 80-90 saat menulis pada kecepatan bus dengan dd. Kinerja yang tidak dimuat tampaknya tidak terpengaruh. Penjadwal semuanya sama, noop atau tenggat waktu tampaknya optimal. Ini mungkin benar untuk sebagian besar konfigurasi BBWC.
korkman

Jawaban:

20

Setelah banyak melakukan benchmark dengan sysbench, saya sampai pada kesimpulan ini:

Untuk bertahan hidup (kinerja-bijaksana) situasi di mana

  • proses salinan jahat membanjiri halaman kotor
  • dan cache perangkat keras hadir (mungkin juga tanpa itu)
  • dan sinkron membaca atau menulis per detik (IOPS) sangat penting

cukup buang semua elevator, antrian, dan cache halaman kotor. Tempat yang benar untuk halaman kotor adalah dalam RAM cache tulis perangkat keras itu.

Sesuaikan dirty_ratio (atau dirty_bytes baru) serendah mungkin, tetapi perhatikan throughput sekuensial. Dalam kasus khusus saya, 15 MB adalah optimal ( echo 15000000 > dirty_bytes).

Ini lebih merupakan peretasan daripada solusi karena gigabyte RAM sekarang digunakan hanya untuk membaca caching daripada cache kotor. Agar cache kotor dapat bekerja dengan baik dalam situasi ini, flusher latar belakang kernel Linux perlu rata-rata pada kecepatan apa perangkat yang mendasarinya menerima permintaan dan menyesuaikan pembilasan latar belakang yang sesuai. Tidak mudah.


Spesifikasi dan tolok ukur untuk perbandingan:

Diuji sementara ddnol ke disk, sysbench menunjukkan keberhasilan besar , meningkatkan 10 utas menulis fsync pada 16 kB dari 33 hingga 700 IOPS (batas idle: 1500 IOPS) dan satu utas dari 8 hingga 400 IOPS.

Tanpa beban, IOPS tidak terpengaruh (~ 1500) dan throughput sedikit berkurang (dari 251 MB / dtk menjadi 216 MB / dtk).

dd panggilan:

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

untuk sysbench, test_file.0 dipersiapkan untuk tidak digunakan dengan:

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

panggilan sysbench untuk 10 utas:

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

panggilan sysbench untuk satu utas:

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

Ukuran blok yang lebih kecil menunjukkan angka yang lebih drastis.

--file-block-size = 4096 dengan 1 GB 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, 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 dengan 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 dengan 15 MB dirty_bytes pada sistem idle:

sysbench 0.4.12: tolok ukur evaluasi sistem multi-utas

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

Sistem uji:

  • Adaptec 5405Z (itu cache cache 512 MB dengan perlindungan)
  • Intel Xeon L5520
  • 6 GiB RAM @ 1066 MHz
  • Motherboard Supermicro X8DTN (5520 chipset)
  • 12 disk Seagate Barracuda 1 TB
    • 10 dalam perangkat lunak Linux RAID 10
  • Kernel 2.6.32
  • Xfs Sistem File
  • Debian tidak stabil

Singkatnya, saya sekarang yakin konfigurasi ini akan berkinerja baik dalam situasi siaga, beban tinggi, dan bahkan beban penuh untuk lalu lintas basis data yang jika tidak akan kelaparan oleh lalu lintas berurutan. Throughput sekuensial lebih tinggi dari dua tautan gigabit yang dapat ditayangkan, jadi tidak ada masalah untuk mengurangi sedikit.

korkman
sumber
Apa metodologi Anda untuk sampai pada bagian '15MB untuk dirty_buffers sudah optimal'?
Marcin
1
Trial and error. Seperti, ubah separuh jumlah waktu berikutnya, dll., Hingga saya berakhir hanya dengan 15 MB dan OK IOPS. Kernel 3.2 saat ini mungkin berperilaku sangat berbeda, BTW.
korkman
2
Hanya ingin mengucapkan terima kasih karena telah menempatkan saya di jalur yang benar. Punya beberapa masalah serupa dengan node XenServer. Ternyata menjadi cache PHP-FPM / APC yang menyebabkan halaman kotor. Menyesuaikan model memori cache APC memecahkan masalah bagi kami. DiskIO berubah dari pemanfaatan 20% menjadi 0.
jeffatrackaid
Logikanya dirty_bytesharus hampir tidak cukup tinggi untuk tidak menghentikan CPU saat proses sedang menulis jika proses sedang menulis rata - rata dengan throughput perangkat. Jika kode aplikasi Anda melakukan siklus perhitungan besar diikuti dengan menulis data dalam jumlah besar, jika akan sangat sulit untuk dioptimalkan karena rata-rata waktu singkat sangat berbeda dari rata-rata lama. Solusi yang benar adalah dengan menyesuaikan dirty_bytespengaturan proses spesifik tetapi Linux tidak mendukung hal seperti itu sejauh yang saya tahu.
Mikko Rantalainen
3

Meskipun menyetel parameter kernel menghentikan masalah, sebenarnya kemungkinan masalah kinerja Anda adalah akibat bug pada pengontrol Adaptec 5405Z yang diperbaiki dalam pembaruan firmware 1 Februari 2012. Catatan rilis mengatakan "Memperbaiki masalah di mana firmware dapat menggantung selama stres I / O tinggi." Mungkin menyebarkan I / O seperti yang Anda lakukan sudah cukup untuk mencegah bug ini dipicu, tapi itu hanya dugaan.

Berikut adalah catatan rilis: http://download.adaptec.com/pdfs/readme/relnotes_arc_fw-b18937_asm-18837.pdf

Bahkan jika ini bukan kasus untuk situasi khusus Anda, saya pikir ini dapat bermanfaat bagi pengguna yang menemukan posting ini di masa depan. Kami melihat beberapa pesan seperti berikut ini di output dmesg kami yang akhirnya membawa kami ke pembaruan firmware:

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

Berikut adalah nomor model pengontrol RAID Adaptec yang tercantum dalam catatan rilis untuk firmware yang memiliki I / O hang fix yang tinggi: 2045, 2405, 2405Q, 2805, 5085, 5405, 5405Z, 5445, 5445Z, 5805, 5805Q, 5805Z, 5805ZQ, 51245, 51645, 52445.

sa289
sumber
1
Wow, terima kasih atas masukan Anda. Meskipun ini bukan masalah bagi saya, Anda memberi saya alasan lain untuk menghindari HW RAID sama sekali dan beralih ke pengaturan HBA saja. HW RAID masih memiliki keunggulan BBWC, tetapi dengan hal-hal seperti bcache pindah ke kernel, bahkan itu pun menghilang. Sisi con untuk HW RAID adalah jenis bug firmware yang Anda jelaskan. Saya memang memiliki sistem lain dengan pengaturan DRBD dan beban I / O yang tinggi menyebabkan firmware-reset, jadi ini tidak jarang ditemukan (mungkin bug yang persis seperti itu).
korkman
1

Kernel yang termasuk "WBT":

Perbaikan di lapisan blok , LWN.net

Dengan pelambatan penulisan kembali, [lapisan blok] berupaya untuk mendapatkan kinerja maksimum tanpa latensi I / O yang berlebihan menggunakan strategi yang dipinjam dari penjadwal jaringan CoDel. CoDel melacak latensi minimum yang diamati dari paket jaringan dan, jika itu melebihi nilai ambang batas, ia mulai menjatuhkan paket. Dropping menulis disukai di subsistem I / O, tetapi strategi yang sama diikuti di mana kernel memonitor latensi minimum dari kedua membaca dan menulis dan, jika itu melebihi nilai ambang batas, itu mulai mengurangi jumlah penulisan kembali latar belakang itu sedang dilakukan. Perilaku ini ditambahkan pada 4.10; Axboe mengatakan bahwa hasil yang cukup baik telah terlihat.

WBT tidak perlu beralih ke lapisan blok blk-mq baru. Yang mengatakan, itu tidak bekerja dengan penjadwal I / O CFQ atau BFQ. Anda dapat menggunakan WBT dengan batas waktu / mq-deadline / noop / none schedulers. Saya percaya ini juga bekerja dengan penjadwal I / O "kyber" yang baru.

Selain penskalaan ukuran antrian untuk mengontrol latensi, kode WBT membatasi jumlah permintaan penulisan kembali latar belakang sebagai proporsi dari batas antrian yang dihitung.

Konfigurasi runtime dalam /sys/class/block/*/queue/wbt_lat_usec.

Opsi konfigurasi build yang dicari adalah

/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

Pernyataan masalah Anda dikonfirmasi 100% oleh penulis WBT - well done :-).

Blok [PATCHSET]: pelambatan penulisan balik buffered

Sejak awal waktu, penulisan balik buffered latar belakang kami telah menyedot. Ketika kita melakukan penulisan balik buffered latar belakang, seharusnya berdampak kecil pada aktivitas latar depan. Itulah definisi kegiatan latar belakang ... Tapi selama yang bisa saya ingat, para penulis buffered besar tidak berperilaku seperti itu. Misalnya, jika saya melakukan sesuatu seperti ini:

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

pada laptop saya, dan kemudian mencoba dan memulai chrome, itu pada dasarnya tidak akan mulai sebelum penulisan balik buffered dilakukan. Atau, untuk beban kerja yang berorientasi server, di mana pemasangan RPM besar (atau serupa) berdampak buruk pada database yang membaca atau menyinkronkan penulisan. Ketika itu terjadi, saya membuat orang-orang meneriaki saya.

Hasil dari beberapa pengujian terbaru dapat ditemukan di sini:

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

Lihat posting sebelumnya untuk deskripsi yang lebih besar dari patchset.

sourcejedi
sumber
Saya senang melihat masalah ini dikenali dan ditangani di dalam kernel sekarang. Perlu diingat blk-mq cukup baru dan mungkin belum matang .
korkman
@korkman menghela nafas, saya kira saya akan memotong-motong kutipan untuk menghindari implikasi yang salah. Saya setuju ini adalah hal-hal yang ditambahkan dalam beberapa tahun terakhir, mungkin masih ada regresi kinerja atau lebih buruk. AFAIR pengelola menolak perbaikan data korupsi dalam arti bahwa itu kebetulan. Jika Anda menggunakan versi kernel di mana blk-mq dikembangkan, dapat diperdebatkan seberapa banyak menggunakan lapisan blok "legacy" akan menghindari bug. Bug yang ditangguhkan yang saya perbaiki adalah bug yang berasal dari blk-mq, kemudian di refactored atau sesuatu & mempengaruhi keduanya. github.com/torvalds/linux/commit/1dc3039bc87a
sourcejedi
0

Berapa rata-rata untuk Dirty di / proc / meminfo? Ini seharusnya tidak melebihi / proc / sys / vm / dirty_ratio Anda. Pada server file khusus saya telah mengatur dirty_ratio ke persentase memori yang sangat tinggi (90), karena saya tidak akan pernah melampauinya. Dirty_ration Anda terlalu rendah, ketika Anda memukulnya, semuanya hancur, naikkan.

Luke
sumber
Masalahnya bukan proses yang diblokir saat menekan dirty_ratio. Saya baik-baik saja dengan itu. Tetapi proses "latar belakang" penulisan data kotor ke disk mengisi antrian tanpa ampun dan membunuh kinerja IOPS. Ini disebut kelaparan IO kurasa. Bahkan, pengaturan dirty_ratio_bytes sangat rendah (seperti 1 MB) membantu banyak, karena pembilasan akan terjadi segera dan antrian akan tetap kosong. Kelemahan mungkin throughput yang lebih rendah untuk berurutan, tapi tidak apa-apa.
korkman
Anda mematikan semua lift? Apa lagi yang Anda tweak dari sistem vanilla?
Luke
1
Lihat jawabanku. Akhir cerita adalah untuk menghapus caching kotor dan menyerahkan bagian itu ke pengontrol HW. Elevator agak tidak relevan dengan cache tulis HW di tempatnya. Pengontrol memiliki algoritma elevator sendiri sehingga memiliki elevator dalam perangkat lunak hanya menambah biaya tambahan.
korkman
Elevevator dalam perangkat lunak adalah tradeoff: pengorbanan latensi untuk meningkatkan bandwidth. Sebagai contoh, bayangkan 100K menulis operasi dalam antrian perangkat lunak yang dikirimkan secara acak; Jika elevator perangkat lunak dapat memesan op-op tersebut menggunakan buffer yang besar, maka pada akhirnya hanya mengirim 5K permintaan yang jauh lebih besar ke perangkat. Namun, akibatnya, latensi perlu ditingkatkan sebesar 100K ops karena mungkin 2K ops pertama dan 1K ops terakhir sebenarnya saling berdekatan di perangkat. Tanpa tambahan latensi, tidak mungkin untuk menggabungkannya.
Mikko Rantalainen