Amazon RDS est à court de mémoire. Devrais-je m'inquiéter?
j'ai une instance D'Amazon RDS. La mémoire exploitable est en déclin depuis la mise en place sur 1-2 semaines, à partir de 15 Go de mémoire jusqu'à environ 250 Mo. Comme il a chuté à ce bas dans les derniers jours, il a commencé à ressembler à un modèle sawtooth où la mémoire libérable chute à cette gamme (250 - 350MB) et remonte ensuite agin à 500 - 600MB dans un modèle sawtooth.
il n'y a pas eu de baisse notable de la qualité des demandes. Cependant, je crains que le DB ne soit à court de de la mémoire et de crash.
y a-t-il un risque que L'instance RDS manque de mémoire? Y a-t-il un paramètre ou un paramètre que je devrais regarder pour déterminer si l'instance est configurée correctement? Quelle est la cause de ce motif sawtooth?
3 réponses
Freeable memory field est utilisé par MySQL pour la mise en cache et la mise en cache de ses propres processus. Il est normal que la quantité de mémoire disponible diminue avec le temps. Je n'aurais pas peur que ça donne un coup de pied aux vieilles infos car ça demande plus de place.
brève réponse - vous ne devriez pas vous inquiéter de FreeableMemory à moins qu'il ne soit devenu vraiment bas (environ 100-200 Mb) ou un échange significatif se produisent (voir RDS swapusage métrique).
FreeableMemory n'est pas une métrique MySQL, mais une métrique OS. Il est difficile de donner une définition précise, mais vous pouvez le traiter comme de la mémoire que L'OS pourra allouer à quiconque le demande (dans votre cas, il sera probablement MySQL). MySQL ont un ensemble de paramètres qui limitent son utilisation globale de la mémoire à certains cap(vous pouvez utiliser quelque chose comme effectivement le calculer). Il est peu probable que votre instance atteigne un jour cette limite, en raison du fait qu'en général vous n'atteignez jamais le nombre maximum de connexions, mais c'est encore possible.
nous revenons maintenant au" déclin " de la métrique FreeableMemory. Pour le MySQL la plupart de la mémoire consomme par InnoDB piscine tampon (voir ici pour plus de détails). Les instances RDS dans la configuration par défaut ont une taille de tampon fixée à 75% de hosts mémoire physique - qui dans votre cas est d'environ 12 Go. Ce tampon est utilisé pour mettre en cache toutes les données DB utilisées dans les opérations de lecture et d'écriture. Donc, dans votre cas, puisque ce buffer est vraiment grand - il se remplit lentement avec des données qui sont mises en cache (il est probable que ce buffer est en fait assez grand pour mettre en cache toute la base de données). Ainsi, lorsque vous démarrez pour la première fois, ce tampon est vide et une fois que vous commencez à lire/écrire des choses dans la base de données, toutes ces données sont amenées dans le cache. Ils vont rester ici jusqu'à la le temps où ce cache est devenu complet et une nouvelle requête est venue. Les données les plus récentes seront remplacées par de nouvelles données. Ainsi le déclin initial de FreeableMemory après le redémarrage D'instance de DB explique avec ce fait. Ce n'est pas une mauvaise chose, parce que vous voulez réellement que le plus possible de vos données soient mises en cache afin que votre base de données puisse fonctionner plus rapidement. La seule chose qui peut devenir désagréable est quand une partie ou la totalité de cette mémoire tampon sera poussée hors de la mémoire physique en swap. À ce moment vous avez énorme chute des performances.
comme un soin préventif, il pourrait être une bonne idée D'accorder MySQL max mémoire utilisée pour une chose différente dans le cas où vous métrique FreeableMemory est constamment sur un niveau de 100-200 Mb, juste pour réduire la possibilité d'échanger.
j'ai été confronté au même problème, la mémoire libre dans mon instance est passée en dessous de 40mb, redémarrer l'instance a réactivé la mémoire.