Sejak MySQL awalnya bercabang menjadi MariaDB, MySQL telah didukung secara luas dan diadopsi dengan cepat oleh banyak audiens di komunitas database open source. Awalnya pengganti drop-in, MariaDB telah mulai membuat perbedaan terhadap MySQL, terutama dengan rilis MariaDB 10.2.
Meskipun demikian, masih belum ada perbedaan nyata antara MariaDB dan MySQL, karena keduanya memiliki mesin yang kompatibel dan dapat berjalan secara native satu sama lain. Jadi jangan heran jika penyetelan pengaturan MariaDB Anda memiliki pendekatan yang mirip dengan penyetelan MySQL.
Blog ini akan membahas penyetelan MariaDB, khususnya sistem yang berjalan di lingkungan Linux.
Optimasi Perangkat Keras dan Sistem MariaDB
MariaDB merekomendasikan agar Anda meningkatkan perangkat keras dengan urutan prioritas berikut...
Memori
Memori adalah faktor terpenting untuk database karena memungkinkan Anda untuk menyesuaikan Variabel Sistem Server. Lebih banyak memori berarti cache kunci dan tabel yang lebih besar, yang disimpan dalam memori sehingga disk dapat mengakses, urutan besarnya lebih lambat, selanjutnya dikurangi.
Namun, perlu diingat, hanya menambahkan lebih banyak memori mungkin tidak menghasilkan peningkatan drastis jika variabel server tidak disetel untuk memanfaatkan memori ekstra yang tersedia.
Menggunakan lebih banyak slot RAM pada motherboard akan meningkatkan frekuensi bus, dan akan ada lebih banyak latensi antara RAM dan CPU. Ini berarti lebih baik menggunakan ukuran RAM tertinggi per slot.
Disk
Akses disk yang cepat sangat penting, karena pada akhirnya di situlah data berada. Angka kuncinya adalah waktu pencarian disk (pengukuran seberapa cepat disk fisik dapat bergerak untuk mengakses data) jadi pilihlah disk dengan waktu pencarian serendah mungkin. Anda juga dapat menambahkan disk khusus untuk file sementara dan log transaksi.
Ethernet Cepat
Dengan persyaratan yang sesuai untuk bandwidth internet Anda, ethernet cepat berarti dapat memiliki respons yang lebih cepat terhadap permintaan klien, waktu respons replikasi untuk membaca log biner di seluruh budak, waktu respons yang lebih cepat juga sangat penting terutama di Galera - cluster berbasis.
CPU
Meskipun kemacetan perangkat keras sering terjadi di tempat lain, prosesor yang lebih cepat memungkinkan penghitungan dilakukan lebih cepat, dan hasilnya dikirim kembali ke klien dengan lebih cepat. Selain kecepatan prosesor, kecepatan bus prosesor dan ukuran cache juga merupakan faktor penting untuk dipertimbangkan.
Mengatur Penjadwal I/O Disk Anda
Penjadwal I/O ada sebagai cara untuk mengoptimalkan permintaan akses disk. Ini menggabungkan permintaan I/O ke lokasi serupa pada disk. Ini berarti bahwa disk drive tidak perlu mencari terlalu sering dan meningkatkan waktu respons keseluruhan yang besar dan menghemat operasi disk. Nilai yang direkomendasikan untuk kinerja I/O adalah noop dan tenggat waktu.
noop berguna untuk memeriksa apakah keputusan penjadwalan I/O yang kompleks dari penjadwal lain tidak menyebabkan kemunduran kinerja I/O. Dalam beberapa kasus, ini dapat membantu untuk perangkat yang melakukan penjadwalan I/O sendiri, sebagai penyimpanan cerdas, atau perangkat yang tidak bergantung pada gerakan mekanis, seperti SSD. Biasanya, penjadwal I/O DEADLINE adalah pilihan yang lebih baik untuk perangkat ini, tetapi karena overhead yang lebih sedikit, NOOP dapat menghasilkan kinerja yang lebih baik pada beban kerja tertentu.
Untuk tenggat waktu, ini adalah penjadwal I/O berorientasi latensi. Setiap permintaan I/O memiliki tenggat waktu yang ditetapkan. Biasanya, permintaan disimpan dalam antrian (baca dan tulis) yang diurutkan berdasarkan nomor sektor. Algoritma DEADLINE mempertahankan dua antrian tambahan (baca dan tulis) di mana permintaan diurutkan berdasarkan tenggat waktu. Selama tidak ada permintaan yang kehabisan waktu, antrian "sektor" digunakan. Jika terjadi timeout, request dari antrian “deadline” akan dilayani sampai tidak ada lagi request yang expired. Umumnya, algoritme lebih memilih membaca daripada menulis.
Untuk perangkat PCIe (drive SSD NVMe), mereka memiliki antrean internal yang besar bersama dengan layanan cepat dan tidak memerlukan atau memanfaatkan pengaturan penjadwal I/O. Disarankan untuk tidak memiliki parameter konfigurasi mode penjadwal yang eksplisit.
Anda dapat memeriksa pengaturan penjadwal dengan:
cat /sys/block/${DEVICE}/queue/schedulerMisalnya, seharusnya terlihat seperti ini:
cat /sys/block/sda/queue/scheduler
[noop] deadline cfqUntuk membuatnya permanen, edit file konfigurasi /etc/default/grub, cari variabel GRUB_CMDLINE_LINUX dan tambahkan elevator seperti di bawah ini:
GRUB_CMDLINE_LINUX="elevator=noop"Meningkatkan Batas File Terbuka
Untuk memastikan kinerja server yang baik, jumlah total koneksi klien, file database, dan file log tidak boleh melebihi batas deskriptor file maksimum pada sistem operasi (ulimit -n). Sistem Linux membatasi jumlah deskriptor file yang dapat dibuka oleh satu proses hingga 1.024 per proses. Pada server database aktif (terutama yang produksi) dapat dengan mudah mencapai batas sistem default.
Untuk meningkatkan ini, edit /etc/security/limits.conf dan tentukan atau tambahkan berikut ini:
mysql soft nofile 65535
mysql hard nofile 65535Ini memerlukan restart sistem. Setelah itu, Anda dapat mengonfirmasi dengan menjalankan perintah berikut:
$ ulimit -Sn
65535
$ ulimit -Hn
65535Secara opsional, Anda dapat mengatur ini melalui mysqld_safe jika Anda memulai proses mysqld melalui mysqld_safe,
[mysqld_safe]
open_files_limit=4294967295atau jika Anda menggunakan systemd,
sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF
[Service]
LimitNOFILE=infinity
EOF
sudo systemctl daemon-reloadMengatur Swappiness di Linux untuk MariaDB
Linux Swap memainkan peran besar dalam sistem database. Ini bertindak seperti ban serep di kendaraan Anda, ketika kebocoran memori buruk mengganggu pekerjaan Anda, mesin akan melambat... tetapi dalam banyak kasus masih akan dapat digunakan untuk menyelesaikan tugas yang diberikan.
Untuk menerapkan perubahan pada swappiness Anda, cukup jalankan,
sysctl -w vm.swappiness=1Ini terjadi secara dinamis, tanpa perlu me-reboot server. Untuk membuatnya persisten, edit /etc/sysctl.conf dan tambahkan baris,
vm.swappiness=1Sangat umum untuk menyetel swappiness=0, tetapi sejak rilis kernel baru (yaitu kernel> 2.6.32-303), perubahan telah dibuat sehingga Anda perlu menyetel vm.swappiness=1.
Optimasi Sistem File untuk MariaDB
Sistem file yang paling umum digunakan di lingkungan Linux yang menjalankan MariaDB adalah ext4 dan XFS. Ada juga pengaturan tertentu yang tersedia untuk mengimplementasikan arsitektur menggunakan ZFS dan BRTFS (seperti yang dirujuk dalam dokumentasi MariaDB).
Selain itu, sebagian besar pengaturan basis data tidak perlu mencatat waktu akses file. Anda mungkin ingin menonaktifkan ini saat memasang volume ke dalam sistem. Untuk melakukannya, edit file /etc/fstab. Misalnya, pada volume bernama /dev/md2, tampilannya seperti ini:
/dev/md2 / ext4 defaults,noatime 0 0Membuat Instance MariaDB yang Optimal
Simpan Data Pada Volume Terpisah
Selalu ideal untuk memisahkan data database Anda pada volume yang terpisah. Volume ini khusus untuk jenis volume penyimpanan cepat seperti SSD, NVMe, atau kartu PCIe. Misalnya, jika seluruh volume sistem Anda akan gagal, Anda akan memiliki volume database Anda aman dan yakin tidak terpengaruh jika perangkat keras penyimpanan Anda akan gagal.
Setel MariaDB Untuk Menggunakan Memori Secara Efisien
innodb_buffer_pool_size
Nilai utama untuk disesuaikan pada server database dengan tabel XtraDB/InnoDB seluruhnya/terutama tabel, dapat diatur hingga 80% dari total memori di lingkungan ini. Jika diatur ke 2 GB atau lebih, Anda mungkin ingin menyesuaikan innodb_buffer_pool_instances juga. Anda dapat mengatur ini secara dinamis jika Anda menggunakan versi MariaDB>=10.2.2. Jika tidak, server memerlukan restart.
tmp_memory_table_size/max_heap_table_size
Untuk tmp_memory_table_size (tmp_table_size), jika Anda berurusan dengan tabel sementara yang besar, menyetel ini lebih tinggi memberikan peningkatan kinerja karena akan disimpan dalam memori. Ini biasa terjadi pada kueri yang banyak menggunakan GROUP BY, UNION, atau subkueri. Meskipun jika max_heap_table_size lebih kecil, batas bawah akan berlaku. Jika tabel melebihi batas, MariaDB mengonversinya menjadi tabel MyISAM atau Aria. Anda dapat melihat apakah perlu untuk meningkatkan dengan membandingkan variabel status Created_tmp_disk_tables dan Created_tmp_tables untuk melihat berapa banyak tabel sementara dari total yang dibuat yang perlu dikonversi ke disk. Seringkali kueri GROUP BY kompleks bertanggung jawab untuk melebihi batas.
Sementara max_heap_table_size, ini adalah ukuran maksimum untuk tabel MEMORY yang dibuat pengguna. Nilai yang ditetapkan pada variabel ini hanya berlaku untuk tabel yang baru dibuat atau dibuat ulang dan bukan tabel yang sudah ada. Semakin kecil max_heap_table_size dan tmp_table_size juga membatasi tabel dalam memori internal. Ketika ukuran maksimum tercapai, setiap upaya lebih lanjut untuk memasukkan data akan menerima kesalahan "tabel ... sudah penuh". Tabel sementara yang dibuat dengan CREATE TEMPORARY tidak akan dikonversi ke Aria, seperti yang terjadi pada tabel sementara internal, tetapi juga akan menerima kesalahan tabel penuh.
innodb_log_file_size
Memori besar dengan pemrosesan berkecepatan tinggi dan disk I/O yang cepat bukanlah hal baru dan memiliki harga yang wajar seperti yang direkomendasikan. Jika Anda lebih menyukai peningkatan kinerja terutama selama dan menangani transaksi InnoDB Anda, menyetel variabel innodb_log_file_size ke nilai yang lebih besar seperti 5Gib atau bahkan 10GiB adalah wajar. Peningkatan berarti bahwa transaksi yang lebih besar dapat berjalan tanpa perlu melakukan disk I/O sebelum melakukan.
join_buffer_size
Dalam beberapa kasus, kueri Anda cenderung kurang menggunakan pengindeksan yang tepat atau hanya, ada saat-saat Anda memerlukan kueri ini untuk dijalankan. Tidak, kecuali jika itu akan banyak dipanggil atau dipanggil dari perspektif klien, pengaturan variabel ini adalah yang terbaik pada tingkat sesi. Tingkatkan untuk mendapatkan penggabungan penuh yang lebih cepat saat menambahkan indeks tidak dimungkinkan, meskipun waspadai masalah memori, karena penggabungan akan selalu mengalokasikan ukuran minimum.
Setel max_allowed_packet Anda
MariaDB memiliki sifat yang sama dengan MySQL saat menangani paket. Ini membagi data menjadi paket-paket dan klien harus mengetahui nilai variabel max_allowed_packet. Server akan memiliki buffer untuk menyimpan body dengan ukuran maksimum yang sesuai dengan nilai max_allowed_packet ini. Jika klien mengirim lebih banyak data daripada ukuran max_allowed_packet, soket akan ditutup. Direktif max_allowed_packet menentukan ukuran maksimum paket yang dapat dikirim.
Menyetel nilai ini terlalu rendah dapat menyebabkan kueri berhenti dan menutup koneksi kliennya yang cukup umum untuk menerima kesalahan seperti ER_NET_PACKET_TOO_LARGE atau Koneksi terputus ke server MySQL selama kueri. Idealnya, terutama pada sebagian besar permintaan aplikasi saat ini, Anda dapat mulai menyetelnya ke 512MiB. Jika itu adalah jenis aplikasi dengan permintaan rendah, gunakan saja nilai default dan setel variabel ini hanya melalui sesi saat diperlukan jika data yang akan dikirim atau diterima terlalu besar dari nilai default (16MiB sejak MariaDB 10.2.4). Dalam beban kerja tertentu yang menuntut paket besar untuk diproses, maka Anda perlu menyesuaikannya lebih tinggi sesuai dengan kebutuhan Anda terutama pada saat replikasi. Jika max_allowed_packet terlalu kecil pada slave, hal ini juga menyebabkan slave menghentikan thread I/O.
Menggunakan Threadpool
Dalam beberapa kasus, penyetelan ini mungkin tidak diperlukan atau direkomendasikan untuk Anda. Threadpool paling efisien dalam situasi di mana kueri relatif pendek dan beban terikat pada CPU (beban kerja OLTP). Jika beban kerja tidak terikat CPU, Anda mungkin masih ingin membatasi jumlah utas untuk menghemat memori untuk buffer memori database.
Menggunakan threadpool adalah solusi ideal terutama jika sistem Anda mengalami peralihan konteks dan Anda menemukan cara untuk menguranginya dan mempertahankan jumlah utas yang lebih rendah daripada jumlah klien. Namun, jumlah ini juga tidak boleh terlalu rendah, karena kami juga ingin memaksimalkan penggunaan CPU yang tersedia. Oleh karena itu, idealnya harus ada satu thread aktif untuk setiap CPU pada mesin.
Anda dapat mengatur thread_pool_max_threads, thread_pool_min_threads untuk jumlah maksimum dan minimum thread. Tidak seperti MySQL, ini hanya ada di MariaDB.
Setel variabel thread_handling yang menentukan bagaimana server menangani thread untuk koneksi klien. Selain utas untuk koneksi klien, ini juga berlaku untuk utas server internal tertentu, seperti utas budak Galera.
Sesuaikan Cache Tabel Anda + max_connections
Jika Anda menghadapi kejadian sesekali dalam daftar proses tentang status Pembukaan tabel dan Menutup tabel, itu bisa menandakan bahwa Anda perlu meningkatkan cache tabel Anda. Anda dapat memantau ini juga melalui prompt klien mysql dengan menjalankan SHOW GLOBAL STATUS LIKE 'Open%table%'; dan memantau variabel status.
Untuk max_connections, jika aplikasi Anda membutuhkan banyak koneksi bersamaan, Anda dapat mulai menyetelnya ke 500.
Untuk table_open_cache, ini akan menjadi jumlah total tabel Anda, tetapi sebaiknya Anda menambahkan lebih banyak tergantung pada jenis kueri yang Anda layani karena tabel sementara juga akan di-cache. Misalnya, jika Anda memiliki 500 tabel, masuk akal jika Anda memulai dengan 1500.
Sementara table_open_cache_instances Anda, mulai atur ke 8. Ini dapat meningkatkan skalabilitas dengan mengurangi pertengkaran antar sesi, cache tabel terbuka dapat dipartisi menjadi beberapa instance cache yang lebih kecil dengan ukuran table_open_cache / table_open_cache_instances.
Untuk InnoDB, table_definition_cache bertindak sebagai batas lunak untuk jumlah instance tabel terbuka dalam cache kamus data InnoDB. Nilai yang akan ditentukan akan mengatur jumlah definisi tabel yang dapat disimpan dalam cache definisi. Jika Anda menggunakan tabel dalam jumlah besar, Anda dapat membuat cache definisi tabel yang besar untuk mempercepat pembukaan tabel. Cache definisi tabel membutuhkan lebih sedikit ruang dan tidak menggunakan deskriptor file, tidak seperti cache tabel normal. Nilai minimum adalah 400. Nilai default didasarkan pada rumus berikut, dibatasi hingga batas 2000:
MIN(400 + table_open_cache / 2, 2000)Jika jumlah instance tabel terbuka melebihi pengaturan table_definition_cache, mekanisme LRU mulai menandai instance tabel untuk dikeluarkan dan akhirnya menghapusnya dari cache kamus data. Batas tersebut membantu mengatasi situasi di mana sejumlah besar memori akan digunakan untuk men-cache instance tabel yang jarang digunakan hingga server berikutnya dimulai ulang. Jumlah instance tabel dengan metadata yang di-cache bisa lebih tinggi dari batas yang ditentukan oleh table_definition_cache, karena instance tabel induk dan anak dengan hubungan kunci asing tidak ditempatkan pada daftar LRU dan tidak tunduk pada pengusiran dari memori.
Tidak seperti table_open_cache, table_definition_cache tidak menggunakan deskriptor file, dan jauh lebih kecil.
Menangani Cache Kueri
Sebaiknya, kami menyarankan untuk menonaktifkan cache kueri di semua penyiapan MariaDB Anda. Anda perlu memastikan bahwa query_cache_type=OFF dan query_cache_size=0 untuk menyelesaikan penonaktifan cache kueri. Tidak seperti MySQL, MariaDB masih sepenuhnya mendukung cache kueri dan tidak memiliki rencana untuk menarik dukungannya untuk menggunakan cache kueri. Ada beberapa orang yang mengklaim bahwa cache kueri masih memberikan manfaat kinerja bagi mereka. Namun, postingan ini dari Percona. Cache kueri MySQL:Musuh atau sahabat terbaik mengungkapkan bahwa cache kueri, jika diaktifkan, menghasilkan overhead dan menunjukkan kinerja server yang buruk.
Jika Anda ingin menggunakan cache kueri, pastikan Anda memantau cache kueri Anda dengan menjalankan SHOW GLOBAL STATUS LIKE 'Qcache%';. Qcache_inserts berisi jumlah kueri yang ditambahkan ke cache kueri, Qcache_hits berisi jumlah kueri yang telah menggunakan cache kueri, sedangkan Qcache_lowmem_prunes berisi jumlah kueri yang dikeluarkan dari cache karena kekurangan memori. Sementara pada waktunya, menggunakan dan mengaktifkan cache kueri dapat menjadi terfragmentasi. Qcache_free_blocks yang tinggi relatif terhadap Qcache_total_blocks dapat mengindikasikan fragmentasi. Untuk mendefragnya, jalankan FLUSH QUERY CACHE. Ini akan mendefrag cache kueri tanpa menghapus kueri apa pun.
Selalu Pantau Server Anda
Sangat penting untuk memantau node MariaDB dengan benar. Alat pemantauan umum di luar sana (seperti Nagios, Zabbix, atau PMM) tersedia jika Anda cenderung lebih menyukai alat sumber terbuka dan gratis. Untuk alat perusahaan dan lengkap, kami sarankan Anda mencoba ClusterControl, karena tidak hanya menyediakan pemantauan, tetapi juga menawarkan penasihat kinerja, peringatan, dan alarm yang membantu Anda meningkatkan kinerja sistem Anda dan tetap mengikuti perkembangan terkini. tren saat Anda terlibat dengan tim Dukungan. Pemantauan basis data dengan ClusterControl gratis dan merupakan bagian dari Edisi Komunitas.
Kesimpulan
Menyetel pengaturan MariaDB Anda hampir sama dengan MySQL, tetapi dengan beberapa perbedaan, karena berbeda dalam beberapa pendekatan dan versi yang didukungnya. MariaDB sekarang menjadi entitas yang berbeda di dunia basis data dan dengan cepat mendapatkan kepercayaan dari komunitas tanpa FUD apa pun. Mereka memiliki alasan sendiri mengapa ini harus diimplementasikan dengan cara ini, jadi sangat penting bagi kami untuk mengetahui cara menyesuaikan ini dan mengoptimalkan server MariaDB Anda.
