performance problemen ext3

[ferno]

Hoi mensen,

Ik loop al een tijdje te zoeken en kan een oplossing voor mijn probleem maar niet vinden, namelijk het volgende:
Ik heb een maxtor 160 gb IDE schijf (geen SATA) met twee partities en geformateerd met EXT3 fs.
ALles werkt opzich goed maar als ik files (vooral grote files) van de ene partitie (van / naar /data ) dan is mijn throughput dramatisch laag, ongeveer 3 a 4 mb per sec.
Doe ik dit binnen dezelfde partitie dan gaat het redelijk in de buurt van 35MB per sec.

Sinds kort heb ik er een tweede schijf bij gehangen van 80 GB met JFS (/data_extended) en als ik van van /data naar /data_extende verplaats of kopieer dan gaat het redelijk maar vanaf / naad /data of /data_extended is het even dramatisch.

De OS is Mandrake 9.2 en de filesys is Ext3.

Verder heb ik nog een vreemd probleempje en dat is als ik files delete dan wordt mijn vrije schijfruimte niet helemaal vrijgegeven, zelfs niet als ik sync., alleen een reboot wil dan helpen.

Heeft iemand enig idee wat dit kan veroorzaken en hoe ik het kan oplossen??

[Kees]

ferno schreef op maandag 04 april 2005 @ 20:41:
Hoi mensen,

Ik loop al een tijdje te zoeken en kan een oplossing voor mijn probleem maar niet vinden, namelijk het volgende:
Ik heb een maxtor 160 gb IDE schijf (geen SATA) met twee partities en geformateerd met EXT3 fs.
ALles werkt opzich goed maar als ik files (vooral grote files) van de ene partitie (van / naar /data ) dan is mijn throughput dramatisch laag, ongeveer 3 a 4 mb per sec.
Doe ik dit binnen dezelfde partitie dan gaat het redelijk in de buurt van 35MB per sec.

Op een disk kopieren is nooit een goed idee, dat gaat altijd traag (alles moet twe keer door de bus, en de kop van de harde schijf moet voor elke lees/schrijfactie bewegen)

Sinds kort heb ik er een tweede schijf bij gehangen van 80 GB met JFS (/data_extended) en als ik van van /data naar /data_extende verplaats of kopieer dan gaat het redelijk maar vanaf / naad /data of /data_extended is het even dramatisch.

Dat is vreemd, probeer eens wat test uit te voeren op die disks? bonnie, en hdparm komen zo bij me op

Verder heb ik nog een vreemd probleempje en dat is als ik files delete dan wordt mijn vrije schijfruimte niet helemaal vrijgegeven, zelfs niet als ik sync., alleen een reboot wil dan helpen.

Heeft iemand enig idee wat dit kan veroorzaken en hoe ik het kan oplossen??

Dat komt omdat de files dan nog in gebruik zijn, in het algemeen wil het HUPpen van het gebruikende process wel eens helpen (dus bij apache logfiles, een apachectl gracefull doen)

[Verwijderd]

Misschien heb je wat aan http://mrlee.homelinux.net/hdparm.txt .

[ferno]

Hey thanx mensen maar met hdparm ben ik al aan de gang geweest zonder suc6.
Ik zal bonnie eens proberen.

[ferno]

Dit zijn de hdparm tests en die zien er volngens mij wel ok uit maar dit is alleen lezen en zegt natuurlijk niets over schrijven:

mount point /

/dev/hda5:
Timing buffered disk reads: 168 MB in 3.03 seconds = 55.45 MB/sec

/dev/hda5:
Timing buffer-cache reads: 960 MB in 2.00 seconds = 480.00 MB/sec


mount point /data

/dev/hda6:
Timing buffered disk reads: 154 MB in 3.02 seconds = 50.99 MB/sec

/dev/hda6:
Timing buffer-cache reads: 924 MB in 2.00 seconds = 462.00 MB/sec


mount point /data_extended

/dev/hdb1:
Timing buffered disk reads: 62 MB in 3.12 seconds = 19.87 MB/sec

/dev/hdb1:
Timing buffer-cache reads: 956 MB in 2.00 seconds = 478.00 MB/sec

[ferno]

Hier mijn bonnie++ test (wordt er niet echt wijs van):

Version 1.02c ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
hostname 2G 11434 53 10615 6 7325 3 13143 54 20912 6 83.8 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 939 77 +++++ +++ +++++ +++ 943 77 +++++ +++ 2084 67
hostname,2G,11434,53,10615,6,7325,3,13143,54,20912,6,83.8,0,16,939,7
7,+++++,+++,+++++,+++,943,77,+++++,+++,2084,67

[Kees]

code:

Version 1.02c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
hostname 2G 11434  53 10615   6  7325   3 13143  54 20912   6  83.8   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   939  77 +++++ +++ +++++ +++   943  77 +++++ +++  2084  67
hostname,2G,11434,53,10615,6,7325,3,13143,54,20912,6,83.8,0,16,939,7
7,+++++,+++,+++++,+++,943,77,+++++,+++,2084,67

[ferno]

Hmm,

Thanx, maar kan je hier iets uit afleiden??
Ik bn niet veel wijzer geworden van deze test maar heb wel het gevoel dat de write performance de boosdoener is.
Deze perfeomance is niet alleen met kopieren maar ook met verplaatsen.


Verder de tweede tip over het huppen, het zijn geen files die in gebruik zijn, het zijn gewoon grote file die gewoon in die data dir staan en ik na een tijdje gewoon wil opschonen.
Het vreemde is wel dat als ik een DF -H doe df zegt dat de schijf vol is maar ik nog steeds data er naar toe kan kopieren.

[ferno]

Hmm,

Niemand een iedee wat er gaande kan zijn??

[Verwijderd]

ferno schreef op donderdag 07 april 2005 @ 19:47:
Hmm,

Niemand een iedee wat er gaande kan zijn??

man filefrag

Ik weet niet wat je "workload" precies is, maar als je al een vrij oud bestandssysteem hebt dat vaak bijna volledig vol heeft gestaan, dan kan je na verloop van tijd op EXT{2|3} partities aardig last gaan krijgen van fragmentatie. Toegegeven, het EXT bestandssysteem zit goed in mekaar, waardoor er op het niveau van het bestandssysteem zelf amper fragmentatie kan optreden (dit in tegenstelling tot bijvoorbeeld NTFS), maar het is een mythe dat EXT partities nooit gedefragmenteerd horen te worden, aangezien de files zélf namelijk wel overal op de HD verspreid kunnen raken.

Als je veel grote bestanden (traag) via P2P programma's binnnenhaalt op een partitie die bijna vol is (en zeker verschillende bestanden door mekaar in eenzelfde directory), dan schiet de fragmentatie, geraporteerd door filefrag, énorm de hoogte in. Als je die grote bestanden dan wilt copiëren, dan moeten de koppen van de HD veel over en weer bewegen, wat de performance énorm naar beneden haalt. Zo keek ik raar op dat ik op een switchted netwerk amper boven de 6 à 7Mb/s kwam voor sommige files, waar ik bij andere de volle 11Mb/s haalde. Na onderzoek met filefrag, was het duidelijk dat de trage files tot wel 20.000 fragmenten hadden.

Op de ext3 mailing list heeft Andrew Morton toegegeven dat EXT3 hier vrij slecht in is. Er bestaat een oud programma om ext2 partities te defraggen, maar dat werkt enkel met een inode grootte van 1Kb, ipv de meer gangbare 4Kb per node, wat dus impliceert dat deze tool voor de meeste mensen onbruikbaar is. De enige echte "oplossing" is files deleten die je zeker niet meer nodig hebt, een tar maken van je bestanden, op een andere partitie plaatsen, de ext3 partitie hermaken, en dan de tarfile extracten op deze nieuwe partitie, zodat alles mooi sequentieel achter mekaar komt te staan met zo min mogelijk fragmentatie.

Lees onder andere deze interessante thread eens door aangaande fragmentatie op ext3 partities. Uit de testen komt naar voren dat XFS, omwille van zijn agressieve caching in het RAM geheugen, een pak beter is om files mooi opeenvolgend te houden.

[ferno]

Hawk,

Dit klinkt heel aannemelijk!

Thanx voor de uitleg, ik heb een hoop lopen zoeken maar het is een lastig probleem om op te googelen.