Saya memiliki instance MySQL pada dua server khusus. Satu untuk produksi, yang lain untuk platform pengujian.

2 servernya cukup sama, satu-satunya perbedaan adalah pengontrol RAID dan volume virtual (HD sama). Pada produksi, ada pengontrol HW RAID khusus dan volume RAID 10. Di sisi lain, pengontrol RAID tampaknya adalah perangkat lunak (Lenovo ThinkServer RAID 110i) dan volumenya adalah RAID 5.

Kami perhatikan bahwa selama komit MySQL, kami memiliki iowait tinggi:

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

dm-10-8 & dm-14-8 terkait dengan partisi database.

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

Saya mencurigai pengontrol serangan, bagaimana saya bisa yakin?

Jawaban saya memiliki 2 bagian: penyelidikan driver perangkat blok; dan pengoptimalan yang layak dilihat dengan use case Anda. Tapi saya menghapus bagian terakhir karena dilaporkan dapat menyebabkan hilangnya data. Lihat komentar.

Investigasi Perangkat Keras

Saya mengerti bahwa untuk aplikasi yang sama tetapi pada 2 perangkat hardware yang berbeda kinerjanya sangat berbeda dan Anda ingin memahami alasannya. Oleh karena itu saya mengusulkan pertama sarana untuk membantu Anda menemukan jawaban untuk "mengapa"

Untuk kinerja, saya sering merujuk ke Linux Performance Map yang disediakan oleh Brendan Gregg di blog-nya. Orang dapat melihat bahwa untuk level rendah (paling dekat dengan perangkat keras) alat seperti blktraceakan sempurna.

Tidak terlalu mengetahui alat ini, saya mencari-cari dan menemukan artikel menarik tentang blktrace oleh Marc Brooker. Pada dasarnya ini menyarankan yang berikut: melakukan jejak I / O menggunakan blktrace; menggunakan alat btt untuk mengekstrak info dari jejak ini. Itu akan menjadi sesuatu seperti ini (untuk jejak 30 detik):

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

Outputnya bisa sangat panjang, tetapi cari entri D2C. Ini akan memberi Anda gambaran tentang waktu yang dibutuhkan untuk I / O dikirim ke driver perangkat untuk dilaporkan selesai oleh driver ini.

Contoh output ( dnf upgradeberjalan pada VirtualBox VM di laptop sibuk saya):

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

Ini menunjukkan rata-rata mengecewakan 45 ms per I / O hingga 3,94 s untuk kasus terburuk !!

Untuk lebih banyak cara menggunakan blktrace untuk melakukan penyelidikan ini, baca artikel dari Marc Brooker, sangat instruktif.

proses jbd2 adalah untuk penjurnalan ext4. Adalah logis bahwa filesystem perlu menulis ke jurnal selama komitmen mysql, ini seharusnya tidak menjadi alasan untuk kekhawatiran. Jumlah beban yang disebabkan oleh jbd dipengaruhi oleh parameter pemasangan Anda untuk partisi dm-10-8 dan dm-14-8. Mungkin diinginkan untuk memiliki jurnal yang sangat konservatif di partisi database untuk memastikan bahwa database Anda tidak rusak jika sesuatu terjadi dan server Anda secara tidak sengaja reboot. Anda dapat memilih opsi pemasangan penjurnalan lain di lingkungan pengujian hanya untuk perbandingan.