Mettere i log di redo Oracle su SSD DRAM per un database di scrittura pesante?

Ho un Sun M4000 collegato a un array EMC CX4-120 con un database pesante per la scrittura. Scrive il picco a circa 1200 IO / se 12 MB / s.

Secondo EMC, sto saturando la cache di scrittura sull'array EMC.

Penso che la soluzione più semplice sia spostare i registri di ripetizione su un SSD basato su DRAM. Ciò ridurrà della metà il carico sull'array EMC e le app non vedranno l'attesa del buffer di registro. Sì, il DBWR potrebbe diventare un collo di bottiglia, ma le app non lo aspetteranno (come fanno per i commit di ripristino!)

Attualmente passo in rassegna circa 4 registri di ripetizione da 4 GB, quindi anche circa 20 GB di SSD farebbero una grande differenza. Poiché si tratta di archiviazione a breve termine e viene costantemente sovrascritta, gli SSD basati su Flash probabilmente non sono un'ottima idea.

L'M4000 non ha lotti di unità extra, quindi una scheda PCI-E sarebbe perfetta, potrei andare all'esterno o spostare i volumi di avvio su EMC e liberare le unità locali.

Sun vende una scheda PCIe Flash Accelerator F20, ma sembra essere una cache per alcuni dischi SATA, non una soluzione SSD DRAM. I dettagli sono imprecisi, non elenca l'M4000 come supportato e sono stanco di combattere l'albero del telefono di Sun in cerca di aiuto umano. :(

Altri concordano sul fatto che un SSD DRAM è la strada da percorrere? Qualche consiglio sull'hardware?

AGGIORNAMENTO Oltre alle informazioni in un commento qui sotto, ho provato varie impostazioni per "commit_write" e non ha fatto differenza.

Primo: suppongo che tu abbia pochissimi dischi nell'array. 1200IOPS può essere facilmente supportato da 12 dischi rotanti (100 IOPS per disco sono molto ragionevoli). Se la cache non è in grado di gestirla, significa che la velocità di scrittura sostenuta di 1200 IOPS è molto più di quanto i dischi possano supportare.

In ogni caso, SSD per i registri di ripetizione non è probabilmente d'aiuto. Innanzitutto, la sessione attende principalmente sull'istruzione COMMIT? Controlla i principali eventi di attesa in statspack / AWR per verificare. Immagino che ~ il 95% del tuo I / O non riguardi affatto i registri di ripetizione. Ad esempio, un singolo inserimento di riga in una tabella con 5 indici può eseguire 1 I / O per leggere un blocco di tabella (che ha spazio per la riga), leggere 5 blocchi di indice (per aggiornarli), scrivere 1 blocco di dati, 1 annulla blocco e 5 blocchi indice (o più, se vengono aggiornati blocchi non foglia) e 1 blocco ripetizione. Quindi, controlla statspack e vedi i tuoi eventi di attesa, probabilmente stai aspettando molti READ e WRITE per dati / indici. Attendere le letture rallenta INSERT e l'attività WRITE rende i READ ancora più lenti - sono gli stessi dischi (BTW - hai davvero bisogno di tutti gli indici? Facendo cadere quelli che non lo sono devi accelerare gli inserimenti).

Un'altra cosa da verificare è la definizione RAID - è RAID1 (mirroring - ogni scrittura è due scritture) o RAID 5 (ogni scrittura è 2 letture e due scritture per il calcolo del checksum). RAID 5 è molto più lento nel carico ad alta intensità di scrittura.

A proposito: se i dischi non riescono a caricare il carico in scrittura, DBWR sarà un collo di bottiglia. Il tuo SGA sarà pieno di blocchi sporchi e non ti sarà lasciato spazio per leggere nuovi blocchi (come blocchi di indice che devono essere elaborati / aggiornati) finché DBWR non può scrivere alcuni blocchi sporchi sui dischi. Ancora una volta, controlla statspack / awr report / addm per diagnosticare qual è il collo di bottiglia, in genere basato sui primi 5 eventi di attesa.

dd è nulla rispetto al blocco degli I / O.

Per alcune altre visualizzazioni, controlla in giro, anandtech.com ha effettuato un test esaustivo (concesso con MS SQL Server) con SAS che ruota contro SSD, in varie combinazioni, e il mondo Solaris ha ZFS con SSD che compongono varie parti (log, cache, ecc. ).

Ma sì, se RAID 5 vs RAID 10 è lo stesso (per le scritture), stai facendo qualcosa di sbagliato. Con le scritture lineari, diamine RAID 5 potrebbe essere più veloce (cioè può fare la parità in memoria, quindi scrivere le strisce e la parità tutte in una volta), ma con un piccolo blocco casuale (4-8k), verrai ucciso aggiornando le strisce (come notato da altri), il raid 10 dovrebbe essere più di 2 volte più veloce, altrimenti qualcosa non va.

Devi scavare più a fondo, prima di spendere soldi per l'hardware.

Ho visto un post sul montaggio di partizioni UFS usando l'opzione "forcedirectio" e impostando il parametro Oracle "filesystemio_options" su "setall".

L'ho provato e ho visto un miglioramento di 4-5x nelle scritture Oracle! Sì!

I sintomi chiave sono stati un throughput basso ma buoni tempi di risposta sul disco. Questo sembra aiutare alcune persone ma non altre. Certamente ha fatto il lavoro per me.

Potrei prendere in considerazione SSD per i nuovi server, ma questo server funziona bene ora.

Roberto

Se questa scatola fosse stata solo una scatola x86 / 64 con sistema operativo Linux avrei felicemente raccomandato una delle schede di unità Fusione PCIe - sono sorprendentemente veloci e non "muoiono" con scritture pesanti come fanno gli SSD. Sfortunatamente non sono supportati con Sparc o Solaris, tuttavia potresti volerli contattare per discuterne.

La scheda PCIe F20e è simile all'I / O Fusion in funzione. Fondamentalmente è solo un SSD Flash collegato PCIe. Con un carico di lavoro pesante in scrittura, dovrai preoccuparti sia di mantenere abbastanza blocchi liberi (tramite una raccolta dei rifiuti basata sull'unità di qualche tipo) in modo da non finire con il ciclo di cancellazione / programma sull'SSD che diventa il collo di bottiglia, così come i cicli di scrittura limitati disponibili su un SSD basato su Flash. È decisamente veloce, ma potrebbe non essere il miglior kit per questo lavoro.