En iyi performans için en iyi yöntemler
Apache Cassandra için Azure Yönetilen Örneği, saf açık kaynak Apache Cassandra kümeleri için tam olarak yönetilen bir hizmettir. Hizmet ayrıca her iş yükünün belirli gereksinimlerine bağlı olarak yapılandırmaların geçersiz kılınmasına olanak tanıyarak gerektiğinde maksimum esneklik ve denetim sağlar. Bu makalede performansı iyileştirmeye yönelik ipuçları sağlanır.
En iyi kurulum ve yapılandırma
Çoğaltma faktörü, disk sayısı, düğüm sayısı ve SKU'lar
Azure desteği çoğu bölgede üç kullanılabilirlik alanı olduğundan ve Cassandra Yönetilen Örneği kullanılabilirlik alanlarını raflarla eşlediğinden, sık erişimli bölümleri önlemek için yüksek kardinaliteye sahip bir bölüm anahtarı seçmenizi öneririz. En iyi güvenilirlik ve hataya dayanıklılık düzeyi için 3 çoğaltma faktörü yapılandırmanızı kesinlikle öneririz. Çoğaltma faktörünün bir katını düğüm sayısı olarak (örneğin 3, 6, 9 vb.) belirtmenizi de öneririz.
Sağladığınız disk sayısı üzerinden RAID 0 kullanırız. Bu nedenle, en uygun IOPS'yi elde etmek için bir P30 diskinin IOPS'siyle birlikte seçtiğiniz SKU'da en yüksek IOPS'yi denetlemeniz gerekir. Örneğin, Standard_DS14_v2 SKU 51.200 uncached IOPS'yi desteklerken, tek bir P30 diskinin temel performansı 5.000 IOPS'dır. Bu nedenle, dört disk 20.000 IOPS'ye yol açabilir ve bu da makinenin sınırlarının çok altındadır.
İş yükünüzün SKU ve disk sayısıyla kapsamlı karşılaştırmasını kesinlikle öneririz. Kıyaslama özellikle yalnızca sekiz çekirdekli SKU'lar için önemlidir. Araştırmamızda sekiz çekirdek CPU'nun yalnızca en az talep gören iş yükleri için çalıştığını ve çoğu iş yükünün en az 16 çekirdeğin performans göstermesi gerektiğini gösteriyor.
Analitik ve İşlemsel iş yükleri karşılaştırması
İşlem iş yükleri genellikle düşük gecikme süresi için iyileştirilmiş bir veri merkezine ihtiyaç duyarken analitik iş yükleri genellikle daha karmaşık sorgular kullanır ve bu sorguların yürütülmesi daha uzun sürer. Çoğu durumda ayrı veri merkezleri isteyebilirsiniz:
- Düşük gecikme süresi için iyileştirilmiş bir tane
- Analitik iş yükleri için iyileştirilmiş bir iş yükü
Analitik iş yüklerini iyileştirme
Müşterilerin analiz iş yükleri için aşağıdaki cassandra.yaml ayarları uygulamasını öneririz (nasıl uygulanacağı konusunda buraya bakın).
Zaman aşımları
| Value | Cassandra MI Varsayılanı | Analitik iş yükü önerisi |
|---|---|---|
| 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 | Kategori 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 |
Önbellekler
| Value | Cassandra MI Varsayılanı | Analitik iş yükü önerisi |
|---|---|---|
| file_cache_size_in_mb | 2,048 | 6144 |
Diğer öneriler
| Value | Cassandra MI Varsayılanı | Analitik iş yükü önerisi |
|---|---|---|
| commitlog_total_space_in_mb | 8,192 | 16,384 |
| column_index_size_in_kb | 64 | 16 |
| compaction_throughput_mb_per_sec | 128 | Kategori 256 |
İstemci ayarları
Sunucuya uygulanan zaman aşımlarına uygun olarak Cassandra istemci sürücüsü zaman aşımlarını artırmanızı öneririz.
Düşük gecikme süresi için iyileştirme
Varsayılan ayarlarımız düşük gecikmeli iş yükleri için zaten uygundur. Kuyruk gecikme sürelerinde en iyi performansı sağlamak için tahmine dayalı yürütmeyi ve istemcinizi uygun şekilde yapılandırmayı destekleyen bir istemci sürücüsü kullanmanızı kesinlikle öneririz. Java V4 sürücüsü için, bunun nasıl çalıştığını ve ilkeyi etkinleştirmeyi gösteren bir tanıtımı burada bulabilirsiniz.
Performans şişesi boyunlarını izleme
CPU performansı
Her veritabanı sistemi gibi Cassandra da CPU kullanımı %50 civarındaysa ve %80'in üzerinde değilse en iyi şekilde çalışır. CPU ölçümlerini portaldan İzleme içindeki Ölçümler sekmesinde görüntüleyebilirsiniz:
CPU çoğu düğüm için kalıcı olarak %80'in üzerindeyse veritabanı birden çok istemci zaman aşımlarında aşırı yüklenir. Bu senaryoda aşağıdaki eylemleri gerçekleştirmenizi öneririz:
- daha fazla CPU çekirdeğine sahip bir SKU'ya dikey olarak ölçeklendirin (özellikle çekirdekler yalnızca 8 veya daha azsa).
- daha fazla düğüm ekleyerek yatay olarak ölçeklendirin (daha önce belirtildiği gibi, düğüm sayısı çoğaltma faktörünün katı olmalıdır).
CPU yalnızca birkaç düğüm için yüksekse ancak diğerleri için düşükse, sık erişimli bir bölüm olduğunu gösterir ve daha fazla araştırma yapılması gerekir.
Not
SKU'nun değiştirilmesi Azure Portal, Azure CLI ve ARM şablonu dağıtımı aracılığıyla desteklenir. ARM şablonunu dağıtabilir/düzenleyebilir ve SKU'yu aşağıdakilerden biriyle değiştirebilirsiniz.
- 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
Şu anda SKU aileleri arasında geçişi desteklemediğimize dikkat edin. Örneğin, şu anda bir Standard_DS13_v2 sahibiyseniz ve gibi Standard_DS14_v2daha büyük bir SKU'ya yükseltmek istiyorsanız bu seçenek kullanılamaz. Ancak, daha yüksek SKU'ya yükseltme isteğinde bulunmak için bir destek bileti açabilirsiniz.
Disk performansı
Hizmet, Azure P30 tarafından yönetilen disklerde çalışır ve bu da "seri IOPS" olanağı sağlar. Diskle ilgili performans sorunları söz konusu olduğunda dikkatli izleme gereklidir. Bu durumda IOPS ölçümlerini gözden geçirmek önemlidir:
Ölçümler aşağıdaki özelliklerden birini veya tümünü gösteriyorsa, ölçeği artırmanız gerektiğini gösterebilir.
- Tutarlı olarak temel IOPS'den daha yüksek veya buna eşit (sayıyı almak için düğüm başına disk sayısıyla 5.000 IOPS'yi çarpmayı unutmayın).
- Yazma işlemleri için SKU için izin verilen en yüksek IOPS'den tutarlı olarak daha yüksek veya buna eşit.
- SKU'nuz önbelleğe alınmış depolamayı (önbelleğe yazma) destekler ve bu sayı yönetilen disklerdeki IOPS'den daha küçüktür (bu, okuma IOPS'niz için üst sınır olacaktır).
IOPS'nin yalnızca birkaç düğüm için yükseltilmiş olduğunu görüyorsanız sık erişimli bir bölüme sahip olabilirsiniz ve olası bir dengesizlik için verilerinizi gözden geçirmeniz gerekebilir.
IOPS'niz seçilen SKU tarafından desteklenenden düşükse ancak disk IOPS'sine eşit veya daha yüksekse aşağıdaki eylemleri gerçekleştirebilirsiniz:
- Performansı artırmak için daha fazla disk ekleyin. Disklerin artırılması için bir destek olayının tetiklenmiş olması gerekir.
- Daha fazla düğüm ekleyerek veri merkezlerini ölçeklendirin.
IOPS'niz SKU'nuzun desteklediğini en üst değere çıkarırsa şunları yapabilirsiniz:
- ölçeğini artırarak daha fazla IOPS destekleyen farklı bir SKU'ya yükseltin.
- Daha fazla düğüm ekleyerek veri merkezlerini ölçeklendirin.
Daha fazla bilgi için Bkz . Sanal Makine ve disk performansı.
Ağ performansı
Çoğu durumda ağ performansı yeterlidir. Ancak, sık sık veri akışı (sık sık yatay ölçeği artırma/azaltma gibi) veya çok büyük giriş/çıkış veri hareketleri varsa, bu bir sorun haline gelebilir. SKU'nuzun ağ performansını değerlendirmeniz gerekebilir. Örneğin, Standard_DS14_v2 SKU 12.000 Mb/sn'yi destekler; bunu ölçümlerdeki bayt/çıkış ile karşılaştırın:
Ağı yalnızca birkaç düğüm için yükseltilmiş olarak görüyorsanız sık erişimli bir bölüme sahip olabilirsiniz ve olası bir dengesizlik için veri dağıtım ve/veya erişim desenlerinizi gözden geçirmeniz gerekebilir.
- Daha fazla ağ G/Ç'sini destekleyen farklı bir SKU'ya dikey olarak ölçeği artırma.
- Daha fazla düğüm ekleyerek kümenin ölçeğini yatay olarak artırma.
Çok fazla bağlı istemci
Dağıtımlar, bir uygulamanın istenen gecikme süresi için gereken en fazla paralel istek sayısını destekleyecek şekilde planlanmalı ve sağlanmalıdır. Belirli bir dağıtım için sisteme minimum eşiğin üzerinde daha fazla yük getirilmesi genel gecikme süresini artırır. Bunun tolere edilebilir sınırları aşmadığından emin olmak için bağlı istemci sayısını izleyin.
Disk alanı
Çoğu durumda, varsayılan dağıtımlar IOPS için iyileştirildiğinden yeterli disk alanı vardır ve bu da diskin düşük kullanımına neden olur. Bununla birlikte, disk alanı ölçümlerini zaman zaman gözden geçirmeniz tavsiye edilir. Cassandra çok fazla disk biriktirir ve sıkıştırma tetiklendiğinde azaltır. Bu nedenle sıkıştırmanın alanı geri alamaması gibi eğilimler oluşturmak için disk kullanımını daha uzun süreler içinde gözden geçirmek önemlidir.
Not
Sıkıştırma için kullanılabilir alan sağlamak için disk kullanımı yaklaşık %50 oranında tutulmalıdır.
Bu davranışı yalnızca birkaç düğüm için görüyorsanız, sık erişimli bir bölüme sahip olabilirsiniz ve olası bir dengesizlik için veri dağıtımınızı ve/veya erişim desenlerinizi gözden geçirmeniz gerekebilir.
- daha fazla disk ekleyin, ancak SKU'nuzun uyguladığı IOPS sınırlarına dikkat edin
- kümenin yatay ölçeğini artırma
JVM belleği
Varsayılan formülümüz, vm belleğinin yarısını JVM'ye üst sınırı 31 GB olan bir değer olarak atar. Bu, çoğu durumda performans ile bellek arasında iyi bir denge sağlar. Bazı iş yükleri, özellikle de sık sık bölümler arası okumalar veya aralık taramaları olan iş yüklerinde bellek zorlanabilir.
Çoğu durumda bellek Java çöp toplayıcısı tarafından etkili bir şekilde geri kazanılır, ancak özellikle CPU genellikle %80'in üzerindeyse, atık toplayıcı için yeterli CPU döngüsü kalmaz. Bu nedenle, tüm CPU performans sorunları bellek sorunlarından önce giderilmelidir.
CPU %70'in altına gelirse ve çöp toplama belleği geri kazanamıyorsa daha fazla JVM belleğine ihtiyacınız olabilir. Bu durum özellikle sınırlı belleğe sahip bir SKU kullanıyorsanız geçerlidir. Çoğu durumda sorgularınızı ve istemci ayarlarınızı gözden geçirmeniz ve CQL sorgunuzda seçilenlerle limit birlikte azaltmanız fetch_size gerekir.
Gerçekten daha fazla belleğe ihtiyacınız varsa şunları yapabilirsiniz:
- JVM bellek ayarlarını sizin için artırmamız için bir bilet oluşturun
- Kullanılabilir belleği daha fazla olan bir SKU'ya dikey olarak ölçeklendirme
Mezar taşı
Reaper ile yedi günde bir onarımlar çalıştırıyoruz ve bu da TTL'nin süresi dolan satırları kaldırıyor ("kaldırıldı işareti" olarak adlandırılır). Bazı iş yüklerinde daha sık silme işlemleri olur ve Cassandra günlüklerinde olduğu gibi Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) uyarılar, hatta aşırı kaldırılmış kaldırılmış öğeler nedeniyle sorgunun yerine getirilemeyeceğini belirten hatalar görülür.
Sorguların yerine getirilememesi durumunda kısa vadeli bir azaltma, Cassandra yapılandırmasındaki değerini varsayılan 100.000 değerinden daha yüksek bir değere yükseltmektirtombstone_failure_threshold.
Buna ek olarak, TTL'yi anahtar alanında gözden geçirmenizi ve daha fazla mezar taşını temizlemek için günlük onarım çalıştırmanızı öneririz. TTL'ler kısaysa (örneğin iki günden kısaysa) ve içindeki veri akışları hızla siliniyorsa sıkıştırma stratejisini gözden geçirmenizi ve tercih yapmanızı Leveled Compaction Strategyöneririz. Bazı durumlarda, bu tür eylemler veri modelinin gözden geçirilmesi gerektiğinin bir göstergesi olabilir.
Toplu iş uyarıları
CassandraLogs ve olası ilgili hatalarda bu uyarıyla karşılaşabilirsiniz:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
Bu durumda, önerilen toplu iş boyutunun altında kalmak için sorgularınızı gözden geçirmeniz gerekir. Nadir durumlarda ve kısa vadeli bir azaltma olarak Cassandra yapılandırmasında varsayılan değer olan 50'den daha yüksek bir değere yükseltebilirsinizbatch_size_fail_threshold_in_kb.
Büyük bölüm uyarısı
CassandraLogs içinde şu uyarıyla karşılaşabilirsiniz:
Writing large partition <table> (105.426MiB) to sstable <file>
Bu, veri modelinde bir sorun olduğunu gösterir. Aşağıda daha ayrıntılı bir yığın taşması makalesi verilmişti. Bu, ciddi performans sorunlarına neden olabilir ve çözülmesi gerekir.
Özelleştirilmiş iyileştirmeler
Sıkıştırma
Cassandra, bir tablo oluşturulduğunda uygun bir sıkıştırma algoritmasının seçilmesine izin verir (bkz . Sıkıştırma) Varsayılan değer LZ4'tür. Bu, aktarım hızı ve CPU için mükemmeldir ancak diskte daha fazla alan tüketir. Zstd (Cassandra 4.0 ve üstü) kullanıldığında minimum CPU yüküyle yaklaşık %12 oranında alan tasarrufu sağlar.
Memtable yığın alanını iyileştirme
Varsayılanımız cassandra.yaml dosyasındaki memtable_heap_space için JVM yığınının 1/4'ünün kullanılmasıdır. Yazma odaklı uygulama ve/veya küçük bellekli SKU'larda bu durum sık sık boşaltma ve parçalanmış sstable'lara yol açarak daha fazla sıkıştırma gerektirebilir. Bu gibi durumlarda en az 4048 olması yararlı olabilir ancak diğer işlemlerin (örneğin okumalar) etkilenmediğinden emin olmak için dikkatli bir karşılaştırma gerektirir.
Sonraki adımlar
Bu makalede, en iyi performans için bazı en iyi yöntemleri ortaya koyduk. Artık kümeyle çalışmaya başlayabilirsiniz: