Apa itu SysBench? Jika Anda bekerja dengan MySQL secara teratur, maka kemungkinan besar Anda pernah mendengarnya. SysBench telah lama berada di ekosistem MySQL. Ini awalnya ditulis oleh Peter Zaitsev, pada tahun 2004. Tujuannya adalah untuk menyediakan alat untuk menjalankan benchmark sintetis MySQL dan perangkat keras yang digunakannya. Itu dirancang untuk menjalankan tes CPU, memori dan I/O. Itu juga memiliki opsi untuk menjalankan beban kerja OLTP pada database MySQL. OLTP adalah singkatan dari pemrosesan transaksi online, beban kerja umum untuk aplikasi online seperti e-commerce, entri pesanan, atau sistem transaksi keuangan.
Dalam posting blog ini, kami akan fokus pada fitur benchmark SQL tetapi perlu diingat bahwa benchmark perangkat keras juga dapat sangat berguna dalam mengidentifikasi masalah pada server database. Misalnya, tolok ukur I/O dimaksudkan untuk mensimulasikan beban kerja I/O InnoDB sementara pengujian CPU melibatkan simulasi lingkungan multi-tapak yang sangat bersamaan bersama dengan pengujian untuk pertentangan mutex - sesuatu yang juga menyerupai jenis beban kerja database.
Sejarah dan Arsitektur SysBench
Seperti disebutkan, SysBench awalnya dibuat pada tahun 2004 oleh Peter Zaitsev. Segera setelah itu, Alexey Kopytov mengambil alih pengembangannya. Itu mencapai versi 0.4.12 dan pengembangan dihentikan. Setelah istirahat panjang Alexey mulai mengerjakan SysBench lagi pada tahun 2016. Segera versi 0.5 telah dirilis dengan benchmark OLTP yang ditulis ulang untuk menggunakan skrip berbasis LUA. Kemudian, pada tahun 2017, SysBench 1.0 dirilis. Ini seperti siang dan malam dibandingkan dengan versi 0.4.12 yang lama. Pertama dan terpenting, alih-alih skrip hardcode, sekarang kami memiliki kemampuan untuk menyesuaikan tolok ukur menggunakan LUA. Misalnya, Percona membuat benchmark mirip TPCC yang dapat dieksekusi menggunakan SysBench. Mari kita lihat sekilas arsitektur SysBench saat ini.
SysBench adalah biner C yang menggunakan skrip LUA untuk mengeksekusi benchmark. Skrip tersebut harus:
- Menangani masukan dari parameter baris perintah
- Tentukan semua mode yang seharusnya digunakan oleh benchmark (persiapan, jalankan, pembersihan)
- Siapkan semua data
- Tentukan bagaimana tolok ukur akan dijalankan (seperti apa tampilan kueri, dll.)
Skrip dapat menggunakan beberapa koneksi ke database, mereka juga dapat memproses hasil jika Anda ingin membuat tolok ukur kompleks di mana kueri bergantung pada kumpulan hasil kueri sebelumnya. Dengan SysBench 1.0 dimungkinkan untuk membuat histogram latensi. Dimungkinkan juga bagi skrip LUA untuk menangkap dan menangani kesalahan melalui kait kesalahan. Ada dukungan untuk paralelisasi dalam skrip LUA, beberapa kueri dapat dieksekusi secara paralel, membuat, misalnya, penyediaan lebih cepat. Last but not least, beberapa format output sekarang didukung. Sebelumnya SysBench hanya menghasilkan output yang dapat dibaca manusia. Sekarang dimungkinkan untuk membuatnya sebagai CSV atau JSON, membuatnya lebih mudah untuk melakukan pasca-pemrosesan dan menghasilkan grafik menggunakan, misalnya, gnuplot atau memasukkan data ke Prometheus, Graphite, atau penyimpanan data serupa.
Mengapa SysBench?
Alasan utama mengapa SysBench menjadi populer adalah karena mudah digunakan. Seseorang tanpa pengetahuan sebelumnya dapat mulai menggunakannya dalam beberapa menit. Ini juga menyediakan, secara default, tolok ukur yang mencakup sebagian besar kasus - beban kerja OLTP, read-only atau read-write, pencarian kunci utama dan pembaruan kunci utama. Semua yang menyebabkan sebagian besar masalah untuk MySQL, hingga MySQL 8.0. Ini juga merupakan alasan mengapa SysBench begitu populer di berbagai benchmark dan perbandingan yang dipublikasikan di Internet. Postingan tersebut membantu mempromosikan alat ini dan menjadikannya tolok ukur sintetis untuk MySQL.
Hal baik lainnya tentang SysBench adalah, sejak versi 0.5 dan penggabungan LUA, siapa pun dapat menyiapkan segala jenis benchmark. Kami telah menyebutkan benchmark seperti TPCC tetapi siapa pun dapat membuat sesuatu yang akan menyerupai beban kerja produksinya. Kami tidak mengatakan itu sederhana, kemungkinan besar akan memakan waktu, tetapi memiliki kemampuan ini bermanfaat jika Anda perlu menyiapkan tolok ukur khusus.
Menjadi benchmark sintetis, SysBench bukanlah alat yang dapat Anda gunakan untuk menyetel konfigurasi server MySQL Anda (kecuali jika Anda menyiapkan skrip LUA dengan beban kerja khusus atau beban kerja Anda sangat mirip dengan beban kerja benchmark yang disertakan dengan SysBench). Apa yang bagus untuk membandingkan kinerja perangkat keras yang berbeda. Anda dapat dengan mudah membandingkan kinerja, katakanlah, berbagai jenis node yang ditawarkan oleh penyedia cloud Anda dan QPS maksimum (kueri per detik) yang mereka tawarkan. Mengetahui metrik itu dan mengetahui apa yang Anda bayar untuk node yang diberikan, Anda kemudian dapat menghitung metrik yang lebih penting - QP$ (kueri per dolar). Ini akan memungkinkan Anda untuk mengidentifikasi jenis node yang akan digunakan saat membangun lingkungan yang hemat biaya. Tentu saja, SysBench dapat digunakan juga untuk penyetelan awal dan menilai kelayakan desain yang diberikan. Katakanlah kita membangun kluster Galera yang tersebar di seluruh dunia - Amerika Utara, UE, Asia. Berapa banyak sisipan per detik yang dapat ditangani oleh pengaturan seperti itu? Apa yang akan menjadi latensi komit? Apakah masuk akal untuk melakukan pembuktian konsep atau mungkin latensi jaringan cukup tinggi sehingga beban kerja sederhana pun tidak berfungsi seperti yang Anda harapkan.
Bagaimana dengan tes stres? Tidak semua orang telah pindah ke cloud, masih ada perusahaan yang lebih memilih untuk membangun infrastruktur mereka sendiri. Setiap server baru yang diperoleh harus melalui periode pemanasan di mana Anda akan menekankannya untuk menunjukkan potensi kerusakan perangkat keras. Dalam hal ini SysBench juga dapat membantu. Baik dengan menjalankan beban kerja OLTP yang membebani server, atau Anda juga dapat menggunakan benchmark khusus untuk CPU, disk, dan memori.
Seperti yang Anda lihat, ada banyak kasus di mana bahkan benchmark sintetis sederhana pun bisa sangat berguna. Di paragraf berikutnya kita akan melihat apa yang bisa kita lakukan dengan SysBench.
Apa yang dapat dilakukan SysBench untuk Anda?
Tes apa yang dapat Anda jalankan?
Seperti yang disebutkan di awal, kami akan fokus pada benchmark OLTP dan hanya sebagai pengingat kami akan mengulangi bahwa SysBench juga dapat digunakan untuk melakukan tes I/O, CPU, dan memori. Mari kita lihat tolok ukur yang disertakan dengan SysBench 1.0 (kami menghapus beberapa file LUA pembantu dan skrip LUA non-basis data dari daftar ini).
-rwxr-xr-x 1 root root 1.5K May 30 07:46 bulk_insert.lua
-rwxr-xr-x 1 root root 1.3K May 30 07:46 oltp_delete.lua
-rwxr-xr-x 1 root root 2.4K May 30 07:46 oltp_insert.lua
-rwxr-xr-x 1 root root 1.3K May 30 07:46 oltp_point_select.lua
-rwxr-xr-x 1 root root 1.7K May 30 07:46 oltp_read_only.lua
-rwxr-xr-x 1 root root 1.8K May 30 07:46 oltp_read_write.lua
-rwxr-xr-x 1 root root 1.1K May 30 07:46 oltp_update_index.lua
-rwxr-xr-x 1 root root 1.2K May 30 07:46 oltp_update_non_index.lua
-rwxr-xr-x 1 root root 1.5K May 30 07:46 oltp_write_only.lua
-rwxr-xr-x 1 root root 1.9K May 30 07:46 select_random_points.lua
-rwxr-xr-x 1 root root 2.1K May 30 07:46 select_random_ranges.luaMari kita bahas satu per satu.
Pertama, bulk_insert.lua. Tes ini dapat digunakan untuk mengukur kemampuan MySQL untuk melakukan penyisipan multi-baris. Ini bisa sangat berguna saat memeriksa, misalnya, kinerja replikasi atau cluster Galera. Dalam kasus pertama, ini dapat membantu Anda menjawab pertanyaan:"seberapa cepat saya dapat memasukkan sebelum jeda replikasi muncul?". Dalam kasus selanjutnya, ini akan memberi tahu Anda seberapa cepat data dapat dimasukkan ke dalam kluster Galera mengingat latensi jaringan saat ini.
Semua skrip oltp_* memiliki struktur tabel yang sama. Dua yang pertama (oltp_delete.lua dan oltp_insert.lua) mengeksekusi pernyataan DELETE dan INSERT tunggal. Sekali lagi, ini bisa menjadi tes untuk replikasi atau cluster Galera - dorong ke batas dan lihat berapa jumlah penyisipan atau pembersihan yang dapat ditangani. Kami juga memiliki tolok ukur lain yang berfokus pada fungsionalitas tertentu - oltp_point_select, oltp_update_index, dan oltp_update_non_index. Ini akan menjalankan subset kueri - pemilihan berbasis kunci utama, pembaruan berbasis indeks, dan pembaruan berbasis non-indeks. Jika Anda ingin menguji beberapa fungsi ini, tes ada di sana. Kami juga memiliki tolok ukur yang lebih kompleks yang didasarkan pada beban kerja OLTP:oltp_read_only, oltp_read_write, dan oltp_write_only. Anda dapat menjalankan beban kerja hanya-baca, yang akan terdiri dari berbagai jenis kueri SELECT, Anda hanya dapat menjalankan penulisan (campuran DELETE, INSERT, dan UPDATE) atau Anda dapat menjalankan campuran keduanya. Terakhir, dengan menggunakan select_random_points dan select_random_ranges Anda dapat menjalankan beberapa SELECT acak baik menggunakan titik acak dalam daftar IN() atau rentang acak menggunakan BETWEEN.
Bagaimana Anda dapat Mengonfigurasi Tolok Ukur?
Yang juga penting, tolok ukur dapat dikonfigurasi - Anda dapat menjalankan pola beban kerja yang berbeda menggunakan tolok ukur yang sama. Mari kita lihat dua tolok ukur yang paling umum untuk dieksekusi. Kami akan mendalami tolok ukur read_only dan OLTP read_write OLTP. Pertama-tama, SysBench memiliki beberapa opsi konfigurasi umum. Disini kita hanya akan membahas yang paling penting saja, kalian bisa cek semuanya dengan menjalankan:
sysbench --helpMari kita lihat mereka.
--threads=N number of threads to use [1]Anda dapat menentukan jenis konkurensi yang Anda inginkan untuk dihasilkan oleh SysBench. MySQL, karena setiap perangkat lunak, memiliki beberapa batasan skalabilitas dan kinerjanya akan mencapai puncaknya pada beberapa tingkat konkurensi. Setelan ini membantu mensimulasikan konkurensi yang berbeda untuk beban kerja tertentu dan memeriksa apakah beban kerja tersebut sudah melewati sweet spot.
--events=N limit for total number of events [0]
--time=N limit for total execution time in seconds [10]Kedua pengaturan tersebut mengatur berapa lama SysBench harus terus berjalan. Itu dapat menjalankan sejumlah kueri atau dapat terus berjalan selama waktu yang telah ditentukan.
--warmup-time=N execute events for this many seconds with statistics disabled before the actual benchmark run with statistics enabled [0]Ini cukup jelas. SysBench menghasilkan hasil statistik dari pengujian dan hasil tersebut mungkin terpengaruh jika MySQL dalam keadaan dingin. Pemanasan membantu mengidentifikasi throughput "biasa" dengan mengeksekusi benchmark untuk waktu yang telah ditentukan, memungkinkan untuk menghangatkan cache, buffer pool, dll.
--rate=N average transactions rate. 0 for unlimited rate [0]Secara default, SysBench akan mencoba mengeksekusi kueri secepat mungkin. Untuk mensimulasikan lalu lintas yang lebih lambat, opsi ini dapat digunakan. Anda dapat menentukan di sini berapa banyak transaksi yang harus dilakukan per detik.
--report-interval=N periodically report intermediate statistics with a specified interval in seconds. 0 disables intermediate reports [0]Secara default SysBench menghasilkan laporan setelah selesai dijalankan dan tidak ada kemajuan yang dilaporkan saat benchmark berjalan. Dengan menggunakan opsi ini, Anda dapat membuat SysBench lebih bertele-tele saat benchmark masih berjalan.
--rand-type=STRING random numbers distribution {uniform, gaussian, special, pareto, zipfian} to use by default [special]SysBench memberi Anda kemampuan untuk menghasilkan berbagai jenis distribusi data. Semua dari mereka mungkin memiliki tujuan mereka sendiri. Opsi default, 'khusus', mendefinisikan beberapa (dapat dikonfigurasi) hot-spot dalam data, sesuatu yang cukup umum di aplikasi web. Anda juga dapat menggunakan distribusi lain jika data Anda berperilaku dengan cara yang berbeda. Dengan membuat pilihan yang berbeda di sini Anda juga dapat mengubah cara database Anda ditekankan. Misalnya, distribusi seragam, di mana semua baris memiliki kemungkinan yang sama untuk diakses, adalah operasi yang jauh lebih intensif memori. Ini akan menggunakan lebih banyak kumpulan buffer untuk menyimpan semua data dan akan jauh lebih banyak menggunakan disk jika kumpulan data Anda tidak muat di memori. Di sisi lain, distribusi khusus dengan beberapa hot-spot akan mengurangi tekanan pada disk karena baris panas lebih mungkin disimpan di kumpulan buffer dan akses ke baris yang disimpan di disk jauh lebih kecil kemungkinannya. Untuk beberapa tipe distribusi data, SysBench memberi Anda lebih banyak penyesuaian. Anda dapat menemukan info ini di keluaran 'sysbench --help'.
--db-ps-mode=STRING prepared statements usage mode {auto, disable} [auto]Dengan menggunakan pengaturan ini, Anda dapat memutuskan apakah SysBench harus menggunakan pernyataan yang telah disiapkan (selama tersedia di penyimpanan data yang diberikan - untuk MySQL artinya PS akan diaktifkan secara default) atau tidak. Ini mungkin membuat perbedaan saat bekerja dengan proxy seperti ProxySQL atau MaxScale - mereka harus memperlakukan pernyataan yang disiapkan dengan cara khusus dan semuanya harus dirutekan ke satu host sehingga tidak mungkin menguji skalabilitas proxy.
Selain opsi konfigurasi umum, setiap pengujian mungkin memiliki konfigurasinya sendiri. Anda dapat memeriksa apa yang mungkin dengan menjalankan:
[email protected]:~# sysbench ./sysbench/src/lua/oltp_read_write.lua help
sysbench 1.1.0-2e6b7d5 (using bundled LuaJIT 2.1.0-beta3)
oltp_read_only.lua options:
--distinct_ranges=N Number of SELECT DISTINCT queries per transaction [1]
--sum_ranges=N Number of SELECT SUM() queries per transaction [1]
--skip_trx[=on|off] Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]
--secondary[=on|off] Use a secondary index in place of the PRIMARY KEY [off]
--create_secondary[=on|off] Create a secondary index in addition to the PRIMARY KEY [on]
--index_updates=N Number of UPDATE index queries per transaction [1]
--range_size=N Range size for range SELECT queries [100]
--auto_inc[=on|off] Use AUTO_INCREMENT column as Primary Key (for MySQL), or its alternatives in other DBMS. When disabled, use client-generated IDs [on]
--delete_inserts=N Number of DELETE/INSERT combinations per transaction [1]
--tables=N Number of tables [1]
--mysql_storage_engine=STRING Storage engine, if MySQL is used [innodb]
--non_index_updates=N Number of UPDATE non-index queries per transaction [1]
--table_size=N Number of rows per table [10000]
--pgsql_variant=STRING Use this PostgreSQL variant when running with the PostgreSQL driver. The only currently supported variant is 'redshift'. When enabled, create_secondary is automatically disabled, and delete_inserts is set to 0
--simple_ranges=N Number of simple range SELECT queries per transaction [1]
--order_ranges=N Number of SELECT ORDER BY queries per transaction [1]
--range_selects[=on|off] Enable/disable all range SELECT queries [on]
--point_selects=N Number of point SELECT queries per transaction [10]Sekali lagi, kita akan membahas opsi yang paling penting dari sini. Pertama-tama, Anda memiliki kendali atas bagaimana tepatnya suatu transaksi akan terlihat. Secara umum, ini terdiri dari berbagai jenis kueri - INSERT, DELETE, berbagai jenis SELECT (pencarian titik, rentang, agregasi) dan UPDATE (diindeks, tidak diindeks). Menggunakan variabel seperti:
--distinct_ranges=N Number of SELECT DISTINCT queries per transaction [1]
--sum_ranges=N Number of SELECT SUM() queries per transaction [1]
--index_updates=N Number of UPDATE index queries per transaction [1]
--delete_inserts=N Number of DELETE/INSERT combinations per transaction [1]
--non_index_updates=N Number of UPDATE non-index queries per transaction [1]
--simple_ranges=N Number of simple range SELECT queries per transaction [1]
--order_ranges=N Number of SELECT ORDER BY queries per transaction [1]
--point_selects=N Number of point SELECT queries per transaction [10]
--range_selects[=on|off] Enable/disable all range SELECT queries [on]Anda dapat menentukan seperti apa tampilan transaksi. Seperti yang Anda lihat dengan melihat nilai default, sebagian besar kueri adalah SELECT - terutama pemilihan titik tetapi juga berbagai jenis SELECT rentang (Anda dapat menonaktifkan semuanya dengan menyetel range_selects ke nonaktif). Anda dapat mengubah beban kerja menjadi beban kerja tulis yang lebih berat dengan meningkatkan jumlah pembaruan atau kueri INSERT/DELETE. Dimungkinkan juga untuk mengubah pengaturan yang terkait dengan indeks sekunder, kenaikan otomatis tetapi juga ukuran kumpulan data (jumlah tabel dan berapa banyak baris yang harus dimiliki masing-masing). Ini memungkinkan Anda menyesuaikan beban kerja dengan cukup baik.
--skip_trx[=on|off] Don't start explicit transactions and execute all queries in the AUTOCOMMIT mode [off]Ini adalah pengaturan lain, cukup penting ketika bekerja dengan proxy. Secara default, SysBench akan mencoba mengeksekusi kueri dalam transaksi eksplisit. Dengan cara ini kumpulan data akan tetap konsisten dan tidak terpengaruh:SysBench akan, misalnya, mengeksekusi INSERT dan DELETE pada baris yang sama, memastikan kumpulan data tidak akan bertambah (mempengaruhi kemampuan Anda untuk mereproduksi hasil). Namun, proxy akan memperlakukan transaksi eksplisit secara berbeda - semua kueri yang dieksekusi dalam suatu transaksi harus dieksekusi pada host yang sama, sehingga menghilangkan kemampuan untuk menskalakan beban kerja. Harap diingat bahwa menonaktifkan transaksi akan menghasilkan kumpulan data yang menyimpang dari titik awal. Ini juga dapat memicu beberapa masalah seperti kesalahan kunci duplikat atau semacamnya. Untuk dapat menonaktifkan transaksi, Anda mungkin juga ingin melihat:
--mysql-ignore-errors=[LIST,...] list of errors to ignore, or "all" [1213,1020,1205]Pengaturan ini memungkinkan Anda untuk menentukan kode kesalahan dari MySQL yang harus diabaikan SysBench (dan tidak mematikan koneksi). Misalnya, untuk mengabaikan kesalahan seperti:error 1062 (Entri duplikat '6' untuk kunci 'PRIMARY'), Anda harus meneruskan kode kesalahan ini:--mysql-ignore-errors=1062
Yang juga penting, setiap tolok ukur harus menyajikan cara untuk menyediakan kumpulan data untuk pengujian, menjalankannya, dan kemudian membersihkannya setelah pengujian selesai. Ini dilakukan dengan menggunakan perintah 'persiapkan', 'jalankan' dan 'pembersihan'. Kami akan menunjukkan bagaimana ini dilakukan di bagian berikutnya.
Contoh
Di bagian ini kita akan membahas beberapa contoh kegunaan SysBench. Seperti yang disebutkan sebelumnya, kami akan fokus pada dua tolok ukur paling populer - OLTP hanya baca dan OLTP baca/tulis. Terkadang mungkin masuk akal untuk menggunakan tolok ukur lain, tetapi setidaknya kami dapat menunjukkan kepada Anda bagaimana keduanya dapat disesuaikan.
Pencarian Kunci Utama
Pertama-tama, kita harus memutuskan benchmark mana yang akan kita jalankan, read-only atau read-write. Secara teknis tidak ada bedanya karena kami dapat menghapus penulisan dari benchmark R/W. Mari kita fokus pada yang hanya-baca.
Sebagai langkah pertama, kita harus menyiapkan kumpulan data. Kita perlu memutuskan seberapa besar seharusnya. Untuk tolok ukur khusus ini, menggunakan pengaturan default (jadi, indeks sekunder dibuat), 1 juta baris akan menghasilkan ~240 MB data. Sepuluh tabel, 1000 000 baris masing-masing sama dengan 2,4 GB:
[email protected]:~# du -sh /var/lib/mysql/sbtest/
2.4G /var/lib/mysql/sbtest/
[email protected]:~# ls -alh /var/lib/mysql/sbtest/
total 2.4G
drwxr-x--- 2 mysql mysql 4.0K Jun 1 12:12 .
drwxr-xr-x 6 mysql mysql 4.0K Jun 1 12:10 ..
-rw-r----- 1 mysql mysql 65 Jun 1 12:08 db.opt
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:12 sbtest10.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:12 sbtest10.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest1.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest1.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest2.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest2.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest3.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest3.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:10 sbtest4.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:10 sbtest4.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest5.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest5.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest6.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest6.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest7.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest7.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:11 sbtest8.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:11 sbtest8.ibd
-rw-r----- 1 mysql mysql 8.5K Jun 1 12:12 sbtest9.frm
-rw-r----- 1 mysql mysql 240M Jun 1 12:12 sbtest9.ibdIni akan memberi Anda gambaran berapa banyak tabel yang Anda inginkan dan seberapa besar seharusnya. Katakanlah kita ingin menguji beban kerja dalam memori sehingga kita ingin membuat tabel yang sesuai dengan kumpulan buffer InnoDB. Di sisi lain, kami juga ingin memastikan ada cukup tabel untuk tidak menjadi hambatan (atau, bahwa jumlah tabel sesuai dengan yang Anda harapkan dalam pengaturan produksi Anda). Mari kita siapkan dataset kita. Harap diingat bahwa, secara default, SysBench mencari skema 'sbtest' yang harus ada sebelum Anda menyiapkan kumpulan data. Anda mungkin harus membuatnya secara manual.
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=4 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 prepare
sysbench 1.1.0-2e6b7d5 (using bundled LuaJIT 2.1.0-beta3)
Initializing worker threads...
Creating table 'sbtest2'...
Creating table 'sbtest3'...
Creating table 'sbtest4'...
Creating table 'sbtest1'...
Inserting 1000000 records into 'sbtest2'
Inserting 1000000 records into 'sbtest4'
Inserting 1000000 records into 'sbtest3'
Inserting 1000000 records into 'sbtest1'
Creating a secondary index on 'sbtest2'...
Creating a secondary index on 'sbtest3'...
Creating a secondary index on 'sbtest1'...
Creating a secondary index on 'sbtest4'...
Creating table 'sbtest6'...
Inserting 1000000 records into 'sbtest6'
Creating table 'sbtest7'...
Inserting 1000000 records into 'sbtest7'
Creating table 'sbtest5'...
Inserting 1000000 records into 'sbtest5'
Creating table 'sbtest8'...
Inserting 1000000 records into 'sbtest8'
Creating a secondary index on 'sbtest6'...
Creating a secondary index on 'sbtest7'...
Creating a secondary index on 'sbtest5'...
Creating a secondary index on 'sbtest8'...
Creating table 'sbtest10'...
Inserting 1000000 records into 'sbtest10'
Creating table 'sbtest9'...
Inserting 1000000 records into 'sbtest9'
Creating a secondary index on 'sbtest10'...
Creating a secondary index on 'sbtest9'...Setelah kita memiliki data kita, mari kita siapkan perintah untuk menjalankan tes. Kami ingin menguji pencarian Kunci Utama oleh karena itu kami akan menonaktifkan semua jenis SELECT lainnya. Kami juga akan menonaktifkan pernyataan yang disiapkan karena kami ingin menguji kueri biasa. Kami akan menguji konkurensi rendah, katakanlah 16 utas. Perintah kami mungkin terlihat seperti di bawah ini:
sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 --range_selects=off --db-ps-mode=disable --report-interval=1 runApa yang kami lakukan di sini? Kami menetapkan jumlah utas menjadi 16. Kami memutuskan bahwa kami ingin benchmark kami berjalan selama 300 detik, tanpa batas kueri yang dieksekusi. Kami mendefinisikan konektivitas ke database, jumlah tabel dan ukurannya. Kami juga menonaktifkan semua SELECT rentang, kami juga menonaktifkan pernyataan yang disiapkan. Akhirnya, kami mengatur interval laporan menjadi satu detik. Ini adalah bagaimana contoh keluaran akan terlihat seperti:
[ 297s ] thds: 16 tps: 97.21 qps: 1127.43 (r/w/o: 935.01/0.00/192.41) lat (ms,95%): 253.35 err/s: 0.00 reconn/s: 0.00
[ 298s ] thds: 16 tps: 195.32 qps: 2378.77 (r/w/o: 1985.13/0.00/393.64) lat (ms,95%): 189.93 err/s: 0.00 reconn/s: 0.00
[ 299s ] thds: 16 tps: 178.02 qps: 2115.22 (r/w/o: 1762.18/0.00/353.04) lat (ms,95%): 155.80 err/s: 0.00 reconn/s: 0.00
[ 300s ] thds: 16 tps: 217.82 qps: 2640.92 (r/w/o: 2202.27/0.00/438.65) lat (ms,95%): 125.52 err/s: 0.00 reconn/s: 0.00Setiap detik kami melihat cuplikan statistik beban kerja. Ini cukup berguna untuk dilacak dan diplot - laporan akhir hanya akan memberi Anda rata-rata. Hasil antara akan memungkinkan untuk melacak kinerja setiap detik. Laporan akhir mungkin terlihat seperti di bawah ini:
SQL statistics:
queries performed:
read: 614660
write: 0
other: 122932
total: 737592
transactions: 61466 (204.84 per sec.)
queries: 737592 (2458.08 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
Throughput:
events/s (eps): 204.8403
time elapsed: 300.0679s
total number of events: 61466
Latency (ms):
min: 24.91
avg: 78.10
max: 331.91
95th percentile: 137.35
sum: 4800234.60
Threads fairness:
events (avg/stddev): 3841.6250/20.87
execution time (avg/stddev): 300.0147/0.02Di sini Anda akan menemukan informasi tentang kueri yang dieksekusi dan pernyataan (BEGIN/COMMIT) lainnya. Anda akan mempelajari berapa banyak transaksi yang dieksekusi, berapa banyak kesalahan yang terjadi, berapa throughputnya, dan total waktu yang telah berlalu. Anda juga dapat memeriksa metrik latensi dan distribusi kueri di seluruh rangkaian pesan.
Jika kami tertarik pada distribusi latensi, kami juga dapat meneruskan argumen '--histogram' ke SysBench. Ini menghasilkan output tambahan seperti di bawah ini:
Latency histogram (values are in milliseconds)
value ------------- distribution ------------- count
29.194 |****** 1
30.815 |****** 1
31.945 |*********** 2
33.718 |****** 1
34.954 |*********** 2
35.589 |****** 1
37.565 |*********************** 4
38.247 |****** 1
38.942 |****** 1
39.650 |*********** 2
40.370 |*********** 2
41.104 |***************** 3
41.851 |***************************** 5
42.611 |***************** 3
43.385 |***************** 3
44.173 |*********** 2
44.976 |**************************************** 7
45.793 |*********************** 4
46.625 |*********** 2
47.472 |***************************** 5
48.335 |**************************************** 7
49.213 |*********** 2
50.107 |********************************** 6
51.018 |*********************** 4
51.945 |**************************************** 7
52.889 |***************** 3
53.850 |***************** 3
54.828 |*********************** 4
55.824 |*********** 2
57.871 |*********** 2
58.923 |*********** 2
59.993 |****** 1
61.083 |****** 1
63.323 |*********** 2
66.838 |****** 1
71.830 |****** 1Setelah kami mendapatkan hasil yang baik, kami dapat membersihkan data:
sysbench /root/sysbench/src/lua/oltp_read_only.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=10 --table-size=1000000 --range_selects=off --db-ps-mode=disable --report-interval=1 cleanupLalu lintas padat tulis
Mari kita bayangkan di sini bahwa kita ingin menjalankan beban kerja tulis-berat (tetapi tidak hanya menulis) dan, misalnya, menguji kinerja subsistem I/O. Pertama-tama, kita harus memutuskan seberapa besar dataset seharusnya. Kami akan mengasumsikan ~48GB data (masing-masing 20 tabel, 10 000 000 baris). Kita perlu mempersiapkannya. Kali ini kita akan menggunakan benchmark read-write.
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=20 --table-size=10000000 prepareSetelah ini selesai, kita dapat mengubah default untuk memaksa lebih banyak penulisan ke dalam campuran kueri:
[email protected]:~# sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=16 --events=0 --time=300 --mysql-host=10.0.0.126 --mysql-user=sbtest --mysql-password=pass --mysql-port=3306 --tables=20 --delete_inserts=10 --index_updates=10 --non_index_updates=10 --table-size=10000000 --db-ps-mode=disable --report-interval=1 runSeperti yang dapat Anda lihat dari hasil antara, transaksi sekarang berada di sisi yang berat:
[ 5s ] thds: 16 tps: 16.99 qps: 946.31 (r/w/o: 231.83/680.50/33.98) lat (ms,95%): 1258.08 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 16 tps: 17.01 qps: 955.81 (r/w/o: 223.19/698.59/34.03) lat (ms,95%): 1032.01 err/s: 0.00 reconn/s: 0.00
[ 7s ] thds: 16 tps: 12.00 qps: 698.91 (r/w/o: 191.97/482.93/24.00) lat (ms,95%): 1235.62 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 16 tps: 14.01 qps: 683.43 (r/w/o: 195.12/460.29/28.02) lat (ms,95%): 1533.66 err/s: 0.00 reconn/s: 0.00Memahami hasilnya
Seperti yang kami tunjukkan di atas, SysBench adalah alat hebat yang dapat membantu menunjukkan dengan tepat beberapa masalah kinerja MySQL atau MariaDB. Ini juga dapat digunakan untuk penyetelan awal konfigurasi database Anda. Tentu saja, Anda harus ingat bahwa, untuk mendapatkan hasil terbaik dari tolok ukur Anda, Anda harus memahami mengapa hasil terlihat seperti itu. Ini akan membutuhkan wawasan tentang metrik internal MySQL menggunakan alat pemantauan, misalnya, ClusterControl. Ini cukup penting untuk diingat - jika Anda tidak mengerti mengapa kinerjanya seperti itu, Anda mungkin menarik kesimpulan yang salah dari tolok ukur. Selalu ada hambatan, dan SysBench dapat membantu meningkatkan masalah kinerja, yang kemudian harus Anda identifikasi.
