Penyesuaian Kinerja MySQL Yang Perlu Diperhatikan Part-2

Posted on

Halo teman-teman saya akan melanjutkan pembahasan mengenai Penyesuaian Kinerja MySQL Yang Perlu Diperhatikan. Innodb_flush_log_at_trx_commit ialah mengenai Innodb yang 100 kali lebih lambat dari MyISAM? Teman-teman mungkin lupa menyesuaikan nilai ini. Nilai default dari 1 akan berarti setiap transaksi pembaruan komit (atau setiap pernyataan di luar transaksi) perlu memasukkan log ke disk yang agak mahal, terutama kalau Teman-teman tak mempunyai cadangan cadangan baterai. Banyak program, terutama yang bergerak dari tabel MyISAM tak masalah dengan nilai 2 yang berarti tak menyiram log ke disk tapi hanya menyiramnya ke cache OS. Log masih memerah ke disk setiap detik sehingga Teman-teman biasanya tak akan kehilangan lebih dari 1-2 sec layak update. Nilai 0 sedikit lebih cepat namun sedikit kurang aman karena Teman-teman dapat kehilangan transaksi meskipun MySQL Server mengalami crash. Nilai 2 hanya menyebabkan kehilangan data dengan full OS crash.

Table_cache – Pembukaan meja dapat mahal. Selaku contoh, tabel MyISAM menTeman-temani MYI header bagi menTeman-temani tabel selaku sedang digunakan. Teman-teman tak ingin hal ini terjadi seperti itu sering dan biasanya sangat bagus bagi ukuran cache Teman-teman sehingga lumayan besar bagi menjaga sebahagian besar tabel Teman-teman terbuka. Ini menggunakan beberapa sumber daya OS dan beberapa memori tapi bagi perlengkapan keras modern, biasanya tak masalah. 1024 ialah nilai bagus bagi program dengan beberapa ratus tabel (ingat setiap koneksi memerlukan entri sendiri) kalau Teman-teman mempunyai banyak koneksi atau banyak tabel akan bertambah lebih besar. Saya telah melihat nilai lebih dari 100.000 digunakan.

Thread_cache Perancangan / penghancuran thread dapat mahal, yang terjadi di masing-masing connect / disconnect. Saya biasanya menetapkan nilai ini setidaknya 16. Bila program mempunyai lompatan besar pada jumlah koneksi konkuren dan saya akan melihat pertumbuhan yang cepat

Variabel Threads_Created saya mendongkraknya lebih tinggi. Tujuannya bukan bagi mempunyai benang yang dikerjakan pada operasi normal.

Query_cache_size kalau program Teman-teman dibaca intensif dan Teman-teman tak mempunyai cache tingkat program, ini dapat amat menolong. Jangan meletakkannya terlalu besar karena dapat memperlambat segalanya karena perawatannya mungkin akan mahal. Nilai dari 32M ke 512M biasanya masuk akal. Periksa saja setelah beberapa ketika dan lihat apakah telah terbiasa. Bagi beban kerja tertentu, rasio hit tembus lebih rendah daripada yang seharusnya dibenarkan kalau mengaktifkannya.

Catatan: karena Teman-teman dapat melihat segala ini ialah variabel global. Variabel ini bergantung di perlengkapan keras dan campuran mesin penyimpanan, sedangkan per variabel sesi biasanya mengandung beban kerja. Bila Teman-teman mempunyai pertanyaan sederhana, tak ada alasan bagi meningkatkan sort_buffer_size bahkan kalau Teman-teman mempunyai memori 64GB bagi dibuang. Berikutnya hal tersebut dapat menurunkan performa.

Saya biasanya meninggalkan tuning variabel per sesi ke langkah kedua setelah saya dapat menganalisis beban kerja.

P.S Catatan Distribusi MySQL berisi sekumpulan file my.cnf contoh yang mungkin adalah sebuah templat hebat yang akan digunakan bagi penyetelan performa database MySQL Teman-teman. Biasanya mereka telah jauh lebih bagus daripada default kalau Teman-teman memilih yang benar. Semoga bermanfaat

sumber :kursuswebprogramming.com/blog/

(Visited 5 times, 1 visits today)

Leave a Reply

Your email address will not be published. Required fields are marked *