Batasi siram latar belakang Linux (halaman kotor)

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?

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.

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.

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.

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.