Solusi 1:
Setelah banyak pembandingan dengan sysbench, saya sampai pada kesimpulan ini:
Untuk bertahan (dari segi kinerja) situasi di mana
- proses penyalinan yang jahat membanjiri halaman kotor
- dan cache tulis perangkat keras ada (mungkin juga tanpa itu)
- dan pembacaan atau penulisan sinkron per detik (IOPS) sangat penting
buang saja semua elevator, antrean, dan cache halaman kotor. Tempat yang tepat untuk halaman kotor adalah di RAM cache tulis perangkat keras tersebut.
Sesuaikan dirty_ratio (atau dirty_bytes baru) serendah mungkin, tetapi awasi throughput berurutan. Dalam kasus khusus saya, 15 MB optimal (echo 15000000 > dirty_bytes ).
Ini lebih merupakan peretasan daripada solusi karena gigabyte RAM sekarang hanya digunakan untuk caching baca, bukan cache kotor. Agar cache yang kotor bekerja dengan baik dalam situasi ini, pembilas latar belakang kernel Linux harus rata-rata pada kecepatan berapa perangkat yang mendasarinya menerima permintaan dan menyesuaikan pembilasan latar belakang yang sesuai. Tidak mudah.
Spesifikasi dan tolok ukur untuk perbandingan:
Diuji saat dd 'ing nol ke disk, sysbench menunjukkan sukses besar , meningkatkan 10 utas penulisan fsync pada 16 kB dari 33 menjadi 700 IOPS (batas tidak aktif:1500 IOPS) dan utas tunggal dari 8 menjadi 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 disiapkan untuk diurai 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 diam:
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 adalah cache tulis 512 MB dengan perlindungan)
- Intel Xeon L5520
- RAM 6 GiB @ 1066 MHz
- Motherboard Supermicro X8DTN (chipset 5520)
- 12 disk Seagate Barracuda 1 TB
- 10 dalam perangkat lunak Linux RAID 10
- Kernel 2.6.32
- Sistem file xfs
- Debian tidak stabil
Singkatnya, saya sekarang yakin konfigurasi ini akan bekerja dengan baik dalam situasi menganggur, beban tinggi, dan bahkan beban penuh untuk lalu lintas database yang sebaliknya akan kelaparan oleh lalu lintas berurutan. Throughput berurutan lebih tinggi daripada yang dapat dihasilkan oleh dua link gigabit, jadi tidak masalah untuk menguranginya sedikit.
Solusi 2:
Meskipun penyetelan parameter kernel menghentikan masalah, sebenarnya masalah kinerja Anda mungkin disebabkan oleh bug pada pengontrol Adaptec 5405Z yang diperbaiki dalam pembaruan firmware 1 Februari 2012. Catatan rilis mengatakan "Memperbaiki masalah di mana firmware dapat hang selama tekanan I/O tinggi." Mungkin menyebarkan I/O seperti yang Anda lakukan sudah cukup untuk mencegah terpicunya bug ini, tetapi itu hanya dugaan.
Berikut catatan rilisnya:http://download.adaptec.com/pdfs/readme/relnotes_arc_fw-b18937_asm-18837.pdf
Bahkan jika ini tidak terjadi pada situasi khusus Anda, saya pikir ini dapat bermanfaat bagi pengguna yang menemukan posting ini di masa mendatang. Kami melihat beberapa pesan seperti berikut di output dmesg kami yang akhirnya mengarahkan 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 Adaptec RAID yang tercantum dalam catatan rilis untuk firmware yang memiliki perbaikan hang I/O tinggi:2045, 2405, 2405Q, 2805, 5085, 5405, 5405Z, 5445, 5445Z, 5805, 5805Q, 5805Z, 5805ZQ, 51245, 51645, 52445.