Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure Managed Instance pour Apache Cassandra est un service complètement managé pour les clusters Apache Cassandra open source purs. Le service permet également aux configurations d’être remplacées, en fonction des besoins spécifiques de chaque charge de travail. Cette fonctionnalité permet une flexibilité et un contrôle maximals si nécessaire. 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 niveaux de produit
Azure prend en charge trois zones de disponibilité dans la plupart des régions. Azure Managed Instance pour Apache Cassandra mappe les zones de disponibilité aux racks. Nous vous recommandons de choisir une clé de partition avec une cardinalité élevée pour éviter les partitions chaudes. Pour le meilleur niveau de fiabilité et de tolérance de panne, nous vous recommandons 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, utilisez 3, 6, 9, etc.
Azure utilise un RAID 0 sur le nombre de disques que vous approvisionnez. Pour obtenir le nombre optimal d'opérations d'entrée/sortie par seconde (IOPS), vérifiez le nombre maximal d'E/S par seconde sur le niveau de produit que vous avez choisi et les IOPS d’un disque P30. Par exemple, le Standard_DS14_v2 niveau produit prend en charge 51 200 IOPS non mises en cache. Un seul disque P30 offre des performances de base de 5 000 IOPS. Quatre disques mènent à 20 000 IOPS, ce qui est bien inférieur aux limites de la machine.
Nous vous recommandons vivement d’évaluer de manière approfondie votre charge de travail par rapport au niveau produit et au nombre de disques. Le benchmarking est particulièrement important pour les gammes de produit avec seulement huit cœurs. Nos recherches montrent que les processeurs de huit cœurs fonctionnent uniquement pour les charges de travail les moins exigeantes. La plupart des charges de travail ont besoin d’un minimum de 16 cœurs pour s’exécuter correctement.
Charges de travail analytiques et transactionnelles
Les charges de travail transactionnelles nécessitent généralement un centre de données optimisé pour une faible latence. Les charges de travail analytiques utilisent souvent des requêtes plus complexes, qui prennent plus de temps à s’exécuter. Dans la plupart des cas, vous souhaitez des centres de données distincts.
- Un optimisé pour une faible latence.
- Une optimisée pour les charges de travail analytiques.
Optimiser les charges de travail analytiques
Nous vous recommandons d’appliquer les paramètres suivants cassandra.yaml pour les charges de travail analytiques. Pour plus d’informations sur l’application de ces paramètres, consultez Mettre à jour la configuration de Cassandra.
Délais d’expiration
| Valeur | Cassandra MI par défaut | 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 par défaut | Recommandation pour les charges de travail analytiques |
|---|---|---|
file_cache_size_in_mb |
2 048 | 6 144 |
Autres recommandations
| Valeur | Cassandra MI par défaut | 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 recommandons d'augmenter les délais d'expiration du pilote client Cassandra pour les ajuster 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 assurer des performances optimales pour les 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 un pilote Java V4, une démonstration illustre le fonctionnement de ce processus et la façon d’activer la stratégie dans cet exemple.
Monitorer les goulots d’étranglement des 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 %. Pour afficher les métriques du processeur, à partir du portail Azure, sous la section Surveillance , ouvrez l’onglet Métriques .
Pour une vue processeur réaliste, ajoutez un filtre et utilisez-le Usage kind=usage_idle pour fractionner la propriété. Si cette valeur est inférieure à 20%, appliquez la répartition pour obtenir l’utilisation par toutes les catégories d’utilisation.
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 d’effectuer les actions suivantes :
- Effectuez un scale-up vertical jusqu’à un niveau de produit avec plus de cœurs de processeur, en particulier si le nombre de cœurs est de 8 ou moins.
- Mettre à l’échelle horizontalement en ajoutant plus de nœuds. Comme mentionné précédemment, le nombre de nœuds doit être un multiple du facteur de réplication.
Si la charge CPU est élevée pour seulement quelques nœuds, mais faible pour les autres, cela indique une partition active. Ce scénario a besoin d’un examen approfondi.
La modification du niveau de produit est prise en charge à l’aide du portail Azure, de l’interface de ligne de commande Azure et du déploiement de modèle Azure Resource Manager (modèle ARM). Vous pouvez déployer ou modifier un modèle ARM et remplacer le niveau produit par l’une des valeurs suivantes :
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
Actuellement, nous ne prenons pas en charge la transition entre les familles de produits. Par exemple, si vous possédez actuellement un Standard_DS13_v2 et que vous souhaitez effectuer une mise à niveau vers un produit plus volumineux, comme Standard_DS14_v2, cette option n’est pas disponible. Ouvrez un ticket de support pour demander une mise à niveau vers le produit supérieur.
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 nécessaire en ce qui concerne les goulots d’étranglement des performances liés au disque. Dans ce cas, il est important de passer en revue les métriques d’IOPS.
Si les métriques affichent une ou toutes les caractéristiques suivantes, vous devrez peut-être effectuer un scale-up :
- Vos métriques sont 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.
- Vos métriques sont constamment supérieures ou égales aux IOPS maximales autorisées pour le niveau de produit des écritures.
- Votre niveau de produit prend en charge le stockage mis en cache (cache en écriture directe) et ce nombre est inférieur aux IOPS des disques managés. Cette valeur est la limite supérieure pour vos E/S de lecture par seconde.
Si vous voyez les IOPS élevées pour seulement quelques nœuds, il est possible que vous ayez une partition à chaud et deviez examiner vos données pour obtenir une asymétrie éventuelle.
Si vos IOPS sont inférieurs à ce que prend en charge votre niveau de produit, mais supérieur ou égal aux E/S par seconde de disque, effectuez les actions suivantes :
- Ajoutez d’autres nœuds pour monter en puissance les centres de données.
Si vos IOPS atteignent la limite supérieure prise en charge par votre niveau de produit, vous pouvez :
- Effectuez un scale-up vers un autre niveau de produit qui prend en charge davantage d’IOPS.
- Ajoutez d’autres nœuds pour monter en puissance les centres de données.
Pour plus d’informations, consultez Les performances des machines virtuelles et des disques.
Performances réseau
En règle générale, les performances réseau sont suffisantes. Si vous diffusez des données fréquemment, telles que le scale-up/scale-down horizontal fréquent, ou s’il existe d’énormes mouvements de données d’entrée/sortie, ces performances peuvent devenir un problème. Vous devrez peut-être évaluer les performances réseau de votre niveau produit. Par exemple, la Standard_DS14_v2 catégorie de produit prend en charge 12 000 Mb/s. Comparez cette valeur à l’octet entrant/sortant dans les métriques.
Si vous voyez le réseau élevé pour quelques nœuds seulement, il est possible que vous ayez une partition à chaud. Passez en revue vos modèles de distribution et d’accès des données pour détecter un éventuel biais.
- Effectuez un scale-up vertical jusqu’à un autre niveau de produit en 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
Planifiez et approvisionnez des déploiements pour prendre en charge le nombre maximal de requêtes parallèles requises pour la latence souhaitée d’une application. Pour un déploiement spécifique, l’introduction d’une charge accrue au système au-dessus d’un seuil minimal augmente la latence globale. Surveillez le nombre de clients connectés pour vous assurer que cette situation ne dépasse pas les limites tolérables.
Espace disque
Dans la plupart des cas, il y a suffisamment d’espace disque. Les déploiements par défaut sont optimisés pour les IOPS, ce qui entraîne une faible utilisation du disque. Néanmoins, nous vous recommandons de passer en revue occasionnellement les métriques d’espace disque. Cassandra accumule de nombreux disques, puis les réduit lorsque le compactage est déclenché. Il est important de passer en revue l’utilisation du disque sur des périodes plus longues pour établir des tendances, comme lorsque le compactage ne peut pas récupérer l’espace.
Remarque
Pour garantir l'espace disponible pour le compactage, maintenez l'utilisation du disque à environ 50%.
Si vous voyez ce comportement pour quelques nœuds seulement, il est possible que vous ayez une partition à chaud. Passez en revue vos modèles de distribution et d’accès des données pour détecter un éventuel biais.
- Ajoutez d’autres disques, mais n’oubliez pas les limites d’E/S par seconde imposées par votre niveau produit.
- Augmentez horizontalement la capacité du cluster.
Mémoire Machine virtuelle Java (JVM)
Notre formule par défaut affecte la moitié de la mémoire de la machine virtuelle à la machine virtuelle Java (JVM) avec une limite supérieure de 31 Go. Dans la plupart des cas, cette approche est un bon équilibre entre les performances et la mémoire. Il est possible que certaines charges de travail, en particulier celles qui ont des lectures entre partitions fréquentes ou des analyses de plages, soient mises à l’épreuve en termes de mémoire.
Dans la plupart des cas, la mémoire est libérée efficacement par le ramasse-miettes Java. Si le processeur est souvent supérieur à 80 %, il n’existe pas suffisamment de battements d’horloge pour le récupérateur de mémoire gauche. Résolvez les problèmes de performances du processeur avant de vérifier les problèmes de mémoire.
Si le processeur pointe au-dessous de 70% et que la collecte de déchets ne peut pas récupérer de mémoire, vous devrez peut-être augmenter la mémoire JVM. D’autres mémoires JVM peuvent être nécessaires si vous êtes sur un niveau produit avec une mémoire limitée. Dans la plupart des cas, vous devez passer en revue vos requêtes et paramètres client et réduire fetch_size ainsi que ce qui est choisi dans limit votre requête CQL (Cassandra Query Language).
Si vous avez besoin de plus de mémoire, vous pouvez :
- Effectuez une mise à l’échelle verticalement vers un niveau de produit qui a plus de mémoire disponible.
Objet tombstone
Nous effectuons des réparations tous les sept jours avec Reaper, qui supprime les lignes dont le temps de vie (TTL) a expiré. Ces lignes sont appelées pierres tombales. Certains workloads effectuent des suppressions plus fréquentes et affichent 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. Certaines erreurs indiquent qu’une requête n’a pas pu être remplie en raison de pierres tombales excessives.
Une atténuation à court terme si les requêtes ne sont pas remplies consiste à augmenter la tombstone_failure_threshold valeur dans la configuration Cassandra de la valeur par défaut de 100 000 à une valeur supérieure.
Nous vous recommandons également de revoir le TTL de l'espace-clé et d'effectuer éventuellement des réparations quotidiennes pour éliminer d'autres pierres tombales. Si les TTL sont courtes (par exemple, moins de deux jours), et que les flux de données sont rapidement supprimés, nous vous recommandons de passer en revue la stratégie de compactage et de favoriser Leveled Compaction Strategy. Dans certains cas, ces actions peuvent indiquer qu’une révision du modèle de données est requise.
Avertissements par lots
Vous pouvez rencontrer l’avertissement suivant dans CassandraLogs et les défaillances potentiellement associées :
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
Passez en revue vos requêtes pour rester en dessous de la taille de lot recommandée. Dans de rares cas et comme atténuation à court terme, augmentez batch_size_fail_threshold_in_kb dans la configuration de Cassandra par rapport à la valeur par défaut de 50 à une valeur plus élevée.
Avertissement de grande partition
Vous pouvez rencontrer l’avertissement suivant dans CassandraLogs :
Writing large partition <table> (105.426MiB) to sstable <file>
Ce message indique un problème dans le modèle de données. Pour plus d’informations, consultez cet article Stack Overflow. Ce problème peut entraîner des problèmes de performances graves et doit être résolu.
Optimisations spécialisées
Compression
Cassandra permet la sélection d’un algorithme de compression approprié lorsqu’une table est créée. La valeur par défaut est LZ4, qui est excellente pour le débit et le processeur, mais consomme plus d’espace sur le disque. L’utilisation de Zstandard (Cassandra 4.0 et up) permet d’économiser environ 12% espace avec une surcharge minimale du processeur.
Optimiser l’espace de segment de mémoire memtable
La valeur par défaut consiste à utiliser un quart du segment de mémoire JVM pour memtable_heap_space dans le cassandra.yaml fichier. Pour les applications orientées écriture ou sur les niveaux de produit avec de petites quantités de mémoire, ce problème peut entraîner un vidage fréquent et fragmenté sstables, ce qui nécessite un autre compactage. Augmenter à au moins 4 048 pourrait être bon. Cette approche nécessite un benchmark prudent pour s’assurer que d’autres opérations (par exemple, les lectures) ne sont pas affectées.