PostgreSQL'de insert performansı için en iyi dosya sistemi hangisidir?

Orada herkes dosya sistemleri ve veritabanı performansı arasında herhangi bir deneme veya karşılaştırma yaptı olup olmadığını merak ediyorum. Linux'ta, postgres veritabanı için en uygun dosya sisteminin ne olduğunu merak ediyorum. Ayrıca, hangi ayarlar (inode, vb.) Bunun için idealdir? Bu, veritabanındaki verilere göre büyük ölçüde farklılık gösterebilecek bir şey mi?

Genel dosya sistemi / veritabanı performansı ile ilgili bir soru arıyorsanız, bu yayında bazı iyi bilgiler var.

Bununla birlikte, mümkün olduğunca okuma performansı yerine kesici uç performansı hakkında çok fazla tavsiye almak istiyorum. Tüm harika cevaplar için teşekkürler!

Greg Smith tarafından "postgresql yüksek performans" bir kopyasını satın alın. Bu harika bir Kitap ve iki veya daha fazla bölüm Disk Donanım ve dosya sistemleri hakkında. Çok şey öğreneceksiniz.

Kısacası: kısa bir cevap yok.

Ama yaz yapmaya çalışacağım:

• ne yaptığınızı bilinceye kadar ext2 kullanmayın.
• ext3 ile fsync çağrıları nedeniyle kontrol noktası ani artışlarına dikkat edin, bkz. sayfa 113 ve 82 ve 79
• ext4 veya xfs kullan
• başka seçenekler var

Ama kendinize hangi FS'yi kullanacağınızı gerçekten sorduğunuzda, kitabı okumalısınız!

Her şeyden önce, önce güvenilir bir dosya sistemi ve hızlı bir saniye istiyorum. Hangi bazı seçenekleri göz ardı eder ...

Performans testi genellikle XFS'nin en iyi performansı verdiğini gösterir. Çok yakın diske yakın senaryolara ulaştığınızda bazı istikrar sorunları var, ancak bunun gerçekleşmediğini izlediğiniz sürece, size biraz daha iyi performans verecektir.

Teorik olarak pg_xlog dizini için günlük kaydı dosya sistemine ihtiyacınız yoktur, ancak hızdaki fark genellikle o kadar küçüktür ki buna değmez. Veri dizini için, her zaman bir meta veri günlük kaydı dosya sistemine sahip olmalısınız.

Veritabanı yönetim sistemleri, veritabanı günlükleri aracılığıyla kendi günlük kayıtlarını uygular, bu nedenle günlüklenmiş bir dosya sistemine böyle bir DBMS yüklemek, iki mekanizma yoluyla performansı düşürür:

1. Yedekli günlük kaydı disk etkinliği miktarını artırır

2. Fiziksel disk düzeni parçalanabilir (bazı günlük dosya sistemlerinde bunu temizlemek için mekanizmalar olsa da).

3. Birçok disk etkinliği günlüğü doldurarak sahte 'disk dolu' koşullara neden olabilir.

Birkaç yıl önce bunun bir HP / UX kutusundaki Baan kurulumunda LFS dosya sisteminde yapıldığı bir örnek gördüm. Sistemde, biri dosya sistemlerinin LFS ile biçimlendirildiğini anlayana kadar tanı konulmayan kalıcı performans ve veri bozulması sorunları vardı.

Veritabanı dosyalarını tutan birimlerde normal olarak az sayıda büyük dosya bulunur. DBMS sunucuları normalde tek bir G / Ç'de kaç blok okunacağını yapılandıran bir ayara sahiptir. Daha küçük sayılar, gereksiz verilerin önbelleğe alınmasını en aza indireceğinden, yüksek hacimli işlem işleme sistemleri için uygun olacaktır. Daha büyük rakamlar, veri depoları gibi çok sayıda sekreterya okuması yapan sistemler için uygun olacaktır. Mümkünse, dosya sistemi ayırma bloğu boyutunuzu, DBMS'nin ayarlandığı çok bloklu okuma ile aynı boyutta olacak şekilde ayarlayın.

Bazı veritabanı yönetim sistemleri ham disk bölümlerini çalıştırabilir. Bu, tipik olarak daha fazla belleğe sahip modern bir sistemde daha az değişen performans artışı sağlar. Dosya sistemi meta verilerini önbelleğe almak için daha az alana sahip eski sistemlerde, disk G / Ç'deki tasarruf oldukça önemlidir. Ham bölümler sistemi yönetmeyi zorlaştırır, ancak mevcut en iyi performansı sağlar.

RAID-5 birimleri, RAID-10 birimlerinden daha fazla yazma yüküne neden olur, bu nedenle çok fazla yazma trafiğine sahip yoğun bir veritabanı RAID-10'da daha iyi (genellikle çok daha iyi) performans gösterir. Günlükler, verilere fiziksel olarak ayrı disk birimleri konulmalıdır. Veritabanınız büyükse ve çoğunlukla salt okunursa (örneğin bir veri ambarı), yükleme işlemini gereksiz yere yavaşlatmazsa, RAID-5 birimlerine koymak için bir durum olabilir.

Bir denetleyicide geri yazma önbelleği, verilerin bozulabileceği bazı (makul olmayan ancak olası) hata modlarını oluşturmak pahasına bir performans kazancı sağlayabilir. Bunun için en büyük performans, oldukça rastgele erişim yüklerinde elde edilir. Bunu yapmak istiyorsanız, günlükleri ayrı bir denetleyiciye koymayı ve günlük birimlerinde geri yazma önbelleğini devre dışı bırakmayı düşünün. Bu durumda günlükler daha iyi veri bütünlüğüne sahip olur ve tek bir hata hem günlük hem de veri hacimlerini alamaz. Bu, bir yedekten geri yüklemenizi ve günlüklerden ileri gitmenizi sağlar.

Çok ayrıntılı bir rapor hazırladım ama sadece Fransızca . Fransızca okuduysanız veya otomatik çeviri araçlarından memnunsanız ... Metodolojiyi yeniden kullanabilir ve kendiniz çalıştırabilirsiniz.

Yönetici özeti: pgbench kullandım. Linux I / O zamanlayıcısının performanslar ve dosya sistemi için çok az önemi vardır. Eğer aceleniz varsa, sadece varsayılanı seçin. JFS'yi seçtim.

Dosya sistemi sorunun sadece bir parçasıdır. IO zamanlayıcınızı değiştirerek önemli performans artışı elde edebilirsiniz. Neyse ki, IO zamanlayıcısını anında değiştirebileceğiniz için test etmek oldukça kolaydır. Her birini tipik yük altında birkaç gün denemenizi ve hangisinin en iyi performansı verdiğini görmenizi öneririm.

Birkaç ay önce bazı testler yaptım:

Her iş parçacığı 1000 (ya da 10000 ise) aynı tabloya eklenen 50 iş parçacığı oluşturdu küçük bir test programı vardı.

• EXT3'teki veritabanı ve 4 diskli RAID5 ile 50 saniye sürdü.
• Ramdisk üzerindeki tablo ile (tablepace kullanarak) hala 50 saniye sürdü. Daha hızlı olmamasının nedeni, her şeyin hala aynı RAID 5'teki pg_xlog dizinine kaydedilmiş olmasıdır.
• Pg_xlog dosyasını 4 diskli bir RAID0'a (şerit) taşıdım ve aynı program 40 saniyede çalışıyor.
• Test amacıyla pg_xlog dosyasını ramdisk'e taşıdım ve EXT3 4 disk RAID'inde diğer her şeye sahiptim. Program 5 saniyeden kısa bir süre sonra tamamlandı.

Ama pg___xlog bir yazılım ramdisk üzerinde olması bir seçenek değildir: pg_xlog dizininin içeriğini kaybederseniz postgres başlamaz. (Ancak ilgi çekici olabilecek pil yedeklemeli donanım ramdiskleri vardır.)

IMHO: Veritabanı dosyaları için en rahat olduğunuz dosya sistemini kullanın. Pg_xlog dosyasını (bir sembolik bağla, belgelere bakın) sahip olabileceğiniz en hızlı aygıta taşıyın.

Tweaked FreeBSD'nin diğer işletim sistemlerinden farklı olarak size biraz daha fazla performans vereceğini hatırladım. Gerçi bu bilgi modası geçmiş ve muhtemelen bir efsane ilk etapta eminim. Ancak yine de deneyebilirsiniz, çekirdek ayarları için bu kılavuza bakın: http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html