Soru Ağır bir yazma veritabanı için Oracle redo günlüklerini DRAM SSD'ye koymak?


EMC CX4-120 dizisine yoğun veri tabanına sahip bir Sun M4000 cihazım var. En yüksek 1200 IO / s ve 12MB / s değerinde yazar.

EMC'ye göre, EMC dizisindeki yazma önbelleğini doyuyorum.

Bence en basit çözüm yineleme günlüklerini DRAM tabanlı bir SSD'ye taşımaktır. Bu, EMC dizisindeki yükü yarıya indirecek ve uygulamalar günlük arabelleğinin beklediğini görmeyecek. Evet, DBWR bir darboğaz haline gelebilir, ancak uygulamalar bunu beklemeyecektir (yeniden yaptırma işlerinde olduğu gibi!)

Şu anda yaklaşık 4 4GB'lık redo kayıtlarından geçiyorum, bu yüzden 20GB'lık SSD bile büyük bir fark yaratıyor. Bu kısa süreli depolama olduğundan ve sürekli üzerine yazıldığından, Flash tabanlı SSD'ler muhtemelen iyi bir fikir değildir.

M4000'de fazladan sürücü yok, dolayısıyla bir PCI-E kartı mükemmel olurdu, harici olarak gidebilir veya EMC'ye önyükleme hacimlerini taşıyabilir ve yerel sürücüleri serbest bırakabilirim.

Sun bir Flash Accelerator F20 PCIe kartı satıyor, ancak bazı SATA diskleri için bir DRAM SSD çözümü değil, önbellek gibi görünüyor. Detaylar kabataslak, desteklendiği gibi M4000'i listelemiyor ve Sun'ın telefon ağacında insani yardım aramaktan sıkıldım. :(

Diğerleri, DRAM SSD'nin gitmenin yolu olduğuna katılıyor mu? Herhangi bir donanım önerisi?

GÜNCELLEŞTİRME Aşağıdaki bir yorumdaki bilgilere ek olarak, "commit_write" için çeşitli ayarları denedim ve bir fark yaratmadı.


9
2017-07-12 18:21


Menşei


Günlükleri bir yere arşivliyor musun? En sonunda diskin SSD'den kopyalanması gerekiyorsa, o zaman darboğazyı arşivlemeye taşıyabilirsiniz. - Gary
Evet ... yineleme günlükleri arşivlenir ve yinelenen bir yazma olduğu için yineleme günlüğü kopyası sırasında IO aslında yaklaşık 80MB / s'ye çıkar. Yineleme günlüklerinin sıralı olduğunu düşünürdüm, ama sanırım değil. - rmeden


Cevaplar:


İlk - Sanırım dizide çok az disk var. 1200IOPS kolayca desteklenebilir 12 eğirme diski (disk başına 100 IOPS çok makul). Önbellek işleyemezse, bu, 1200 IOPS sürekli yazma hızınızın disklerinizin destekleyebileceğinden çok daha fazla olduğu anlamına gelir.

Her neyse, yineleme günlükleri için SSD'nin yardımcı olması olası değildir. İlk olarak, oturumunuz çoğunlukla COMMIT bildirisinde bekler mi? Doğrulamak için statspack / AWR'deki en iyi bekleme olaylarını kontrol edin. I / O'nızın% 95'inin yineleme günlükleri için olmadığını tahmin ederim. Örneğin, 5 endeksli bir tabloya tek bir satır eki, bir tablo bloğunu okumak için 1 I / O yapabilir (satır için boşluk içerir), 5 dizin bloğunu oku (bunları güncelleştirmek için), 1 veri bloğu yaz, 1 geri al blok ve 5 dizin bloğu (veya yaprak olmayan bloklar güncellenirse daha fazla) ve 1 redo bloğu. Bu yüzden, statspack'i kontrol edin ve bekleme etkinliklerinizi görün, büyük olasılıkla veri / dizin için hem READ'leri hem de WRITE'ları beklersiniz. Okumaları beklemek INSERT'i yavaşlatır ve WRITE etkinliği READ'leri daha da yavaşlatır - aynı diskler (BTW - gerçekten tüm dizinlere ihtiyacınız var mı? Eklemeyi hızlandıracak olmayanları düşürmeniz gerekir).

Kontrol edilmesi gereken başka bir şey de RAID tanımlamasıdır - RAID1 (yansıtma - her yazma iki yazma) veya RAID 5 (her yazma, 2 sağlama ve sağlama toplamı için iki yazmadır). Yoğun yazma yoğunluğunda RAID 5 daha yavaştır.

BTW - diskler yazma yükünü kaldıramıyorsa, DBWR bir darboğaz olacaktır. SGA'nız kirli bloklarla dolu olacaktır ve DBWR disklere bazı kirli bloklar yazana kadar yeni blokları (işlenecek / güncellenmesi gereken dizin blokları gibi) okumak için yer kalmayacak. Yine, en iyi 5 bekleme olayına dayanan darboğazın ne olduğunu teşhis etmek için statspack / awr raporu / addm'yi kontrol edin.


9
2017-07-12 20:58



+1 - eğer yapabilirsem +10 verirdim. - Helvick
Tıkanıklığın nerede olduğunu görmek için tavsiye almak için +1. - DCookie
Beklemeler "günlük dosyası senkronizasyonu" ve "günlük arabelleği alanı" dır. DD kullanarak hacmi 150MB / s alabilirim. LGWR'nin bir sonraki raporunu göndermeden önce bir İO'nun tamamlanmasını beklediğinden şüpheleniyorum. IO servis süresi yaklaşık 1ms'dir. EMC'nin, tüm kutuyu yükseltmeksizin EMC'ye göre artırılamayacak kadar büyük bir 500MB'lık önbellek var. Dizide 22 TB var, neden bu kadar az önbellek ile bir şey sunacaklar, benim dışımda. Yineleme günlükleri şu anda 5-genişliğindeki bir RAID 5'te, fakat RAID 10 ile hiçbir fark yoktu (önbellekten şüphelenmek için başka bir sebep) - rmeden
Btw, daha fazla önbellek varsa disk hala devam etmeyebilir. REDO'yu EMC dizisinden uzaklaştırarak, veri diskleri için kapasiteyi serbest bırakır ve I / O'yu yarıya indirir. Küçük bir DRAM SSD, küçük olabileceği için en ucuz, yüksek performanslı disk olabilir. - rmeden
meden - Oracle saniyede ne kadar yineleme yapıyor? Toplam G / Ç'nin 12 MB / s ve 1200 IOPS olduğunu söylediniz, bu çok sayıda küçük IO anlamına geliyor (ortalama 10 KB). Yineleme günlüklerini SSD'ye taşırsanız, DBWR'nin darboğaz haline gelmesi ve INSERT'nin SGA'daki boş arabelleği beklemesi nedeniyle farklı bekleme olaylarını göreceksiniz. Lütfen kontrol edin - hangi RAID türünüz var, şerit boyutu nedir ve Oracle blok boyutu nedir (ayrıca, veri dosyalarınız tüm diskler üzerinde çizgili mi?). Ayrıca, G / Ç'nin çoğunun kaynağı için statspack'i kontrol edin - yineleyin mi yoksa başka bir şey mi? - Tablo başına G / Ç'yi kontrol edin - Ofir Manor


dd, blok i / o ile karşılaştırıldığında hiçbir şey değildir.

Diğer bazı görünümler için, kontrol edin, anandtech.com çeşitli kombinasyonlarda SAS döner vs SSD ile exaustive bir test (MS SQL sunucusu ile verilir) yaptı ve Solaris dünyası SSD çeşitli parçaları (logs, önbellek, vb. ).

Ama evet, eğer RAID 5 vs RAID 10 aynıysa (yazmalar için), yanlış bir şey yapıyorsunuz demektir. Doğrusal yazımlarla, heck RAID 5 daha hızlı olabilir (yani bellekte parite yapabilir, ardından çizgileri ve pariteyi bir kerede yazabilir), ancak rastgele küçük bir blokla (4-8k), ( Diğerleri tarafından kaydedilen), baskın 10, 2x daha hızlı olmalıdır, eğer değilse, bir şey yanlıştır.

Donanımı para harcamadan önce daha derine inmelisin.


2
2017-07-13 00:42





"Forcedirectio" seçeneğini kullanarak ve "fileystemio_options" Oracle parametresini "setall" olarak ayarlayarak UFS bölümlerinin montajıyla ilgili bir yazı gördüm.

Bunu denedim ve Oracle yazımında 4-5x'lik bir gelişme görüyorum! Evet!

Anahtar belirtiler düşük çıktı, ancak diskte iyi yanıt süreleriydi. Bu, bazı insanlara yardımcı olur ama diğerleri değil. Kesinlikle benim için iş yaptı.

SSD'leri yeni sunucular için düşünebilirim, ancak bu sunucu şu anda iyi çalışıyor.

Robert


2
2017-10-27 16:35



Büyük olasılıkla, yaşadığınız hızlanma doğrudan G / Ç'nin etkinleştirilmesiyle değil, eşzamansız G / Ç'yi etkinleştirerek olmamıştır. Oracle'da, setalli doğrudan + async anlamına gelir. - kubanczyk


Bu kutu sadece çalışan bir linux linux x86 / 64 kutusu olsaydı, FusionIO PCIe sürücü kartlarından birini tavsiye edebilirdim. Şaşırtıcı derecede hızlılar ve SSD'ler gibi ağır yazımlarla 'ölmezler'. Ne yazık ki, ya Sparc ya da Solaris ile desteklenmiyorlar, ancak bunu tartışmak için onlarla iletişime geçmek isteyebilirsiniz.


1
2017-07-13 14:11





F20e PCIe kartı, Fusion I / O işlevine benzer. Temel olarak sadece bir PCIe ekli Flash SSD. Yoğun iş yükü ile, yeterli boş blokları (bir çeşit sürücü tabanlı çöp toplama yoluyla) korumak için endişelenmeniz gerekecek, böylece SSD'deki Darboğaz / Program döngüsü ile birlikte darboğaz haline gelmeyeceksiniz. Flash tabanlı SSD'de kullanılabilen sınırlı yazma döngüleri. Bu kesinlikle hızlı, ancak bu iş için en iyi takım olmayabilir.


1
2017-08-31 15:41



John. Benim için çalışacağını düşünmemiştim. Güneş zaten bir M4000 üzerinde bile desteklemiyor. :( - rmeden