Memperkenalkan metode untuk mengoptimalkan MYSQL dari beberapa aspek untuk mendapatkan kinerja. Pengoptimalan adalah tugas yang kompleks karena pada akhirnya memerlukan pemahaman tentang keseluruhan sistem. Meskipun beberapa pengoptimalan lokal dapat dilakukan dengan sedikit pengetahuan tentang sistem/aplikasi Anda, semakin Anda ingin membuat sistem Anda lebih optimal, Anda harus mengetahuinya. juga lebih lanjut. Oleh karena itu, bab ini akan mencoba menjelaskan dan memberikan beberapa contoh berbagai cara untuk mengoptimalkan MySQL. Namun perlu diingat bahwa selalu ada cara tertentu (yang semakin sulit) yang harus dilakukan agar sistem dapat lebih cepat bagian terpenting untuk membuat sistem Anda lebih cepat tentu saja adalah desain dasarnya. Anda juga perlu mengetahui bahwa sistem Anda akan melakukan hal-hal seperti ini, dan itulah hambatan yang paling umum adalah:
Pencarian disk. Waktu yang dibutuhkan disk untuk menemukan sepotong data. Waktu rata-rata untuk disk modern yang digunakan pada tahun 1999 biasanya kurang dari 10 ms, jadi secara teori kita dapat mencari sekitar 1000 kali per detik disk dan sulit untuk diukur. Optimasi satu tabel. Cara untuk mengoptimalkannya adalah dengan menyebarkan data ke beberapa disk. Disk membaca/menulis ketika disk berada di lokasi yang tepat di mana kita perlu membaca data. satu transfer disk seperti 10-20Mb/s. Ini harus diupayakan lebih mudah untuk dioptimalkan karena Anda dapat membaca dari beberapa disk dalam siklus CPU paralel. Saat kita membaca data ke dalam memori, (atau jika sudah ada) kita perlu memprosesnya untuk mencapainya hasil kami. Ketika Ini adalah faktor pembatas yang paling umum ketika kita memiliki tabel dengan memori yang relatif kecil, namun dengan kecepatan tabel yang kecil biasanya tidak menjadi masalah. Bandwidth memori menjadi hambatan dalam memori ketika CPU membutuhkan lebih banyak data daripada yang dapat ditampung dalam cache CPU. Ini adalah hambatan yang jarang terjadi pada sebagian besar sistem tetapi Anda harus mewaspadainya. 10.2 Penyetelan Sistem/Waktu Kompilasi dan Parameter Boot Kita mulai dengan hal-hal di tingkat sistem, karena beberapa keputusan ini dibuat sangat awal. Di lain waktu, sekilas bagian ini mungkin cukup karena tidak penting untuk keuntungan besar, tapi selalu baik untuk merasakan seberapa besar keuntungan pada level ini. OS default yang digunakan memang penting! beberapa CPU sampai batas tertentu, Anda harus menggunakan Solaris (karena thread bekerja dengan sangat baik) atau Linux (karena inti 2.2 memiliki dukungan SMP yang sangat baik). Dan pada mesin 32-bit, Linux memiliki batas ukuran file 2G secara default. Mudah-mudahan masalah ini akan segera diperbaiki ketika sistem file baru (XFS) dirilis. Karena kami tidak menjalankan MySQL produksi di banyak platform, kami menyarankan Anda untuk menguji platform yang ingin Anda jalankan sebelum mungkin memilihnya.
Saran lainnya:
Jika Anda memiliki cukup RAM, Anda dapat menghapus semua perangkat swap. Beberapa sistem operasi akan menggunakan perangkat SWAP dalam beberapa kasus meskipun Anda memiliki memori kosong. Gunakan opsi --skip -locking MySQL untuk menghindari penguncian eksternal Fungsionalitas MySQL selama hanya berjalan di satu server. Ingatlah untuk menghentikan server (atau mengunci bagian yang relevan) sebelum Anda menjalankan myisamchk. Pada beberapa sistem, peralihan ini wajib karena penguncian eksternal tidak tersedia pada semua pekerjaan . Saat mengkompilasi dengan MIT-pthreads, opsi --skip-locking defaultnya adalah on (on) karena kawanan() tidak sepenuhnya didukung oleh MIT-pthreads di semua platform klien) pada data yang sama, Anda tidak dapat menggunakan --skip-locking, jika tidak, jalankan myisamchk di atas meja tanpa terlebih dahulu membilas atau mengunci server mysqld. Anda masih dapat menggunakan LOCK TABLES/UNLOCK TABLES, bahkan jika Anda menggunakan --skip -mengunci.
Bagaimana kompilasi dan penautan mempengaruhi kecepatan MySQL
Sebagian besar pengujian berikut dilakukan di Linux dan menggunakan benchmark MySQL, namun pengujian tersebut seharusnya memberikan beberapa indikasi untuk sistem operasi dan beban kerja lain. Anda mendapatkan executable tercepat saat Anda menautkan dengan -static. Menggunakan soket Unix Menghubungkan ke database, bukan TCP /IP juga dapat memberikan kinerja yang lebih baik. Di Linux, Anda akan mendapatkan kode tercepat saat mengkompilasi dengan pgcc dan -O6. Untuk mengkompilasi "sql_yacc.cc" dengan opsi ini, Anda memerlukan memori sekitar 200 juta, karena gcc/pgcc memerlukan banyak memori. memori untuk membuat semua fungsi menjadi inline. Saat mengonfigurasi MySQL, Anda juga harus mengatur CXX=gcc untuk menghindari penyertaan pustaka libstdc++ (tidak diperlukan). Hanya dengan menggunakan kompiler yang lebih baik atau opsi kompiler yang lebih baik, Anda bisa mendapatkan 10 -30% percepatan dalam aplikasi Anda. Ini sangat penting jika Anda mengkompilasi server SQL sendiri! Di Intel, misalnya Anda harus menggunakan pgcc atau kompiler Cygnus CodeFusion. Dapatkan kecepatan maksimum cukup bebas kesalahan untuk mengoptimalkan kompilasi MySQL.
Berikut beberapa lembar pengukuran yang telah kami buat:
Jika Anda menggunakan pgcc dengan -O6 dan mengkompilasi apa pun, server mysqld 11% lebih cepat dibandingkan dengan gcc (dengan versi string 99). Jika Anda menautkan secara dinamis (tanpa -statis), hasilnya 13% lebih lambat masih Dapat menggunakan perpustakaan MySQL yang tertaut secara dinamis. Hanya server yang penting untuk kinerja. Jika Anda menggunakan TCP/IP dan bukan soket Unix, hasilnya 7,5% lebih lambat 4.2 13% lebih cepat. Pada Solaris 2.5.1, MIT-pthreads 8-12% lebih lambat dibandingkan Solaris dengan thread asli pada satu prosesor. Distribusi Linux dikompilasi dengan pgcc dan terhubung secara statis.
Seperti disebutkan sebelumnya, pencarian disk adalah hambatan kinerja yang besar, masalah ini menjadi semakin jelas ketika data mulai bertambah sehingga caching menjadi tidak mungkin untuk database besar, di mana Anda harus lebih atau kurang acak Untuk mengakses data, Anda bisa mengandalkan fakta bahwa Anda memerlukan setidaknya satu disk untuk membaca dan beberapa disk untuk menulis. Untuk meminimalkan masalah ini, gunakan disk dengan waktu pencarian rendah untuk menambah jumlah spindel disk yang tersedia (sehingga mengurangi overhead pencarian). dimungkinkan untuk menghubungkan file ke disk yang berbeda atau untuk membagi disk. Menggunakan symlink ini berarti Anda secara simbolis menghubungkan file indeks/data dari direktori data normal ke disk lain (yang juga dapat dipisah). kali lebih baik (jika disk tidak digunakan untuk hal lain). Lihat 10.2.2.1 Menggunakan symlink ke database dan tabel. Split Split berarti Anda memiliki banyak disk dan meletakkan blok pertama pada satu disk, blok kedua ada pada disk kedua , dan blok ke-n ada di disk ke-(n mod number_of_disks), dst. Ini berarti bahwa jika ukuran data normal Anda lebih kecil dari ukuran pemisahan (atau sempurna (diatur sesuai), Anda akan mendapatkan kinerja yang sedikit lebih baik. Perhatikan bahwa pemisahan sangat bergantung pada OS dan ukuran pemisahan. Jadi ujilah aplikasi Anda dengan ukuran pemisahan yang berbeda. Lihat 10.8 Menggunakan Tolok Ukur Anda Sendiri. Perhatikan bahwa pemisahan sangat bergantung pada OS dan ukuran pemisahan parameter dan jumlah disk, Anda bisa mendapatkan perbedaan urutan besarnya. Perhatikan bahwa Anda harus memilih untuk mengoptimalkan akses acak atau berurutan, Untuk keandalan, Anda mungkin ingin menggunakan serangan RAID 0+ 1 (split + mirror), tapi dalam hal ini Anda memerlukan 2*N drive untuk menyimpan data N drive. Jika Anda punya uang, ini mungkin pilihan terbaik! Namun Anda mungkin juga harus berinvestasi dalam perangkat lunak manajemen volume untuk menanganinya secara efisien A pilihan yang baik adalah memiliki data yang kurang penting (yang dapat direproduksi) pada disk RAID 0, dan data yang sangat penting (seperti informasi host dan file log) pada disk RAID 0+ 1 atau RAID N Jika Anda memiliki banyak dari penulisan karena memperbarui bit paritas, RAID N mungkin menjadi masalah. Anda juga dapat mengatur parameter untuk sistem file yang digunakan oleh database. Perubahan yang mudah adalah dengan memasang sistem file dengan opsi noatime inode yang melewatkan pembaruan, dan ini akan menghindari beberapa pencarian disk.
Anda dapat memindahkan tabel dan database dari direktori database ke lokasi lain dan menggantinya dengan simbol yang tertaut ke lokasi baru. Anda mungkin ingin melakukan ini, misalnya dengan memindahkan database ke sistem file yang memiliki lebih banyak ruang kosong Pemberitahuan MySQL Tabel adalah tautan simbolik, yang akan menyelesaikan tautan simbolik dan menggunakan tabel yang sebenarnya ditunjuknya. Tabel tersebut berfungsi pada semua sistem yang mendukung panggilan realpath() (setidaknya Linux dan Solaris mendukung realpath())! yang tidak mendukung realpath() Pada sistem Anda, Anda tidak boleh mengakses tabel melalui jalur nyata dan tautan simbolik secara bersamaan! Jika Anda melakukannya, tabel akan menjadi tidak konsisten setelah pembaruan apa pun. MySQL tidak mendukung tautan basis data secara default. Selama Anda tidak membuat tautan simbolis antar database, semuanya akan berfungsi dengan baik. Asumsikan Anda memiliki database db1 di direktori data MySQL, dan buat tautan simbolik db2 yang menunjuk ke db1:
shell&> cd /path/ke/datadir
kulit&> ln -s db1 db2
Sekarang, untuk tabel apa pun tbl_a di db1, juga akan ada tabel tbl_a di db2. Jika satu utas memperbarui db1.tbl_a dan utas lainnya memperbarui db2.tbl_a, akan ada masalah "mysys/mf_format.c" harus diubah:
if (!lstat(to,&stat_buff)) /* Periksa apakah itu tautan simbolik */
if (S_ISLNK(stat_buff.st_mode) && realpath(ke,buff))
Ubah kodenya menjadi ini:
jika (jalur nyata (ke, buff))