MySQL Performance Tuning 101 (Bahasa)

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
MySQL Performance Tuning 101
Ricky Setyawan
Principal Sales Consultant – MySQL
ASEAN

Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
2

Agenda
3
Oracle Premier Support for MySQL
MySQL Performance Tuning Best Practices
Top 6 Tips
Summary
Q & A
1
2
3
4
5

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 4
Linkedin : goo.gl/vjwN9H

Oracle Premier Support untuk
MySQL
Kami selalu mendukung anda

MySQL Enterprise Support
• Diberikan oleh expert, langsung dari sumbernya
• Didukung oleh para developer MySQL
• Support kelas dunia, dalam 27 bahasa
• Hot fixes & release maintenance
• 24x7x365
• Tak ada batas insiden
• Support konsultatif
• Skala dunia
Dapatkan pertolongan segera utk
masalah MySQL, plus advis dari
ahlinya
6

MySQL Support konsultatif
• Remote Troubleshooting menggunakan Webex
• Replication review
• Partitioning review
• Schema review
• Query review
• Performance tuning di OS platform yg berbeda2
• ...and more
7
Maksimalkan production deployment anda

Best practice dalam MySQL Performance
Tuning
8

• Berhati2lah akan “best practices”
– Tidak ada dua system yg sama
– Yang dulu pernah bekerja dgn baik, sekarang mungkin tidak
• HW and SW vendors semuanya berbohong! Sebenarnya tidak begitu
– Test, Benchmark, Monitor
– Gunakan sysbench, mysqlslap, tool2 monitoring
9

10

• Pikirkan – apa yg anda lakukan dan mengapa?
11

• Pikirkan – apa yg anda lakukan dan mengapa?
• Guideline ada, tapi bukan konfigurasi terbaik
12

• Perhatikan kebutuhan anda
– Beberapa opsi memberikan pilihan antara performa & keamanan data – Apa yg anda
butuhkan?
• Terkadang default value adalah value terbaik
• Pastikan semua table memiliki PRIMARY KEY
• InnoDB mengatur data menurut PRIMARY KEY :
– PRIMARY KEY termasuk di semua secondary index agar dapat mencari row yg
diinginkan => semakin kecil PRIMARY KEY memberikan secondary index yg makin kecil
– PRIMARY KEY yg kebanyakan berurutan secara general direkomendasikan utk
menghindari memasukkan row baru diantara row existing
13

Top 6 Tips
Tuning performa MySQL
14

01. Pikir
• Berpikir adalah pertahanan terbaik anda
• Analisa problem performa anda :
– Pastikan anda mengerti apa masalah sebenarnya :
• Bukan seperti ini : performa sangat lambat
• Tapi seperti ini :
– Query tersebut butuh 10 detik, tapi dipakai utk penggunaan interaktif maka harus selesai dalam 0.1 detik
atau kurang
– Server harus handle 200k query per detik
– Putuskan penyebabnya
• Jangan segera melompat ke kesimpulan
• Pertimbangkan seluruh stack
• Justifikasi mengapa anda piker anda telah menemukan penyebabnya
15

01. Pikir
• Menerapkan solusinya
– Buat daftar semua solusi yg anda dapat pikirkan
• Pastikan anda berpikir “outside the box” – tidak hanya apa yg anda asumsikan
– Jelaskan mengapa solusi2 tersebut akan bekerja
– Implementasikan action plan :
• Uji action plan dan rubah bila perlu
• Pastikan anda implementasikan solusi yg sama di test & production
• Bila regresi terjadi, anda memiliki
• Jika regresi terjadi, Anda memiliki catatan langkah-langkah yang dilakukan
16

02. Monitoring
• Berikan anda sebuah base line
• Memberi tahu anda apa yg telah terjadi – berguna utk penyelidikan
masalah performa
• Memungkinkan Anda untuk secara proaktif menangani masalah potensial
17

02. Monitoring
• Banyak opsi tersedia :
– MySQL Enterprise Monitor
– MySQL Workbench
– Slow Query Log
– MySQL Plugin utk Oracle Enterprise Manager
– And many more
• Pastikan anda konfigurasikan alert hingga anda
• Make sure you configure alerts so bereaksi terhadap semua kejadian
berdasarkan tingkat severity!
18

02. Monitoring
• Di Linux, perf adalah tool yg bagus utk melakukan live monitoring dan
dapat merekam utk jangka waktu tertentu
– https://perf.wiki.kernel.org/index.php/Main_Page
– http://www.brendangregg.com/perf.html
• MySQL Enterprise Monitor memiliki beberapa report utk mendapatkan
snapshot data
• Workbench memiliki report performa dari sys schema
“Real time” monitoring
19

02. Monitoring
MySQL Workbench Report performa
20

02. Monitoring
• Sys schema adalah koleksi view, function, procedure yg digunakan agar
information schema & performance schema lebih mudah dipakai
• Termasuk secara default di MySQL 5.7+
• Juga tersedia dari https://github.com/mysql/mysql-sys utk MySQL 5.6
• Dulu dikenal sebagai ps_helper oleh Mark Leith
• https://dev.mysql.com/doc/refman/5.7/en/sys-schema.html
Apakah sys schema?
21

02. Monitoring
Temukan query utk dioptimasi - MySQL Enterprise Monitor Query Analyzer
22

02. Monitoring
Temukan query utk dioptimasi – Performance Schema Digest Summary
mysql> SELECT LEFT(DIGEST_TEXT, 64) AS DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT, MAX_TIMER_WAIT
FROM performance_schema.events_statements_summary_by_digest
ORDER BY MAX_TIMER_WAIT DESC
LIMIT 10;
+------------------------------------------------------------------+------------+-----------------+----------------+
| DIGEST_TEXT | COUNT_STAR | SUM_TIMER_WAIT | MAX_TIMER_WAIT |
+------------------------------------------------------------------+------------+-----------------+----------------+
| INSERT INTO `salaries` VALUES (...) /* , ... */ | 342 | 159811231808000 | 4156961573000 |
| INSERT INTO `dept_emp` VALUES (...) /* , ... */ | 42 | 31561264335000 | 2458392698000 |
| INSERT INTO `titles` VALUES (...) /* , ... */ | 63 | 35738435708000 | 1735350241000 |
| INSERT INTO èmployees` VALUES (...) /* , ... */ | 51 | 18004605187000 | 1679817477000 |
| INSERT INTO `sbtest` ( `k` , `c` , `pad` ) VALUES (...) /* , ... | 10 | 5241286782000 | 1247361451000 |
| COMMIT | 342 | 31984662051000 | 992714081000 |
| DROP SCHEMA IF EXISTS èmployees` | 6 | 1252459420000 | 848771265000 |
| CREATE TABLE `sbtest` ( ìd` INTEGER UNSIGNED NOT NULL AUTO_INCR | 1 | 565468324000 | 565468324000 |
| CREATE TABLE `dept_manager` ( `dept_no` CHARACTER (?) NOT NULL , | 3 | 355874700000 | 220491035000 |
| SELECT COUNT (?) AS `cnt` , `round` ( ( `performance_schema` . ` | 6 | 386062170000 | 217206520000 |
+------------------------------------------------------------------+------------+-----------------+----------------+
10 rows in set (0.00 sec)
23

03. Initial Configuration File
1. Mulai dengan config file kosong
2. Set paths, port, dll.
3. Nyalakan monitoring tambahan
4. Set setting kapasitas
5. Jangan lakukan lebih dari ini!
24

• Bisa menjadi kelebihan memiliki path yg mengarah ke disk system terpisah
– Kurangi contention
– I/O seringkali menjadi bottleneck
– Dapat meletakkan “hot file” di disk yg lbh cepat
• Misalnya dengan innodb_flush_log_at_trx_commit = 1 dan transaction commit rate yg tinggi,
mungkin perlu utk meletakkan InnoDB redo log di SSD utk mendukung flush rate yg tinggi
• Note: File-per-table tablespace and general tablespace dapat diletakkan
diluar datadir sewaktu mereka dibuat
Path
25

• Bila anda gunakan InnoDB, aktifkan semua INNODB_METRICS counter :
– innodb_monitor_enable = ‘%’
• Extra detail yg diberikan sangat berguna & overhead sangat kecil
• Pastikan performance schema sudah diaktivasi
– Ada overhead tapi menyediakan informasi yg sgt berguna utk tuning performa
– Pertimbangkan utk nyalakan tambahan consumers & instruments seperlunya
(misalnya utk transactions di MySQL 5.7)
– Performance schema dpt dikonfigurasi secara dinamis sewaktu runtime
Nyalakan monitoring tambahan
26

• MySQL Reference Manual (about innodb_buffer_pool_size):
“On a dedicated database server, you might set the buffer pool size to 80%
of the machine's physical memory size.”
– Bagaimana bila anda memiliki 1TB memory? Apakah anda masih akan menyimpan
20% sisanya utk keperluan lain?
• Semestinya :
– Berapa banyak memory host miliki?
– Kurangi memory yg diperlukan oleh OS & proses lain2
– Kurangi memory yg diperlukan oleh MySQL selain InnoDB Buffer pool
– Pilih minimum dari ini dan ukuran dari “working data set”
Setting kapasitas - innodb_buffer_pool_size
27

• Total redo log size ditentukan dgn two opsi :
– innodb_log_file_size
– innodb_log_files_in_group
• Total size = innodb_log_file_size * innodb_log_files_in_group
– Max total redo log size yg disupport :
• MySQL 5.5 dan sebelumnya : just below 4G
• MySQL 5.6 dan setelahnya: just below 512G
• Harus cukup besar utk hindari checkpointing yg berlebihan
• Semakin besar redo log, semakin lambat proses shutdown berjalan
Setting kapasitas – InnoDB redo log
28

• Ambil current Log sequence number (LSN) dan checkpoint terakhir :
– SHOW ENGINE INNODB STATUS:
– INNODB_METRICS:
Setting kapasitas – InnoDB redo log – Apakah cukup besar?
---
LOG
---
Log sequence number 602763740
Log flushed up to 602763740
Pages flushed up to 584668961
Last checkpoint at 555157885
mysql> SELECT NAME, COUNT
FROM information_schema.INNODB_METRICS
WHERE NAME IN ('log_lsn_current', 'log_lsn_last_checkpoint');
+-------------------------+-----------+
| NAME | COUNT |
+-------------------------+-----------+
| log_lsn_last_checkpoint | 555157885 |
| log_lsn_current | 602763740 |
+-------------------------+-----------+
29

• Hitung besar redo log terpakai :
– Used log = log_lsn_current – log_lsn_last_checkpoint
= 602763740 - 555157885
= 47605855 (bytes)
• Bandingkan dgn total size :
– Used % = (Used log / Total log) * 100
= (47605855 / (innodb_log_file_size * innodb_log_files_in_group)) * 100
= (47605855 / 100663296) * 100
= 47.29 %
30

• Bila pemakaian mencapai 75% asynchronous flush terjadi
– I/O dpt menjadi sangat intensif yg membuat proses lain dari MySQL terhenti
– InnoDB thread utama mungkin berstatus : flushing buffer pool pages
• Pastikan anda memiliki buffer cukup utk menangani peak load
– Misalnya targetkan utk gunakan max 60% atau 70% dari redo log
• Penting utk memonitor redo log usage
• Perbaikan flushing algorithm dan opsi baru utk mengkontrol I/O telah
ditambahkan di versi MySQL terbaru
31

• Innodb_undo_tablespaces hanya dpt di-set sblm initializing datadir!
• Bila di-set maka undo log tablespace akan dibuat diluar system tablespace
(ibdata1)
• Kelebihan :
– Membuat system tablespace lebih kecil
– Dpt di-set agar undo log diletakkan di disk yg lbh cepat spt SSD
– Di MySQL 5.7 undo log tablespace dapat di-truncate
• Tiap undo tablespace adalah 10M awalnya
• Maximum 95 undo tablespace di 5.7
InnoDB Undo Log
32

• max_connections – berhati2 set ini terlalu besar karena tiap koneksi butuh
memory
• table_definition_cache – pastikan semua table dapat disimpan di cache.
Bila memiliki 4000 tables, maka set table_definition_cache > 4000
• table_open_cache – tiap table dapat dibuka lebih dari sekali
• table_open_cache_instances – Biasanya di-set di 16
Opsi kapasitas lain
33

04. Buffers And Caches
• Apakah menyalakan cache adalah selalu pilihan terbaik?
• Apakah cache & buffer lebih besar lebih baik?
Beberapa buffer & cache yg tersedia
34

• Apakah menyalakan cache adalah selalu pilihan terbaik?
• Apakah cache & buffer lebih besar lebih baik?
• No!
Beberapa buffer & cache yg tersedia
35

• Biasanya menyalakan query cache jarang berguna
– Dioperasikan oleh single mutex
• Kebanyakan workload lbh baik gunakan query cache disabled (default) :
– query_cache_type = 0
• Bila anda berpikir bahwa workload anda butuh query cache, test dahulu
– Makin banyak write, semakin sedikit gunanya
– Makin banyak data tersimpan di buffer pool, semakin sedikit gunanya
– Makin complex query dan makin besar scan, semakin banyak gunanya
• Biasanya solusi caching lainnya adalah opsi yg lbh baik
Query Cache
36

• Di MySQL 5.5 dan sebelumnya : hanya digunakan utk index scan biasa,
range index scan, dan join2 yg tak gunakan index
– Tidak ada alasan utk memiliki lbh besar dari size masing2 row yg match
• Di MySQL 5.6+ juga digunakan utk Batched Key Access (BKA)
– Query yg gunakan BKA dapat diuntungkan dari join buffer yg lbh besar
• Size minimum telaah dialokasi!
• Biasanya global value yg kecil yg terbaik : 32k-256k
• Besarkan dalam session bila diperlukan
join_buffer_size
37

• Seperti join_buffer_size, global value yg kecil bisanya terbaik : 32k-256k
• Dapat dimonitor menggunakan global status variable Sort_merge_passes:
• Targetkan utk beberapa Sort_merge_passes per detik di server yg sibuk
• Besarkan di level session bila perlu
sort_buffer_size
mysql> SHOW GLOBAL STATUS LIKE 'Sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.00 sec)
38

• Beberapa buffer dialokasi secara full tiap kali mereka dipakai
• Satu query dpt gunakan bbrp buffer, maka buffer2 besar dpt akibatkan
pemakaian memory yg jauh lbh besar
• Alokasi memory relative mahal
• Misalnya Linux glibc malloc merubah algoritma alokasi memory ketika
batas telah terlewati (biasanya 256k or 512k)
– Algoritma utk alokasi yg lbh besar dpt 40 kali lbh lembat daripada alokasi kecil
Mengapa penting dgn global value yg kecil?
39

05. Data Consistency Versus Performance
• Value yg dpt di-set sesuai urutan mulai dari data safety plg baik
– 1: secara teori adalah yg plg lambat, namun dgn SSD cepat dapat secepat opsi 2 dan 0
– 2: di-flush tiap detik (innodb_flush_log_at_timeout in 5.6+)
• Transaksi dpt hilang bila OS crash
– 0: MySQL tidak pernah fsync
• Transaksi dpt hilang bila OS crash
• Defaults adalah 1 – flush redo log setelah tiap commit
– Dibutuhkan utk memenuhi D dalam ACID
– Karena alasan ini lah, 1 adalah value recommended
innodb_flush_log_at_trx_commit
40

• Bagaimana bila innodb_flush_log_at_trx_commit = 1 terlalu lamban dan
anda ingin D dalam ACID?
– Pastikan redo log group dalam disk yg terpisah dgn data
• Jangan tergoda utk meletakkan masing2 redo log di disk terpisah
– Pertimbangkan SSD terutama bila anda memiliki commit rate yg tinggi
– Disk cache battery-backed juga memberikan flush yg murah karena IO cepat
innodb_flush_log_at_trx_commit
41

• Spesifikasikan berapa banyak transaksi antara tiap flush binary log
– 0: ketika rotating binary log atau ketika OS inisiasi
– 1: tiap transaction commit – Ini yg paling safe
– N: tiap N commit
• Default value:
– MySQL 5.6 dan sebelumnya : 0
– MySQL 5.7 dan setelahnya : 1
• MySQL 5.6 dan setelahnya mendukung group commit utk InnoDB yg
mengurangi overhead dari sync_binlog=1
sync_binlog
42

• Sync_binlog != 1 berarti slave kemungkinan besar akan harus di-rebuild bila
master crash
• Namun sync_binlog = 0 pastilah memberi performa terbaik, benar?
sync_binlog
43

• Sync_binlog != 1 berarti slave kemungkinan besar akan harus di-rebuild bila
master crash
• Namun sync_binlog = 0 pastilah memberi performa terbaik, benar?
– By default: max_binlog_size = 1G
– 1G tidak dianggap kebutuhan besar utk memory saat ini
– Maka OS dapat mem-buffer seluruh binary log
– Ketika rotating binary log, diatas 1G akan di-flush ke disk
• Menghentikan semua commit2 lain sampai binary log rotation selesai
• Maka pendeknya : sync_binlog=0 akan berikan throughput terbaik, tapi
sync_binlog =1 akan berikan performa yg paling dpt diprediksi
sync_binlog
44

06. Consider the Whole Stack
• Masalah dpt terjadi di setiap level dalam stack, misalnya :
– Application
– Application host/hardware
– Network antara application dan host dgn MySQL
– MySQL host/hardware
– MySQL
• Ini harus juga dipertimbangkan sewaktu monitoring
• Pertimbangkan setting OS/hardware
45

• Pastikan anda memiliki cukup RAM
– Semua data aktif harus tersimpan di buffer pool
– Koneksi & cache MySQL membutuhkan memory
– Extra RAM utk
• FS cache
• Monitoring
• RAM disk (tmpfs)
Pertimbangan hardware
46

• CPU cepat sangat diperlukan utk performa single thread
• Server2 baru memiliki 32 – 80 core
• Nyalakan hyper-threading
• MySQL skrg dpt scale lbh dari 72 core di 5.7
• Jumlah core yg sama di socket yg lbh sedikit lebih baik
• Core yg lbh cepat lbh baik dari core yg lambat & banyak
Pertimbangan hardware
47

• Storage yg cepat & handal bagus utk load yg berat di IO
• HDD utk sequential reads & writes
• SSD attach ke bus utk random reads & writes
• SATA atau disk lain utk log file
• Beberapa disk!
• Umur disk juga harus dipertimbangkan
Pertimbangan hardware - Storage
48

• Linux (L of LAMP)
• Solaris juga bagus
• Oracle juga invest di Windows
• Utk performa murni, gunakan Linux
Operating System
49

• I/O Scheduler
– Beberapa Linux distro menggunakan CFQ scheduler by default
• OK utk reads
• Serial writes!
– NOOP & deadline biasanya lbh baik utk workload MySQL
• Deadline adalah default I/O scheduler utk Oracle Linux Unbreakable
Setting I/O di the operating system
50

• I/O Scheduler
– Cek scheduler saat ini :
– Update scheduler secara dinamis :
– Utk set waktu boot time, gunakan “elevator=deadline” boot option
Setting I/O di the operating system
shell# cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
shell# echo deadline > /sys/block/sda/queue/scheduler
shell# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
51

• Linux glibc malloc dpt menjadi performa bottleneck
• Lbh baik gunakan malloc library alternative :
– tcmalloc
– jemalloc
Memory allocation library
52

• Set alternative malloc library:
– mysqld_safe
– systemd distributions:
• Set LD_PRELOAD in /etc/sysconfig/mysql
Memory allocation library
[mysqld_safe]
malloc-lib = /usr/lib64/libjemalloc.so.1
53

Summary
Wrapping it all up
54

Ringkasan
• Tuning performa MySQL mirip dgn tuning performa database lain :
– Optimisasi premature tidak baik
– Hanya rubah satu hal tiap waktu & jgn lakukan perubahan terlalu besar
– Jangan micro manage
– Satu size tidak cocok utk semua
– Buat keputusan berdasarkan pengukuran
– Mengerti apa maksudnya sebuah opsi sebelum implementasi opsi tersebut
– Mengerti system anda (data)
– Mengerti apa yg anda butuhkan
– Pertimbangkan seluruh stack
55

Thank You
Q&A
56

MySQL Performance Tuning 101 (Bahasa)

MySQL Performance Tuning 101 (Bahasa)

Recommended

More Related Content

What's hot (20)

Similar to MySQL Performance Tuning 101 (Bahasa) (20)

More from OracleMySQL (7)

Recently uploaded (20)

MySQL Performance Tuning 101 (Bahasa)

Editor's Notes