Wow, hai dell'hardware terribilmente robusto per questo problema. Non c'è molto di più che si possa considerare dal punto di vista hardware, ad eccezione dell'aggiornamento a forse le CPU Sandy / Ivy Bridge per prestazioni migliori del 20-50% rispetto alle ricerche Btree, ecc.
Nota che il mio forte è Innodb, quindi lo farò
- Ignora che sei myisam e agisci come se non facesse la differenza.
- Supponiamo che questo problema sia sufficiente per farti aggiornare. Sì, è un aggiornamento.
Innodb può aiutare a sfruttare al meglio tutta quella memoria memorizzando queste righe a cui si accede frequentemente nel suo pool di buffer. Puoi ottimizzarlo per essere grande quanto vuoi (diciamo l'80% della memoria) e le letture / scritture nuove rimangono in memoria fino a quando non è necessario spingerle sul disco per fare spazio agli ultimi dati a cui si accede. In memoria è un ordine di grandezza più veloce dei tuoi FusionIO.
Esistono molte altre funzionalità di Innodb, come hash adattivi, meccanismi di blocco automatico, ecc. Che possono essere un vantaggio per il tuo ambiente. Tuttavia, conosci i tuoi dati meglio di me.
Nel mondo innodb, una buona soluzione a breve termine è quella di ottimizzare il tuo slave: hai davvero bisogno di ogni indice sul tuo slave che hai sul tuo master? Gli indici sono una palla a catena su inserti / aggiornamenti / eliminazioni, ANCHE con schede IO Fusion. IOPS non sono tutto qui. I processori Sandy / Ivy bridge hanno una memoria e prestazioni di calcolo molto migliori: possono fare una grande differenza per i Westmer che hai ora. (Figura 20-50% complessivo). Rimuovi tutti gli indici che non ti servono sullo slave!
Secondo, e quasi certamente si applica solo a innodb, è che mk-prefetch può sapere quali aggiornamenti e prima che lo slave li scriva. Ciò consente a mk-prefetch di eseguire prima una query di lettura, forzando in tal modo i dati in memoria quando il singolo sostituto esegue la query di scrittura. Ciò significa che i dati sono in memoria e non in fusionIO, un rapido ordine di guadagno delle prestazioni di grandezza. Questo fa una GRANDE differenza, più di quanto ci si potrebbe aspettare. Molte aziende lo usano come soluzione permanente. Per saperne di più, consulta Percona Toolkit .
Terzo, e soprattutto, dopo aver effettuato l'aggiornamento a Innodb, dai un'occhiata a Tokutek. Questi ragazzi hanno delle cose terribilmente fantastiche che superano le prestazioni di scrittura / aggiornamento / eliminazione di Innodb da un colpo lungo. Hanno promosso una maggiore velocità di replica come uno dei vantaggi chiave e dai loro parametri di riferimento è possibile capire perché IOPS pazzi di Fusions non ti aiuterà ancora nel caso di Btrees . (Nota: non verificato da me in modo indipendente.) Usano un drop-in sostituto di un indice btree che, sebbene orribilmente più complesso, migliora molti dei limiti di velocità algoritmica degli indici btree.
Sono in procinto di prendere in considerazione l'adozione di Tokutek. Se liberano tanta velocità di scrittura, ciò mi consente di aggiungere più indici. Dato che comprimono i dati e gli indici a rapporti così meravigliosi (25 volte citano), non si paga nemmeno un prezzo (prestazioni, manutenzione) per aumentare i dati. Paghi ($) per il loro motore, $ 2500 / anno per GB precompresso, IIRC. Hanno sconti se hai i dati replicati, ma puoi anche semplicemente installare Tokutek sul tuo slave e mantenere il tuo master così com'è. Consulta i dettagli tecnici nella lezione del MIT Algoritms Open Courseware . In alternativa, hanno tonnellate di materiale tecnico sul loro blog e white paper regolari per coloro che non hanno 1:20 per guardare il video. Credo che questo video fornisca anche la formula Big-O per quanto sono veloci le letture. Io hosupporre che le letture siano più lente (c'è sempre un compromesso!), ma la formula è troppo complessa per me per valutare quanto. Sostengono che è più o meno la stessa cosa, ma preferirei capire la matematica (probabilmente non!). Potresti trovarti in una situazione migliore per scoprirlo di me.
Ps Non sono affiliato con Tokutek, non ho mai eseguito il loro prodotto e non sanno nemmeno che li sto guardando.
Aggiornamento :
Vedo che hai altre domande su questa pagina e ho pensato di aggiungere:
Innanzitutto, il pre-fetch degli schiavi non funzionerà quasi certamente per myisam a meno che non si abbia un ambiente eccezionale. Ciò è principalmente dovuto al fatto che il prefetching bloccherà proprio le tabelle in cui si intende scrivere, oppure il thread slave ha la tabella bloccata di cui il demone pre-fetch ha bisogno. Se le tue tabelle sono estremamente ben bilanciate per la replica e vengono scritte diverse tabelle in modo round robin, questo può funzionare - ma tieni presente che è molto teorico. Il libro "High Performance Mysql" contiene ulteriori informazioni nella sezione "Problemi di replica".
In secondo luogo, presumibilmente il tuo slave ha un carico di 1,0-1,5, potrebbe essere più alto se hai altri proc o query in esecuzione ma una baseline di 1.0. Ciò significa che probabilmente sei legato alla CPU, il che è probabile con FusionIO integrato. Come ho detto prima, Sandy / Ivy Bridge darà un po 'più di brio, ma probabilmente non abbastanza per superare i tempi più difficili con un ritardo minimo. Se il carico su questo slave è per lo più di sola scrittura (cioè non molte letture), la CPU sta quasi sicuramente impiegando il suo tempo a calcolare le posizioni per inserimenti / eliminazioni btree. Questo dovrebbe rafforzare il mio punto sopra sulla rimozione di indici non critici: puoi sempre aggiungerli di nuovo in un secondo momento. Disabilitare l'hyperthreading non funzionerà, più CPU non è il tuo nemico. Una volta superati i 32 GB di RAM, diciamo 64 GB, devi preoccuparti della distribuzione delle ram, ma anche allora i sintomi sono diversi.
Infine, e soprattutto (non saltare questa parte;)), presumo che ora stai eseguendo RBR (replica basata su righe) perché hai menzionato un aumento delle prestazioni non banale quando lo hai cambiato. Tuttavia, potrebbe esserci un modo per ottenere prestazioni ancora maggiori qui. Il bug 5q75 di Mysql può manifestarsi se hai tabelle replicate senza chiave primaria. Lo slave non è fondamentalmente abbastanza intelligente da utilizzare qualsiasi cosa tranne una chiave primaria, quindi l'assenza di uno forza il thread di replica a eseguire una scansione della tabella completa per ogni aggiornamento. Una correzione consiste semplicemente nell'aggiungere una chiave primaria autoincrementante benigna e surrogata. Lo farei solo se la tabella fosse grande (diciamo più di 10 o migliaia di righe). Questo, ovviamente, ha il costo di avere un altro indice sul tavolo, il che fa apparire il prezzo da pagare in CPU. Nota che ci sono pochissimi argomenti teorici contro questo, poiché InnoDB ne aggiunge uno dietro le quinte se non lo fai. Quello fantasma, però, non è una difesa utile contro 53375. tungsteno in grado di superare anche questo problema, ma è necessario per essere sicuri quando si utilizza tungsteno che avete la vostra codifica dritto. L'ultima volta che ci ho giocato, sarebbe morto in modo orribile quando ogni stringa non UTF8 doveva essere replicata. Questo è il momento in cui mi sono arreso.
