Note
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 références SKU
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 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.
Azure utilise un RAID 0 sur le nombre de disques que vous approvisionnez. Pour obtenir les IOPS optimales, vérifiez le nombre maximal d’IOPS sur la référence SKU que vous avez choisie avec les 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 mèneraient à 20 000 IOPS, ce qui est 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. Le benchmarking est particulièrement important pour les SKU ne comportant que huit cœurs. Notre recherche montre que huit processeurs principaux 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 être performants.
Analytique et Charges de travail transactionnelles
Les charges de travail transactionnelles nécessitent généralement un centre de données optimisé pour une faible latence, tandis que les charges de travail analytiques utilisent souvent des requêtes plus complexes, ce qui prend plus de temps à s’exécuter. Dans la plupart des cas, vous souhaitez 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 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'attente
| 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 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 dans cet exemple.
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 :
Conseil
Pour une vue réaliste du processeur, ajoutez un filtre et fractionnez la propriété par Usage kind=usage_idle. Si cette valeur est inférieure à 20 %, vous pouvez appliquer un fractionnement pour obtenir une utilisation par tous les types 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 :
- 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.
- Mettre à l’échelle horizontalement en ajoutant plus de nœuds. Comme mentionné précédemment, le nombre de nœuds doit être multiple du facteur de réplication.
Si seulement quelques nœuds ont une utilisation élevée du processeur, mais qu'elle est faible pour les autres, cela indique un problème de partition chaude, qui nécessite un examen plus approfondi.
Remarque
La modification de la référence SKU est prise en charge à l’aide du portail Azure, d’Azure CLI et du déploiement de modèles ARM. Vous pouvez déployer ou modifier un modèle ARM et remplacer la référence SKU par l’une des valeurs 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
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 Standard_DS13_v2 et souhaitez passer à une référence SKU plus grande comme 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 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.
- Supérieur ou égal à l’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 (écriture par cache) 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 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 vos IOPS sont inférieures à celles prises en charge par votre référence SKU, mais supérieures ou égales aux IOPS de disque, vous pouvez effectuer les actions 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 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 :
- Effectuez un scale-up vers une autre référence SKU prenant en charge davantage d’IOPS.
- Effectuez un scale-up des centres de données en ajoutant d’autres nœuds.
Pour plus d’informations, consultez Les performances des machines virtuelles et des disques.
Performances réseau
Dans la plupart des cas, les performances réseau sont suffisantes. Toutefois, si vous diffusez fréquemment des données, 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 référence SKU. Par exemple, le Standard_DS14_v2 SKU prend en charge 12 000 Mb/s. Comparez cette valeur à l’octet entrant/sortant 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 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
Vous devez planifier et provisionner 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 donné, l’introduction d’autres charges dans le 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 d’examiner occasionnellement les métriques d’espace disque. Cassandra accumule de nombreux disques, puis le 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 le compactage incapable de récupérer de 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 accédiez aux modèles pour une asymétrie éventuelle.
- Ajoutez d’autres disques, mais n’oubliez pas les 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 affecte la moitié de la mémoire de la machine virtuelle à la machine virtuelle Jave (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, 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. D’autres mémoires JVM peuvent être nécessaires si vous utilisez 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 effectuons des réparations tous les sept jours avec reaper, ce qui supprime les lignes dont le TTL a expiré, appelées tombstone. Certaines charges de travail suppriment des suppressions fréquemment et montrent 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'un nombre excessif de pierres tombales.
Une mesure à court terme si les requêtes ne sont pas satisfaites consiste à augmenter la valeur de tombstone_failure_threshold dans la configuration Cassandra par rapport à la valeur par défaut de 100 000.
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 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 passer en revue vos requêtes pour rester au-dessous de la taille de lot recommandée. Dans de rares cas, et en guise d’atténuation à court terme, vous pouvez augmenter batch_size_fail_threshold_in_kb dans la configuration de Cassandra en passant de la valeur par défaut de 50 à une valeur supérieure.
Avertissement de grande partition
Vous pouvez rencontrer cet avertissement dans les 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 de 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 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
Le 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 les applications orientées vers l'écriture et/ou sur les UGS à faible mémoire, ce problème peut conduire à des vidages fréquents et à des données fragmentées sstables, ce qui nécessite un compactage plus important. Dans ce cas, l’augmentation à au moins 4048 peut être bonne. Cette approche nécessite un étalonnage prudent pour s'assurer que d'autres opérations, comme les lectures par exemple, ne sont pas affectées.