Diagram pencucian halaman InnoDB

Database


Bab 6

Siapa yang berani memetakan sistem dan proses serumit mencuci layar InnoDB? saya akan lakukan.

Ini adalah posting blog ketujuh hingga kesebelas: satu untuk kata pengantar dan sepuluh untuk setiap bab buku saya Kinerja MySQL yang efisien. Daftar lengkap tag / kinerja-mysql-efisien.

Pembilasan Halaman InnoDB

Bagan itu untuk Bab 6 Kinerja MySQL yang efisien, Yang merupakan penyelaman mendalam ke tolok ukur server MySQL yang paling berguna. Ada bagian panjang dari kriteria InnoDB yang lebih berfokus pada jalur penulisan: dari komitmen transaksi hingga buffer pool dan sebagian besar (tetapi tidak semua) bagiannya. Saya mendorong Anda untuk membaca seluruh bab karena posting blog informal yang pendek seperti ini tidak dapat mendekati kedalaman dan kejelasan buku. Sebagai gantinya, saya ingin berbicara cepat tentang tips InnoDB yang perlu diketahui oleh DBAa baru.

Hindari, optimalkan, dan tunda

InnoDB Bertindak seperti Sebuah cache dalam memori (dan pada saat yang sama tahan lama) karena semua membaca dan menulis logis dilakukan dalam repositori buffer, yang ada di memori. Secara umum, saya pikir akan berguna untuk melihat InnoDB sebagai cache di memori alih-alih mesin penyimpanan di atas disk yang lambat. Ini membantu mencegah stabilisasi akses disk yang lambat. MySQL dan InnoDB (dan mungkin database apa pun yang pernah dibuat) sudah tahu bahwa akses disk lambat. Sebagian besar dari Alasan eksistensial InnoDB melakukan pekerjaan yang baik untuk mencegah, mengoptimalkan, dan menunda akses disk. InnoDB sangat baik dalam ketiga teknik ini sehingga ia bekerja seperti cache dengan keajaiban di balik layar dalam operasi reguler untuk mendukung data, mendukung transaksi, dan banyak lagi. Seperti kata pepatah, “Cara tercepat untuk melakukan sesuatu adalah tidak melakukannya.”

“Dalam memori” identik dengan “di buffer pool”. MySQL dan InnoDB memiliki struktur data dalam memori lain, tetapi “dalam memori” dalam istilah MySQL berarti “dalam repositori buffer”.

Bacaan

Performa membaca jarang bermasalah Di tingkat penyimpanan Karena, sekali lagi, InnoDB bertindak seperti cache di memori, dan sangat bagus dalam menyimpan alur kerja di memori. Tapi kenapa mereka lambat SELECT Pertanyaan yang sangat umum? Tidak ada jawaban tunggal (Anda harus melakukan analisis kueri untuk menentukan alasannya), tetapi pembacaan fisik (dari disk) adalah salah satu masalah terakhir yang saya curigai. Untuk masalah itu, Anda perlu:

  • Ukuran alur kerja jauh lebih besar daripada RAM fisik Dan
  • Kueri yang memiliki akses hampir eksklusif ke data baru Dan
  • Daya pengoperasian sangat tinggi sehingga InnoDB harus terus-menerus menghapus data lama untuk memuat data baru

Saya belum pernah melihat volume pekerjaan dengan ketiga kondisi tersebut dan saya tidak bisa membayangkannya. Tetapi jika ada beban kerja seperti itu, solusinya akan sederhana: jangan gunakan MySQL. Gunakan penyimpanan data lain yang lebih cocok untuk jenis beban kerja tersebut.

Intinya adalah, Anda dapat membayangkan bahwa InnoDB hampir selalu melakukan pembacaan logis: dari memori, bukan dari disk. Oleh karena itu, seseorang SELECT Mungkin tidak lambat karena pembacaan fisik atau logis karena, masing-masing, data mungkin sudah ada di memori (alur kerja) dan membaca dari memori sangat cepat. Masalah yang lebih umum adalah akses yang berlebihan ke baris dan perbedaan sumber daya server.

sedang menulis

Jangan salahkan MySQL atau InnoDB untuk kinerja penulisan mereka. InnoDB adalah satu-satunya alasan Anda mendapatkan kinerja penulisan yang dapat diterima sejak awal karena perangkat keras standar dan sistem operasi untuk database tidak diatur dengan baik. Sebaliknya, keduanya harus bekerja dengan relatif baik untuk segala hal, yang berarti bahwa keduanya tidak disesuaikan dengan baik untuk apa pun – keduanya umumnya cepat dan efisien. Dan bahkan jika mereka dikonfigurasi untuk database, mereka harus dikonfigurasi untuk versi MySQL tertentu, perangkat keras tertentu, dan beban kerja khusus aplikasi, karena ketiganya berubah dan digabungkan untuk menciptakan persyaratan kinerja yang berbeda.

Sayangnya, kinerjanya sulit, itulah sebabnya berguna untuk memahami bahwa InnoDB adalah karena Anda mendapatkan kinerja menulis sama sekali. Bagan di atas hanyalah tampilan tingkat tinggi dari pencucian halaman InnoDB. InnoDB melakukan lebih banyak. Misalnya, kami dapat memperbesar laporan transaksi (atau “laporan ulang”) di bagian atas halaman untuk melihat bagaimana kecepatannya seimbang (secara bersamaan). COMMIT) Dan daya tahan (jenuhkan perubahan pada data yang dikomit pada disk). Perhatikan bahwa secara bersamaan COMMIT Ini berbeda dari penulisan bersamaan: yang terakhir lebih mudah (dan lebih tentang memisahkan transaksi dan mengunci baris) karena penulisan logis dalam memori. Perubahan data dibuat permanen di daftar ulang di komit.

Performa penulisan mungkin tampak seperti masalah tingkat yang sangat rendah dan relatif sederhana: seberapa cepat InnoDB dapat menulis secara fisik ke disk, dan fsync? Tapi pertanyaan ini biasanya salah karena Avoid, Optimize dan Delay. Kinerja basis data adalah yang pertama dan terpenting EfisiensiLakukan hal yang sama (atau lebih) dengan lebih sedikit. Misalnya, mobil Anda memiliki kecepatan tertinggi 260 km/jam. Apakah Anda mengemudi dengan kecepatan 260 km/jam untuk berangkat kerja? Anda bisa, tetapi Anda mungkin tidak seharusnya melakukannya. Demikian juga, misalkan hard drive Anda mendukung 20k IOPS. Apakah Anda menulis dengan 20k IOPS? Anda bisa, tetapi Anda mungkin tidak seharusnya melakukannya.

Pencucian halaman adalah bagian yang dapat diperbaiki dari InnoDB yang membuat penulisan menjadi efisien. Itu sebabnya saya menghabiskan begitu banyak waktu di Bab 6 Kinerja MySQL yang efisien Untuk menjelaskannya, alih-alih memperbaiki akses disk tingkat rendah – yang tetap tidak dapat Anda ubah kecuali Anda mengubah sistem penyimpanan atau perangkat – pelajari cara kerja pembilasan halaman InnoDB. Spoiler: Algoritme pembilasan adaptif bersifat dinamis, jadi Anda tidak dapat begitu saja meningkatkan variabel sistem MySQL untuk secara ajaib memengaruhi lebih banyak kinerja penulisan – sekali lagi: penghindaran, pengoptimalan, dan latensi.

Halaman kotor

Penting untuk diingat bahwa database pada disk mungkin ada Bukan Saat ini. (Di mana “flow” berarti “memiliki semua nilai terbaru”.) Ini agak aneh karena kita cenderung menggunakan database sebagai partikel untuk objek langsung Ini adalah sumber kebenaran, tetapi pertanyaan sebenarnya adalah, “Pada titik waktu apa?” Akhirnya data dapat dialirkan (atau dikonversi), tetapi untuk pengulangan: penghindaran, pengoptimalan, dan penundaan.

Faktanya, buffer repository penuh dengan halaman kotor (yang memiliki nilai saat ini), dan ini tidak menjadi masalah karena perubahan data yang membuat halaman tersebut kotor konsisten dalam pelaporan transaksi. Jadi “sumber” kebenaran adalah benar-benar database ditambah laporan transaksi – ketika yang terakhir berlaku untuk yang pertama.

Ukuran laporan transaksi tetap, jadi InnoDB mencuci halaman kotor untuk memberi ruang dalam laporan transaksi untuk perubahan data baru, bukan karena halaman kotor “buruk” atau menampilkan data yang tidak konsisten. Jika laporan transaksi tidak berukuran tetap, dapat menunda pembilasan untuk waktu yang sangat lama. Algoritme pembilasan adaptif mencoba melakukan ini: ia hanya berkedip saat dibutuhkan dan hanya saat dibutuhkan – inilah yang membuatnya “adaptif”.

Kerugian utama dari halaman kotor adalah mereka memperlambat startup atau shutdown MySQL, tergantung pada bagaimana MySQL dikonfigurasi. Shutdown cepat menyebabkan startup lambat. Shutdown lambat menyebabkan startup cepat.

IOPS

Pembatasan input / output yang dapat disesuaikan mempengaruhi daftar flash, bukan LRU yang mencuci atau membaca data dari disk. Ini adalah poin penting yang sering tidak Anda baca. Ini berarti bahwa InnoDB dapat dan memang menggunakan ribuan IOPS saat startup, misalnya, saat data pertama kali dimuat. Atau ketika kueri yang buruk secara tidak sengaja memilih hampir semua baris, jadi InnoDB harus melakukan pembacaan fisik untuk memuat baris ke dalam memori.

Tapi jangan khawatir: Seperti yang disebutkan sebelumnya, InnoDB sangat bagus dalam menyimpan portofolio di memori. Akibatnya, server biasa menggunakan lebih banyak IOPS untuk pembilasan halaman – khususnya, daftar flash untuk mengosongkan ruang dalam pelaporan transaksi. Bersama-sama, ini adalah bagaimana dan mengapa MySQL dapat mempertahankan throughput tinggi (QPS) dengan IOPS yang sangat sedikit: membaca dari memori (lembar kerja) dan menulis dengan sangat optimal (layar penuh).

Log biner

Tidak ditunjukkan pada grafik di atas: Penulisan / pemulusan dalam log biner. Komit bersifat bifasik (2PC): mulai, tulis / asam binlog, komit. Ini diperlukan untuk membantu memastikan bahwa pendaftaran ulang dan biner sinkron. Tentu saja, kerusakan selama 2PC dimungkinkan, dan pemulihan kerusakan InnoDB mengelolanya. Karena itu, Anda harus ingat untuk mengaktifkan laporan biner selama pengujian, dengan asumsi bahwa semua node biasanya mengaktifkan perekaman biner dalam produksi. Perhatikan bahwa log biner dikelola oleh MySQL, bukan InnoDB.



Source link

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan.