MySQL RDS Nourriture de la mémoire et échange
J'ai un problème avec la mémoire sur une instance RDS qui est de classe db.m2.4xlarge.
Voici les spécifications de l'instance RDS
Classe Instance: db.m2.4xlarge (68,4 Go de RAM)
Moteur: mysql (05/05/37)
IOPS: 8000
Stockage: 805GB (128 Go de données)
Multi AZ: Oui
Les sauvegardes automatisées: Activé (5 jours)
L'instance de mysql est réglée sans changer les valeurs des tampons InnoDB.
Tampons Total: 23.9G 3,0M global + par filetage (1000 fils max)
Utilisation de la mémoire possible maximale: 26,8 g (42% de RAM)
Les données dans des tables InnoDB: 98G
Plus tôt, nous avons l'habitude d'avoir une plus grande valeur tampon qui a été plus optimisé, mais la fréquence des redémarrages nous a fait pour le réduire revenir à la taille de la mémoire tampon par défaut fixé par RDS.
Nos travaux d'application de 4 serveur ColdFusion et 4 serveurs asp.net, ils communiquent tous à l'instance MySQL RDS concerné. Nous utilisons la mise en commun de connexion pour les applications. Toutes les déclarations DML sont effectuées en utilisant des procédures stockées et ils sont exécutés très fréquemment.
Mon problème est que l'instance RDS si laissé seul, mange lentement la mémoire et commence à échanger. Quand il troque nos applications commence à échouer un par un. Donc, il nous reste la seule option de redémarrer l'instance. À l'heure actuelle, nous redémarrer le serveur, chaque fois que la mémoire passe en dessous de 5 Go.
Une autre approche que nous prenons est des serveurs de fusion à froid redémarrage, redémarrer IIS et publier ensuite un " tableaux de chasse " requête. Mais cela donne des résultats parfois, mais parfois, il n'y a pas de changement. En théorie, je crois même sans tableaux de chasse requête, la mémoire doivent être libérés, ce qui ne se produit pas. Encore une fois, la mémoire libérée est habituellement dans une plage de 1-7 GB.
Le jeu de délai interactif pour MySQL est de 300 secondes et la durée de connexion ColdFusion est de 300 secondes et le jeu de délai d'attente en asp.net est de 270 secondes.
Je suis incapable de traquer ce qui est en utilisant la mémoire et de le garder à lui-même. La mémoire devrait idéalement se libérer quand MySQL a besoin il. Mais il ne se produit pas.
Je besoin de quelques conseils sur la façon de traquer le porc de la mémoire, de sorte que l'instance RDS continue de fonctionner sans avoir besoin de redémarrer.
Nous avons déjà MONyog suivi des RDS. En outre, ont permis Historique du statut mondial (GOSH) RDS, qui n'a pas été vraiment utile pour moi.
J'ai déjà vu problème similaire mentionné ici @ Quand dois-je penser à améliorer notre exemple RDS MySQL basée sur l'utilisation de la mémoire? Nous avons déjà fait tout ce qui y est recommandé comme une partie de réglage DB.
Voici les graphiques
Ce graphique représente 3 semaines
Le graphique commence par un redémarrage, ce qui est arrivé après que la mémoire est descendu à 0 et swapping commencé. Après quoi, il y a eu 2 redémarrages.
La semaine en cours
Il y a 2 versions de mémoire qui ont eu lieu le 19 Août 2014. Un qui soulagé 6GB a été fait par le redémarrage des services et une table de rinçage comme expliqué ci-dessous.
Voici comment passé 24 heures a été.
[~ # ~] éditer [~ # ~]
Ajout de détails au besoin.
La liste des processus est comme ci-dessous
mysql> SHOW PROCESSLIST;
+ -------- + ----------------- + ---------------------- ------------------------------ + ------------ + ------ --- + ------- + -------- + ----------------------------- ---------- + | Id | utilisateur | Héberger
[.____] | dB | commande | temps | État | Info
[.____] | + -------- + ----------------- + ---------------------- ------------------------------ + ------------ + ------ --- + ------- + -------- + ----------------------------- ---------- + | 1 | event_scheduler | localhost
[.____] | Null | daemon | 30 | En attente d'activation prochaine | NUL
[.____] | | 332 | Utilisateur | IP3: 32355 | Null | Dormir | 1 | | NUL
[.____] | | 836 | rdsadmin | localhost: 40463
[.____] | mysql | Dormir | 6 | | NUL
[.____] | | 345919 | Utilisateur | server2: 49173 | Null | Dormir | 0 | | Null | | 354132 | Utilisateur | server2: 49641 | Null | Dormir | 82 | | Null | | 386366 | Utilisateur | ip1.us-ouest-2.compute.internal: 64097 | dB | Dormir | 1 | | Null | | 389625 | Utilisateur | ip2.us-ouest-2.compute.internal: 59819 | dB | Dormir | 0 | | Null | | 390109 | utilisateur
[.____] | ip1.us-ouest-2.compute.internal: 64879 | dB | Dormir | 1 |
[.____] | Null | | 391366 | Utilisateur | ip2.us-ouest-2.compute.internal: 60319 | dB | Dormir | 1 |
[.____] | Null | | 392045 | Utilisateur | IP3: 39593
[.____] | Null | Dormir | 20193 | | NUL
[.____] | | 393625 | Utilisateur | IP3: 26708 | dB | Dormir | 3902 | | Null | | 393626 | Utilisateur | IP3: 37544 | NUL
[.____] | Dormir | 5677 | | Null | | 393933 | Utilisateur | ip2.us-ouest-2.compute.internal: 60912 | dB | Dormir | 0 | | Null | | 394462 | Utilisateur | ip1.us-ouest-2.compute.internal: 49971 | dB | Dormir |
3 | | Null | | 394802 | utilisateur
[.____] | IP7: 1142 | dB | Dormir | 88 |
[.____] | Null | | 395410 | Utilisateur | ip2.us-ouest-2.compute.internal: 64725 | dB | Dormir | 4 |
[.____] | Null | | 396217 | Utilisateur | IP2.US-West-2.Compute.Internal: 64891 | dB | Dormir | 12 |
[.____] | Null | | 396581 | Utilisateur | IP7: 1423
[.____] | dB | Dormir | 22 | | NUL
[.____] | | 396731 | Utilisateur | IP7: 1429 | dB | Dormir | 21 | | Null | | 396954 | Utilisateur | IP1.US-West-2.Compute.Internal: 50472 | dB | Dormir | 7 | | Null | | 398509 | Utilisateur | IP1.US-West-2.Compute.Internal: 50595 | dB | Dormir |
[.____] 179 | | Null | | 399337 | Utilisateur | IP3.us-West-2.Compute.Internal: 49539 | dB | Dormir | 219 |
[.____] | Null | | 399338 | Utilisateur | IP3.US-West-2.Compute.Internal: 49540 | dB | Dormir | 219 |
[.____] | Null | | 399360 | Utilisateur | IP4.US-West-2.Compute.Internal: 62560 | dB | Dormir | 0 |
[.____] | Null | | 399363 | Utilisateur | IP4.US-West-2.Compute.Internal: 62568 | dB | Dormir | 0 |
[.____] | Null | | 399580 | Utilisateur | IP5.US-West-2.Compute.Internal: 50055 | dB | Dormir | 1 |
[.____] | Null | | 399581 | Utilisateur | IP6.US-West-2.Compute.Internal: 58023 | dB | Dormir | 1 |
[.____] | Null | | 399607 | Utilisateur | IP6.US-West-2.Compute.Internal: 58034 | dB | Dormir | 1 |
[.____] | Null | | 399608 | Utilisateur | IP6.US-West-2.Compute.Internal: 58036 | dB | Dormir | 1 |
[.____] | Null | | 399609 | Utilisateur | IP6.US-West-2.Compute.Internal: 58037 | dB | Dormir | 1 |
[.____] | Null | | 399669 | Utilisateur | IP4.US-West-2.Compute.Internal: 62615 | dB | Dormir | 0 |
[.____] | Null | | 399682 | Utilisateur | IP3: 9507
[.____] | Null | Requête | 0 | Null | Show processlist | | 399696 | Utilisateur | Server1: 53241 | dB | Dormir | 1 | | NUL
[.____] | | 399704 | Utilisateur | Server1: 53242 | dB | Dormir
[.____] | 0 | | Null | | 399705 | Utilisateur | IP4.US-West-2.Compute.Internal: 62618 | dB | Dormir |
[.____] 0 | | Null | | 399706 | utilisateur
[.____] | IP4.US-West-2.Compute.Internal: 62619 | dB | Dormir | 0 |
[.____] | Null | | 399707 | Utilisateur | IP4.US-West-2.Compute.Internal: 62620 | dB | Dormir | 0 |
[.____] | Null | + --------- + ------------------ + ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -------------------------------- + ------------ + ------ --- + ------- + ----------------------------- + -------- ----------- +
Afficher le moteur InnoDb Statut
Je n'ai pas été en mesure de formater les données correctement, alors je pose cela sur Pastebin http://pastebin.com/jetq6kg
Merci.
Le serveur a de nouveau été redémarré le matin pour libérer la mémoire.
La mémoire n'est pas instrumentée dans MySQL avant version 5.7 (actuellement en développement), cela rend donc votre question un jeu de devinettes.
Je peux voir à partir du statut d'InnoDb à l'intérieur, qu'il ne semble pas être innodb consommant la mémoire (en supposant que vous avez recueilli ceci à partir du sujet du problème):
Total memory allocated 26217103360; in additional pool allocated 0
Dictionary memory allocated 1212141
Buffer pool size 1563519
Total de la mémoire: 24.41 GiB (Innodb a besoin d'environ 5 à 10% de plus que votre piscine tampon pour structures internes) Mémoire de la piscine tampon: ~ 23.85 GIB
Je vais deviner que la mémoire est consommée sur la couche MySQL (non innovée) et que deux causes courantes sont des tables temporaires intrinsèques et de très gros tampons de tri/jointure.