Vraag Wat is het beste Linux-bestandssysteem voor MySQL (InnoDB)?


Ik heb geprobeerd om benchmark te zoeken naar de prestaties van verschillende bestandssystemen met MySQL InnoDB, maar ik kon er geen vinden.

Mijn database-werkbelasting is de standaard webgebaseerde OLTP, ongeveer 90% gelezen, 10% schrijf. Willekeurige IO.

Onder populaire bestandssystemen zoals ext3, ext4, xfs, jfs, Reiserfs, Reiser4, etc. welke is volgens jou het beste voor MySQL?


47
2018-06-20 19:06


oorsprong




antwoorden:


Hoeveel waardeert u de gegevens?

Serieus, elk bestandssysteem heeft zijn eigen afwegingen. Voordat ik veel verder ga, ben ik een grote fan van zowel XFS als Reiser, hoewel ik vaak Ext3 gebruik. Er is hier dus geen echte voorkeur voor het bestandssysteem, laat het je gewoon weten ...

Als het bestandssysteem weinig meer is dan een container voor u, kies dan wat u de beste toegangstijden biedt.

Als de gegevens van enige significante waarde zijn, wilt u XFS vermijden. Waarom? Omdat als het niet een deel van een bestand kan herstellen dat is gejournaliseerd het zal de blokken nul maken en de gegevens onherstelbaar maken. Dit probleem is opgelost in Linux Kernel 2.6.22.

ReiserFS is een geweldig bestandssysteem, op voorwaarde dat het crasht nooit hard. Het herstel van het journaal werkt prima, maar als je om wat voor reden dan ook je parition info kwijt bent, of de kernblokken van het bestandssysteem zijn weggeblazen, heb je misschien een quandry als er meerdere ReiserFS-partities op een schijf zijn - omdat het herstelmechanisme fundamenteel scant de hele schijf, sector voor sector, op zoek naar wat het "denkt" is het begin van het bestandssysteem. Als je drie partities hebt met ReiserFS maar er slechts één wordt geblazen, kun je je voorstellen welke chaos dit zal veroorzaken, aangezien het herstelproces een Frankenstein-rotzooi van de andere twee systemen samenvoegt ...

Ext3 is "langzaam", in een "Ik heb 32.000 bestanden en het kost tijd om ze allemaal te vinden lsAls je duizenden kleine tijdelijke tafels overal zult hebben, zul je een beetje verdriet hebben. Nieuwere versies bevatten nu een indexoptie die het doorlopen van mappen drastisch afsnijdt, maar het kan nog steeds pijnlijk zijn.

Ik heb nog nooit JFS gebruikt. Ik kan alleen maar zeggen dat elke recensie die ik ooit heb gelezen iets is geweest in de trant van "solide, maar niet het snelste kind van het vak". Het kan een onderzoek waard zijn.

Genoeg van de nadelen, laten we naar de profs kijken:

XFS:

  • schreeuwt met enorme bestanden, snelle hersteltijd
  • zeer snel zoeken naar mappen
  • Primitieven voor bevriezing en het bevriezen van het bestandssysteem voor dumping

ReiserFS:

  • Zeer optimale toegang tot kleine bestanden
  • Pakt verschillende kleine bestanden in dezelfde blokken in, waardoor de ruimte van het bestandssysteem behouden blijft
  • snel herstel, rivalen XFS-hersteltijden

ext3:

  • Geprobeerd en waar, op basis van goed geteste Ext2-code
  • Veel gereedschappen om mee te werken
  • Kan opnieuw worden gemonteerd als Ext2 in een mum van tijd voor herstel
  • Kan allebei zijn gekrompen en uitgebreid (andere bestandssystemen kunnen alleen worden uitgebreid)
  • Nieuwste versies kunnen "live" worden uitgebreid (als je dat durft)

Dus je ziet, elk heeft zijn eigen eigenaardigheden. De vraag is, wat is het minst eigenzinnig voor jou?


43
2018-06-22 05:54



Dat XFS NULLed-bestanden probleem werd opgelost meer dan 3 jaar geleden. xfs.org/index.php/... - EvilRyry
Hoewel het waar is dat ik niet alle tijd van de wereld heb om bij te blijven met veranderingen in de kernelontwikkeling (bovenop werk en een gezin), is het ook zeker waar dat er krakende oude implementaties zijn die moeten worden bijgewerkt. Ik geef echter een +1 op omdat ik erop heb gewezen dat de oplossing is gemaakt. - Avery Payne


Het is misschien ook de moeite waard om op te merken dat je InnoDB zonder een bestandssysteem kunt draaien en de prestaties kunt verbeteren zonder bestandssysteemoverhead. Ik weet niet zeker of ik het zou aanbevelen, maar ik heb het eerder zonder problemen gebruikt.

InnoDB Raw-apparaten

Als u bovendien 90% leest en 10% schrijft, tenzij u de transactievaardigheid van InnoDB nodig hebt, kunt u de overdracht naar MyISAM overwegen voor betere leesprestaties.


12
2017-10-06 17:53



-1 voor het voorstellen om naar MyISAM te gaan voor betere leesprestaties. Heeft zoveel andere gebreken en nadelen. InnoDB moet in plaats daarvan correct worden geconfigureerd. +1 voor suggestie van InnoDB-on-raw-device. - gertvdijk
Ik blijf bij mijn verklaring, MyISAM heeft nadelen, maar er is veel goeds te krijgen. MyISAM is nog steeds de baas voor gelezen werklasten. - Xorlev


De antwoorden hier zijn ernstig verouderd en moeten worden bijgewerkt omdat dit in de zoekresultaten van google aan de orde komt.

Voor produciton-omgevingen, XFS. Elke keer. XFS is journaled en non-blocking. Zorg ervoor dat u de volgende variabelen voor een moderne (2011/2012) MySQL-database hebt die InnoDB in productie gebruikt:

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

Gebruik geen EXT3 of zelfs EXT4. Op een dag zal BTRFS daar aankomen.

EXT3, en misschien EXT4, vergrendelt op inode-niveau, niet slim!

bronnen:  - www.mysqlperformanceblog.com  - http://dev.mysql.com/doc/internals/en/index.html  - MySQL Internals begrijpen door Sasha Pachev  - https://www.facebook.com/note.php?note_id=10150210901610933  - http://oss.sgi.com/projects/xfs/training/  - Wat swing-kit, vallen en opstaan.

EDIT: een update. EXT4 lijkt het vanaf midden 2013 aardig goed te doen! BTRFS is nog steeds geen goede optie. En RHEL maakt XFS misschien wel tot het nieuwe standaard bestandssysteem. Gebruik wederom GEEN EXT3.


10
2017-12-12 08:56



Volgens Vadim Tkachenko's test, EXT4 biedt 20% doorvoer via XFS als MySQL 5.5 met InnoDB wordt gebruikt. Vadim raadt aan de optie 'dioread_nolock' EXT4 te gebruiken waar beschikbaar (hoewel hij deze niet bij de test heeft gebruikt). - caligari
Waarom is vergrendeling op het niveau van de inodes slecht? - jpaugh
de andere antwoorden zijn verouderd ... nu, 5 jaar later ... - kaiser
Google "inode lock contention" voor de problemen met inode locking. - stark


De korte versie is dat het dichtst bij een aanbeveling die ik MySQL op bestandssystemen heb gemaakt XFS is, maar ext3 zou ook goed moeten zijn, ext4 belooft een mooie verbetering te zijn, maar het is nog steeds niet helemaal stabiel, hoewel het vóór de aanbeveling zou moeten zijn. einde van het jaar.

Als u clusterbestandssystemen CXFS uitvoert, zouden OCFS2 en GFS allemaal in orde moeten zijn.

Ik zou sterk waarschuwen voor alle Reiser-derivaten, en JFS hoewel ooit leuk was, werd meestal verslagen door XFS en ext4, die beide op ruimere schaal worden ingezet.


8
2018-06-21 10:35





Het maakt waarschijnlijk niet veel uit. Ga met wat je distributie gebruikt als de standaard, op voorwaarde dat het voldoende is.

Besteed je inspanningen aan het afstemmen van andere dingen - verkrijg genoeg ram - krijg een overvalcontroller die niet zuigt - en maak het kreupele (ab) gebruik van de database (NB: dit is de hoofdschuldige in de meeste gevallen waar het nog niet is gebeurd) gedaan).

Overweeg echter voorzichtig het bestandssysteem dat je je mysql tmpdir oplegt; dit is van invloed op de prestaties, met name queries die op schijven gebaseerde filesort () s (zie EXPLAIN voor meer informatie).

Ik denk dat een bestandssysteem dat vertraagde toewijzing ondersteunt hier echt handig is, omdat je IO volledig kunt vermijden voor kortstondige bestanden wanneer er genoeg ram is om ze in de cache te houden. XFS bijvoorbeeld, maakt helemaal geen moeite met het schrijven van bestanden die worden verwijderd en gesloten voordat ze zijn toegewezen.

Natuurlijk is het plaatsen van een tmpdir op een tmpfs aantrekkelijk vanuit een prestatieperspectief, maar dit leidt tot een risico van uitputting van de ruimte en het hebben van queries die anders zouden lukken (zij het met gebruikte schijf tijdelijke bestanden).


6
2018-06-21 11:09





Ik vind geen recente artikelen met benchmark-"roundups "op MySQL die op verschillende bestandssystemen worden uitgevoerd. Gezien de werklast die u beschrijft, betwijfel ik dat fragmentatie op bestandsniveau een groot probleem zal zijn. Zonder een formele benchmark, kan ik niets zeggen dat je als gezaghebbend zou moeten nemen, maar mijn gevoel zegt dat elk bestandssysteem dat je hierboven noemde ongeveer in dezelfde marge zal presteren (dat wil zeggen allemaal in dezelfde orde van grootte voor prestatienummers) .

De database draait echt de show, omdat het bestandssysteem slechts grote extents beheert die de opslag-engine gebruikt.

Toch zou het interessant zijn om een ​​performance-roundup uit te voeren met al die bestandssystemen. (Ik heb echter minder dan geen enthousiasme voor MySQL, dus ik ga het niet ondernemen. Benchmarking van Postgres, OTOH, kan interessant zijn ...)


4
2018-06-20 19:26



Thee is ook een stackoverflow.com/questions/1021854/... dupliceer met enkele referenties die u mogelijk interesseren - nik


IMHO de moeite waard om FSs te noteren beschikbaar voor linux zijn:

XFS (slechte leessnelheid) staat er om bekend dat het licht is voor de systeembronnen en snel is met grote bestanden, maar slecht om veel kleine bestanden te verwerken.

ReiserFS (slechte schrijfsnelheid) is niet erg vriendelijk voor systeembronnen, maar presteert zeer goed met veel kleine bestanden.

EXT3 valt daar tussenin en presteert acceptabel op alle velden (de reden waarom het als de standaard linux FS).

Ik heb nog niet EXT4 niet ReiserFS4 zelf gebruikt, maar ik heb rond een aantal benchmarks gekeken en ReiserFS lijkt de beste prestaties te hebben als het gaat om leessnelheid, waarvan je zei dat die het belangrijkst was voor jou.

Kijk hier eens even naar : ReserFS4 X Ext4 X Ext3

Ik zou Ext3 willen aanbevelen voor zijn stabiliteit, veiligheid en volwassenheid, maar als leessnelheid het belangrijkste voor u is, zou u ReiserFS moeten overwegen.

Vergeet niet dat u ook moet overwegen CPU-gebruik, stabiliteit, beveiliging enzovoort voordat u een FS kiest.

En natuurlijk is het maken van een pilot, het testen en benchmarken van uw specifieke omgeving altijd de beste manier om te vertellen wat het beste werkt voor u.

PS: Ik zou meer benchmarks hebben gepost maar ik kan niet meer dan één link plaatsen.


2
2018-06-21 19:47