Come si sintonizza MySQL per un carico di lavoro pesante di InnoDB?

Supponendo un sistema di produzione OLTP con tabelle prevalentemente InnoDB

• Quali sono i sintomi comuni di un sistema non corretto / configurato in modo errato?
• Quali parametri di configurazione cambiate più comunemente dai loro valori predefiniti?
• Come individuare potenziali colli di bottiglia prima che si verifichi un problema?
• Come riconosci e risolvi i problemi attivi?

Tutti gli aneddoti che descrivono le statusvariabili e la diagnostica specifiche sarebbero apprezzati.

Ecco un buon articolo sull'ottimizzazione di InnoDB da parte di Jenny Chen di Sun: scrive molto su MySQL, in parte è specifico di Solaris (ad es. Usando DTrace ) ma l'intero blog è pieno di curiosità interessanti.

È interessante notare che in MySQL 5.5 ora puoi avere più pool di buffer innodb.

I parametri che ti interessano sono

• innodb_buffer_pool_instances (il valore predefinito è 1)
• innodb_buffer_pool_size (il valore predefinito è 1G)

In circa un mese, sono previsto di implementare 112 pool di buffer innodb per un client. Ti farò sapere come è andata.

AGGIORNAMENTO 2011-02-27 21:57 EDT

Ho scoperto che il valore massimo per innodb_buffer_pool_instances è 64 Ho deciso di configurare 144 GB, quindi ho impostato innodb_buffer_pool_instances su 18 e innodb_buffer_pool_size su 8. Attualmente sto caricando il server con 450 GB

AGGIORNAMENTO 2011-04-28 13:44 EDT

Ho provato più pool di buffer InnoDB. Vi erano troppi blocchi e contese di threading. Sono passato a un singolo pool di buffer da 162 GB + impostando read_io_threads e write_io_threads su 64 (valore massimo). Questo ha funzionato molto meglio.

AGGIORNAMENTO 2012-07-03 17:27 EDT

Ho imparato qualcosa di straordinario su MySQL. Se si alloca un singolo pool di buffer InnoDB monolitico che è più grande del totale installato diviso per il numero di CPU fisiche , si inciterà il sistema operativo a scambiare la memoria a intervalli regolari a causa di un pool di buffer InnoDB completo. L'opzione MySQL 5.5 nota come innodb_buffer_pool_instances può essere utilizzata per suddividere il pool di buffer. Ieri, l'ho implementato correttamente per il cliente di cui ho parlato nella mia risposta l'anno scorso. Ho ancora 162 GB per il pool di buffer del client. Ho impostato l'opzione innodb_buffer_pool_instances del server su 2 perché ogni DB Server è a doppio hexacore. Stavo pensando di impostarlo su 12 ma poi un collega mi ha mostrato un blog di Jeremy Cole su MySQL e Swappiness. Dopo averlo letto, lo metto subito in pratica per il mio cliente. Ho eseguito questo comando

numactl --hardware

Ho visto una mappatura di 192 GB di RAM del server come 96 GB su ciascun core fisico. Pertanto, ho impostato innodb_buffer_pool_instances su 2. Le cose stanno andando bene in questo momento. Aggiornerò la mia risposta per vedere come ciò influisce sullo scambio di memoria per i prossimi 2 mesi.

Potresti voler esplorare le seguenti risorse:

• Una FAQ delle migliori pratiche
• Manuale: ottimizzazione dei parametri del server
• Manuale: sintonizzazione InnoDB
• Un elenco più vecchio di variabili importanti.

Innanzitutto aumentare la dimensione predefinita del pool di buffer InnoDB in my.cnf (credo che sia predefinita a 8 MB)

Probabilmente dovresti impostarlo al 75% della dimensione della tua RAM (in generale)

Quali parametri di configurazione cambiate più comunemente dai loro valori predefiniti?

configurazione della memoria