MySQL (InnoDB) için en iyi Linux dosya sistemi nedir?


48

MySQL InnoDB ile çeşitli dosya sistemlerinin performansları üzerine kıyaslama yapmaya çalıştım ama bulamadım.

Veritabanım iş yükü tipik web tabanlı OLTP, yaklaşık% 90 oranında okuma,% 10 oranında yazma. Rastgele IO.

Ext3, ext4, xfs, jfs, Reiserfs, Reiser4 gibi popüler dosya sistemlerinden hangisinin MySQL için en iyisi olduğunu düşünüyorsunuz?

Yanıtlar:


44

Verilere ne kadar değer veriyorsunuz?

Cidden, her dosya sisteminin kendine has bir hükmü var. Çok daha ileri gitmeden önce, her zaman Ext3'ü çalıştırdığım halde, her ikisini de büyük XFS ve Reiser hayranıyım. Yani işte gerçek bir dosya sistemi önyargısı yok, sadece size bildirmek ...

Dosya sistemi sizin için bir kapsayıcıdan biraz daha fazlaysa, en iyi erişim zamanlarını size ne sağlarsa verin.

Veriler önemli bir değere sahipse, XFS'den kaçınmak istersiniz. Neden? Çünkü günlüklenmiş bir dosyanın bir bölümünü kurtaramazsa , blokları sıfırlar ve verileri kurtarılamaz hale getirir. Bu sorun Linux Çekirdeği 2.6.22'de düzeltildi .

ReiserFS, asla sert çökmemesi koşuluyla mükemmel bir dosya sistemidir . Dergi kurtarma işlemi iyi çalışıyor, ancak bir nedenden dolayı ayrıştırma bilgilerinizi kaybederseniz veya dosya sisteminin çekirdek blokları atılırsa, bir diskte birden fazla ReiserFS bölümü varsa, bir kuveytiniz olabilir - çünkü kurtarma mekanizması temel olarak tarar. tüm diski, sektöre göre sektör, "ne düşündüğünü" arayan dosya sisteminin başlangıcıdır . ReiserFS ile üç bölümünüz varsa, ancak yalnızca biri patladıysa, kurtarma işleminin diğer iki sistemden bir Frankenstein karmaşasını bir araya getirmesiyle kaosun hayal edersiniz.

Ext3 "32.000 dosyam var ve hepsini çalışırken bulmam biraz zaman alıyor" şeklinde "yavaş" ls. Her yerde binlerce küçük geçici masa olacaksa, biraz üzüleceksiniz. Daha yeni sürümler, artık dizin geçişini önemli ölçüde azaltan bir dizin seçeneği içeriyor, ancak yine de acı verici olabilir.

Hiç JFS kullanmadım. Sadece şimdiye kadar okuduğum her incelemenin "sağlam, ama bloktaki en hızlı çocuk" çizgisi boyunca bir şey olduğunu söyleyebilirim. Soruşturmayı hak edebilir.

Eksileri Yeterince, Artılarına bakalım:

XFS'in:

  • muazzam dosyalar ile çığlıklar, hızlı iyileşme süresi
  • çok hızlı rehber arama
  • Damping için dosya sistemini dondurmak ve çözmek için gerekli ilkeler

ReiserFS:

  • Son derece optimum küçük dosya erişimi
  • Birkaç küçük dosyayı aynı bloklara paketleyerek dosya sistemi alanını korur
  • hızlı kurtarma, XFS kurtarma sürelerine rakip

Ext3:

  • İyi test edilmiş Ext2 koduna dayanarak denenmiş ve doğru
  • Bununla çalışmak için çok sayıda araç
  • Kurtarma için bir tutam içine Ext2 olarak yeniden monte edilebilir
  • Hem küçültülebilir hem de genişletilebilir (diğer dosya sistemleri sadece genişletilebilir)
  • En yeni sürümler "canlı" olarak genişletilebilir (eğer cüret ederseniz)

Görüyorsunuz, her birinin kendine özgü tuhaflıkları var. Asıl soru, sizin için en ilginç olan hangisi?


29
Bu XFS NULLed dosya sorunu 3 yıl önce düzeltildi. xfs.org/index.php/…
Ryan Bair

5
Çekirdek gelişim değişikliklerine ayak uydurabilmek için dünyanın her yerinde vaktim olmadığı doğru olsa da (işin başında ve ailenin yanında), aynı zamanda kesinlikle güncellenmesi gereken cüruflu eski konuşmalar olduğu da doğru. Ancak, düzeltmenin yapıldığına işaret etmek için + 1'e yongalayacağım.
Avery Payne

13

Ayrıca InnoDB'yi bir dosya sistemi olmadan çalıştırabileceğiniz ve dosya sistemi ek yükü olmadan performansı artırabileceğinize dikkat edin. Tavsiye edebileceğimden emin değilim, ama daha önce sorunsuz kullandım.

InnoDB Ham Cihazlar

Buna ek olarak,% 90 okur ve% 10 yazıyorsanız, InnoDB'nin işlem yeteneğine ihtiyacınız olmadıkça, daha iyi okuma performansı için MyISAM'e aktarmayı düşünebilirsiniz.


6
-1 daha iyi okuma performansı için MyISAM'e taşınmayı önerdiğiniz için. Çok fazla kusur ve dezavantaj var. InnoDB yerine düzgün yapılandırılmalıdır. Cihazda InnoDB ürün reçetesi için +1.
gertvdijk

5
İfademin yanındayım, MyISAM'in dezavantajları var ama olması gereken çok şey var. MyISAM hala okuma iş yükü için patron.
Xorlev

11

Buradaki cevaplar ciddiye alınmamıştır ve bu, google sonuçlarında geldiği için güncellenmesi gerekir.

Üretim ortamları için, XFS. Her zaman. XFS günlüğe kaydedilir ve engellenmez. Üretimde InnoDB kullanan modern (2011/2012) MySQL veritabanı için aşağıdaki değişkenlere sahip olduğunuzdan emin olun:

innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1 # an ACID requirement
sync_binlog = 1 # more ACID
innodb_flush_method = O_DIRECT

EXT3 veya hatta EXT4 kullanmayın. Bir gün BTRFS oraya gelecek.

EXT3 ve belki de EXT4, akıllı değil, inode seviyesinde kilitlenir!

Kaynaklar: - www.mysqlperformanceblog.com - http://dev.mysql.com/doc/internals/tr/index.html - Sasha Pachev tarafından MySQL Internals'ı Anlamak - https://www.facebook.com/note.php? note_id = 10150210901610933 - http://oss.sgi.com/projects/xfs/training/ - Bazı salıncak seti, deneme yanılma.

EDIT: Bir güncelleme. EXT4 2013'ün ortalarından itibaren oldukça iyi görünüyor! BTRFS hala iyi bir seçenek değil. Ve RHEL, XFS'yi yeni varsayılan dosya sistemi haline getirebilir. Yine, EXT3'ü KULLANMAYIN.


Göre Vadim Tkachenko testi InnoDb MySQL 5.5 kullanıldığında, EXT4 XFS üzerinde% 20 verim sağlar. Vadim, uygun olan yerlerde 'dioread_nolock' EXT4 seçeneğini kullanmanızı önerir (testte kullanmamış olmasına rağmen).
caligari

İnode seviyesinde kilitleme neden kötü?
jpaugh

diğer cevaplar modası geçmiş … şimdi,: 5 yıl sonra…
kaiser

İnode kilitlemeyle ilgili sorunlar için Google "inode lock çekişmesi".
sade

9

Kısa versiyon, MySQL'in dosya sistemlerinde yaptığını düşündüğüm bir tavsiyeye en yakın olanın XFS olduğu, ancak ext3'ün de iyi olması gerektiği, ext4'ün güzel bir iyileştirme olacağına dair söz vermesine rağmen, yine de oldukça kararlı değil. yılın sonu.

Küme dosya sistemlerini kullanıyorsanız, CXFS, OCFS2 ve GFS'nin iyi olması gerekir.

Reiser türevlerine ve JFS'ye karşı şiddetle uyarmıştım, ancak bir kez daha iyi dağıtılan XFS ve ext4 tarafından bir kez daha iyi bir şekilde dövüldü.


6

Çok fazla fark yaratması mümkün değil. Dağıtımınızın, varsayılan olarak ne kullanıyorsa kullanın, yeterli olması koşuluyla.

Başka şeyleri ayarlama çabanızı harcayın - yeterince ram elde edin - emmeyen bir baskın denetleyicisi edinin - ve uygulamanın topal (ab) veritabanının kullanımını düzeltin (NB: bu zaten bulunmadığı çoğu durumda ana suçludur) yapıldı).

Bununla birlikte, dikkatlice, mysql tmpdir 'ini kurduğunuz dosya sistemini göz önünde bulundurun; bu, performansı, özellikle de disk tabanlı filesort () ları yapan sorguları etkileyecektir (daha fazla bilgi için bkz. EXPLAIN).

Gecikmeli tahsisi destekleyen bir dosya sisteminin gerçekten kullanışlı olduğunu düşünüyorum, zira önbellekte saklamak için yeterli ram olduğunda, kısa ömürlü dosyalar için IO'yu tamamen önleyebilirsiniz. Örneğin, XFS, tahsis edilmeden önce silinen ve kapatılan hiçbir şekilde dosya yazma zahmetine girmez.

Tabii ki bir tmpf'nin üzerine bir tmpdir koymak, performans perspektifinden çekicidir, ancak alanı boşaltma ve aksi halde başarılı olacak sorguların (kullanılan disk geçici dosyaları da olsa) başarısız olma riskine yol açar.


5

Çeşitli dosya sistemlerinde çalışan MySQL üzerinde "roundup" kıyaslaması bulunan yeni makaleler bulamıyorum. Tanımladığınız iş yükü göz önüne alındığında, dosya düzeyinde parçalanmanın bir sorun olacağından şüpheliyim. Resmi bir kriter olmadan, yetkili olarak kabul etmeniz gereken hiçbir şey söyleyemem, ama bağırsaklarım yukarıda bahsettiğiniz her dosya sisteminin aynı oyun parkında (yani, performans sayıları için aynı büyüklük sırasına göre) kabaca çalışacağını söylüyor. .

Veri tabanı gerçekten gösteriyi çalıştırıyor, çünkü dosya sistemi sadece depolama motorunun erişebildiği geniş kapsamları yönetiyor.

Yine de, tüm bu dosya sistemlerinde bir performans toplaması yapmak ilginç olurdu. (Yine de MySQL için hiç bir merakım yok, bu yüzden bunu yapmayacağım. Benchmarking Postgres, OTOH, ilginç olabilir ...)


1
Ayrıca, ilginizi çekebilecek bazı referansları içeren bir stackoverflow.com/questions/1021854/… kopyasıdır
nik

3

IMHO linux için mevcut olan kayda değer FS'ler:

XFS (düşük okuma hızı), sistem kaynakları üzerinde hafif olduğu ve büyük dosyalarla hızlı olduğu, ancak birçok küçük dosyayı işlemesi için düşük olduğu bilinmektedir.

ReiserFS (düşük yazma hızı) sistem kaynaklarında çok kibar değil, birçok küçük dosyada çok iyi bir performans sergiliyor.

EXT3, tüm alanlarda kabul edilebilir bir şekilde performans göstererek ( varsayılan linux FS olarak kabul edilmesinin nedeni) arasına girer .

Henüz EXT4'ü ReiserFS4'ü kullanmamıştım ama bazı ölçütlere baktım ve ReiserFS, sizin için en önemli olduğunu düşündüğünüz okuma hızına gelince en iyi performansa sahip görünüyor.

Şuna bir bakın: ReserFS4 X Ext4 X Ext3

Ext3'ü istikrarı, güvenliği ve olgunluğu için tavsiye ederim, ancak okuma hızı sizin için en önemli olan şeyse, ReiserFS'yi göz önünde bulundurmalısınız.

Bir FS seçmeden önce CPU kullanımı, kararlılığı, güvenliği de dikkate almanız gerektiğini unutmayın.

Ve elbette bir pilotluk yapmak, kendi çevreniz üzerinde test etmek ve kıyaslama yapmak sizin için en iyi olanı yapmanın her zaman en iyi yoludur.

Not: Daha fazla kriter gönderirdim ama birden fazla bağlantı gönderemedim.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.