A fragmentációról általánoságban

A fragmentáció gonosz. Mindenképpen szerettem volna ezzel kezdeni, és mindenkiben már a legelején tudatosítani, hogy a fragmentáció nem a barátunk.

Miről is van szó tulajdonképpen?

A merevlemezen az adatok egy, a fájlrendszer átlal meghatározott sorrendben helyezkednek el, ami általában, hasonlóan a bakelit lemezekhez, a körkörös lemez felület egyik végétől kezdődnek, és spirálisan, egybefüggően a másik vége felé tartanak (leegyszerűsítve). Ezzel nincs is nagy gond egészen addig, amíg csak írunk a lemezre, azonban amint elkezdünk törölgetni is, ebben az összefüggő sávban a törölt fájlok helyén lyukak keletkeznek.

Ahogy jobban és jobban telik meg a vinyó, egyre kevesebb üres hely lesz az adathordozón, ugyanakkor a módosítások, törlések, stb. miatt egyre több apró lyuk is keletkezik a lemezen. A probléma akkor keletkezik, amikor egyszercsak nagyobb fájlt akarunk kiírni a legnagyobb összefüggő szabad blokk méreténél: ekkor ugyanis a rendszer kénytelen lesz a fájlt szétdarabolni, több lyukat betömve ezzel. Ez azért hátrányos számunkra, mert íráskor és olvasáskor is a lemezen fizikailag egymástól távol lévő helyekre kell vezérelni az író-olvasó fejet, aminek a mozgatása pedig sajnos igen időigényes.

(Ennek szemléltetésére: az én WD vinyóm szekvenciálisan (azaz egymás után összefüggő adatok olvasása esetén) 14-40 MB/s sebességet tud produkálni, míg „random” (azaz a lemez felületén véletlenszerűen, össze-vissza elhelyezkedő adatok esetén) 0.47-1.74 MB/s-et ér csak el. Ez annyira szignifikáns különbség, hogy képesek vagyunk miatta idegrohamot kapni és szétverni kalapáccsal számítógépeket.)

Ezek kordában tartása a fájlrendszer feladata.

HFS+

Az OS X a HFS+ fájlrendszerrel érkezik, ami tervezésekor, mint minden más esetben is, kompromisszumokat kellett kötni sok jellemző érték között. Méréseim alapján arra jutottam, hogy a HFS+ a fájlok egybentartásának problémáját csillagos ötösre oldja meg, több gépen mérve, majdnem mindegyiken azt kaptam, hogy 1.01%-os össz-fragmentációs arányt képes biztosítani. Ez a gyakorlatban azt jelenti, hogy a 320 gigás vinyómon a 2.6 millió fájlomból kb. 3000 db fájl volt több, nem összefüggő fragmensben kiírva.

Ami viszont sajnos ezzel együtt jár, az az, hogy szükségszerűen fragmentálódik a szabad lemezterület. Méréseim szintén egybehangzóan több gépen azt mutatták, hogy 96-99%-os fragmentáció jellemző HFS+-on az üres helyre. Csak hogy szemléltessem: nálam ez a 46 giga üres hely esetén 240 megás legnagyobb összefüggő üres területet jelentett.

Swap

A mai modern operációs rendszerek mindegyike épít arra, hogy a gépben fizikailag elhelyezkedő RAM-ot elkülöníti a programok által logikailag látható memóriától, ezt nevezzük virtuális memóriának. A virtuális memória méretének csak a processzor címtartománya (azaz hogy 32 vagy 64 bites) szab határt. A virtuális memóriát természetesen le kell képezni a fizikai memóriára, erre vannak jó és kevésbé jó módszerek, de egyben megegyeznek: ami éppen nem fér bele a RAM-ba, azt ki kell írni háttértárolóra, ezt nevezzük swap-nek. Swap-be általában az éppen nem használt, nem kellő programok, vagy azok adatai kerülnek. Amikor visszaváltunk egy ilyen programra, akkor valami mást ki kell „swappelni” helyette, és a háttértárról be kell tölteni a használni kívánt program adatait a RAM-ba. Amíg ez megtörténik, addig szokott „strandlabdázni” az OS X.

És akkor kombináljuk a kettőt!

Ha sok programot futtatsz és kevés a RAM-od, akkor bizony swap-elnie kell a gépednek, ami 1-2-4 gigányi adat kiírását jelenti a vinyóra, ami viszont ha töredezett, akkor kénytelen lesz a rendszer fragmentált swap fájlokkal dolgozni. Kitaláljátok mi az eredmény? A mai átlagos több Gbit/s-es RAM átviteli sebességek a vinyó random olvasásának 2-400 kB/s-es alsó határáig kúsznak vissza, vagyis 5 percekig ülhetünk a strandlabda előtt, amíg a rendszer visszalapátolja a kedvenc programunkat a memóriába.

Egy megoldás

Az üres hely töredezettsége (ideiglenesen) megszüntethető. Erre kiváló program a korábban az Apple által ingyen a gépekhez adott TechTool Pro nevű stuff. Ezek után a swap fájlok egyben le tudnak foglalódni a vinyón, amitől az általános sebessége és reszponzivitása is sokszorosára javul a rendszernek.

Az egyik probléma természetesen ezzel az, hogy csak ideiglenes megoldás, mivel a fájlrendszer előbb-utóbb mindenképpen ugyanarra a sorsra jut, és kezdhetjük előről. Ez ellen úgy védekezhetünk, hogy a szabad hely fragmentációjának megszüntetése után a Disk Utility-vel egy 4-8 gigás szeletet lecsippentünk a rendszer partícióból, és kinevezzük exkluzív Swap partíciónak. Ezek után azon csak a swap fájlok lehetnek, így nem fog fragmentálódni a hely.

Persze meg kell mondanunk a rendszernek, hogy ezentúl oda swap-eljen, ebben nyújt segítséget a MacOSXHints egyik cikke. Csak egy helyen kell átírnunk egy plist fájlt.

TechTool Pro tapasztalatok

Én a saját MacBook-omon és az otthoni Mac Minin futtattam le a defragmentálást. Snow Leopardhoz mindenképpen legalább az 5.0.6-os verzió beszerzése ajánlott, ez elérhető boot CD formájában is, ami azért hasznos, mert használatban lévő lemezt nem ajánlatos defragmentálással bolygatni. A CD-ről indítva a gépet pár kattintással meg is kezdhető a folyamat. A fájlok egyberakását itt „File optimalization”-nek hívják, ez nálam 5 perc alatt lefutott mindkét gépen, a szabad hely egybegyúrásának pedig „Volume optimalization” a neve marketingesen. Na ez már egy nagyobb falat, a Minin kb. 18 órát futott (160 GB PATA vinyó, G4), nálam pedig olyan 12 óra alatt végzett (320 GB SATA vinyó, C2D). Amire felhívnám mindenki figyelmét, hogy valószínűleg valami probléma van a boot CD drivereivel, így nekem első éjszaka onnan próbálva a dolgot nem jutott a gép 1%-ig sem el. (A program nem becsül hátralévő időt, de én megtettem: 4.5 év lett volna.) A megoldás az volt, hogy egy külső vinyóra telepítettem egy OS X-et, oda felraktam a TechTool-t és arról bootolva már szép „gyorsan” lefutott a folyamat.

A saját kálváriám

Sajnos nálam ez nem oldotta meg a problémákat. A következő furcsaságok figyelhetőek meg most a rendszeremben:

  • amíg nincs swap-elés, addig megy minden, mint az olajozott istennyila
  • hiába van 4 giga RAM-om (amiből ugye a PCI címtartomány miatt 3 giga használható), 2 giga összmérete jön ki az aktuálisan futó programok „Real memory” memóriahasználatának összege, akármit csinálok
  • még így is gyanúsan hamar elkezd swapelni a gép, amikor még elvileg elférne minden a RAM-ban, már 200-800 mega swap-em van
  • Ha indítok egy 1 giga RAM-os VMWare virtuális gépet, Aperture-t, iPhoto-t, Google Earth-öt és pár ablak Safarit, akkor ez játszi könnyedséggel felkúszik 2-4 GB swap használatra is, amit teljesen irreálisnak tartok
  • Ha tényleg nagyon sokminden fut egyszerre, akkor végtelenül lassúnak érződik a rendszer, minden kattintásnak nagy delay-e van, egyszerűen nem jó érzés használni a gépet
  • Miután mindenből kilépek visszagyorsul minden az eredeti állapotára, viszont a swap nagyrésze nem szabadítódik fel, pl. most épp 1 giga megmaradt.

Mindezek miatt, akármennyire is utálom, valószínűleg szerdán újratelepítés fog következni. Az Úr legyen velem!

8 hozzászólás

Submit a Comment
  • Vakondgyar

    Végig olvastam a postot. Vakondgyar

  • GK

    Örülök neki! :D

  • Attis

    Ezt en nemertem: „hiába van 4 giga RAM-om (amiből ugye a PCI címtartomány miatt 3 giga használható)”. Nem 64 bites OS-t tetszik hasznalni? Akkor nem 4 giga ami lekepezheto, hanem 16.8 csillio terabyte (vagy ilyesmi), amiben az az 1G a PCI-nek olyan mint tu a szenakazalban. Vagy en gondolom rosszul? De akkor miert lehet az csucs Maceket 8G rammal kerni?

  • GK

    A kernel a kernel driverek kompatibilitása miatt 32 biten fut, de az én gépemben a memória-vezérlő sem támogatta a 4 gigát.

  • bbkmbtni

    Windows 7-re tudsz ajánlani vmi jó fragmentáló progit?

  • GK

    Nem tudok.

  • Atomant

    Nahát, Május 35!
    Még senkitől nem hallottam : )

Trackbacks for this post

  1. SSD | GK blog

Submit a CommentPlease be polite. We appreciate that.

Your Comment