Gli abbiamo detto di non comprare altra RAM.
Un e-commerce di articoli per la casa ha avuto una mattinata di errori «too many connections». La correzione ovvia era più RAM. I dati hanno detto di non spenderla: il working set stava già in memoria, e la risposta era nelle regole dell'applicazione stessa.
In questo articolo 3 sezioni
- Il database di un e-commerce di articoli per la casa ha cominciato una mattina a restituire ERROR 1040: Too many connections, subito dopo che lo spazio per le tabelle temporanee si era riempito.
- La correzione ovvia era più RAM: un database più grande del suo buffer pool sembra affamato. Allargare il pool sarebbe costato denaro e non avrebbe risolto nulla.
- La misurazione l'ha sconfessata. Il buffer pool trovava i dati in cache quasi ogni volta e aveva ancora spazio libero. Il working set era già in memoria.
- La causa reale era una tabella di regole di sconto cresciuta ben oltre ciò che serviva al negozio. La correzione stava nelle regole dell'applicazione, non in altra RAM.
È cominciata come una mattinata di errori di connessione. Lo spazio per le tabelle temporanee, su tmpfs, si era riempito, e pochi secondi dopo il database ha cominciato a rispondere ERROR 1040: Too many connections. Il nostro ingegnere reperibile lo aveva a schermo in pochi minuti, e abbiamo lavorato fin dall'inizio insieme agli sviluppatori del negozio.
temp-table space (tmpfs) ........ FULL
… seconds later …
mysqld: ERROR 1040 (HY000): Too many connectionsLa risposta costosa, e perché l'abbiamo messa da parte
Un database più grande del suo buffer pool, e memoria libera sulla macchina. Ogni numero in superficie punta nella stessa direzione: date al pool più RAM, fatto. Sembra progresso e costa denaro vero. La misurazione diceva che non avrebbe risolto nulla.
| LA RISPOSTA COSTOSA | COSA DICEVANO I DATI |
|---|---|
| Il database è più grande del pool. Allargate il pool. | Il rapporto di hit della cache era quasi perfetto. Il working set viveva già in memoria. |
| Una cache più grande risolve l'overflow. | Il pool aveva già spazio inutilizzato. Altra RAM avrebbe messo in cache dati già in cache. |
| HANNO VINTO I DATIAggiungete hardware, problema risolto. | La tabella sovradimensionata continua a crescere dietro il pool più grande finché non trabocca di nuovo. |
Due letture hanno chiuso la questione. Il buffer pool quasi non mancava mai il colpo, e aveva ancora pagine libere. Insieme dicono una cosa sola: il working set stava già interamente in memoria. Non c'erano dati in attesa su disco che una cache più grande potesse contenere.
La causa reale era nelle dimensioni delle tabelle
Esclusa la memoria, siamo passati alle dimensioni delle tabelle. Una spiccava: la tabella delle combinazioni di regole di sconto, di gran lunga la cosa più grande del database.
Quella tabella viene generata dalle regole di sconto attive del negozio, e le combinazioni crescono con il quadrato del numero di regole. Col tempo le regole si erano accumulate, e la tabella era cresciuta con loro. Le query su di essa facevano traboccare lo spazio per le tabelle temporanee, e quell'overflow si propagava fino all'esaurimento delle connessioni. L'errore 1040 era l'ultimo domino, non il primo.
# 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 risposta disciplinata e la risposta costosa puntavano in direzioni opposte
Un pool più grande avrebbe comprato tempo, e la tabella avrebbe continuato a crescergli dietro. Una sola risposta toccava la causa vera: mettere ordine nelle regole di sconto, porre un tetto alle combinazioni e lasciare l'hardware com'era. Gli sviluppatori del negozio hanno fatto la modifica, e gli errori sono finiti.
La macchina non è mai stata il problema. I dati mostravano che il working set stava già in memoria, quindi la correzione era nelle regole dell'applicazione, non in altra RAM. La cosa più utile che potevamo consegnare a questo cliente non era altro nostro hardware. Era un motivo per non comprarlo.
“A volte la cosa più preziosa che un host può dirvi è: non spendete quei soldi.”
Risposte dirette
Il mio database ha restituito «ERROR 1040: Too many connections». Devo alzare il limite di connessioni?+
Di solito no. Un tetto più alto non corregge ciò che tiene aperte le connessioni, ne lascia accumulare di più prima che qualcosa scatti. Un limite sensato fallisce in fretta e tiene piccolo il danno. Trovate cosa trattiene le sessioni prima di alzare il numero.
Devo aggiungere RAM se il mio database è più grande del buffer pool?+
Non su quel solo dato. Il numero che decide è l'hit rate del buffer pool, non la dimensione su disco. Se il pool trova già i dati quasi ogni volta e ha pagine libere, il working set sta in memoria e altra RAM metterebbe in cache dati già in cache.
Qual è un hit ratio normale del buffer pool InnoDB?+
Sopra il 99 per cento una volta che il working set sta in memoria. Se il pool è già lì e ha ancora pagine libere, un pool più grande non compra nulla; guardate invece le query.
Perché lo spazio per le tabelle temporanee di MySQL continua a riempirsi?+
Di solito una query che produce molte più righe intermedie di quante ne servano al risultato. Qui una tabella di regole di sconto molto grande ha fatto traboccare lo spazio per le tabelle temporanee, che poi si è propagato fino all'esaurimento delle connessioni. La correzione era nei dati, non nel disco.
EuroVPS mi dirà di non comprare un upgrade?+
Sì, quando i dati dicono che l'upgrade non risolve nulla. Preferiamo risalire alla causa reale piuttosto che vendervi hardware che la nasconde. In questo caso la risposta onesta era: non allargate il buffer pool, mettete ordine nelle regole.
Prima di comprare l'upgrade, lasciate che leggiamo i numeri.
Se una macchina più grande risolverebbe il problema, lo diremo. Se nasconderebbe soltanto la causa reale, diremo anche quello, con la misurazione.
Parla con un ingegnere (shell cta.talkToEngineer)Siete arrivati alla fine.
Mettete la lettura al lavoro
Cosa fate girare?
Raccontateci il carico di lavoro, il traffico e i requisiti di ripristino. Partite dal configuratore di server, oppure discutete i dettagli con un ingegnere.
Scritto dagli ingegneri che costruiscono e gestiscono l'infrastruttura che descrive.Parla con un ingegnere