Ağır yazma veritabanı için Oracle yeniden yazma günlüklerini DRAM SSD'ye mi koyuyorsunuz?

Bir yazma ağır veritabanı ile bir EMC CX4-120 dizisine bağlı bir Sun M4000 var. En fazla 1200 IO / s ve 12MB / s hızda yazar.

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

Bence en basit çözüm yineleme günlüklerini DRAM tabanlı bir SSD'ye taşımaktır. Bu, EMC dizisi üzerindeki yükü yarıya indirir ve uygulamalar günlük arabelleği beklemelerini görmez. Evet, DBWR bir darboğaz haline gelebilir, ancak uygulamalar bunu beklemeyecektir (yeniden yapma işlemlerinde yaptıkları gibi!)

Şu anda yaklaşık 4 4GB'lık yineleme günlükleri arasında dolaşıyorum, bu yüzden SSD'nin 20GB veya daha fazlası bile büyük bir fark yaratacaktır. 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'in ekstra sürücü lotu yoktur, bu nedenle bir PCI-E kartı mükemmel olurdu, harici olabilir veya önyükleme birimlerini EMC'ye taşıyabilir ve yerel sürücüleri boşaltabilirim.

Sun bir Flash Accelerator F20 PCIe kartı satıyor, ancak bu DRAM SSD çözümü için değil, bazı SATA diskleri için önbellek gibi görünüyor. Ayrıntılar kabataslak, M4000'i desteklenen olarak listelemiyor ve Sun'ın telefon ağacıyla insan yardımı aramaktan bıktım. :(

Diğerleri bir DRAM SSD'nin gidilecek yol olduğu konusunda hemfikir mi? Herhangi bir donanım önerisi var mı?

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

İlk - Sanırım dizide çok az disk var. 1200IOPS 12 eğirme diski olarak kolayca desteklenebilir (disk başına 100 IOPS çok makuldür). Önbellek bunu kaldıramazsa, 1200 IOPS'luk sürekli yazma oranı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ı muhtemel değildir. İlk olarak, oturumunuz çoğunlukla COMMIT deyiminde mi bekliyor? Doğrulamak için istatistik paketindeki / AWR'deki en iyi bekleme etkinliklerini kontrol edin. I / O ~% 95 hiç yineleme günlükleri için değil tahmin ediyorum. Örneğin, 5 dizinli bir tabloya tek satırlı bir ekleme, bir tablo bloğunu (satır için boşluğu olan) okumak için 1 G / Ç yapabilir, 5 dizin bloğunu okuyabilir (güncellemek için), 1 veri bloğu yazabilir, 1 geri alabilir blok ve 5 dizin bloğu (veya yaprak olmayan bloklar güncellenirse daha fazla) ve 1 blok yinele. Böylece, istatistik paketini kontrol edin ve bekleme etkinliklerinizi görün, muhtemelen veri / dizinler için hem READ'ların hem de WRITE'ların çoğunu bekliyorsunuz. Okumaları beklemek INSERT'i yavaşlatır ve WRITE aktivitesi READ'leri daha da yavaşlatır - aynı disklerdir (BTW - gerçekten tüm indekslere ihtiyacınız var mı? Olmayanları bırakmak ekleri hızlandıracaktır).

Kontrol edilecek başka bir şey RAID tanımı - RAID1 (yansıtma - her yazma iki yazma) veya RAID 5 (her yazma 2 okuma ve sağlama toplamı hesaplaması için iki yazma). RAID 5 yazma yoğun yükte çok daha yavaştır.

BTW - diskler yazma yükünü kaldıramazsa, DBWR bir darboğaz olacaktır. SGA'nız kirli bloklarla dolu olacak ve DBWR disklere kirli bloklar yazana kadar yeni blokları (işlenmesi / güncellenmesi gereken dizin blokları gibi) okuyacak yeriniz olmayacak. Yine, genellikle en iyi 5 bekleme olayını temel alan darboğazın ne olduğunu teşhis etmek için statspack / awr rapor / addm'yi kontrol edin.

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 SSD'ye karşı SAS dönen ile exaustive bir test yaptı (MS SQL sunucusu ile verildi) ve Solaris dünyasında çeşitli parçaları (kütükler, önbellek, vb. ).

Ancak evet, RAID 5 ve RAID 10 aynı ise (yazma için) yanlış bir şey yapıyorsunuz demektir. Lineer yazımlarla, heck RAID 5 daha hızlı olabilir (yani hafızadaki pariteyi yapabilir, ardından çizgileri ve pariteyi bir kerede yazabilir), ancak rastgele küçük blok (4-8k) ile şeritleri güncelleyerek ( başkaları tarafından not edildi), baskın 10, 2x'ten daha hızlı olmalı, değilse, bir sorun var.

Donanıma para harcamadan önce daha derine inmeniz gerekir.

"Zorunlu yönlendirme" seçeneğini kullanarak UFS bölümlerini bağlama ve Oracle "filesystemio_options" parametresini "setall" olarak ayarlama hakkında bir yazı gördüm.

Denedim ve Oracle yazıyor 4-5x bir gelişme görmek! Evet!

Anahtar semptomlar düşük verim, ancak diskte iyi yanıt süreleridir. Bu bazı insanlara yardım ediyor gibi görünüyor ama diğerlerine değil. Kesinlikle benim için iş yaptı.

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

Robert

Bu kutu sadece bir x86 / 64 kutusu çalıştıran linux olsaydı, FusionIO PCIe sürücü kartlarından birini mutlu bir şekilde tavsiye ederdim - şaşırtıcı derecede hızlıdırlar ve SSD'ler gibi ağır yazmalarla 'ölmezler'. Ne yazık ki Sparc veya Solaris ile desteklenmiyorlar, bunu tartışmak için onlarla iletişime geçmek isteyebilirsiniz.

F20e PCIe kartı işlevdeki Fusion I / O'ya benzer. Temel olarak yalnızca PCIe'ye bağlı Flash SSD'dir. Yazma ağır iş yükü ile, hem yeterli boş blokların (bir tür sürücü tabanlı çöp toplama yoluyla) sürdürülmesi konusunda endişelenmeniz gerekir, böylece SSD'nin darboğaz haline gelen Sil / Program döngüsüne katılmazsınız, hem de Flash tabanlı SSD'de bulunan sınırlı yazma döngüleri. Kesinlikle hızlı, ancak bu iş için en iyi kit olmayabilir.