Tabella dei parametri di istanza

Leggere una classe di istanza come un insieme di valori di parametri

Una classe di istanza sembra un dato a due colonne — tante vCPU, tanta memoria — ma in realtà è un insieme di decisioni già prese per te. La sola cifra di memoria fissa il tetto di connessioni, la cache dei buffer e la visione del mondo del planner. Questa tabella mostra ogni istanza accanto ai valori di parametri che la sua memoria implica, così puoi leggere una classe come la configurazione che davvero è.

Come funziona

• Elenca ogni classe di istanza nel catalogo del cloud che scegli, dalla più piccola alla più grande.
• Mostra la memoria per vCPU, il modo più rapido per distinguere una classe general purpose da una ottimizzata per la memoria.
• Fornisce max_connections per istanza, calcolato dalla regola pubblicata del provider e dal motore selezionato.
• Mostra shared_buffers o innodb_buffer_pool_size ed effective_cache_size, ricavati dalle espressioni predefinite di RDS.

colonne e da dove arriva ciascuna
  vCPU, memoria    la tabella delle classi di istanza del provider
  GiB / vCPU       memoria divisa per vCPU
  max_connections  la regola pubblicata del provider per il motore scelto
  shared_buffers        25% della memoria  (PostgreSQL)
  innodb_buffer_pool    75% della memoria  (MySQL)
  effective_cache_size  75% della memoria  (suggerimento al planner)

Esempio pratico

Una classe di istanza, db.m5.2xlarge con 8 vCPU e 32 GiB, letta su entrambi i motori.

1. memoria per vCPU = 32 ÷ 8 = 4 GiB, il rapporto general purpose
2. PostgreSQL: circa 3.324 connessioni, shared_buffers 8 GiB, effective_cache_size 24 GiB
3. MySQL: circa 2.518 connessioni, innodb_buffer_pool_size 24 GiB
4. lo stesso hardware, due motori, e l'allocazione dei buffer differisce di un fattore tre

PostgreSQL tiene per sé il 25% e lascia il resto alla cache del sistema operativo; MySQL rivendica il 75% per InnoDB perché non si appoggia a quella cache. Nessuna delle due è una scelta di tuning da prendere alla leggera: entrambe discendono dalla scelta della classe, ed è il motivo per cui la stessa istanza si comporta diversamente sotto i due motori.

Come leggere il risultato

• La memoria per vCPU dice a cosa serve una classe. Circa 2 GiB per vCPU è orientata al calcolo, 4 GiB è general purpose, 8 GiB e oltre è ottimizzata per la memoria — le classi r di AWS, la serie E di Azure. Per un database i rapporti più alti sono di solito l'affare migliore, perché la memoria compra sia cache sia margine di connessioni.
• Il B1ms di Azure è l'unica riga che non segue il proprio schema: 50 connessioni dove la regola per GiB ne prevedrebbe molte di più. Questa tabella riproduce i valori pubblicati da Azure anziché interpolarvi una curva, così quell'anomalia sopravvive invece di essere smussata.
• La classe t di AWS e la serie B di Azure sono burstable. Accumulano crediti CPU a riposo e limitano una volta esauriti, il che le rende eccellenti per lo sviluppo e scadenti sotto carico di produzione costante: la tabella mostra la configurazione, non questa avvertenza, quindi tienila a mente.
• Le voci Cloud SQL qui sono forme personalizzate comuni, non un catalogo esaustivo, perché Cloud SQL consente di richiedere quasi qualsiasi combinazione di vCPU e memoria. Considera quella colonna come rappresentativa.
• Questi valori sono i predefiniti con cui parte un'istanza, non limiti. Tutti e tre i cloud consentono di sovrascriverli tramite un gruppo di parametri o un flag, e le formule delle connessioni in particolare sono solo predefiniti: vedi il calcolatore delle connessioni massime per capire cosa costa cambiarli.

Domande frequenti

Perché max_connections cambia quando cambio motore?

Perché ogni motore ha il proprio divisore nella formula del provider. Su AWS, PostgreSQL divide la memoria disponibile per circa 9,5 MB per connessione mentre MySQL divide per circa 12,6 MB, quindi la stessa istanza rende meno connessioni MySQL. MariaDB dalla 10.5 usa un divisore ancora diverso.

Più memoria per vCPU è sempre meglio per un database?

Di solito sì, fino al punto in cui il working set entra in memoria. Una volta che i dati toccati dalle query sono in cache, aggiungere memoria smette di comprare velocità e compra solo margine di connessioni. Se il tuo insieme di dati è piccolo e le query sono pesanti sulla CPU — molto ordinamento, aggregazione o elaborazione JSON — un rapporto più basso con più core può essere l'istanza migliore.

Posso cambiare questi valori dopo l'avvio?

Sì, tramite un gruppo di parametri su RDS, i parametri server su Azure o i flag del database su Cloud SQL. Alcuni hanno effetto immediato e altri richiedono un riavvio: shared_buffers e innodb_buffer_pool_size vengono allocati all'avvio, quindi rientrano nella seconda categoria. I valori predefiniti mostrati qui sono buoni punti di partenza e meritano una ragione prima di essere sovrascritti.

Fonti

• Amazon RDS — classi di istanza DB
• Azure Database for PostgreSQL — limiti
• Cloud SQL per PostgreSQL — flag