Opérations Et Optimisation Des Performances Cassandra

Opérations  Et Optimisation Des Performances Cassandra

Dans cette rubrique, je couvrirai les bases de l’optimisation des performances générales d’Apache Cassandra: quand ajuster les performances, comment éviter et identifier les problèmes et les méthodologies permettant d’améliorer les performances.

Quand avez-vous besoin d’ajuster les performances?

optimiser:

Quand ça marche mais que ça pourrait être mieux. nous voulons obtenir de meilleures performances.

Dépannage:

Résoudre un problème qui aurait un impact sur les performances pourrait en réalité être cassé, pourrait simplement être lent dans un cluster, quelque chose de cassé peut se traduire par une performance lente.

Quels sont quelques exemples de plaintes liées aux performances qu’un administrateur pourrait recevoir concernant Apache Cassandra?

Plaintes liées à la performance:

  • c’est lent.
  • certaines requêtes sont lentes.
  • le programme X qui utilise le cluster est lent.
  • Un noeud est tombé.

Latence, débit et méthode U.S.E:

Mauvaise méthodologie.
Comment ne pas aborder les problèmes liés à la performance?

  • anti-éclairage de rue
  • anti-méthode de changement aléatoire
  • blâmer quelqu’un d’autre anti-méthode

Dans le réglage des performances, qu’essayons-nous d’améliorer?

latence – combien de temps un cluster, un noeud, un serveur ou un sous-système d’E / S met-il à répondre à une demande?
débit – combien de transactions d’une taille (ou d’une plage) donnée qu’un cluster, un nœud ou un sous-système d’E / S peuvent effectuer dans un laps de temps donné?
combien d’opérations par secondes notre nœud de cluster est-il en train de traiter?
Mais nous ne pouvons pas oublier les coûts !!

Quel est le lien entre la latence et le débit?

Théoriquement, ils sont indépendants les uns des autres.
Cependant, une modification de la latence peut avoir un effet proportionnel sur le débit.

Qu’est-ce qui cause un changement de latence et de débit?

Compréhension du réglage des performances: utilisation, saturation, erreurs, disponibilité

Qu’est-ce que l’utilisation? saturation? les erreurs ? disponibilité ?

Utilisation – à quel point les ressources sont-elles stressées?
Saturation – la mesure dans laquelle une ressource a mis en file d’attente un travail qu’elle ne peut pas servir
Erreurs – défaillance récupérable ou événements exceptionnels au cours d’une opération normale
Disponibilité – si une ressource donnée peut servir le travail ou pas

OBJECTIF:

Quelle est la première étape pour atteindre une performance?
objectif de réglage?
Fixer un objectif!
Quels sont quelques exemples d’objectifs de réglage de performances Cassandra couramment entendus? les lectures devraient être plus rapides,
L’écriture dans la table x devrait être plus rapide.
Le cluster doit pouvoir effectuer x transactions par seconde

Que doit prendre en compte un objectif de performance clairement défini?

Rédaction de SLA (contrat de niveau de service)
Nous avons besoin de savoir :
Quel est le type d’opération ou de requête?
lire ou écrire une charge de travail (sélectionner, insérer, mettre à jour ou supprimer)
nous devons comprendre la latence: exprimée en centile
par exemple, le rang de latence de lecture au 95e percentile est égal à 2 ms
débit: opérations par seconde
taille: exprimée en octets moyens
Nous devons penser à la durée: exprimée en minutes ou en heures
portée: espace de clés, table, requête
Exemple de SLA: « le cluster devrait pouvoir supporter
20 000 opérations de lecture de 2 Ko par seconde à partir de la table X pour
deux heures avec une latence de lecture de 95 ms au troisième centile. « 

Après avoir défini un objectif, comment la réalisation d’un objectif peut-elle être vérifiée?

En utilisant:

  • le temps a pris dans votre application
  • suivi de requête
  • plan de test jmeter
  • cassandra-stress personnalisable

Temps dans l’optimisation des performances informatiques:

Combien de temps dure une milliseconde? Pourquoi nous soucions-nous des millisecondes?

Tempos de latence courants dans Apache Cassandra:

  • les lectures de la mémoire principale devraient prendre entre 36 et 130 microsecondes
  • la lecture d’un disque SSD devrait prendre entre 100 microsecondes et 12 millisecondes
  • les lectures d’un lecteur de rotation SCSI connecté en série devraient prendre entre 8 millisecondes et 40 millisecondes
  • les lectures d’un disque SATA prennent plus de 15 millisecondes
    Exemple:
    Caractérisation de la charge de travail:

    Cas d’utilisation en classe et histoire Cassandra Une firme financière de taille moyenne utilise Cassandra pour gérer des données distribuées: 42 millions de cotes boursières basées sur un ensemble particulier de requêtes

Quelles requêtes ont conduit ce modèle de données?

Récupérer des informations sur un stock spécifique par identifiant. Trouvez toutes les informations sur les transactions boursières pour un symbole boursier et des horodatages de plage spécifiques. Trouvez toutes les informations sur les transactions boursières ayant eu lieu à une date spécifique sur une courte période.

Comment caractérisez-vous la charge de travail?

Quelle est la charge placée sur votre cluster?
Appeler une application ou une API
Adresse IP à distance

Qui est à l’origine de la charge?

Chemin de code ou trace de pile

Pourquoi appelle-t-on la charge?

Quelles sont les caractéristiques de charge?
débit
Direction (lecture / écriture)
inclure la variance
espace clavier et famille de colonnes
Comment caractérisez-vous votre charge de travail?
Comment la charge change-t-elle dans le temps et y a-t-il
un modèle quotidien?
Votre charge de travail est-elle lourde à lire ou à écrire?
Quelle est la taille de vos données?
Combien de données sur chaque nœud (octets sur nœud = densité de données)?
Les données actives tiennent-elles dans le cache tampon?

Impact du modèle de données sur les performances: comment le modèle de données affecte-t-il les performances?

Larges lignes: en raison de problèmes de modélisation des données, par exemple, une ligne de partition qui grossit considérablement par rapport aux autres lignes des données.
Points chauds: par hasard, un nœud devient responsable d’un pourcentage plus élevé de l’espace de jeton que les autres nœuds du cluster.
Mauvais index primaire ou secondaire
Trop de pierres tombales (beaucoup de suppression)

Considérations relatives au modèle de données:

Comprendre comment la clé primaire affecte les performances.
Examinez les modèles de requête et ajustez la manière dont les tables sont modélisées.
Découvrez l’impact du facteur de réplication et / ou du niveau de cohérence sur les performances.
Un changement de stratégie de compactage peut avoir un impact positif (ou négatif).
Paralléliser lit / écrit si nécessaire.
Examinez en quoi le déplacement de données rarement utilisées peut améliorer les performances.
Découvrez l’impact du cache de famille par colonne.
Quelle est la relation entre le modèle de données et les optimisations du chemin de lecture de Cassandra (cache de clé / ligne, filtres de bloom, résumé de partition, index de partition, carte de décalage de compression)?
Imbrication des données (permet une plus grande flexibilité dans la structure de la famille de colonnes.) (Conservez toutes les données sur la même partition pour répondre à une requête donnée), mais il est facile de trouver un modèle pour conserver la plupart des ensembles de données actifs dans le cache, données fréquemment consultées qui sont en cache peuvent améliorer les performances.

Méthodologies:

Réglage actif des performances:
Nous nous concentrons sur le problème en particulier et nous vérifions s’il est résolu – suspectons qu’il existe un problème, isolons le problème à l’aide d’outils, déterminons si le problème se trouve dans Cassandra, dans l’environnement ou les deux.
Vérifiez les problèmes et testez leur reproductibilité, corrigez les problèmes à l’aide de stratégies de réglage, testez, testez et testez à nouveau.

Réglage passif des performances:
« Contrôles systématiques » du système: en recherchant un seuil, nous ajustons en fonction de la croissance et surveillons régulièrement les zones de santé clés de Cassandra / environnement.
Identifiez et accordez-vous pour la croissance / l’évolutivité future.
Vérifier les problèmes et tester la reproductibilité, résoudre les problèmes en utilisant des stratégies de réglage, tester, tester et tester à nouveau
Appliquez des stratégies de réglage au besoin.

Nous devons utiliser la méthode USE comme outil de dépannage:

Cette méthode nous donne la méthodologie pour rechercher tous les composants du système, pas un seul. C’est la stratégie définie par Brendan Gregg www.brendangregg.com/USEmethod/use-linux.html.
Effectue également une vérification de l’état de santé de divers composants du système afin d’identifier les goulots d’étranglement et les erreurs.
séparé par composants, type et métrique pour réduire la portée et trouver l’emplacement du problème.
Quelles sont les deux choses à améliorer dans l’optimisation des performances? latence et débit.
Quels sont les deux types de méthodologies de réglage des performances? actif et passif
Quel outil peut être utilisé pour obtenir une base de performance? jeter ou cassandra-stress

Cassandra-stress:

Interprétation de la production de cassandra-stress
Chaque ligne rapporte des données pour l’intervalle entre le dernier temps écoulé et le temps écoulé actuel, défini par l’option –progress-interval (10 secondes par défaut).

cassandra-stress write -node 192.168.56.71 
INFO  04:11:53 Impossible de trouver le transport epoll natif de Netty dans le chemin de classe, par défaut, NIO.
INFO  04:11:56 Utilisation du nom de centre de données 'datacenter1' pour DCAwareRoundRobinPolicy (s'il est incorrect, indiquez le nom de centre de données correct avec le constructeur DCAwareRoundRobinPolicy)
INFO  04:11:56 New Cassandra host /192.168.56.71:9042 added
INFO  04:11:56 New Cassandra host /192.168.56.72:9042 added
INFO  04:11:56 New Cassandra host /192.168.56.73:9042 added
INFO  04:11:56 New Cassandra host /192.168.56.74:9042 added
Connected to cluster: Training_Cluster
Datatacenter: datacenter1; Host: /192.168.56.71; Rack: rack1
Datatacenter: datacenter1; Host: /192.168.56.72; Rack: rack1
Datatacenter: datacenter1; Host: /192.168.56.73; Rack: rack1
Datatacenter: datacenter1; Host: /192.168.56.74; Rack: rack1
Created keyspaces. Sleeping 1s for propagation.
Sleeping 2s...
Préchauffage en cours WRITE avec 50000 itérations ... Échec de la connexion via JMX; AVERTISSEMENT: le mode incertitude (err & amp; lt;) entraîne une charge de travail inégale entre les exécutions de threads; il convient donc de l'utiliser pour l'analyse de haut niveau uniquement. Exécution avec 4 threadCount L'exécution de WRITE avec 4 threads jusqu'à ce que la valeur moyenne & amp; amp; lt; 0.02 Échec de la connexion via JMX. ne pas collecter ces statistiquestype,      total   ops,    op/s,    pk/s,   row/s,    mean,   med,    .95,     .99,    .999,   max,  time,  stderr, 
total,      402,   403,     403,     403,    10,4,   5,9,    31,4,    86,2,   132,7,   132,7,  1,0,  0,00000,
total,      979,   482,     482,     482,     8,1,   6,3,    17,5,    45,9,    88,3,    88,3,  2,2,  0,06272,
total,      1520,  530,     530,     530,     7,5,   6,4,    14,8,    24,3,   103,9,   103,9,  3,2,  0,07029,  
total,      1844,  321,     321,     321,    11,9,   6,4,    33,0,   234,5,   248,5,   248,5,  4,2,  0,06134,  
total,      2229,  360,     360,     360,    11,3,   5,4,    43,6,   127,6,   145,4,   145,4,  5,3,  0,06577,  
total,      2457,  199,     199,     199,    20,2,   5,9,    82,2,   125,4,   203,6,   203,6,  6,4,  0,11009,   
total,      2904,  443,     443,     443,     8,9,   7,0,    23,0,    37,3,    56,1,    56,1,  7,4,  0,09396,   
total,      3246,  340,     340,     340,    11,7,   7,4,    41,6,    87,0,   101,0,   101,0,  8,5,  0,08625,   
total,      3484,  235,     235,     235,    16,6,   7,2,    76,1,   151,8,   152,1,   152,1,  9,5,  0,09208,   
.............
Results:
op rate                   : 388 [WRITE:388]
partition rate            : 388 [WRITE:388]
row rate                  : 388 [WRITE:388]
latency mean              : 10,2 [WRITE:10,2]
latency median            : 7,1 [WRITE:7,1]
latency 95th percentile   : 25,9 [WRITE:25,9]
latency 99th percentile   : 71,2 [WRITE:71,2]
latency 99.9th percentile : 150,3 [WRITE:150,3]
latency max               : 396,8 [WRITE:396,8]
Total partitions          : 63058 [WRITE:63058]
Total errors              : 0 [WRITE:0]
total gc count            : 0
total gc mb               : 0
total gc time (s)         : 0
avg gc time(ms)           : NaN
stdev gc time(ms)         : 0
Total operation time      : 00:02:42
Sleeping for 15s

Les données                            La description
--------------------------------------------------------------------------------------------------
total	                           :Nombre total d'opérations depuis le début du test.
interval_op_rate	           :Nombre d'opérations effectuées par seconde pendant l'intervalle 
(default 10 seconds).
interval_key_rate	           :Nombre de clés / lignes lues ou écrites par seconde pendant l'intervalle 
(normalement identique à interval_op_rate sauf si vous faites des tranches de plage). latence Latence moyenne: pour chaque opération effectuée pendant cet intervalle. 95ème                             :95% of the time the latency was less than the number displayed in the column 
(Cassandra 1.2 or later).
99th                               :99% of the time the latency was less than the number displayed in the column 
(Cassandra 1.2 ou plus tard).
écoulé Nombre de secondes: écoulé depuis le début du test.

Accord Cassandra:

Pour que les performances soient optimales, il faut comprendre.
Comprendre ce que certains indicateurs signifient.
Comment le logiciel que nous ajustons est-il une architecture?
Dans le système distribué, nous devons savoir comment le logiciel d’un nœud fonctionne avec le logiciel des autres nœuds.
c’est pour la section suivante: comment différentes pièces de Cassandra peuvent-elles être assemblées?
Nous pouvons parler de Cassandra, modèle de données.
Comment pouvons-nous obtenir des métriques et comment ils peuvent être performants.
Dans la section suivante, nous parlerons du réglage de l’environnement: JVM et système d’exploitation.
Il se concentrera sur le réglage du disque et le compactage.

Examiner la santé et le réglage du cluster et des nœuds:

Discutez de la conception et de l’ajustement des tables: l’optimisation des performances dépend de la compréhension.
Comprendre quel genre de métriques signifie? comment le logiciel que nous sommes
le réglage est l’architecture? avec le système distribué, nous devons savoir comment le logiciel d’un nœud fonctionne avec le logiciel avec d’autres nœuds?
quelques métriques que nous exposerons
nous parlons de Cassandra, du modèle de données, puis de l’optimisation de l’environnement en tant que machine virtuelle et du système d’exploitation, ainsi que de l’optimisation du disque et de la compression.

Parlons de la mise au point du cluster et des noeuds: quelles sont les activités d’un cluster Cassandra?
se passer entre les nœuds?
que se passe-t-il sur le réseau? lorsque nous creuserons un problème de performances, nous examinerons tous les nœuds et pas seulement un:
les réponses sont: coordinateur, potins, réplication, réparation, réparation de lecture, amorçage,
retrait de noeud, mise hors service de noeud.
nous devons creuser non seulement un noeud mais un noeud supplémentaire

Pourquoi choisir un nœud Cassandra dans un nœud? lire la performance, écrire,
surveiller, participer aux clusters, maintenir la cohérence.
Cassandra a beaucoup de choses à faire en interne, il y a une architecture qui
comment est-il organisé? Comment Cassandra organise-t-elle tout ce travail?
la réponse de ceci est SEDA (architecture pilotée par événement staged), ainsi nous avons
plusieurs pools de threads et le service de messagerie pour savoir comment fonctionne la file d’attente.

Qu’est-ce qu’un pool de threads?

Par exemple, nous avons le pool de threads: workers: 6

  task          queue:max pending tasks:7        worker thread
  task task task task task task task task task   worker thread 
  task                                task       worker thread
  blocked tasks

Quels sont les pools de threads de Cassandra?

read readstage:32

write (mutationstage,flushwriter,memtablepostflusher,countermutation,migrationstage)
monitor (memorymeter:1,tracing)
participate in cluster (requestresponsestage:%CPUs,pendingrangecalculator:1,gossipstage:1)
maintain consistency(commitlogarchiver:1,miscstage:1 snapshoting/replicate data after node remove)
antientropystage:1 repair consistency – merkle tree build,internal responsestage:#CPUs,HintedHanoff:1,readrepairstage:#CPUs)

Nous connaîtrons, par exemple, le thread unique sur le moniteur (memorymeter: 1).
Lequel a le nombre configurable de threads? sa lecture (readstage: 32 *).

L’utilitaire tel que nodetool tpstats qui peut nous donner des métriques, combien de travail chaque pool fait-il?

Combien de blocs actifs ajoutés:
actif – nombre de messages extraits de la file d’attente, en cours de traitement par un thread.
en attente – nombre de messages dans la file d’attente en attente d’un thread.
complete – nombre de messages terminés.
bloqué – lorsqu’un pool atteint son nombre maximal de threads, il commence à être mis en file d’attente.
jusqu’à ce que la taille maximale soit atteinte. une fois atteint, il bloquera jusqu’à ce qu’il y ait de la place dans la file d’attente.
total bloqué / toutes les heures bloquées – nombre total de messages bloqués.

Pools de threads Cassandra: étapes multi-threadées:

readstage (affecté par la mémoire principale, le disque) – effectue des lectures locales.
mutationstage (affecté par la CPU, la mémoire principale, le disque) – effectue une insertion / mise à jour locale, une fusion de schéma, une relecture de journal valide, des astuces en cours).
requestresponsestage (affecté par le réseau, d’autres nœuds) – lorsqu’une réponse à une demande est reçue, c’est l’étape utilisée pour exécuter les rappels créés avec la demande d’origine.
flushwriter (affecté par la CPU, le disque) – trie et écrit les memtables sur le disque.
hintedhandoff (un thread par hôte reçoit des indications, affecté par le disque, le réseau, les autres nœuds) – envoie les mutations manquantes aux autres nœuds
memorymeter (plusieurs threads séparés) – mesure l’utilisation de la mémoire et le ratio de temps réel d’une memtable.
readrepairstage (affecté par le réseau, d’autres nœuds) – effectue une réparation de lecture
countermutation (anciennement replicateOnWriteStage) – exécute un compteur écrit sur des nœuds non coordinateurs et se réplique après une écriture locale
internalresponsestage – correspond aux messages non initiés par le client, y compris l’amorçage et la vérification du schéma.

Stades mono-filetés:
Gossipstage (affecté par le réseau) – communication de potins
anti-entropystage (affecté par le réseau, d’autres nœuds) – construire un arbre à pastilles et réparer la cohérence
migrationstage (affecté par le réseau, d’autres nœuds) – apporte des modifications au schéma
miscstage (affecté par le disque, le réseau, les autres nœuds) – capture instantanée, réplication des données après la suppression du nœud
memtablepostflusher (affecté par le disque) – opérations après avoir vidé le memtable.
Supprimez les fichiers journaux de validation contenant toutes les données persistantes dans sstables.
rincer les index secondaires non liés à une famille de colonnes
traçage – pour le traçage des requêtes
commitlogarchiver (officiellement commitlog_archiver) – sauvegarde ou restaure un journal de validation.

Types de messages:
Géré par le pool de threads readstage (lecture: lecture de données dans le cache ou le disque, range_slice: lecture d’une plage de données, paged_range: lecture d’une partie d’une plage de données)
Géré par le pool de threads de la séquence de mutation: (mutation: écriture des données d’écriture (insertion ou mise à jour), counter_mutation: modification des colonnes de compteurs, read_repair: mise à jour des données non synchronisées découvertes lors d’une lecture)
Manipulé par readresponsestage: (request_response: répondre à un coordinateur, _trace: utilisé pour tracer une requête (activer le traçage ou toutes les requêtes (probabilité de traçage))
Binaire: obsolète

Pourquoi certains types de messages sont-ils « droppables »?
Si le message défini dans l’une des files d’attente est long et trop long, le délai sera déterminé par le fichier cassandra.yaml, il sera supprimé.
Pourquoi Cassandra va faire ça? Pourquoi Cassandra ne fait pas mon travail?
si le nœud dispose d’une ressource suffisante pour effectuer le travail, il ne l’a pas abandonné.
en pratique, si j’ai une lecture à donner à Cassandra et que le délai d’attente est écoulé et que le délai d’attente est écoulé. que fait le coordinateur dans cette situation? cela dépend, peut-être peut-il être satisfait par le niveau de cohérence d’un autre nœud, puis le niveau de cohérence renvoie la requête ou le délai d’attente renvoyé au client s’il s’agit du niveau de cohérence le plus élevé.
Dans la lecture, il n’y a pas d’accord, nous pouvons généralement ré-exécuter la requête.
Cependant nous avons une autre mutation (insertion / suppression / mise à jour) ils peuvent être dans la file d’attente trop longtemps (2 secondes) alors rien n’est fait,
alors qu’est-ce qui se passe? le coordinateur peut être expérimenté la
le temps imparti, peut-être stocke-t-il l’indice, peut-être qu’il peut être renvoyé au pilote pour qu’il réessaye, nous
Je ne sais pas, mais la chose importante que certaines actions de récupération peuvent prendre à cet égard.
toujours ce noeud qui a une écriture n’effectue pas, cette chose comme la réparation de lecture ou la commande de réparation peut renvoyer le résultat au client.

Pourquoi certains types de messages sont « droppables »
certains messages peuvent être supprimés pour hiérarchiser les activités dans cassandra en cas de conflit de ressources important.
le nombre de ces messages supprimés est dans la sortie de nodetool tpstats
si vous voyez des messages supprimés, vous devriez enquêter.
Question: Quel est l’état de votre cluster? nous avons nodetool pour collecter des informations sur notre cluster ou OpsCenter pour collecter des informations sur notre cluster.
nodetool nous donne des informations sur ce qui se passe en ce moment, il est cumulatif
mais on ne sait pas ce qui se passe à la dernière seconde, c’est bon pour une évaluation générale
et aussi pour la comparaison entre les noeuds (nodetool -h node0 tpstats, nodetool -h node0 compactionstats)
nodetool -h noeud netstats (nous devons rechercher des statistiques de réparation) read repair
est lorsque nous recherchons des différences et si nous trouvons des différences entre les noeuds, nous allons les réparer en augmentant cch (blocage), une autre réparation de lecture est l’arrière-plan, si nous exécutons la requête, le niveau de cohérence 1 et le coordinateur ne renverront probablement aucune réponse application, si nous obtenons une différence. alors nous augmenterons le cch (fond).Trop large: nous avons une partition trop grande
Trop étroit: la partition est trop petite et notre requête prend en compte toutes les partitions.
Points chauds: nous avons un client qui décide de concevoir la partition par code de pays, puis 90% de toutes les lignes sont aux États-Unis et le reste dans tous les autres pays.

indices primaires et secondaires médiocres:
Trop de pierres tombales:

nous avons une charge de travail qui consiste à supprimer et à lire des données sur la même partition, ce qui peut avoir un impact considérable sur les performances de lecture.

OpsCenter

Modification des niveaux de journalisation avec nodetool setlogginglevel:
nodetool getlogginglevels: utilisé pour obtenir les niveaux de journalisation d’exécution actuels

root@ds220:~# nodetool getlogginglevels
Logger Name                                      Log Level
ROOT                                             INFO
DroppedAuditEventLogger                          INFO
SLF4JAuditWriter                                 INFO
com.cryptsoft                                    OFF
com.thinkaurelius.thrift                         ERROR
org.apache.lucene.index                          INFO
org.apache.solr.core.CassandraSolrConfig         WARN
org.apache.solr.core.RequestHandlers             WARN
org.apache.solr.core.SolrCore                    WARN
org.apache.solr.handler.component                WARN
org.apache.solr.search.SolrIndexSearcher         WARN
org.apache.solr.update                           WARN

nodetool setlogginglevel: utilisé pour définir le niveau de journalisation d’un service peut être utilisé au lieu de modifier les niveaux possibles du fichier logback.xml:

ALL
TRACE
DEBUG
INFO
WARN
ERROR
OFF

on peut augmenter le niveau de journalisation par exemple pour un espace de noms uniquement vers DEBUG ou même TRACE

Réglage du modèle de données:

L’un des composants clés de Cassandra est le modèle de données.
pour le réglage des performances, nous avons la charge de travail qui est placée dans la base de données. c’est à l’endroit indiqué sur la table de Cassandra que le modèle de données vient. Nous avons ensuite le réglage logiciel (OS, JVM, Cassandra) et le matériel.
dans de nombreux cas, la mise à jour du matériel est une option.
Lorsque nous devons diagnostiquer le modèle de données, Cassandra fournit de nombreux outils pour savoir comment notre table fonctionne, ainsi que la requête.
En voici un nodetool cfstats, additionaly nodetool cfhistograms
Lorsque nous identifions la requête que nous pouvons suspecter, nous avons le traçage CQL mais nous avons aussi nodetool settraceprobability
nodetool cfstats example:

cfstats1

Celui-ci ci-dessous est le numéro d’agrégat de l’espace de clé non utilisé pour cette table particulière:
cfstats2
Ensuite, sous le numéro global du stock de table uniquement:

cfstats3
Ici, nous avons 13 sstable sur le disque pour cette table.
Quelle quantité de données est stockée sur le disque avec l’espace métrique utilisé? dans ce cas, nous avons des octets en direct et le nombre total d’octets est identique, cela signifie que dans ce tableau particulier, nous n’avons pas de suppression, nous ne mettons à jour que l’insertion, cependant, si je supprime ou met à jour, nous verrons la différence entre live et espace total utilisé, le nombre total sera plus grand que le live.
La mémoire off heap utilisée (1928102) nous indique combien de mémoire cette table utilise. Nous avons également quelques autres mesures telles que l’espace de filtrage bloom utilisé, octets: 7088, et la mémoire filtrée Bloom filtrée utilisée, octets: 6984, la mémoire récapitulative Index optimisée utilisée: 390 et les métadonnées de compression extraites, octets : 1920728 et taille de données memTable, octets (36389573)

Conclusion:Si je regarde ces chiffres:

1928102 + 7088 + 6984 + 1920728 +36389573=40252475 bytes (39 MB)

Je peux savoir combien de mémoire de bélier consomme cette table.
Taux de compression SSTable: 0.173624: si j’active la compression comme ici. Nous avons 17% de compression de ce tableau.
Nombre de clés: 1664, cela ne compte que la partition. Donc, si nous avons un schéma de table simple, n’avons qu’une clé de partition, pas de colonne de cluster, ce nombre (1664) sera un nombre approximatif de lignes sur un serveur donné.
Ces métriques peuvent être différentes sur chaque serveur, nous devons donc examiner chaque serveur.
Nombre de cellules Memtable (126342), taille de données memTable, octets (36389573) et nombre de commutateurs memTable (107). MemTable data size (36389573), il s’agit d’une donnée qui est actuellement stockée en mémoire et qui se videra sur le disque. Pour le nombre de commutateurs memTable, cette métrique augmente chaque fois que je vide les données memTable sur le disque. Memtable nombre de cellules indique combien de cellules nous avons en mémoire. Si nous divisons cela par nombre de colonnes en regardant dans la définition du schéma (exemple 5 colonnes), 126342/5 = 25268,4, nous pouvons connaître approximativement le nombre de lignes car Cassandra stocke la cellule les rangées.
Le nombre de lectures locales, la latence de lecture locale, le nombre d’écritures locales et la latence d’écriture locale indiquent les métriques lues, écrites pour cette table particulière. Le nombre de lectures locales et le nombre d’écritures locales nous donnent l’indication de savoir si nous avons lu ou écrit beaucoup. Pour notre exemple, nous avons écrit heavy (4352651 supérieur à 942517).
Tâches en attente: 0 ceci compte toutes les tâches en attente, nous l’avons vu plus tôt dans les tpstats.Bloom

filtrer les faux positifs, faux ratio de bloom, espace de filtre de bloom utilisé, octets, filtre de bloom hors mémoire utilisée, octets: la métrique principale ici est le faux ratio (0,0000) qui prend le nombre de faux positifs de filtre de bloom (48566) divisé par le nombre de lectures locales (942517), qui peut nous donner le faux ratio. Qu’avons-nous payé pour obtenir 48566 de faux positifs de filtre bloom afin d’obtenir un nombre de lectures locales de 942517? Nous avons payé cet espace de filtre de bloom mémoire RAM utilisé, octets: 7088 plus le filtre Bloom de la mémoire vive utilisée, octets: 6984, total de ces mémoires: 7088 + 6984 = 14072 octets environ: 14 Ko de RAM pour obtenir des faux positifs afin d’éviter des disques inutiles. chercher. Si cela est inacceptable, nous pouvons le régler en dépensant plus de mémoire, en réduisant le nombre de faux positifs et, par conséquent, en réduisant le nombre inutile de recherches de disque inutiles. Les performances de lecture augmenteront donc.
Index récapitulatif de la mémoire de base utilisée, en octets: 390: est une structure de mémoire que nous utilisons pour nous aider à accéder correctement à la mémoire dans l’index de la partition. Dans ce cas, nous avons payé 390 octets de mémoire, ce qui est également réglable, mais dans Cassandra 2.1, nous ne pouvons pas l’ajuster automatiquement.
Métadonnées de compression hors de la mémoire de base utilisée, octets: 1920728 octets, il s’agit de la quantité de mémoire vive consommée pour la compression. Nous pouvons regarder aussi.

Octets minimum de partition compactée, octet maximum de partition compactée, octets moyens de partition compactée: métriques très utiles pour obtenir des indications sur la manière dont nous avons configuré notre partition. Qu’est-ce que je veux dire par là? si nous regardons les octets minimaux de partition compactée (35426 octets = 35 Ko) et les octets moyens de partition compactée (122344216 octets = 116,68 Mo) et si nous examinons le nombre maximal d’octets (557074610 octets = 531,28 Mo), nous avons l’idée de la distribution de la taille de la partition. Si nous regardons le nombre d’octets moyens (122344216 octets = 116,68 Mo), il y a une énorme différence entre le min et le max, nous avons probablement la bonne indication du point chaud des données, la partition est anormalement beaucoup plus grande que le autres partitions.

Nombre moyen de cellules vivantes par tranche, nombre moyen de pierres tombales par tranche: ces mesures ne sont utiles que pour la production.
Nombre moyen de cellules vivantes par tranche (cinq dernières minutes): 2,0: la lecture était en moyenne de 2,0 et 0,0 pour les pierres tombales, ce qui est bien. S’il s’agit par exemple de 2.0 pour les pierres tombales, cela signifie que toutes les cinq dernières minutes de lecture pour 2.0, il est probable qu’il sélectionne à 2.0 pierres tombales, ce qui donne 50% de performances de lecture supplémentaires aux pierres tombales.

Malheureusement, ce nombre de pierres tombales ne peut pas être identique. C’est la bonne indication que nous avons l’exception grande suppression de données.

Pour toutes ces métriques, nous avons des paramètres ajustables.

Remarques:
Labloom_filter_fp_chance etread_repair_chance contrôler deux choses différentes. Habituellement, vous les laisseriez définis sur leurs valeurs par défaut, ce qui devrait bien fonctionner pour les cas d’utilisation les plus courants.bloom_filter_fp_chance: contrôle la précision des données de filtre de bloom pour les fichiers SSTables stockés sur le disque. Le filtre bloom est conservé en mémoire et lorsque vous effectuez une lecture, Cassandra vérifie les filtres bloom pour voir quelles tables SSTables pourraient contenir des données pour la clé que vous lisez. Un filtre bloom donne souvent de faux positifs et lorsque vous lisez réellement la table SSTable, il s’avère que la clé n’existe pas dans la table et que sa lecture fait perdre du temps. Plus la précision utilisée pour le filtre de bloom est bonne, moins il donnera de faux positifs (mais plus il aura besoin de mémoire).
Du
documentation:
0 Active le filtre de Bloom non modifié, effectivement le plus grand possible.
1.0 Désactive le filtre Bloom
Le paramètre recommandé est 0.1. Une valeur plus élevée génère des rendements décroissants.
Ainsi, un nombre plus élevé augmente les risques de faux positif (fp) lors de la lecture du filtre de bloom.
read_repair_chance: contrôle la probabilité qu’une lecture d’une clé soit vérifiée par rapport aux autres répliques de cette clé. Ceci est utile si votre système a des temps d’arrêt fréquents des nœuds, ce qui entraîne une désynchronisation des données. Si vous effectuez beaucoup de lectures, la réparation de lecture ramènera lentement les données dans la synchronisation comme vous le faites sans avoir à exécuter une réparation complète sur les nœuds. Des paramètres plus élevés entraîneront davantage de réparations en arrière-plan et consomment plus de ressources, mais synchroniseraient les données plus rapidement lors de la lecture.
Voir la documentation sur ce lien: http://docs.datastax.com/en/cql/3.1/cql/cql_reference/
Vous pouvez également lire ce document: http: //www.datastax.com/dev/blog/common-mistakes-and-misconceptions
Voici la description de cette table:desc-table1

Ci-dessous, nous avons des paramètres réglables pour cette table:
desc-table2
Ces paramètres influencent directement les mesures que nous avons vues précédemment.
Exemple:
bloom_filter_fp_chance=0.010000, cela a un impact sur le nombre de faux positifs que nous avons obtenus et sur la quantité de mémoire que nous allons donner à faible ou élevée.
caching = ‘KEYS_ONLY’: Dans ce cas, il s’agit uniquement d’une clé. Nous allons simplement mettre en cache uniquement la clé, mais nous avons la possibilité de mettre en cache le cache de lignes. Nous allons donc augmenter l’utilisation de la mémoire de cette table, qui a également un impact important.
dclocal_read_repair_chance = 0.100000 et read_repair_chance = 0.00000: ces paramètres ont une influence sur les émissions sans blocage dans tpstats.
gc_grace_seconds = 864000: cela a un impact sur les pierres tombales, combien de temps nous pouvons conserver sur les pierres tombales, mais sur la dernière ligne que nous avons vue précédemment (pierres tombales moyennes par tranche (cinq dernières minutes), donc ajustable.
index_interval = 128: dans Cassandra 2.1, un intervalle max et min, ils auront un impact sur le résumé de l’index en dehors de la mémoire utilisée, octets vus plus tôt. C’est accordable.
Populate_io_cache_on_flush = ‘false’: dans Cassandra 2.0, cela nous permet de peupler si nous voulons vider le disque et dire.
MemTable_flush_period_in_ms = 0 si nous voulons vider le disque en planifiant, la plupart des gens le font.
Compression = {‘sstable_compression’: ‘LZ4compressor’}: cela peut avoir un impact sur le taux de compression observé auparavant. Si nous le voulons, nous pouvons désactiver la compression. Pourquoi changeons-nous cela? Peut-être que le taux de compression élevé s’échange probablement en dehors du cycle de traitement, nous pouvons le changer.
Speculative_retry = ’99 .0PERCENTILE ‘: cela n’a pas d’impact sur la sortie tpstats. Lorsque nous effectuons une lecture, nous pouvons utiliser une réplication supplémentaire pour sentir la requête. Cassandra attendra ce long 99,0%. Si le quorum est atteint, chaque réplicat ira demander à d’autres réplicat de récupérer les données. Cassandra attendra. ce long 99.0 PERCENTILE en terme en millisecondes.

NODETOOL CFHISTOGRAMS:

Passons à la commande nodetool cfhistograms: dans Cassandra 2.0, elle est assez longue, elle nous donne un très beau seau. Aussi, nous avons un nouveau format pour le centile sstables écrit latence, latence de lecture, taille de la partition, nombre de cellules

Comment nous lisons nous?
sstables par read:

31261 lecture sera satisfaite par un seul sstable mais nous avons 240663 opérations de lecture seront satisfaites en ajoutant un autre sstable, que deux disques recherchent pour que la performance soit là, puis quand nous descendons ici, nous avons 397454 opérations de lecture en ajoutant un autre sstables, nous avons trois sstables, que trois disques cherche. Quand nous y allons, la performance ralentit, nous avons le problème de performance, nous devons entrer à l’intérieur pour savoir comment cela se passe.
Généralement, si nous avons ce problème, c’est généralement la fonction de compactage qui prend du retard. Le compactage est la tâche à faible priorité, il contient un disque, nous ne le faisons pas lorsque nous avons une activité énorme sur le cluster.
Conséquence: il faut lire sur les stables pour satisfaire plus de lus.
Nous voyons ici sur les cinq stables nous avons 272481 opérations de lecture pour satisfaire le problème de read.
Suivant est la latence d’écriture:

Nous avons vu dans la commande nodetool cfstats, une latence en lecture locale: 0 000 ms et une latence en écriture locale: 0 000 ms.
En latence d’écriture, nous sommes en microsecondes. Ici, nous voyons que 2415947 opérations d’écriture seront terminées dans 50 us (microsecondes), ceci est la responsabilité, mes opérations d’écriture terminées en 50, nous avons donc une longue queue, puis lorsque nous descendons sur la latence d’écriture, le maximum était 126934 us: 1
Pour la latence de lecture, 50 us (microsecondes) d’opérations de lecture ont 12976, il s’agit d’un mâle pour les opérations de lecture. Cela prouve qu’avec Cassandra, la latence d’écriture est bien inférieure à la latence de lecture.

Une autre tendance est la notion de deux bosses:
Voici la première bosse:

Deuxième bosse:

Ceci est une indication de lecture depuis le bélier pour le premier choc et de lecture depuis le disque pour le deuxième choc.

Taille de la partition:

Nous avons donc une bonne sortie pour la taille de la partition, ces données sont généralement représentatives de cfstats par les métriques suivantes (octets minimum de partition compactée, octets maximum de partition compactée et octets moyens de partition compactée).
Nous pouvons voir ici que nous avons une partition avec 42Ko et à la fin, ma plus grande a 25109160 octets (24Mo). 0, 1, 2 signifie que nous créons le seau.

Nombre de cellules par partition:
Parfois, les gens ont un grand volume de données dans chaque cellule, ce qui influence définitivement le nombre de partitions, mais nous avons des données volumineuses et un petit nombre de cellules (0, 1, 2). En combinant les informations ci-dessous avec lesquelles nous avons vu la taille de la partition, nous pouvons voir comment les données sont disposées sur la durée du modèle de données. Cela regarde le schéma de la table

Donc, cette ligne signifie que 3 de ma partition ont 4866323 cellules

Quiz:
Laquelle des informations suivantes CQL affiche-t-elle pour une trace de requête? Temps écoulé
Pour lequel des composants suivants ne trouveriez-vous pas de statistiques dans une sortie nodetool cfstats? cache de lignes
nodetool cfhistograms affiche les statistiques par espace de clé pour la latence de lecture et d’écriture? faux seulement pour la table.

Réglage de l’environnement:

Certains nous devons ajuster d’autres composants. Par exemple:
Les goulots d’étranglement les plus courants à Cassandra? Point de contrôle des performances, des choses qui ralentissent les performances du système.
Les goulots d’étranglement les plus courants sont:
Matériel inadéquat.
Paramètres JVM mal configurés: Cassandra s’exécute sur cette machine virtuelle.
Utilisation élevée du processeur: particulièrement pour la charge de travail en écriture, nous pouvons voir la liaison du processeur Cassandra, le choix du processeur.
Réglage du cache mémoire insuffisant ou incorrect: cette référence pour la lecture. Ce point est très en dehors de Cassandra.
J’aime conduire ce point.
Question: Quel est le meilleur moyen de faire face à un matériel de nœud inadéquat dans un cluster Cassandra?
Beaucoup de gens demandent, nous avons une machine alors nous voulons la performance alors que pouvons-nous faire?
Mettez à niveau le matériel. C’est la mauvaise nouvelle.
Si nous ne disposons pas d’équipement adéquat pour le travail, ce n’est pas une bonne idée de le faire.
Nous pourrions dire d’ajouter un autre nœud si la machine existante ne fonctionne pas.

Quelles sont certaines des technologies dont dépend un nœud Cassandra?
Java, JVM, JNA, JMX et un tas d’autres choses qui commencent par « j »

JVM:

Cassandra est le programme java, nous saurons comment fonctionne le JVM, nous pourrons donc l’accorder.
Quand nous pouvons le faire, JVM a beaucoup d’options.
Si nous lançons cette commande:

java -XX: + PrintFlagsFinal

Nous verrons toutes les options.
JVM et Garbage Collection (GC): qu’est-ce que la récupération de place? Java donne au développeur l’affectation et la libération de la mémoire. Java peut se plaindre de toutes les ressources de la machine, beaucoup de RAM, de CPU, d’E / S.

Tas générationnel JVM:

Lorsque nous commençons le processus java, jvm allouera un gros bloc de RAM et que le bloc qui sera géré pourra être divisé en deux. À l’intérieur de ce bloc, il s’agit d’un tas, il se divise en plusieurs parties, nous avons la nouvelle génération, l’ancienne génération et la permanente. après java 8, changement permanent. Qu’est-ce que fait? Il stocke toutes les définitions de classes.
Ce qui est important, c’est que Cassandra démarre tout le code dans la plus grande partie de la génération permanente, qui ne pouvait pas changer de taille.

Avec Cassandra, on peut tout faire en perm gen.
Mais dans la nouvelle génération, nous avons des espaces Eden et de survie. Ainsi, lorsque nous créons de nouveaux objets, tous types d’objets, cet objet sera créé dans Eden. Disons que nous l’avons créé à l’intérieur de la fonction, puis il sera créé dans l’Eden et à mesure que l’espace d’eden se remplira d’objets alloués pouvant être envoyés par le ramasse-miettes kik, que le premier ramasse-miettes.
Cette pièce (new gen) s’appelle parallèle new.
La chose importante est que si Eden se remplit, nous devons rechercher des déchets, nous allons trouver et déposer tous les objets qui ne seront pas des références et les désallouer. Cependant, il y aura d’autres objets qui sont toujours des références, ils peuvent être déplacés vers la zone de survie dans New gen.
Et après la survie, ce processus pourrait être promu à la vieille génération.
Il existe de nombreuses options pour définir le nombre de fois que les objets peuvent être sur Eden ou pour passer à la survie et à la vieille génération. Beaucoup d’options.
Ce sont (vieux gen), peut être remplir avec les options.
Regarde ça.
J’ai dans mon cluster de test, 4 nœuds travaillant dans différentes machines virtuelles.

nodetool status
[hduser@base cassandra]$ nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load     Tokens Owns Host ID                           Rack
UN 192.168.56.72 40.21 MB 256   ? 5ddb3532-70de-47b3-a9ca-9a8c9a70b186 rack1
UN 192.168.56.73 50.88 MB 256   ? ea5286bb-5b69-4ccc-b22c-474981a1f789 rack1
UN 192.168.56.74 48.63 MB 256   ? 158812a5-8adb-4bfb-9a56-3ec235e76547 rack1
UN 192.168.56.71 48.52 MB 256   ? a42d792b-1620-4f41-8662-8e44c73c38d4 rack1
[/php]
[php]cassandra-stress write -node 192.168.56.71
INFO 23:56:42 Using data-center name 'datacenter1' for DCAwareRoundRobinPolicy 
(if this is incorrect, please provide the correct datacenter 
name with DCAwareRoundRobinPolicy constructor) INFO 23:56:42 New Cassandra 
host /192.168.56.71:9042 added INFO 23:56:42 New Cassandra 
host /192.168.56.72:9042 added INFO 23:56:42 New Cassandra host /192.168.56.73:9042 
added INFO 23:56:42 New Cassandra host /192.168.56.74:9042 
added Connected to cluster: Training_Cluster Datatacenter: datacenter1; 
Host: /192.168.56.71; Rack: rack1 Datatacenter: datacenter1; 
Host: /192.168.56.72; Rack: rack1 Datatacenter: datacenter1; 
Host: /192.168.56.73; Rack: rack1 Datatacenter: datacenter1; 
Host: /192.168.56.74; 
Rack: rack1 Created keyspaces. Sleeping 1s for propagation. 
Sleeping 2s... Warming up WRITE with 50000 iterations... 
Failed to connect over JMX; 
not collecting these stats WARNING: uncertainty mode (err<) 
results in uneven workload between thread runs, so should be used for high level 
analysis only Running with 4 threadCount Running WRITE with 4 threads 
until stderr of mean < 0.02 Failed to connect over JMX; not collecting 
these stats type, 
total ops, op/s, pk/s, row/s, mean, med, .95, .99, .999, max, time, stderr, errors, gc: #, max ms, sum ms, sdv ms, mb 
total, 2086, 2086, 2086, 2086, 1,9, 1,5, 4,2, 7,0, 46,4, 58,0, 1,0, 0,00000, 0, 0, 0, 0, 0, 0 
total, 4122, 2029, 2029, 2029, 2,0, 1,6, 4,8, 8,0, 14,0, 15,3, 2,0, 0,02617, 0, 0, 0, 0, 0, 0 
total, 6171, 2029, 2029, 2029, 1,9, 1,5, 5,1, 7,6, 12,0, 13,6, 3,0, 0,02038, 0, 0, 0, 0, 0, 0 
total, 8466, 2288, 2288, 2288, 1,7, 1,4, 4,2, 6,1, 11,9, 14,4, 4,0, 0,02715, 0, 0, 0, 0, 0, 0

Nous pouvons exécuter le programme appelé jvisualvm
Si nous avons le JDK installé ce java visual vm

Nous pouvons voir les plugins disponibles dans la fenêtre Outils et activer certains plugins tels que VisualVM-Glassfish, visual GC:

Nous pouvons voir l’espace Eden:

Dans le long terme, Cassandra a recommandé le collecteur CMS. En java 7, G1 existe et en java 8, il est très bon. Ainsi, selon la version de Cassandra que vous utilisez, ce sera CMS ou G 1.
CMS et G1 ont à la fois une génération ancienne et une génération permanente.

La différence est dans G1 nous avons plusieurs morceaux de mémoire contigus comme ceci:

G1 est très très bien avec très gros tas. Nous recommandons généralement un tas de 8 Go pour Cassandra.
Lorsque l’ancienne génération se remplit, nous pouvons avoir la capacité nécessaire et effectuer un regroupement des ordures en fusion, ce temps de pause peut durer une seconde. Cela amène la pause. Quelle est la notion de pausis? Lorsque nous effectuons la récupération de place dans CMS ou G1, une partie de la tâche consiste à arrêter la pause de travail, c’est-à-dire à arrêter le programme en cours et dans l’espace eden et survivor pour trouver des informations inutiles. objets afin que nous puissions les nettoyer.
Combien de temps cette pause est la dernière? est la fonction de quelques choses différentes
Combien d’objets sont encore en direct?
Le nombre de processeurs disponibles sur le jvm est également déterminant. Combien de temps la collecte des ordures s’y arrête
De plus, CMS propose une des autres choses appelée la fragmentation de tas. Quelle que soit la méthode utilisée par le CMS pour les défragmenter, il suffit que le collecteur en série arrête la pause du mur, ce qui est un autre ramasse-miettes, mais il s’agit d’un seul thread. C’est de là que vient l’extrême longue pause.
Pour G1, la seule option dont nous disposons est le temps de pause cible et le minimum est de 12 cents millisecondes.
Nous avons quelques outils disponibles:

1. java visual vm

2. OpsCenter

3. Jconsole et jvisualvm

4. Et le dernier est jstat

jstat -gccause 1607 5000 (1607 is the process id for Cassandra)

Remarques:

La récupération de place a été l’impact le plus significatif pour la machine virtuelle Java sur les performances de Cassandra.
Le collecteur G1 est le choix préféré pour la récupération de place par rapport au système de gestion de contenu.
Le métaspace n’existe pas dans la partie nouvelle génération de la mémoire de segment de la machine virtuelle Java.

Outils JVM et stratégies de réglage:

Si nous avons le serveur avec 126 Go de RAM, il commence Cassandra avec 8 Go de mémoire alloués, que fait-il du reste de la mémoire?
Cache de page.
Qu’est-ce que la mise en cache de page? Ceci est utile pour améliorer les performances de lecture de Cassandra. il peut mettre en mémoire cache les données auxquelles les gens accèdent fréquemment et les récupérer plus rapidement que sur le disque.

free -m
             total   used    free   shared  buffers  cached
Mem:          5935   4271    1664       13     104     1189
-/+ buffers/cache:   2977    2957 
Swap:         2047      0    2047 

Ici, nous avons 5935 Mo de RAM mais 4271 Mo sont utilisés, donc seulement 1189 Mo sont mis en cache.

Comment Cassandra utilise-t-elle la mise en cache des pages?

Cela rend aussi une écriture efficace mais cela ne peut pas améliorer beaucoup l’écriture.
Comment trier la cause première des erreurs de mémoire insuffisante? Si nous n’avons pas assez de mémoire.
Il peut s’agir d’erreurs Java et pas seulement de Cassandra.
Tout le défi peut être de mettre des données en mémoire tampon en cas d’écriture. Il essaie d’écrire des données sur le disque

Quiz:

Quel est l’avantage d’utiliser le cache de pages? Les lectures sont plus efficaces, les écritures sont plus efficaces et les réparations sont plus efficaces
La mémoire utilisée par le cache de pages ne sera pas disponible pour les autres programmes tant qu’elle n’aura pas été explicitement libérée. ? vrai
Lequel des éléments suivants est le plus susceptible de provoquer une erreur de mémoire insuffisante? Jointures côté client

CPU
Utilisation intensive du processeur:
Les écritures (INSERT, UPDATE, DELETE), le chiffrement, la compression et le garbage collection demandent beaucoup de ressources de calcul.
Plus vous accordez de ressources processeur à garbage, plus le ramassage des ordures est rapide.
Si vous souhaitez activer la compression ou le cryptage, vous devez surveiller l’utilisation du processeur avec des outils tels que dstat ou opscenter.
Que faire ?
Ajouter des nœuds
Utilisez des nœuds dotés de processeurs plus nombreux et plus rapides
Cependant, si vous avez une saturation du processeur, nous avons deux options:
1. Désactivez le cryptage, désactivez la compression
2. Ajouter des nœuds
3. Vous pouvez également mettre à niveau ces nœuds avec plus de CPU
Quiz:
Laquelle des opérations suivantes bénéficierait de manière significative de processeurs plus rapides? Écrit et ramasse-miettes
OpsCenter est un outil qui peut être utilisé pour surveiller l’utilisation du processeur? vrai
Quel serait le meilleur plan d’action pour résoudre les problèmes de saturation du processeur? Ajouter plus de nœuds.

Réglage du disque:

Dans cette section, nous allons parler de l’ajustement du disque et du compactage.
Question: Comment les considérations de disque affectent-elles les performances?
Lorsque nous travaillons dans la base de données, comme Cassandra, nous avons un jeu de données actif doté d’une grande mémoire vive, disque. Donc, nous devons prendre ces choses en compte.
SSD: les disques en rotation ou en rotation doivent déplacer une tête mécanique en lecture / écriture sur la partie du disque en cours d’écriture ou de lecture.
Cassandra est une architecture autour du lecteur de rotation avec écriture séquentielle et lecture séquentielle. Cependant, le SSD est très rapide. Si vous avez une application de latence, le SSD est essentiel.

Certains des réglages dans le fichier Cassandra.yaml qui affectent le disque sont:
Configuration des disques dans le fichier Cassandra.yaml:
1. Disk_failure_policy: que devrait-il se passer si un disque de données tombe en panne? Pas pour la performance.

Par défaut, nous empêchons Cassandra de détecter certains types de corruption, de dissiper les commérages et d’épargner.

• Arrêtez au mieux en utilisant un disque en panne et répondez en utilisant les sstables restants sur d’autres disques. Des données obsolètes peuvent être renvoyées si le niveau de cohérence est égal à un.
• Ignore -ignore les erreurs fatales et laisse les demandes échouer
2.Commit_failure_policy: – Que devrait-il se passer si un disque de journal de validation échoue?
• Stop-même comme ci-dessus
• Stop_commit – ferme le journal de validation, laisse les écritures collecter mais continue de servir les lectures
• Ignore -ignore les erreurs fatales et laisse les lots échouer
3 Concurrent_reads – généralement défini sur 16 * nombre de lecteurs: nombre de threads pouvant être alloués au pool de lectures

4. Trickle_fsync – bon à activer sur les SSD mais très mauvais pour la rotation. En SSD, ça va faire du gros flash

Outils pour diagnostiquer le problème des disques relatifs:

Utilisation des outils sysstat Linux pour découvrir les statistiques du disque:
Rapporteur d’activité système (sar) -peut obtenir des informations sur l’activité du tampon système, les appels système, le périphérique de blocage, la pagination globale, l’allocation de sémaphore et de mémoire, ainsi que l’utilisation de l’UC.
Les drapeaux identifient l’élément à vérifier:

sar  -d for disk 
sar  -r for memory 
sar  -S for swap space used 
sar  -b for overall I/O activities 
dstat  -a Leatherman tool for Linux -versatile replacement 
for sysstat (vmstat,iostat,netstat,nfsstat,and ifstat) 
with colors
Flags identify the item to check:                      
dstat      -d          for disk 
dstat      -m          for memory, etc

Peut également faire passer des drapeaux pour obtenir plusieurs statistiques:

dstat    -dmnrs

Étape pour installer dstat sur RHEL / CentOS 5.x / 6.x et fedora 16/17/18/19/20:
Installation du référentiel RPMForge dans RHEL / CentOS
Pour RHEL / CentOS 6.x 64 bits

sudo rpm -Uvh http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
sudo yum repolist
sudo yum install dstat

Si nous voulons utiliser le script linux pour surveiller nos statistiques, nous pouvons utiliser des tâches cron telles que:

sudo dstat  -drsmn --output /var/log/dstat.txt 5 3 >/dev/null
#!/bin/bash
dstat -lrvn 10 --output /tmp/dstat.csv -CDN 30 360 mutt 
-a /tmp/dstat.csv -s "dstat report" me@me.com >/dev/null
  • charge moyenne (-l), entrée-sortie sur disque (-r), vmstat (-v) et débit du réseau (-n)

    La sortie peut être affichée sur la page Web pour la surveillance
    La sortie pourrait être canalisée dans des programmes graphiques, tels que Gnumeric, Gnuplot et Excel pour des affichages visuels.

    la mémoire doit être utilisée à environ 95% (la majeure partie de celle-ci dans la colonne de mémoire cache).
    Le processeur devrait être <1-2% de iowait et 2-15% du temps système.
    Le débit du réseau doit être identique à celui de l’application.

    Un autre outil est: cfhistograms nodetool pour découvrir les problèmes de disque:

Pour les disques SSD io disk performants, cet outil peut nous dire quelque chose. Le problème pourrait être la JVM, la taille de la RAM, il y a beaucoup de choses que cela pourrait être mais le disque est l’une des choses qu’il pourrait être.
Avec les histogrammes, il existe deux groupes de bosses. Cela peut être l’une des trois choses, nous voyons généralement deux bosses.
Un relatif à lire venant de la RAM et un gros venant du disque. Parfois, cela peut être autre chose que beaucoup de compactage. Le compactage peut provoquer des conflits de disque et ce conflit peut entraîner une montée du disque lu. parce que le compactage utilise le disque en lisant.
Alors, comment pouvons-nous approfondir cela? Comment le réparer?
Nous avons l’utilitaire Throttle down compacting en réduisant le compactage_throughput_mb_per_sec.
Utilisation des proxyhistograms nodetool pour détecter les problèmes de disque: affiche la latence complète des requêtes enregistrée par le coordinateur.

Utilisation de CQL TRACING:
Pour faire la distinction entre une réponse de disque lente et une requête lente: une réponse de disque lente sera évidente dans le temps nécessaire pour accéder à chaque lecteur.
Si vos requêtes doivent rechercher des tables SSTables sur trop de partitions, vous verrez ceci dans la trace.
Ces problèmes auront des modèles différents.
Ici, nous pouvons voir beaucoup d’informations telles que regarder sur le tombstoned, etc. Nous pouvons savoir si notre latence sur la requête provient du disque. Elle nous indique également la source sur laquelle la machine connaît ces latences plus longues.
Où les informations de traçage sont-elles stockées?
La table des événements nous donne beaucoup de détails relatifs pour cette requête particulière.
Quel rôle joue le readahead de disque dans la performance? Nous lisons une tête à quelques blocs et ce réglage, combien de blocs pour lire une tête? Le problème est que dans Cassandra nous ne savons pas exactement combien de données nous voulons lire par tête
Nous recommandons aux utilisateurs d’utiliser la valeur readahead de 8 pour les SSD
Commande à faire c’est:

blockdev -setra 8 

QUIZ:

cfhistograms nodetool affiche la latence de requête complète enregistrée par le coordinator.false
Parmi les affirmations suivantes, laquelle n’est PAS vraie à propos du paramètre readahead?
Lequel des outils suivants peut être utilisé pour surveiller les statistiques du disque? iostat, dstat, sysstat, sar.

Réglage du disque:
Compactage
Quel est l’impact du compactage sur les performances?

Le compactage est l’opération la plus intensive du cluster Cassandra. Nous avons donc choisi entre autres nos stratégies de compactage et la manière dont nous limitons, certaines choses se passent sur le disque, l’impact considérable sur l’utilisation du disque dans notre cluster.
Stratégie de compactage DateTiered DTCS pour le modèle de données de série chronologique.
Ajuster le compactage consiste à examiner l’impact des seuils SSTable min / max.
Comprendre les stratégies de compactage: il en existe actuellement 3 (stratégie de compactage de taille standard, STCS, stratégie de compactage datée, DTCS, stratégie de compactage nivelé LTCS)
Pour une écriture intensive et une charge de travail intensive, la stratégie de compactage avec niveaux de taille STCS peut être la meilleure.
La stratégie de compactage nivelé est généralement recommandée pour la lecture et la charge de travail uniquement si nous utilisons des disques SSD.
Compilation dateTiered entre le nombre de tables SSTables et la compaction car elle affecte les performances
Voir quelles options sont disponibles pour le compactage afin d’améliorer les performances
Comment les pierres tombales affectent-elles le compactage?
Compaction supprime les pierres tombales et supprime les données supprimées tout en consolidant plusieurs tables SSTables en un. Plus de pierres tombales signifie plus de temps consacré au compactage des tables SSTables.
Une fois qu’une colonne est marquée avec une désactivation, elle continuera d’exister jusqu’à ce que le compactage supprime définitivement la cellule. Notez que si un nœud est plus long que gc_grace_seconds et est remis en ligne, cela peut entraîner la réplication des données supprimées -zombie!
Pour éviter les problèmes, une réparation doit être effectuée régulièrement sur chaque nœud.

Meilleures pratiques: les nœuds doivent être réparés tous les 7 jours lorsque gc_grace_seconds est égal à 10 jours (paramètre par défaut)

Comment la modélisation des données affecte les pierres tombales?

Si un modèle de données nécessite de nombreuses suppressions au sein d’une partition de données, de nombreuses pierres tombales sont créées. Les pierres tombales identifient les données périmées en attente de suppression, lesquelles devront être lues jusqu’à ce qu’elles soient supprimées par compactage.
Une modélisation plus efficace des données atténuera ce problème. Assurez-vous que votre modèle de données est plus susceptible de supprimer des partitions entières plutôt que des colonnes d’une partition.
Le modèle de données a un impact significatif sur les performances. Une modélisation minutieuse des données évitera les pièges des pierres tombales endémiques qui affectent les performances de lecture.
Les pierres tombales sont des écritures normales mais n’affecteront pas les performances d’écriture.
Si vous savez que vous supprimez souvent une suppression longue qui affectera les performances en lecture, nous devrons probablement faire quelque chose pour la corriger, par exemple modifier un modèle de données ou la manière dont notre charge de travail utilise ce modèle de données.

Utilisation de nodetool compactionstats pour étudier des problèmes:

Cet outil peut être utilisé pour découvrir les statistiques de compactage pendant le compactage. Indique combien de compactage doit encore être effectué et la quantité totale de données en cours de compactage.
Mais en utilisant le traçage CQL pour étudier les problèmes, nous pouvons voir combien de nœuds et de partitions sont utilisés.
Le nombre de pierres tombales sera affiché.
Le temps d’accès en lecture peut être observé en diminution après la fin du compactage. On peut également constater que cela prend plus de temps pendant le compactage.
Pourquoi une file d’attente durable est-elle un anti-motif pouvant causer des problèmes de compactage?
Beaucoup de gens pour une autre raison aiment utiliser Cassandra pour une file d’attente durable à cause de ce problème de pierres tombales, il s’agit d’un motif anti-usage. Généralement, ce qui se passe, seules les lectures et les suppressions au même endroit puis les performances de lecture peuvent évoluer. Si vous essayez de trouver une file d’attente, utilisez une file, comme KAFKA, la file d’attente durable parfaite. Cassandra n’est pas un outil à utiliser en file d’attente.

Comment les choix de disques affectent-ils les problèmes de compactage?

Le compactage est le plus grand nombre d’entrées / sorties avec un fonctionnement intensif de la performance Cassandra. De ce fait, avoir de bons disques a un effet positif positif. Inversement, un disque lent peut avoir un effet très néfaste sur celui-ci. Lorsque le compactage est très lent, vous pouvez augmenter SSTable en lecture, alors les performances en lecture peuvent en souffrir.
Utilisez cfhistograms nodetool pour examiner les performances de lecture.
QUIZ:
Laquelle des stratégies de compactage suivantes doit être utilisée pour les charges de travail nécessitant beaucoup de lecture, en supposant que certaines conditions matérielles soient remplies? Compactage nivelé
Quel outil, commande ou paramètre peut être utilisé pour étudier les problèmes liés aux pierres tombales? Traçage CQL
Le compactage peut potentiellement utiliser non seulement une quantité importante d’E / S de disque, mais également de l’espace disque.

Réglage du disque: victoires faciles et conclusion:

Pour terminer ce document, nous devons revenir sur:
• méthodologie de réglage des performances
• Décrivez facilement les gains de performances
• Contour Cassandra ou environnement anti-patters

Comment cela s’accorde-t-il?

1. Nous devons comprendre la performance et Cassandra au plus haut niveau. Ce sont des techniques générales d’ajustement des performances et une partie de la terminologie, ainsi que le fonctionnement de Cassandra.
2. Recueillez des données de performances sur les éléments suivants pour savoir où rechercher des données et ce que ces données signifient en termes de problème de réglage ou d’isolement:
• charge de travail et modèle de données
• cluster et nœuds
• système d’exploitation et matériel
• stratégies de disque et de compactage.
3. Analyser les informations recueillies et commencer à élaborer un plan:
• Sur la base des métriques collectées, quels sont les goulots d’étranglement?
• Quels outils sont disponibles pour résoudre les problèmes qui surviennent?
4. Appliquez des solutions à toutes les zones requises et testez les solutions:
• En utilisant les outils et les connaissances acquises, appliquez les solutions, testez les solutions appliquées et redémarrez le cycle si nécessaire.

Question: Quelle était encore cette méthodologie d’ajustement des performances?

On a:​

Optimisation active des performances: suspectez-vous un problème?​
• Optimisation active des performances: suspectez-vous un problème?​ange-tombstones

Utilisez des index inversés pour vous aider lorsque la duplication ou l’imbrication de données n’est pas appropriée.
• Utilisez les pilotes DataStax pour vous assurer que la charge de travail du coordinateur est répartie uniformément sur le cluster.
• Utiliser la politique d’équilibrage de la charge token Aware: vous permet d’accéder directement aux données des données en évitant de consulter le coordinateur.
• Utilisez les instructions préparées (le cas échéant). Si vous effectuez une requête longtemps, vous constaterez un gain de performances si vous l’utilisez.
• Placez la base de données d’OpsCenter sur un cluster dédié.
• Dimensionner le cluster pour la charge de travail anticipée maximale: par exemple, pour l’équilibrage de la charge ou le balisage.
• Utilisez un réseau 10G entre les nœuds pour éviter les goulots d’étranglement du réseau.
• Sur la taille de la mémoire de la machine virtuelle Java, le numéro un est la mémoire vive et le processeur si nous voulons que Garbage Collection s’exécute plus rapidement. Veillez donc à ce qu’il y ait suffisamment de mémoire vive pour conserver les données actives en mémoire.
• Comprenez comment l’allocation de tas affecte les performances.
• Examinez l’incidence du cache de clés sur les performances en mémoire.
• Comprendre les filtres de bloom et leur impact en mémoire: nous pouvons l’accorder sur la table à l’aide du filtre de bloom faux positif pour éliminer les recherches de disque inutiles.
• Désactiver swap: swap peut poser problème et il sera très difficile à reproduire, nous devons le désactiver à l’aide de la commande suivante:

sudo swapoff –a

• Supprimez tous les fichiers d’échange sur / etc / fstab en:

sed -i ‘s /^(.* swap) / # 1 /’ / etc / fstab

• Examinez l’impact des memtables sur les performances: par défaut, les memtables enregistrent les enregistrements par tas, puis plus nous avons de memtables, plus ils sont vidés sur le disque, plus il ya de disque d’IO, de sorte que nous comprenons rougissent

Quels sont certains anti-modèles Cassandra / environnement?

1. Stockage connecté au réseau. Les goulots d’étranglement incluent: lorsque vous mettez Cassandra sur le SAN, c’est comme si vous le placiez au sommet du système de stockage. Cassandra a également un modèle séquentiel de lectures et d’écritures. Le conseil est de ne pas utiliser SAN et que cela coûtera moins cher.
L’utilisation de Cassandra sur le SAN augmentera la latence du réseau pour toutes les opérations.
• Latence du routeur
• carte d’interface réseau (NIC)
• NIC dans le périphérique NAS
2. Systèmes de fichiers réseau partagés.
3. Taille excessive de l’espace mémoire: cela peut entraîner un temps de pause très long de la machine virtuelle Java, car l’exécution de la mémoire prend du temps.
• Peut altérer la capacité de la machine virtuelle à effectuer un ramassage des déchets fluide.
4. Equilibreurs de charge: ne placez pas d’équilibreurs de charge entre les applications de Cassandra car Cassandra intègre l’équilibreur de charge intégré dans les pilotes.
5. Files d’attente et jeux de données semblables à des files d’attente: n’utilisez pas Cassandra comme une file d’attente.
• Les suppressions ne suppriment pas les lignes / colonnes immédiatement.
• Peut entraîner une surcharge de mémoire vive / disque en raison des pierres tombales.
• Peut affecter les performances de lecture si les données ne sont pas bien modélisées​

Laisser un commentaire

Fermer le menu
×
×

Panier