Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Azure Managed Instance for Apache Cassandra adalah layanan terkelola penuh untuk kluster Apache Cassandra sumber terbuka murni. Layanan ini juga memungkinkan konfigurasi untuk diganti, tergantung pada kebutuhan spesifik setiap beban kerja. Fitur ini 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 tingkat produk
Azure mendukung tiga zona ketersediaan di sebagian besar wilayah. Azure Managed Instance for Apache Cassandra memetakan zona ketersediaan ke rak. Kami menyarankan agar Anda memilih kunci partisi dengan kardinalitas tinggi untuk menghindari partisi panas. Untuk tingkat keandalan dan toleransi kesalahan terbaik, kami sangat menyarankan Anda mengonfigurasi faktor replikasi 3. Kami juga menyarankan agar Anda menentukan kelipatan faktor replikasi sebagai jumlah simpul. Misalnya, gunakan 3, 6, 9, dll.
Azure menggunakan RAID 0 atas jumlah disk yang Anda provisikan. Untuk mendapatkan operasi input/output yang optimal per detik (IOPS), periksa IOPS maksimum pada tingkatan produk yang Anda pilih bersama dengan IOPS dari disk P30. Misalnya, Standard_DS14_v2 tingkat produk mendukung 51.200 IOPS yang tidak di-cache. Satu disk P30 memiliki performa dasar 5.000 IOPS. Empat disk menghasilkan 20.000 IOPS, yang jauh di bawah batas mesin.
Kami sangat menyarankan pengujian tolok ukur ekstensif beban kerja Anda terhadap tingkatan produk dan jumlah disk. Tolok ukur sangat penting untuk tingkat produk dengan hanya delapan inti. Penelitian kami menunjukkan bahwa CPU delapan inti hanya berfungsi untuk beban kerja yang paling tidak menuntut. Sebagian besar beban kerja membutuhkan minimal 16 core untuk berkinerja dengan benar.
Beban kerja analitik vs. transaksional
Beban kerja transaksi biasanya memerlukan pusat data yang dioptimalkan untuk latensi rendah. Beban kerja analitis sering menggunakan kueri yang lebih kompleks, yang membutuhkan waktu lebih lama untuk dijalankan. Dalam kebanyakan kasus, Anda ingin memisahkan pusat data dengan:
- Satu dioptimalkan untuk latensi rendah.
- Satu yang dioptimalkan untuk beban kerja analitis.
Mengoptimalkan beban kerja analitik
Kami menyarankan agar Anda menerapkan pengaturan berikut cassandra.yaml untuk beban kerja analitis. Untuk informasi selengkapnya tentang cara menerapkan pengaturan ini, lihat Memperbarui konfigurasi Cassandra.
Waktu habis
| Nilai | Default Cassandra MI | 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 | Default Cassandra MI | Rekomendasi untuk beban kerja analitik |
|---|---|---|
file_cache_size_in_mb |
2,048 | 6.144 |
Rekomendasi lainnya
| Nilai | Default Cassandra MI | 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
Kami menyarankan agar Anda meningkatkan batas waktu driver klien Cassandra sesuai dengan batas waktu yang diterapkan di server.
Optimalkan untuk latensi rendah
Pengaturan default kami sudah cocok untuk beban kerja latensi rendah. Untuk memastikan performa terbaik untuk latensi ekor, kami sangat menyarankan Anda menggunakan driver client yang mendukung eksekusi spekulatif dan mengonfigurasi klien Anda sesuai. Untuk driver Java V4, demo menggambarkan cara kerja proses ini dan cara mengaktifkan kebijakan dalam sampel ini.
Awasi hambatan performa
Performa CPU
Seperti setiap sistem database, Cassandra bekerja paling baik jika pemanfaatan CPU sekitar 50% dan tidak pernah di atas 80%. Untuk melihat metrik CPU, dari portal Microsoft Azure, di bawah bagian Pemantauan , buka tab Metrik .
Untuk tampilan CPU realistis, tambahkan filter dan gunakan Usage kind=usage_idle untuk memisahkan properti. Jika nilai ini lebih rendah dari 20%, terapkan pemisahan untuk mendapatkan penggunaan oleh semua jenisnya.
Jika CPU secara permanen di atas 80% untuk sebagian besar simpul, database menjadi kelebihan beban, yang bermanifestasi dalam beberapa batas waktu klien. Dalam skenario ini, kami sarankan Anda mengambil tindakan berikut:
- Skalakan secara vertikal ke tingkat produk dengan lebih banyak inti CPU, terutama jika intinya hanya 8 atau kurang.
- Skala secara horizontal dengan menambahkan lebih banyak node. Seperti disebutkan sebelumnya, jumlah simpul harus menjadi kelipatan faktor replikasi.
Jika CPU tinggi hanya untuk beberapa node, tetapi rendah untuk yang lain, itu menunjukkan partisi panas. Skenario ini perlu penyelidikan lebih lanjut.
Mengubah tingkat produk didukung dengan menggunakan portal Microsoft Azure, Azure CLI, dan penyebaran templat Azure Resource Manager (templat ARM). Anda dapat menyebarkan atau mengedit templat ARM dan mengganti tingkat produk dengan salah satu nilai berikut:
Standard_E8s_v4Standard_E16s_v4Standard_E20s_v4Standard_E32s_v4Standard_DS13_v2Standard_DS14_v2Standard_D8s_v4Standard_D16s_v4Standard_D32s_v4Standard_L8s_v3Standard_L16s_v3Standard_L32s_v3Standard_L8as_v3Standard_L16as_v3Standard_L32as_v3
Saat ini, kami tidak mendukung transisi di seluruh keluarga produk. Misalnya, jika saat ini Anda memiliki Standard_DS13_v2 dan ingin meningkatkan ke produk yang lebih besar, seperti Standard_DS14_v2, opsi ini tidak tersedia. Buka tiket dukungan untuk meminta peningkatan ke produk yang lebih tinggi.
Performa disk
Layanan ini berjalan pada disk terkelola Azure P30, yang memungkinkan burst IOPS. Pemantauan yang cermat diperlukan dalam hal kemacetan performa yang berhubungan dengan disk. Dalam hal ini, penting untuk meninjau metrik IOPS.
Jika metrik menunjukkan satu atau semua karakteristik berikut, Anda mungkin perlu meningkatkan skala:
- Metrik Anda secara konsisten lebih tinggi dari atau sama dengan IOPS dasar. Ingatlah untuk mengalikan 5.000 IOPS dengan jumlah disk per simpul untuk mendapatkan angkanya.
- Metrik Anda secara konsisten lebih tinggi dari atau sama dengan IOPS maksimum yang diizinkan untuk level produk untuk operasi penulisan.
- Tingkat produk Anda mendukung penyimpanan cache (cache write-through), dan jumlah ini lebih kecil dari IOPS dari disk terkelola. Nilai ini adalah batas atas untuk IOPS baca Anda.
Jika Anda melihat IOPS meningkat hanya untuk beberapa simpul, Anda mungkin memiliki partisi yang panas dan perlu meninjau data Anda untuk potensi ketidakseimbangan.
Jika IOPS Anda lebih rendah dari apa yang didukung tingkat produk Anda, tetapi lebih tinggi atau sama dengan IOPS disk, lakukan tindakan berikut:
- Tambahkan lebih banyak simpul untuk meningkatkan pusat data.
Jika IOPS Anda mencapai batas atas yang didukung tingkat produk Anda, Anda dapat:
- Tingkatkan skala ke tingkat produk yang berbeda yang mendukung lebih banyak IOPS.
- Tambahkan lebih banyak simpul untuk meningkatkan pusat data.
Untuk informasi selengkapnya, lihat Komputer virtual dan performa disk.
Performa jaringan
Biasanya, performa jaringan cukup. Jika Anda sering melakukan streaming data, seperti sering meningkatkan/menurunkan skala horizontal, atau ada pergerakan data masuk/keluar yang besar, performa ini bisa menjadi masalah. Anda mungkin perlu mengevaluasi performa jaringan tingkat produk Anda. Misalnya, Standard_DS14_v2 lapisan produk mendukung 12.000 Mb/s. Bandingkan nilai ini dengan byte-in/out dalam metrik.
Jika Anda melihat jaringan yang ditingkatkan hanya untuk beberapa simpul, Anda mungkin memiliki partisi panas. Tinjau distribusi data dan pola aksesnya untuk potensi ketidakseimbangan.
- Tingkatkan skala vertikal ke tingkat produk yang berbeda dengan mendukung lebih banyak I/O jaringan.
- Tingkatkan kluster secara horizontal dengan menambahkan lebih banyak simpul.
Terlalu banyak klien yang terhubung
Rencanakan dan sediakan penyebaran 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 bahwa situasi ini tidak melebihi batas yang dapat ditoleransi.
Ruang disk
Dalam kebanyakan kasus, ada ruang disk yang cukup. Penyebaran default dioptimalkan untuk IOPS, yang menyebabkan pemanfaatan disk yang rendah. Namun demikian, kami sarankan Anda sesekali meninjau metrik ruang disk. Cassandra mengumpulkan banyak disk dan kemudian menguranginya ketika pemadatan dipicu. Penting untuk meninjau pemakaian disk selama periode yang lebih lama untuk menetapkan tren, seperti ketika pemadatan tidak dapat memulihkan ruang.
Catatan
Untuk memastikan ruang yang tersedia untuk pemadatan, jaga penggunaan disk hingga sekitar 50%.
Jika Anda melihat perilaku ini hanya untuk beberapa simpul, Anda mungkin memiliki partisi panas. Tinjau distribusi data dan pola aksesnya untuk potensi ketidakseimbangan.
- Tambahkan lebih banyak disk, tetapi perhatikan batas IOPS yang diberlakukan oleh tingkat produk Anda.
- Meningkatkan skala kluster secara horizontal.
Memori JVM
Rumus default kami menetapkan setengah memori komputer virtual ke Java Virtual Machine (JVM) dengan batas atas 31 GB. Dalam kebanyakan kasus, pendekatan ini adalah keseimbangan yang baik antara performa dan memori. Beberapa tugas kerja, terutama yang sering membutuhkan pembacaan lintas partisi atau pemindaian rentang, mungkin mengalami tantangan memori.
Dalam kebanyakan kasus, memori dapat dikembalikan secara efektif oleh pengumpul sampah Java. Jika CPU sering di atas 80%, maka tidak ada cukup siklus CPU yang tersedia untuk pengumpul sampah. Atasi masalah performa CPU sebelum Anda memeriksa masalah memori apa pun.
Jika CPU berada di bawah 70% dan pengumpulan sampah tidak dapat mengembalikan memori, Anda mungkin memerlukan lebih banyak kapasitas memori JVM. Lebih banyak memori JVM mungkin diperlukan jika Anda berada di tingkat produk dengan memori terbatas. Dalam kebanyakan kasus, Anda perlu meninjau kueri serta pengaturan klien Anda, dan mengurangi fetch_size bersama dengan pilihan dalam limit di kueri Cassandra Query Language (CQL) Anda.
Jika Anda membutuhkan lebih banyak memori, Anda dapat:
- Tingkatkan secara vertikal ke tingkat produk yang menawarkan lebih banyak memori.
Batu Nisan
Kami melakukan pemeliharaan setiap tujuh hari dengan menggunakan reaper, yang menghapus baris yang waktu hidupnya (TTL) kedaluwarsa. Baris-baris ini disebut batu nisan. Beberapa beban kerja lebih sering dihapus dan menampilkan peringatan seperti Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) di log Cassandra. Beberapa kesalahan menunjukkan bahwa kueri tidak dapat dipenuhi karena batu nisan yang berlebihan.
Mitigasi jangka pendek jika kueri tidak terpenuhi adalah meningkatkan tombstone_failure_threshold nilai dalam konfigurasi Cassandra dari default 100.000 ke nilai yang lebih tinggi.
Kami juga menyarankan agar Anda meninjau TTL pada keyspace dan berpotensi menjalankan perbaikan setiap hari untuk menghapus lebih banyak batu nisan. Jika TTL pendek (misalnya, kurang dari dua hari), dan aliran data masuk dan dihapus dengan cepat, kami sarankan Anda meninjau strategi pemadatan dan mendukung Leveled Compaction Strategy. Dalam beberapa kasus, tindakan tersebut mungkin menunjukkan bahwa tinjauan model data diperlukan.
Peringatan batch
Anda mungkin mengalami peringatan berikut di CassandraLogs dan kegagalan yang berpotensi terkait:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
Tinjau kueri Anda untuk tetap berada di bawah ukuran batch yang direkomendasikan. Dalam kasus yang jarang terjadi dan sebagai mitigasi jangka pendek, tingkatkan batch_size_fail_threshold_in_kbkonfigurasi Cassandra dari default 50 ke nilai yang lebih tinggi.
Peringatan partisi besar
Anda mungkin mengalami peringatan berikut di CassandraLogs:
Writing large partition <table> (105.426MiB) to sstable <file>
Pesan ini menunjukkan masalah dalam model data. Untuk informasi selengkapnya, lihat artikel Stack Overflow ini. Masalah ini dapat menyebabkan masalah performa yang parah dan harus diatasi.
Pengoptimalan khusus
Kompresi
Cassandra memungkinkan pemilihan algoritma kompresi yang sesuai saat tabel dibuat. Defaultnya adalah LZ4, yang sangat baik untuk throughput dan CPU tetapi menggunakan lebih banyak ruang pada disk. Menggunakan Zstandard (Cassandra 4.0 ke atas) dapat menghemat sekitar 12% ruang penyimpanan dengan penggunaan CPU yang minimal.
Mengoptimalkan ruang heap memtable
Secara default, digunakan seperempat dari heap JVM untuk memtable_heap_space di dalam file cassandra.yaml. Untuk aplikasi yang berorientasi penulisan atau pada tier produk dengan jumlah memori kecil, masalah ini dapat menyebabkan pengosongan yang sering dan fragmentasi yang membutuhkan lebih banyak pemadatan. Meningkatkan ke setidaknya 4.048 mungkin akan menjadi ide bagus. Pendekatan ini memerlukan tolok ukur yang cermat untuk memastikan bahwa operasi lain (misalnya, bacaan) tidak terpengaruh.