Seuils de performance et surveillance de l'instance AWS RDS db.t2

Nous avons déployé une configuration de server Web standard pour le logiciel CMS courant comme Drupal et WordPress, avec le server et le stockage sur EC2 / EBS et la database pour ces logiciels dans RDS / MySQL.

Habituellement, nous entrons en production avec un CPU t2.micro et un DB DB.t2.micro , ce qui rend les clients heureux avec nous et AWS car ils peuvent souvent restr sur le niveau gratuit pour la première année. Les outils de surveillance par défaut sur EC2 montrent clairement quand nous pourrions dépasser la ressource la plus chère pour l'hôte Web, qui est l'utilisation de la CPU . Si le seuil se rapproche ou passe 10%, nous soaps que le moment est venu de migrer vers le type d'instance t2.small .

Nous sums beaucoup less sûrs de savoir quand il faudra peut-être passer de db.t2.micro à db.t2.small et peut-être au-delà. Ces exigences n'entraîneraient pas de multi-AZ ou de répliques de lecture, ce n'est que lorsque le logiciel CMS pourrait s'appuyer fortement sur la database pendant les périodes de pointe que nous devrons repérer via un graphique ou une alarme.

Les documents relatifs aux instances EC2 indiquent clairement leurs propres limites et je me demandais si ces limites pour les instances RDS pourraient être recommandées pour notre cas simple. Les exigences générales dans leurs meilleures pratiques pour Amazon RDS sont utiles, même si je n'ai pas suivi tous les liens car j'essaie simplement de définir des seuils que nous pouvons mettre en place qui imposeront clairement une mise à jour de l'instance DB d'une manière que mes non- Les clients techniques peuvent comprendre et observer.

J'avoue que je ne suis pas un DBA; Par la nature de mon travail, j'ai laissé l'architecture de la database aux concepteurs du logiciel CMS. Je suis certainement disposé à apprendre les bases de l'évaluation de la performance si quelqu'un me dit par où commencer en ce qui concerne cette configuration sur la plate-forme AWS. Peut-être que je n'ai tout simplement pas trouvé les bons documents officiels ou les tutoriels.

Alternativement: il suffit de savoir comment mesurer quantitativement si un retard dans l'access à notre instance RDS résulte de la taille de l'instance trop petite (ou peut-être que les parameters de ressources MySQL sont trop bas) en fonction de ce que nous voyons sur CloudWatch.

Trivialement, je peux dire si la mésortingque de CloudWatch met à l'écart de zéro, nous aurions besoin d'une mise à niveau d'instance. Et comme pour notre instance EC2, il faut aussi utiliser une utilisation CPU maximale, ce qui, je suppose, serait bien inférieur à 100%, mais encore une fois, je n'ai pas vu cela documenté comme je l'ai pour EC2. J'imagine qu'il y aurait un maximum pratique pour les connections DB . Enfin, j'espère que quelqu'un me dira comment interpréter l' IOPS d'écriture et lisez les IOPS et si cela impose des limitations de performance sur de petites configurations comme la nôtre ou si elles sont simplement utilisées pour calculer les coûts.

ps, j'ai essayé de publier ceci sur les forums AWS: Amazon Relational Database Service, mais le lien Post New Thread produit actuellement une "Redirect loop". (Désolé, je ne peux pas inclure plus d'URL ici, mais je ne suis pas autorisé).

[edit, réponse au commentaire] Merci @Ross, je ne savais pas que CPUCreditBalance était également disponible sur RDS (j'avais vu ça sur EC2); n'a pas vu qu'il y avait un deuxième écran avec 7 autres mesures avec tous les 17 sélectionnables dans une list. Je me demandais toujours quelles limitations pourraient être imposées sur les ressources surveillables autres que la CPU, en particulier l'activité E / S, selon le type d'instance RDS.

pps, j'ai raffiné une question un peu plus et posté sur les forums AWS ( Comment déterminer si les instances RDS T2 ont la taille correcte avec les statistics CloudWatch? )

One Solution collect form web for “Seuils de performance et surveillance de l'instance AWS RDS db.t2”

J'ai eu une certaine perspective à ce sujet au cours des derniers mois et je crois que ces éléments à surveiller répondront à toutes les préoccupations ci-dessus:

1) Le commentaire de @Ross sur la publication originale est la key. Les instances T2, quelle que soit l'échelle, qu'elles soient EC2 ou RDS, cesseront de fonctionner lorsque leurs crédits de CPU seront épuisés au fur et à mesure que les requests CPU maximales continueront.

2) Le mode de défaillance d'un server Web CMS que nous avons vu le plus souvent est montré exactement par cette condition: le graphique CloudWatch plonge vers zéro lorsque le pourcentage de CPU requirejs par les process httpd dépasse le pourcentage de CPU atsortingbué à ce type d'instance (voir le lien doc ci-dessous ).

3) La solution rapide pour une instance T2 qui a épuisé les crédits de la CPU est d'arrêter, de mettre à niveau le type d'instance et de lancer l'instance à nouveau, ce qui prend environ 3-4 minutes. La description la plus importante des capacités de différents types d'instances est la suivante: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html

4) Tout server Web de production sur AWS doit avoir une adresse IP élastique atsortingbuée par avance pour cette raison: sinon, et l'instance est redéfinie, l'adresse IP changera, laissant le server Web inaccessible bien au-delà de ce qui serait autrement uniquement 3- 4 minutes de time d'arrêt.

5) La seule façon d'acquérir plus de crédits de CPU est de mettre à niveau le type de machine. La quantité de crédits que chaque taille d'instance T2 peut contenir est décrite dans le lien de la documentation ci-dessus: il est toujours égal au travail de la CPU que le type d'instance ferait en 24 heures.

6) La machine peut être returnnée à son échelle d'origine pendant un certain time d'arrêt planifié (encore une fois, 3-4 minutes) après que les exigences de pointe atteignent la tension.

7) L'activité d'E / S n'a pas encore provoqué de dégradation de performance pour notre server Web dans toutes les périodes de pointe. La quantité d'IOPS est déterminée ssortingctement par la taille du volume EBS. La signification exacte de IOPS, et cette relation, sont décrites ici: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-io-characteristics.html

8) Aucune des memorys Cloud Watch Freeable Memory ni DB Connections ne prévoyait d'anticiper ou de corriger des problèmes de performance dans un environnement Web Server intensif.

  • MySQL haute latence
  • Existe-t-il un moyen de définir le nom d'une instance AWS à partir d'outils de command line?
  • Quelle est exactement la différence entre Route53 Internal vs External.
  • Amazon S3 et Access-Control-Allow-Origin
  • Comment puis-je utiliser AWS CloudFront et API Gateway côte à côte pour le même domaine?
  • Une façon d'activer Amazon S3 Versioning pour les objects existants?
  • Avantages de l'utilisation de HAProxy devant AWS ELBs
  • AWS EC2 Instance Not Reachable plus
  • Ubuntu 12.04 Dispositif éphémère précis non disponible pour l'instance lors de la génération d'AMI personnalisé
  • Comment find le motif d'un time d'arrêt hebdomadaire sur un server Web Ubuntu hébergé par AWS?
  • Le site utilise des paramètres de sécurité périmés qui peuvent empêcher les versions futures de Chrome de pouvoir l'accéder en toute sécurité
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.