Apache Cassandra için Azure Yönetilen Örneği'nde 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, her iş yükünün belirli ihtiyaçlarına bağlı olarak yapılandırmaların geçersiz kılınmasına da olanak tanır. Bu özellik 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 ürün katmanları

Azure çoğu bölgede üç kullanılabilirlik alanı destekler. Apache Cassandra için Azure Yönetilen Örneği, kullanılabilirlik alanlarını raflarla eşleştirir. 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. Ayrıca düğüm sayısı olarak çoğaltma faktörünün bir katını belirtmenizi öneririz. Örneğin, 3, 6, 9 vb. kullanın.

Azure, sağladığınız disk sayısı üzerinden RAID 0 kullanır. Saniye başına en iyi giriş/çıkış işlemlerini (IOPS) almak için P30 diskinin IOPS değeriyle birlikte seçtiğiniz ürün katmanında en yüksek IOPS'yi denetleyin. Örneğin, Standard_DS14_v2 ürün katmanı 51.200 uncached IOPS'yi destekler. Tek bir P30 diskinin temel performansı 5.000 IOPS'dır. Dört disk, makine sınırlarının çok altında olan 20.000 IOPS'ye yol açar.

İş yükünüzün ürün katmanına ve disk sayısına göre kapsamlı bir karşılaştırmasını kesinlikle öneririz. Kıyaslama özellikle yalnızca sekiz çekirdeği olan ürün katmanları için önemlidir. Araştırmamızda sekiz çekirdekli CPU'ların yalnızca en az talep gören iş yükleri için çalıştığını gösteriyor. Çoğu iş yükünün düzgün performans göstermeleri için en az 16 çekirdek gerekir.

Analitik ve iş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ç duyar. Analitik iş yükleri genellikle daha karmaşık sorgular kullanır ve bu sorguların çalıştırılması daha uzun sürer. Çoğu durumda, aşağıdakilerle ayrı veri merkezleri istiyorsunuz:

• Düşük gecikme süresi için iyileştirilmiş bir tane.
• Analitik iş yükleri için optimize edilmiş bir sistem.

Analitik iş yükleri için optimizasyon yapın

Analiz iş yükleri için aşağıdaki cassandra.yaml ayarları uygulamanızı öneririz. Bu ayarların nasıl uygulanacağı hakkında daha fazla bilgi için bkz. Cassandra yapılandırmasını güncelleştirme.

Zaman aşımları

Değer	Cassandra MI varsayılanı	Analitik iş yükü önerisi
read_request_timeout_in_ms	5.000	Kategori 10,000
range_request_timeout_in_ms	Kategori 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	beş yüz	1.000
roles_validity_in_ms	2.000	120.000
permissions_validity_in_ms	2.000	120.000

Önbellekler

Değer	Cassandra MI varsayılanı	Analitik iş yükü önerisi
file_cache_size_in_mb	2,048	6144

Diğer öneriler

Değer	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 gecikme süreli iş yükleri için zaten uygundur. Kuyruk gecikme sürelerinde en iyi performansı sağlamak için kurgusal yürütmeyi destekleyen ve istemcinizi uygun şekilde yapılandıran bir istemci sürücüsü kullanmanızı kesinlikle öneririz. Java V4 sürücüsü için bir tanıtımda bu işlemin nasıl çalıştığı ve bu örnekte ilkenin nasıl etkinleştirileceği gösterilir.

Performans sorunları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 görüntülemek için Azure portalında İzleme bölümünün altında Ölçümler sekmesini açın.

Gerçekçi bir CPU görünümü için bir filtre ekleyin ve özelliği bölmek için Usage kind=usage_idle kullanın. Bu değer%20'den küçükse, kullanımı tüm kullanım türlerine göre elde etmek için bölme uygulayın.

CPU çoğu düğüm için kalıcı olarak 80% üzerindeyse, veritabanı aşırı yüklenir ve bu da birden çok istemci zaman aşımında ortaya çıkar. Bu senaryoda, aşağıdaki eylemleri gerçekleştirmenizi öneririz:

• Özellikle çekirdekler yalnızca 8 veya daha azsa, daha fazla CPU çekirdeğine sahip bir ürün katmanına dikey olarak ölçeklendirin.
• Daha fazla düğüm ekleyerek yatay olarak ölçeklendirin. Daha önce belirtildiği gibi, düğüm sayısı çoğaltma faktörünün bir katı olmalıdır.

CPU yalnızca birkaç düğüm için yüksekse ancak diğerleri için düşükse, sıcak bir bölüm olduğunu gösterir. Bu senaryo için daha fazla araştırma yapılması gerekir.

Ürün katmanının değiştirilmesi Azure portalı, Azure CLI ve Azure Resource Manager şablonu (ARM şablonu) dağıtımı kullanılarak desteklenir. ARM şablonunu dağıtabilir veya düzenleyebilir ve ürün katmanını aşağıdaki değerlerden 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 ürün aileleri arasında geçişi desteklemiyoruz. Örneğin, şu anda bir Standard_DS13_v2 ürününüz varsa ve gibi Standard_DS14_v2daha büyük bir ürüne yükseltmek istiyorsanız bu seçenek kullanılamaz. Daha yüksek bir ürüne yükseltme isteğinde bulunmak için bir destek bileti açın.

Disk performansı

Hizmet, seri IOPS'ye olanak tanıyan Azure P30 yönetilen disklerinde çalışır. 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 gerekebilir:

• Ölçümleriniz tutarlı olarak temel IOPS'ye eşit veya daha yüksektir. Sayıyı almak için düğüm başına disk sayısıyla 5.000 IOPS'yi çarpmayı unutmayın.
• Ölçümleriniz, yazma işlemleri için ürün katmanı için izin verilen maksimum IOPS'den tutarlı olarak daha yüksek veya buna eşit.
• Ürün katmanınız önbelleğe alınmış depolamayı (yazma önbelleği) destekler ve bu sayı yönetilen disklerdeki IOPS'den daha küçüktür. Bu değer, okuma IOPS'niz için üst sınırdır.

IOPS'nin yalnızca birkaç düğüm için yükseltilmiş olduğunu görürseniz, sıcak bir bölüme sahip olabilirsiniz ve olası bir dengesizlik için verilerinizi gözden geçirmeniz gereklidir.

IOPS'leriniz ürün katmanınızın desteklediğinden düşükse ancak disk IOPS'sine eşit veya daha yüksekse aşağıdaki eylemleri gerçekleştirin:

• Veri merkezlerinin ölçeğini genişletmek için daha fazla düğüm ekleyin.

IOPS'niz ürün katmanınızın desteklediği üst sınıra ulaşırsa şunları yapabilirsiniz:

• Daha fazla IOPS destekleyen farklı bir ürün katmanına ölçeklendirin.
• Veri merkezlerinin ölçeğini genişletmek için daha fazla düğüm ekleyin.

Daha fazla bilgi için bkz . Sanal makine ve disk performansı.

Ağ performansı

Genellikle ağ performansı yeterlidir. Sık sık yatay ölçeği artırma/ölçeği azaltma gibi sık sık veri akışı yaparsanız veya çok büyük giriş/çıkış veri hareketleri varsa, bu performans sorun haline gelebilir. Ürün katmanınızın ağ performansını değerlendirmeniz gerekebilir. Örneğin, Standard_DS14_v2 ürün katmanı 12.000 Mb/sn'yi destekler. Bu değeri ölçümlerdeki bayt/çıkış ile karşılaştırın.

Ağın yalnızca birkaç düğüm için yükseltilmiş olduğunu görürseniz sık erişimli bölüme sahip olabilirsiniz. Olası bir dengesizlik için veri dağıtımınızı ve erişim desenlerinizi gözden geçirin.

• Daha fazla ağ G/Ç'sini destekleyerek dikey olarak farklı bir ürün katmanına ölçeklendirin.
• Daha fazla düğüm ekleyerek kümenin ölçeğini yatay olarak artırma.

Çok fazla bağlı istemci

Bir uygulamanın istenen gecikme süresi için gereken en fazla paralel istek sayısını desteklemek için dağıtımları planlayın ve sağlayın. 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. Bu durumun tolere edilebilir sınırları aşmadığından emin olmak için bağlı istemci sayısını izleyin.

Disk alanı

Çoğu durumda yeterli disk alanı vardır. Varsayılan dağıtımlar IOPS için iyileştirilmiştir ve bu da diskin düşük kullanımına neden olur. Bununla birlikte, disk alanı ölçümlerini zaman zaman gözden geçirmenizi öneririz. Cassandra çok sayıda disk biriktirir ve sıkıştırma tetiklendiğinde bunları azaltır. Sıkıştırmanın alanı geri alamaması gibi eğilimler oluşturmak için daha uzun sürelerde disk kullanımını gözden geçirmek önemlidir.

Not

Sıkıştırma için kullanılabilir alan sağlamak için disk kullanımını 50%civarında tutun.

Sadece birkaç düğüm için bu davranışı görüyorsanız, aktif bir bölüme sahip olabilirsiniz. Olası bir dengesizlik için veri dağıtımınızı ve erişim desenlerinizi gözden geçirin.

• Daha fazla disk ekleyin, ancak ürün katmanınız tarafından uygulanan IOPS sınırlarına dikkat edin.
• Kümenin ölçeğini yatay olarak artırma.

JVM belleği

Varsayılan formülümüz, sanal makinenin belleğinin yarısını üst sınırı 31 GB olan Java Sanal Makinesi'ne (JVM) atar. Çoğu durumda, bu yaklaşım performans ve bellek arasında iyi bir dengedir. 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. CPU genellikle%80'in üzerindeyse, atık toplayıcı için yeterli CPU döngüsü kalmaz. Bellek sorunlarını denetlemeden önce CPU performans sorunlarını giderin.

CPU 70% altına gelirse ve çöp toplama belleği geri kazanamıyorsa daha fazla JVM belleğine ihtiyacınız olabilir. Sınırlı belleğe sahip bir ürün katmanındaysanız daha fazla JVM belleği gerekebilir. Çoğu durumda, sorgularınızı ve istemci ayarlarınızı gözden geçirmeniz ve Cassandra Sorgu Dili (CQL) sorgunuzda fetch_size içinde seçilenlerle birlikte limit azaltmanız gerekir.

Daha fazla belleğe ihtiyacınız varsa şunları yapabilirsiniz:

• Kullanılabilir belleği daha fazla olan bir ürün katmanına dikey olarak ölçeklendirin.

Mezar taşı

Reaper ile yedi günde bir onarımlar çalıştırıyoruz ve bu da yaşam süresi (TTL) dolan satırları kaldırıyor. Bu satırlara mezar taşı adı verilir. Bazı iş yükleri daha sık silinir ve Cassandra günlüklerindeki gibi Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) uyarılar gösterir. Bazı hatalar, aşırı tombstone kayıtları nedeniyle bir sorgunun gerçekleştirilemeyeceğini belirtir.

Sorguların yerine getirilememesi durumunda kısa vadeli bir azaltma, tombstone_failure_threshold değeri varsayılan 100.000 değerinden daha yüksek bir değere yükseltmektir.

Ayrıca keyspace üzerindeki TTL'yi 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ısa) ve içinde veri akışları olup hızla siliniyorsa, sıkıştırma stratejisini gözden geçirmenizi ve Leveled Compaction Strategytercih yapmanızı öneririz. Bazı durumlarda, bu tür eylemler veri modelinin gözden geçirilmesi gerektiğini gösterebilir.

Toplu iş uyarıları

CassandraLogs ve olası ilgili hatalarda aşağıdaki uyarıyla karşılaşabilirsiniz:

Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.

Önerilen toplu iş boyutunun altında kalmak için sorgularınızı gözden geçirin. Nadir durumlarda ve kısa vadeli bir azaltma olarak batch_size_fail_threshold_in_kb varsayılan değer olan 50'den daha yüksek bir değere yükseltin.

Büyük bölüm uyarısı

CassandraLogs'ta aşağıdaki uyarıyla karşılaşabilirsiniz:

Writing large partition <table> (105.426MiB) to sstable <file>

Bu ileti, veri modelinde bir sorun olduğunu gösterir. Daha fazla bilgi için bu Stack Overflow makalesine bakın. Bu sorun ciddi performans sorunlarına neden olabilir ve çözülmesi gerekir.

Özelleştirilmiş iyileştirmeler

Sıkıştırma

Cassandra, tablo oluşturulduğunda uygun bir sıkıştırma algoritmasının seçilmesine izin verir. Varsayılan değer, aktarım hızı ve CPU için mükemmel olan ancak diskte daha fazla alan tüketen LZ4'dür. Zstandard (Cassandra 4.0 ve üstü) kullanıldığında en az CPU yüküyle yaklaşık 12% alan tasarrufu sağlar.

Memtable yığın alanını iyileştirin

Varsayılan değer, dosyadaki memtable_heap_space için JVM yığınının dörtte birini kullanmaktır cassandra.yaml . Yazma odaklı uygulamalarda veya az miktarda belleğe sahip ürün katmanlarında bu sorun sık sık temizlemeye ve parçalanmış sstablesöğesine yol açabilir ve bu da daha fazla sıkıştırma gerektirir. En az 4.048'e yükseltmek iyi olabilir. Bu yaklaşım, diğer işlemlerin (örneğin, okumalar) etkilenmediğinden emin olmak için dikkatli bir karşılaştırma gerektirir.

Sonraki adım

Azure portalını kullanarak küme oluşturma