Meilleures pratiques pour un niveau de performance optimal
Azure Managed Instance pour Apache Cassandra est un service complètement managé pour les clusters Apache Cassandra open source purs. Le service permet également de remplacer des configurations, en fonction des besoins spécifiques de chaque charge de travail, ce qui permet une flexibilité et un contrôle optimaux, le cas échéant. Cet article vous fournit des conseils sur le moyen d’optimiser les performances.
Installation et configuration optimales
Facteur de réplication, nombre de disques, nombre de nœuds et références SKU
Du fait qu’Azure prend en charge trois zones de disponibilité dans la plupart des régions et que Cassandra Managed Instance route des zones de disponibilité vers des racks, nous vous recommandons de choisir une clé de partition avec une cardinalité élevée pour éviter des partitions à chaud. Pour obtenir un meilleur niveau de fiabilité et de tolérance de panne, nous vous conseillons vivement de configurer un facteur de réplication de 3. Nous vous recommandons également de spécifier un multiple du facteur de réplication comme nombre de nœuds, par exemple 3, 6, 9, etc.
Nous utilisons un RAID 0 sur le nombre de disques que vous approvisionnez. Par conséquent, pour obtenir un nombre optimal d’IOPS, vous devez vérifier le nombre maximal d’IOPS sur la référence SKU choisie de concert avec le nombre d’IOPS d’un disque P30. Par exemple, la référence SKU Standard_DS14_v2 prend en charge 51 200 IOPS non mis en cache, tandis qu’un disque P30 unique a une performance de base de 5 000 IOPS. Quatre disques aboutiront donc à 20 000 IOPS, ce qui bien inférieur aux limites de la machine.
Nous vous recommandons vivement d’évaluer votre charge de travail par rapport à la référence SKU et au nombre de disques. L’évaluation est particulièrement importante dans le cas de références SKU ayant uniquement huit cœurs. Notre recherche montre que huit processeurs cœurs fonctionnent uniquement pour les charges de travail les moins exigeantes et la majorité des charges de travail ont besoin de 16 cœurs minimaux pour être performantes.
Analytique et Charges de travail transactionnelles
Les charges de travail transactionnelles ont généralement besoin d’un centre de données optimisé pour une latence faible, tandis que les charges de travail analytiques utilisent souvent des requêtes plus complexes dont l’exécution prend davantage de temps. Dans la plupart des cas, vous voudrez séparer les centres de données :
- Un centre optimisé pour une faible latence
- Un centre optimisé pour les charges de travail analytiques
Optimisation pour les charges de travail analytiques
Nous recommandons aux utilisateurs d’appliquer les paramètres cassandra.yaml suivants pour les charges de travail d’analyse (voir ici comment effectuer l’application).
Délais d'attente
| Valeur | Cassandra MI Default | Recommandation pour les charges de travail analytiques |
|---|---|---|
| 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 |
Caches
| Valeur | Cassandra MI Default | Recommandation pour les charges de travail analytiques |
|---|---|---|
| file_cache_size_in_mb | 2 048 | 6 144 |
Autres recommandations
| Valeur | Cassandra MI Default | Recommandation pour les charges de travail analytiques |
|---|---|---|
| commitlog_total_space_in_mb | 8 192 | 16 384 |
| column_index_size_in_kb | 64 | 16 |
| compaction_throughput_mb_per_sec | 128 | 256 |
Paramètres du client
Nous vous conseillons d’optimiser les délais d’inactivité du pilote client Cassandra conformément aux délais d’expiration appliqués sur le serveur.
Optimiser pour une faible latence
Nos paramètres par défaut conviennent déjà aux charges de travail à faible latence. Pour veiller aux meilleures performances des latences de queue, nous vous recommandons vivement d’utiliser un pilote client qui prend en charge l’exécution spéculative et de configurer votre client en conséquence. Pour le pilote Java V4, vous trouverez une démonstration illustrant comment cela fonctionne et comment activer la stratégie ici.
Monitoring des goulots d’étranglement de performances
Performances du processeur
Comme chaque système de base de données, Cassandra fonctionne mieux si l’utilisation du processeur est d’environ 50 % et ne dépasse pas 80 %. Vous pouvez afficher les métriques du processeur sous l’onglet Métriques du portail :
Si le processeur est en permanence au-dessus de 80 % pour la majorité des nœuds, la base de données est surchargée, ce qui se manifeste par de nombreux délais d’inactivité chez le client. Dans ce scénario, nous vous recommandons de prendre les mesures suivantes :
- effectuer un scale-up vers une référence SKU avec plus de cœurs de processeur (en particulier si le nombre de cœurs inférieur ou égal à 8).
- effectuer une mise à l’échelle horizontale en ajoutant d’autres nœuds (comme mentionné plus tôt, le nombre de nœuds doit être un multiple du facteur de réplication).
Si le processeur est uniquement élevé pour quelques nœuds et faible pour les autres, il indique une partition à chaud et nécessite une enquête supplémentaire.
Remarque
La modification de la référence SKU est prise en charge par le Portail Azure, Azure CLI et le déploiement de modèles ARM. Vous pouvez déployer/modifier le modèle ARM et remplacer la référence SKU par l’une des options suivantes.
- 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
Remarquez qu’actuellement, nous ne prenons pas en charge la transition entre les familles de références SKU. Par exemple, si vous possédez actuellement une référence SKU Standard_DS13_v2 et souhaitez effectuer une mise à niveau vers une référence SKU plus élevée, par exemple Standard_DS14_v2, cette option n’est pas disponible. Toutefois, vous pouvez ouvrir un ticket de support pour demander une mise à niveau vers la référence SKU supérieure.
Performances des disques
Le service s’exécute sur des disques managés Azure P30, ce qui permet des « IOPS en rafale ». Un monitoring minutieux est requis quand il s’agit de goulots d’étranglement des performances liés au disque. Dans ce cas, il est important d’examiner les métriques d’IOPS :
Si les métriques affichent une ou toutes les caractéristiques suivantes, elles peuvent indiquer que vous devez effectuer un scale-up.
- Constamment supérieures ou égales aux IOPS de base (n’oubliez pas de multiplier 5 000 IOPS par le nombre de disques par nœud pour obtenir le nombre).
- Constamment supérieures ou égales au nombre maximal d’IOPS autorisées pour la référence SKU des écritures.
- Votre référence SKU prend en charge le stockage mis en cache (cache d’écriture immédiate) et ce nombre est inférieur aux IOPS des disques managés (il s’agit de la limite supérieure de vos IOPS en lecture).
Si vous ne voyez le nombre élevé d’IOPS que pour quelques nœuds, il est possible que vous ayez une partition à chaud et que vous deviez examiner vos données pour une asymétrie éventuelle.
Si votre nombre d’IOPS est inférieur à ce qui est pris en charge par la référence SKU choisie, mais égal ou supérieur aux IOPS de disque, vous pouvez prendre les mesures suivantes :
- Ajoutez d’autres disques pour améliorer les performances. L’augmentation de disques nécessite l’ouverture d’un cas de support.
- Effectuez un scale-up du ou des centres de données en ajoutant d’autres nœuds.
Si votre nombre d’IOPS maximise ce que votre référence SKU prend en charge, vous pouvez :
- effectuer un scale-up vers une autre référence SKU prenant en charge d’autres IOPS.
- Effectuez un scale-up du ou des centres de données en ajoutant d’autres nœuds.
Pour plus d’informations, consultez Performances des disques et de la machine virtuelle.
Performances réseau
Les performances réseau sont suffisantes dans la plupart des cas. Toutefois, si vous transmettez en continu des données de manière fréquente (comme un scale-up/scale-down horizontal régulier) ou qu’il existe des déplacements des données volumineux en entrée/sortie, cela peut devenir un problème. Vous devrez peut-être évaluer les performances réseau de votre référence SKU. Par exemple, la référence SKU Standard_DS14_v2 prend en charge 12 000 Mo/s. Comparez cet élément aux octets entrants/sortants dans les métriques :
Si le réseau est élevé pour quelques nœuds, il est possible que vous ayez une partition à chaud et que vous deviez examiner la distribution de vos données et/ou accédiez aux modèles pour une asymétrie éventuelle.
- Effectuez un scale-up horizontal vers une autre référence SKU prenant en charge davantage d’E/S réseau.
- Effectuez un scale-up horizontal du cluster en ajoutant d’autres nœuds.
Trop de clients connectés
Les déploiements doivent être planifiés et approvisionnés pour prendre en charge le nombre maximal de requêtes parallèles requis pour la latence souhaitée d’une application. Pour un déploiement donné, l’introduction d’autres charges dans le système au-dessus d’un seuil minimal augmente la latence globale. Monitorez le nombre de clients connectés pour veiller à ce qu’il ne dépasse pas les limites tolérables.
Espace disque
Dans la plupart des cas, l’espace disque est suffisant car les déploiements par défaut sont optimisés pour les IOPS, ce qui entraîne une utilisation faible du disque. Néanmoins, nous conseillons d’examiner occasionnellement les métriques d’espace disque. Cassandra accumule un nombre important de disques, puis le diminue lorsque le compactage est déclenché. Il est ainsi important d’examiner l’utilisation du disque sur de plus longues périodes pour établir des tendances, comme un compactage ne pouvant pas récupérer l’espace.
Remarque
Pour veiller à obtenir l’espace disponible pour le compactage, l’utilisation du disque doit être maintenue à environ 50 %.
Si vous ne voyez ce comportement que pour quelques nœuds, il est possible que vous ayez une partition à chaud et que vous deviez examiner la distribution de vos données et/ou accédiez aux modèles pour une asymétrie éventuelle.
- ajouter d’autres disques pour être attentif aux limites d’IOPS imposées par votre référence SKU
- effectuer un scale-up horizontal du cluster
Mémoire Machine virtuelle Java (JVM)
Notre formule par défaut attribue la moitié de la mémoire de la machine virtuelle à JVM avec une limite supérieure de 31 Go, ce qui est dans la plupart des cas un bon équilibre entre les performances et la mémoire. Il est possible que certaines charges de travail, notamment celles ayant des lectures fréquentes entre plusieurs partitions ou des analyses de plages, soient remises en cause.
Dans la plupart des cas, la mémoire est récupérée efficacement par le récupérateur de mémoire Java, mais surtout si le processeur est souvent au-dessus de 80 %, les cycles de processeur ne sont pas suffisants pour le récupérateur de mémoire restant. Tout problème lié aux performances du processeur doit donc être traité avant les problèmes de mémoire.
Si le processeur se situe sous les 70 % et que le nettoyage de la mémoire ne peut pas récupérer la mémoire, il est possible que vous ayez besoin de davantage de mémoire JVM. C’est particulièrement le cas si vous êtes sur une référence SKU avec une mémoire limitée. Dans la majorité des cas, vous devez examiner vos paramètres client et requêtes et réduire fetch_size, ainsi que ce qui est choisi dans limit au sein de votre requête CQL.
Si vous avez effectivement besoin de davantage de mémoire, vous pouvez effectuer ce qui suit :
- Créez un ticket pour que nous augmentions les paramètres de mémoire JVM à votre place
- Mise à l’échelle verticale vers une référence SKU dotée de plus de mémoire disponible
Objet tombstone
Nous exécutons des réparations tous les sept jours avec le Reaper qui supprime les lignes dont les durées de vie (TTL) ont expiré (appelées « objets tombstone »). Certaines charges de travail ont des suppressions plus fréquentes et vous pouvez voir des avertissements tels que Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) dans les journaux Cassandra, ou même des erreurs indiquant qu’une requête n’a pas pu être satisfaite en raison d’objets tombstone trop nombreux.
Une atténuation à court terme, en cas de requête non satisfaite, consiste à augmenter le tombstone_failure_threshold dans la configuration Cassandra de la valeur par défaut de 100 000 vers une valeur plus élevée.
Outre ceci, nous vous recommandons d’examiner la TTL sur l’espace de clé et d’exécuter éventuellement des réparations quotidiennes pour effacer d’autres objets tombstone. Si les TTL sont courtes (par exemple, inférieures à deux jours) et que des données circulent et sont rapidement supprimées, nous vous recommandons d’examiner la stratégie de compactage et de favoriser Leveled Compaction Strategy. Dans certains cas, ces actions peuvent indiquer qu’une évaluation du modèle de données est nécessaire.
Avertissements par lots
Vous pouvez rencontrer cet avertissement dans les CassandraLogs et des échecs éventuellement liés :
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
Dans ce cas, vous devez examiner vos requêtes pour rester en dessous de la taille de lot recommandée. Dans de rares cas et en tant qu’atténuation à court terme, vous pouvez augmenter batch_size_fail_threshold_in_kb dans la configuration Cassandra de la valeur par défaut de 50 à une valeur plus élevée.
Avertissement de grande partition
Vous pouvez rencontrer cet avertissement dans les CassandraLogs :
Writing large partition <table> (105.426MiB) to sstable <file>
Cela indique qu’un problème existe dans le modèle de données. Voici un article sur le dépassement de la capacité de la pile donnant plus de détails. Cela peut entraîner des problèmes de performances graves qui doivent être traités.
Optimisations spécialisées
Compression
Cassandra permet de sélectionner un algorithme approprié de compression lors de la création d’une table (voir Compression). La valeur par défaut est LZ4 qui est excellente pour le débit et le processeur, mais consomme davantage d’espace sur un disque. L’utilisation de Zstd (Cassandra 4.0 et version ultérieure) permet d’économiser environ 12 % d’espace avec une surcharge de processeur minimale.
Optimisation de l’espace de segment de mémoire memtable
Notre processus par défaut est d’utiliser 1/4 de segment de mémoire JVM pour memtable_heap_space dans le fichier cassandra.yaml. Pour une application axée sur les écritures et/ou sur les références SKU avec peu de mémoire, cela peut entraîner des vidages fréquents et des sstables fragmentés et exige donc d’autres compactages. Dans de tels cas, une augmentation jusqu’au moins 4048 peut être bénéfique, mais exige un point de référence prudent pour vérifier que d’autres opérations (par exemple, des lectures) ne sont pas affectées.
Étapes suivantes
Dans cet article, nous exposons certaines des meilleures pratiques pour obtenir des performances optimales. Vous pouvez maintenant commencer à utiliser le cluster :