Praktik terbaik untuk performa optimal
Azure Managed Instance for Apache Cassandra adalah layanan terkelola penuh untuk kluster Apache Cassandra sumber terbuka murni. Layanan ini juga memungkinkan konfigurasi untuk ditimpa, tergantung pada kebutuhan spesifik setiap beban kerja, memungkinkan fleksibilitas dan kontrol maksimum jika diperlukan. Artikel ini menyediakan tips tentang cara mengoptimalkan performa.
Penyiapan dan konfigurasi optimal
Faktor replikasi, jumlah disk, jumlah simpul, dan SKU
Karena Azure mendukung tiga zona ketersediaan di sebagian besar wilayah, dan Instans Terkelola Cassandra memetakan zona ketersediaan ke rak, sebaiknya pilih kunci partisi dengan kardinalitas tinggi untuk menghindari partisi panas. Untuk tingkat keandalan dan toleransi kesalahan terbaik, kami sangat menyarankan untuk mengonfigurasi faktor replikasi 3. Sebaiknya tentukan kelipatan faktor replikasi sebagai jumlah simpul, misalnya 3, 6, 9, dll.
Kami menggunakan RAID 0 atas jumlah disk yang Anda provisikan. Jadi untuk mendapatkan IOPS optimal, Anda perlu memeriksa IOPS maksimum pada SKU yang telah Anda pilih bersama dengan IOPS disk P30. Misalnya, Standard_DS14_v2 SKU mendukung 51.200 IOPS yang tidak di-cache, sedangkan satu disk P30 memiliki performa dasar 5.000 IOPS. Jadi, empat disk akan menyebabkan 20.000 IOPS, yang jauh di bawah batas komputer.
Kami sangat menyarankan tolok ukur ekstensif beban kerja Anda terhadap SKU dan jumlah disk. Tolok ukur sangat penting dalam kasus SKU hanya dengan delapan inti. Penelitian kami menunjukkan bahwa delapan CPU inti hanya berfungsi untuk beban kerja yang paling tidak menuntut, dan sebagian besar beban kerja membutuhkan minimal 16 inti untuk berkinerja.
Beban kerja Analitik vs. Transaksional
Beban kerja transaksi biasanya memerlukan pusat data yang dioptimalkan untuk latensi rendah, sementara beban kerja analitis sering menggunakan kueri yang lebih kompleks, yang membutuhkan waktu lebih lama untuk dijalankan. Dalam kebanyakan kasus, Anda ingin pusat data terpisah:
- Satu dioptimalkan untuk latensi rendah
- Satu dioptimalkan untuk beban kerja analitik
Mengoptimalkan beban kerja analitik
Sebaiknya pelanggan menerapkan pengaturan berikut cassandra.yaml untuk beban kerja analitis (lihat di sini tentang cara menerapkan).
Waktu habis
| Nilai | Cassandra MI Default | Rekomendasi untuk beban kerja analitik |
|---|---|---|
| read_request_timeout_in_ms | 5,000 | 10,000 |
| range_request_timeout_in_ms | 10,000 | 20.000 |
| counter_write_request_timeout_in_ms | 5,000 | 10,000 |
| cas_contention_timeout_in_ms | 1,000 | 2.000 |
| truncate_request_timeout_in_ms | 60,000 | 120.000 |
| slow_query_log_timeout_in_ms | 500 | 1,000 |
| roles_validity_in_ms | 2,000 | 120.000 |
| permissions_validity_in_ms | 2,000 | 120.000 |
Penembolokan
| Nilai | Cassandra MI Default | Rekomendasi untuk beban kerja analitik |
|---|---|---|
| file_cache_size_in_mb | 2,048 | 6.144 |
Rekomendasi lainnya
| Nilai | Cassandra MI Default | Rekomendasi untuk beban kerja analitik |
|---|---|---|
| commitlog_total_space_in_mb | 8,192 | 16,384 |
| column_index_size_in_kb | 64 | 16 |
| compaction_throughput_mb_per_sec | 128 | 256 |
Pengaturan klien
Sebaiknya tingkatkan batas waktu driver klien Cassandra sesuai dengan batas waktu yang diterapkan di server.
Mengoptimalkan latensi rendah
Pengaturan default kami sudah cocok untuk beban kerja latensi rendah. Untuk memastikan performa terbaik untuk latensi ekor, sebaiknya gunakan driver klien yang mendukung eksekusi spekulatif dan mengonfigurasi klien Anda. Untuk driver Java V4, Anda dapat menemukan demo yang mengilustrasikan cara kerjanya dan cara mengaktifkan kebijakan di sini.
Pemantauan untuk leher botol performa
Performa CPU
Seperti setiap sistem database, Cassandra bekerja paling baik jika pemanfaatan CPU sekitar 50% dan tidak pernah di atas 80%. Anda dapat melihat metrik CPU di tab Metrik dalam Pemantauan dari portal:
Jika CPU secara permanen di atas 80% untuk sebagian besar simpul database menjadi manifes kelebihan beban dalam beberapa batas waktu klien. Dalam skenario ini, sebaiknya lakukan tindakan berikut:
- meningkatkan skala secara vertikal ke SKU dengan lebih banyak inti CPU (terutama jika intinya hanya 8 atau kurang).
- skala horizontal dengan menambahkan lebih banyak simpul (seperti yang disebutkan sebelumnya, jumlah simpul harus kelipatan faktor replikasi).
Jika CPU hanya tinggi untuk beberapa simpul, tetapi rendah untuk yang lain, itu menunjukkan partisi panas dan perlu penyelidikan lebih lanjut.
Catatan
Mengubah SKU didukung melalui Portal Microsoft Azure, Azure CLI, dan penyebaran templat ARM. Anda dapat menyebarkan/mengedit templat ARM, dan mengganti SKU dengan salah satu hal berikut ini.
- Standard_E8s_v4
- Standard_E16s_v4
- Standard_E20s_v4
- Standard_E32s_v4
- Standard_DS13_v2
- Standard_DS14_v2
- Standard_D8s_v4
- Standard_D16s_v4
- Standard_D32s_v4
- Standard_L8s_v3
- Standard_L16s_v3
- Standard_L32s_v3
- Standard_L8as_v3
- Standard_L16as_v3
- Standard_L32as_v3
Harap dicatat bahwa saat ini, kami tidak mendukung transisi di seluruh keluarga SKU. Misalnya, jika saat ini Anda memiliki Standard_DS13_v2 dan tertarik untuk meningkatkan ke SKU yang lebih besar seperti Standard_DS14_v2, opsi ini tidak tersedia. Namun, Anda dapat membuka tiket dukungan untuk meminta peningkatan ke SKU yang lebih tinggi.
Performa disk
Layanan ini berjalan pada disk terkelola Azure P30, yang memungkinkan "burst IOPS". Pemantauan yang cermat diperlukan ketika datang ke hambatan performa terkait disk. Dalam hal ini, penting untuk meninjau metrik IOPS:
Jika metrik menunjukkan satu atau semua karakteristik berikut, metrik dapat menunjukkan bahwa Anda perlu meningkatkan skala.
- Secara konsisten lebih tinggi dari atau sama dengan IOPS dasar (ingatlah untuk mengalikan 5.000 IOPS dengan jumlah disk per simpul untuk mendapatkan angka).
- Secara konsisten lebih tinggi dari atau sama dengan IOPS maksimum yang diizinkan untuk SKU untuk penulisan.
- SKU Anda mendukung penyimpanan cache (write-through-cache) dan jumlah ini lebih kecil dari IOPS dari disk terkelola (ini akan menjadi batas atas untuk IOPS baca Anda).
Jika Anda hanya melihat IOPS yang ditingkatkan untuk beberapa simpul, Anda mungkin memiliki partisi panas dan perlu meninjau data Anda untuk potensi ke condong.
Jika IOPS Anda lebih rendah dari apa yang didukung oleh SKU yang dipilih, tetapi lebih tinggi atau sama dengan IOPS disk, Anda dapat mengambil tindakan berikut:
- Tambahkan lebih banyak disk untuk meningkatkan performa. Meningkatkan disk memerlukan kasus dukungan untuk dinaikkan.
- Tingkatkan skala pusat data dengan menambahkan lebih banyak simpul.
Jika IOPS Anda memaksimalkan apa yang didukung SKU Anda, Anda dapat:
- meningkatkan skala ke SKU yang berbeda yang mendukung lebih banyak IOPS.
- Tingkatkan skala pusat data dengan menambahkan lebih banyak simpul.
Untuk informasi selengkapnya, lihat Komputer Virtual dan performa disk.
Performa jaringan
Dalam kebanyakan kasus, performa jaringan cukup. Namun, jika Anda sering melakukan streaming data (seperti sering meningkatkan/menurunkan skala horizontal) atau ada pergerakan data masuk/keluar yang besar, ini bisa menjadi masalah. Anda mungkin perlu mengevaluasi performa jaringan SKU Anda. Misalnya, Standard_DS14_v2 SKU mendukung 12.000 Mb/dtk, bandingkan ini dengan byte-in/out dalam metrik:
Jika Anda hanya melihat jaringan yang ditingkatkan untuk beberapa simpul, Anda mungkin memiliki partisi panas dan perlu meninjau distribusi data dan/atau pola akses Anda untuk potensi ke condong.
- Meningkatkan skala secara vertikal ke SKU yang berbeda yang mendukung lebih banyak I/O jaringan.
- Tingkatkan kluster secara horizontal dengan menambahkan lebih banyak simpul.
Terlalu banyak klien yang terhubung
Penyebaran harus direncanakan dan disediakan untuk mendukung jumlah maksimum permintaan paralel yang diperlukan untuk latensi aplikasi yang diinginkan. Untuk penyebaran tertentu, memperkenalkan lebih banyak beban ke sistem di atas ambang minimum meningkatkan latensi keseluruhan. Pantau jumlah klien yang terhubung untuk memastikan ini tidak melebihi batas yang dapat ditoleransi.
Ruang disk
Dalam kebanyakan kasus, ada ruang disk yang cukup karena penyebaran default dioptimalkan untuk IOPS, yang menyebabkan pemanfaatan disk yang rendah. Namun demikian, kami menyarankan untuk meninjau metrik ruang disk sesekali. Cassandra mengumpulkan banyak disk dan kemudian menguranginya ketika pemadatan dipicu. Oleh karena itu penting untuk meninjau penggunaan disk selama periode yang lebih lama untuk menetapkan tren - seperti pemadatan tidak dapat mengatasi ruang.
Catatan
Untuk memastikan ruang yang tersedia untuk pemadatan, pemanfaatan disk harus disimpan hingga sekitar 50%.
Jika Anda hanya melihat perilaku ini untuk beberapa simpul, Anda mungkin memiliki partisi panas dan perlu meninjau distribusi data dan/atau pola akses Anda untuk potensi ke condong.
- tambahkan lebih banyak disk tetapi perhatikan batas IOPS yang diberlakukan oleh SKU Anda
- meningkatkan skala kluster secara horizontal
Memori JVM
Rumus default kami menetapkan setengah memori VM ke JVM dengan batas atas 31 GB - yang dalam kebanyakan kasus adalah keseimbangan yang baik antara performa dan memori. Beberapa beban kerja, terutama yang sering membaca lintas partisi atau pemindaian rentang mungkin ditantang memori.
Dalam kebanyakan kasus memori direklamasi secara efektif oleh pengumpul sampah Java, tetapi terutama jika CPU sering di atas 80% tidak ada cukup siklus CPU untuk pengumpul sampah yang tersisa. Jadi setiap masalah performa CPU harus diatasi sebelum masalah memori.
Jika CPU mengambang di bawah 70%, dan pengumpulan sampah tidak dapat mengklaim kembali memori, Anda mungkin memerlukan lebih banyak memori JVM. Ini terutama terjadi jika Anda menggunakan SKU dengan memori terbatas. Dalam kebanyakan kasus, Anda perlu meninjau kueri dan pengaturan klien dan mengurangi fetch_size bersama dengan apa yang dipilih dalam limit kueri CQL Anda.
Jika Anda memang membutuhkan lebih banyak memori, Anda dapat:
- Ajukan tiket kepada kami untuk meningkatkan pengaturan memori JVM untuk Anda
- Menskalakan secara vertikal ke SKU yang memiliki lebih banyak memori yang tersedia
Batu Nisan
Kami menjalankan perbaikan setiap tujuh hari dengan reaper, yang menghapus baris yang TTL-nya telah kedaluwarsa (disebut "batu nisan"). Beberapa beban kerja memiliki penghapusan yang lebih sering dan melihat peringatan seperti Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) di log Cassandra, atau bahkan kesalahan yang menunjukkan bahwa kueri tidak dapat dipenuhi karena batu nisan yang berlebihan.
Mitigasi jangka pendek jika kueri tidak terpenuhi adalah meningkatkan tombstone_failure_threshold dalam konfigurasi Cassandra dari default 100.000 ke nilai yang lebih tinggi.
Selain itu, sebaiknya tinjau TTL pada keyspace dan berpotensi menjalankan perbaikan setiap hari untuk membersihkan lebih banyak batu nisan. Jika TTL pendek, misalnya kurang dari dua hari, dan aliran data masuk dan dihapus dengan cepat, sebaiknya tinjau strategi pemadatan dan mendukung Leveled Compaction Strategy. Dalam beberapa kasus, tindakan tersebut mungkin merupakan indikasi bahwa peninjauan model data diperlukan.
Peringatan batch
Anda mungkin mengalami peringatan ini di CassandraLogs dan kegagalan yang berpotensi terkait:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
Dalam hal ini, Anda harus meninjau kueri Anda untuk tetap berada di bawah ukuran batch yang direkomendasikan. Dalam kasus yang jarang terjadi dan sebagai mitigasi jangka pendek Anda dapat meningkatkan batch_size_fail_threshold_in_kbkonfigurasi Cassandra dari default 50 ke nilai yang lebih tinggi.
Peringatan partisi besar
Anda mungkin mengalami peringatan ini di CassandraLogs:
Writing large partition <table> (105.426MiB) to sstable <file>
Ini menunjukkan masalah dalam model data. Berikut adalah artikel luapan tumpukan yang masuk ke detail selengkapnya. Hal ini dapat menyebabkan masalah performa yang parah dan perlu ditangani.
Pengoptimalan khusus
Kompresi
Cassandra memungkinkan pemilihan algoritma kompresi yang sesuai ketika tabel dibuat (lihat Kompresi) Defaultnya adalah LZ4, yang sangat baik untuk throughput dan CPU tetapi mengonsumsi lebih banyak ruang pada disk. Menggunakan Zstd (Cassandra 4.0 ke atas) menghemat sekitar ~ 12% ruang dengan overhead CPU minimal.
Mengoptimalkan ruang timbunan yang dapat diingat
Default kami adalah menggunakan 1/4 dari tumpukan JVM untuk memtable_heap_space di cassandra.yaml. Untuk aplikasi berorientasi tulis dan/atau pada SKU dengan memori kecil, ini dapat menyebabkan seringnya pembilasan dan stabil terfragmentasi sehingga membutuhkan lebih banyak pemadatan. Dalam kasus seperti itu meningkat, setidaknya 4048 mungkin bermanfaat tetapi memerlukan tolok ukur yang cermat untuk memastikan operasi lain (misalnya, bacaan) tidak terpengaruh.
Langkah berikutnya
Dalam artikel ini, kami meletakkan beberapa praktik terbaik untuk performa optimal. Sekarang, Anda dapat mulai bekerja menggunakan kluster: