2012-05-10 5 views
5

Sto perfezionando una query di grandi dimensioni e voglio eseguirlo dalla stessa linea di base prima e dopo, per fare un confronto.come cancellare/svuotare il pool di buffer innodb mysql?

Conosco la cache di query mysql, ma non è rilevante per me, dal momento che le 2 query non sarebbero comunque memorizzate nella cache.

Che cosa viene memorizzato nella cache, è le pagine di innodb, nel pool di buffer. C'è un modo per cancellare l'intero pool di buffer in modo da poter confrontare le due query dallo stesso punto di partenza?

Mentre il riavvio del server MySQL dopo aver eseguito ogni query sarebbe senza dubbio il lavoro, Id piacerebbe evitare questo, se possibile,

risposta

8

ATTENZIONE: La seguente funziona solo per MySQL 5.5 e MySQL 5.1.41+ (InnoDB Plugin)

Tweek la durata di voci nel buffer InnoDB piscina con queste impostazioni:

SET GLOBAL innodb_old_blocks_time=250; // This is 0.25 seconds 
SET GLOBAL innodb_old_blocks_pct=5; 
SET GLOBAL innodb_max_dirty_pages_pct=0; 

quando si è fatto il test, impostandoli ai valori predefiniti:

SET GLOBAL innodb_old_blocks_time=0; 
SET GLOBAL innodb_old_blocks_pct=37; 
SET GLOBAL innodb_max_dirty_pages_pct=90; // 75 for MySQL 5.5/MySQL 5.1 InnoDB Plugin 

Partenza la definizione di queste impostazioni

+0

ottima risposta, grazie. Ho solo una domanda però ... Quando una pagina tampone è scaduta, è appena contrassegnata come cancellata? Voglio solo assicurarmi che non ci sia qualche thread innodb in esecuzione che periodicamente prompa le pagine buffer scadute (e potenzialmente crea un carico maggiore sul database perché il timeout è così basso). --- So che è solo temporaneo per i test, ma ho bisogno di avere una buona padronanza su questi particolari benchmark – carpii

+0

@Rolando, se ho molti altri programmi in esecuzione e ho bisogno di MySQL per usare meno RAM possibile, vuol dire che io dovrebbe impostare il pool buffer innodb a zero? O c'è un importo minimo richiesto? – Pacerier

2

Molto più semplice ... Esegui questo due volte

SELECT SQL_NO_CACHE ...; 

E guardate il secondo tempistica .

Il primo riscalda il buffer_pool; il secondo evita il controllo di qualità avendo SQL_NO_CACHE.

Quindi il secondo tempo è una buona indicazione di quanto tempo ci vuole in un sistema di produzione con una cache calda.

Inoltre, Guardate Handler conta

FLUSH STATUS; 
SELECT ...; 
SHOW SESSION STATUS LIKE 'Handlers%'; 

dà un ragionevolmente quadro chiaro di quante righe vengono toccati. Questo, a sua volta, ti dà una buona sensazione per quanto sforzo richiede la query. Si noti che questo può essere eseguito con successo (e rapidamente) su piccoli set di dati. Quindi è possibile (spesso) estrapolare a set di dati più grandi.

Un "Handler_read" potrebbe leggere una riga di indice o una riga di dati. Potrebbe essere la riga 'successiva' (quindi probabilmente memorizzata nella cache nel blocco che è stato letto per la riga precedente), o potrebbe essere casuale (quindi probabilmente soggetta a un altro hit del disco). Cioè, la tecnica non aiuta molto con "quanti blocchi sono necessari".

Questa tecnica di Handler è impenetrabile a quello che sta succedendo; dà risultati coerenti.

"Handler_write" indica che era necessaria una tabella tmp.

I numeri che approssimano il numero di righe nella tabella (o un multiplo di tali), probabilmente indicano una scansione di tabella. Un numero uguale a LIMITpotrebbe essere significa che è stato creato un indice così buono da consumare lo LIMIT in se stesso.

Se fate lavare la buffer_pool, si potrebbe guardare per i cambiamenti nella Innodb_buffer_pool_reads per dare una precisa (?) Conteggio del numero di pagine lette in un freddo sistema di . Ciò includerebbe pagine indice non foglia, che sono quasi sempre memorizzate nella cache. Se nel sistema è in corso qualcos'altro, questo valore STATUS non dovrebbe essere considerato attendibile perché è "globale", non "sessione".