Nous leur avons dit de ne pas acheter plus de RAM.
Une boutique d'articles pour la maison a eu une matinée d'erreurs « too many connections ». La solution évidente était plus de RAM. Les données ont dit de ne pas la dépenser : le working set tenait déjà en mémoire, et la réponse se trouvait dans les règles de l'application elle-même.
Dans cet article 3 sections
- La base de données d'une boutique d'articles pour la maison a commencé à renvoyer ERROR 1040: Too many connections un matin, juste après que son espace de temp tables s'est rempli.
- La solution évidente était plus de RAM : une base plus grande que son buffer pool a l'air affamée. Agrandir le pool aurait coûté de l'argent et n'aurait rien corrigé.
- La mesure l'a emporté. Le buffer pool touchait son cache presque à chaque fois et avait encore de la marge. Le working set était déjà en mémoire.
- La vraie cause était une table de règles de remise qui avait grossi bien au-delà de ce dont la boutique avait besoin. Le correctif était dans les règles de l'application, pas dans plus de RAM.
Cela a commencé par une matinée d'erreurs de connexion. L'espace des temp tables, sur tmpfs, s'était rempli, et quelques secondes plus tard la base a commencé à répondre ERROR 1040: Too many connections. Notre ingénieur d'astreinte l'avait à l'écran en quelques minutes, et nous avons travaillé dessus avec les développeurs de la boutique dès le début.
temp-table space (tmpfs) ........ FULL
… seconds later …
mysqld: ERROR 1040 (HY000): Too many connectionsLa réponse coûteuse, et pourquoi nous l'avons écartée
Une base plus grande que son buffer pool, et de la mémoire libre sur la machine. Chaque chiffre de surface pointe dans la même direction : donnez plus de RAM au pool, terminé. Cela ressemble à un progrès et cela coûte de l'argent réel. La mesure a dit que cela ne corrigerait rien.
| LA RÉPONSE COÛTEUSE | CE QUE LES DONNÉES ONT DIT |
|---|---|
| La base est plus grande que le pool. Agrandissez le pool. | Le taux de cache-hit était presque parfait. Le working set vivait déjà en mémoire. |
| Un cache plus grand corrige le débordement. | Le pool avait déjà de la place inutilisée. Plus de RAM mettrait en cache des données déjà en cache. |
| LES DONNÉES ONT GAGNÉAjoutez du matériel, problème résolu. | La table surdimensionnée continue de grossir derrière le pool agrandi jusqu'à déborder de nouveau. |
Deux lectures ont tranché. Le buffer pool ne manquait presque jamais, et il lui restait encore des pages libres. Ensemble, elles disent une seule chose : le working set tenait déjà entièrement en mémoire. Aucune donnée n'attendait sur disque qu'un cache plus grand la retienne.
La vraie cause était dans la taille des tables
La mémoire écartée, nous sommes passés à la taille des tables. Une seule se détachait : la table des combinaisons de règles de remise, de loin le plus gros objet de la base.
Cette table est générée à partir des règles de remise actives de la boutique, et les combinaisons croissent avec le carré du nombre de règles. Avec le temps, les règles s'étaient accumulées, et la table avait grossi avec elles. Les requêtes qui la touchaient faisaient déborder l'espace des temp tables, et ce débordement se propageait en épuisement des connexions. L'erreur 1040 était le dernier domino, pas le premier.
# table name is an illustrative rename.
> table sizes, largest first
discount_rule_combinations largest table by a wide margin
↳ generated from the active discount rules
↳ combinations grow with the SQUARE of the rule countLa réponse disciplinée et la réponse coûteuse pointaient dans des directions opposées
Un pool plus grand aurait acheté du temps, et la table aurait continué de grossir derrière lui. Une seule réponse touchait la cause réelle : faire le tri dans les règles de remise, plafonner les combinaisons, et garder le matériel tel qu'il était. Les développeurs de la boutique ont fait le changement, et les erreurs ont cessé.
La machine n'a jamais été le problème. Les données ont montré que le working set tenait déjà en mémoire, donc le correctif était dans les règles de l'application, pas dans plus de RAM. La chose la plus utile que nous pouvions donner à ce client n'était pas davantage de notre matériel. C'était une raison de ne pas l'acheter.
“Parfois, la chose la plus précieuse qu'un hébergeur peut vous dire est : ne dépensez pas cet argent.”
Réponses directes
Ma base a renvoyé « ERROR 1040: Too many connections ». Dois-je augmenter la limite de connexions ?+
En général, non. Un plafond plus haut ne corrige pas ce qui garde les connexions ouvertes, il en laisse davantage s'empiler avant que quelque chose ne saute. Une limite raisonnable échoue vite et garde les dégâts petits. Trouvez ce qui retient les sessions avant d'augmenter le nombre.
Dois-je ajouter de la RAM si ma base est plus grande que mon buffer pool ?+
Pas sur ce seul fait. Le chiffre qui décide est le taux de hit du buffer pool, pas la taille sur disque. Si le pool touche déjà presque à chaque fois et a des pages libres, le working set tient en mémoire et plus de RAM mettrait en cache des données qui le sont déjà.
Quel est un taux de hit normal pour le buffer pool InnoDB ?+
Au-dessus de 99 pour cent une fois que le working set tient en mémoire. Si le pool y est déjà et a encore des pages libres, un pool plus grand n'achète rien ; regardez plutôt les requêtes.
Pourquoi mon espace de temp tables MySQL se remplit-il sans cesse ?+
En général, une requête qui produit bien plus de lignes intermédiaires que le résultat n'en a besoin. Ici, une très grande table de règles de remise a fait déborder l'espace des temp tables, ce qui s'est propagé en épuisement des connexions. Le correctif était dans les données, pas dans le disque.
EuroVPS me dira-t-elle de ne pas acheter une montée en gamme ?+
Oui, quand les données disent que la montée en gamme ne corrige rien. Nous préférons remonter à la vraie cause plutôt que de vous vendre du matériel qui la cache. Dans ce cas, la réponse honnête était : n'agrandissez pas le buffer pool, faites le tri dans les règles.
Avant d'acheter la montée en gamme, laissez-nous lire les chiffres.
Si une machine plus grosse réglait le problème, nous le dirions. Si elle ne faisait que cacher la vraie cause, nous le dirions aussi, avec la mesure.
Parler à un ingénieurVous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur