Hogyan csípje az SSD-t az Ubuntu-ban a jobb teljesítmény érdekében

Rengeteg tipp van az SSD Linuxon való csípésében, és sok anekdotikus jelentés arról, hogy mi működik és mi nem. A saját referenciaértékeinket néhány konkrét tweaks-szal futtattuk, hogy megmutassuk a valódi különbséget.

referenciaértékek

A lemezünk összehasonlításához a Phoronix Test Suite-t használtuk. Ez ingyenes, és rendelkezik egy tárolóval az Ubuntu-hoz, így nem kell semmiből összeállítania a gyors tesztek futtatásához. A rendszerünket az Ubuntu Natty 64 bites friss telepítése után teszteltük az ext4 fájlrendszer alapértelmezett paramétereivel.

Rendszerünk specifikációi a következők voltak:

• AMD Phenom II quad-core @ 3.2 GHz
• MSI 760GM E51 alaplap
• 3,5 GB RAM
• AMD Radeon 3000 integrált w / 512 MB RAM
• Ubuntu Natty

Természetesen az általunk tesztelt SSD egy 64 GB-os OCZ Onyx meghajtó volt ($ 117 az Amazon.com-on az írás idején)..

Kiemelkedő Tweaks

Az SSD-re való frissítés során az emberek nagyon kevés változtatást javasolnak. Néhány régebbi cucc kiszűrése után egy rövid listát készítettünk, melyeket a Linux distros nem tartalmazott alapértelmezettként az SSD-k számára. Ezek közül három magában foglalja az fstab-fájl szerkesztését, így vissza, mielőtt tovább folytatná a következő parancsot:

sudo cp / etc / fstab /etc/fstab.bak

Ha valami hibás, mindig törölheti az új fstab fájlt, és helyettesítheti azt a biztonsági másolat másolatával. Ha nem tudod, hogy mi az, vagy szeretné, hogy tisztítsa meg, hogyan működik, nézd meg a HTG Explains: Mi a Linux fstab és hogyan működik??

Az Access Times használata

Segítségével növelheti az SSD élettartamát azáltal, hogy csökkenti, hogy az operációs rendszer írjon a lemezre. Ha tudnia kell, hogy az egyes fájlok vagy könyvtárak utoljára elérték, a két lehetőséget hozzáadhatja az / etc / fstab fájlhoz:

noatime, nodiratime

Adja hozzá őket a többi opcióval együtt, és győződjön meg róla, hogy mindegyik vesszővel és szóköz nélkül van elválasztva.

TRIM engedélyezése

Engedélyezheti a TRIM-et, hogy hosszú távon segítse a lemez teljesítményének kezelését. A következő opció hozzáadása az fstab fájlhoz:

megválni

Ez jól működik az ext4 fájlrendszerek esetében, még a szabványos merevlemezeken is. Legalább 2.6.33 vagy újabb rendszermag-verzióval kell rendelkeznie; ha Maverick vagy Natty használ, vagy ha a Lucid-on engedélyezett a tartalék. Bár ez nem javítja a kezdeti teljesítményértékelést, a hosszú távon a rendszer jobban teljesítenie kell, így a listát is elkészítette.

tmpfs

A rendszer gyorsítótárát a / tmp fájlban tárolja. Megmondhatjuk az fstabnak, hogy ezt ideiglenes fájlrendszerként csatlakoztassa a RAM-ba, így a rendszer kevésbé érinti a merevlemezt. Adja meg az alábbi sort az / etc / fstab fájl aljára egy új sorban:

tmpfs / tmp tmpfs alapértelmezett értékek, noatime, mode = 1777 0 0

Mentsd el az fstab fájlt a módosítások végrehajtásához.

IO-ütemezők váltása

A rendszer nem írja azonnal az összes lemezt a lemezre, és több kérés sorba áll. Az alapértelmezett bemeneti-kimeneti ütemező - cfq - kezeli ezt az okot, de ezt megváltoztathatjuk olyanra, amely jobban működik a hardverünkhöz.

Először felsorolja, hogy mely opciók állnak rendelkezésre a következő paranccsal: az „X” helyettesítése a root meghajtó betűjével:

cat / sys / block / sdX / sor / ütemező

A telepítésem sda. Néhány különböző lehetőséget kell látnia.

Ha van határideje, akkor ezt kell használnod, mivel egy extra csípést ad a sorban. Ha nem, akkor problémamentesen kell használni a noopot. Meg kell mondanunk az operációs rendszernek, hogy minden egyes indítás után használja ezeket az opciókat, ezért szerkesztenünk kell az rc.local fájlt.

Nano-t fogunk használni, hiszen elégedettek vagyunk a parancssorral, de bármilyen más szövegszerkesztőt használhatsz (gedit, vim, stb.).

sudo nano /etc/rc.local

A „0-os kijárat” sor felett adja meg a két sort, ha határidőt használ:

echo deadline> / sys / blokk / sdX / sor / ütemező

echo 1> / sys / block / sdX / queue / iosched / fifo_batch

Ha noopot használ, adja hozzá ezt a sort:

echo noop> / sys / block / sdX / sor / ütemező

Ismét cserélje ki az „X” -et a telepítés megfelelő meghajtóbetűjével. Nézd meg mindent, hogy jól nézzen ki.

Ezután nyomja meg a CTRL + O gombot a mentéshez, majd a CTRL + X billentyűt a kilépéshez.

Újrakezd

Ahhoz, hogy ezek a változtatások hatályba lépjenek, újra kell indítani. Ezután mindenkit be kell állítani. Ha valami rosszul megy, és nem tudja elindítani a rendszert, szisztematikusan visszavonhatja a fenti lépéseket mindaddig, amíg újra nem indul el. A LiveCD-t vagy a LiveUSB-t is használhatja, ha akarja.

A fstab változásai a telepítés élettartamát is magukban fogják tartani, még a frissítések ellenére is, de a rc.local változását minden frissítés után újra kell indítani..

Benchmarking eredmények

A referenciaértékek végrehajtásához a lemezek tesztjét futtattuk. Az egyes tesztek legfelső képe az ext4 konfiguráció csípése előtt van, az alsó kép pedig a tweaks és az újraindítás után történik. Rövid magyarázatot fog kapni arról, hogy milyenek a vizsgálati intézkedések, valamint az eredmények értelmezése.

Nagy fájlműveletek

Ez a teszt egy 2 GB-os fájlt tömörít véletlenszerű adatokkal, és írja a lemezre. Az SSD csípése körülbelül 40% -os javulást mutat.

Az IOzone a fájlrendszer teljesítményét szimulálja, ebben az esetben egy 8 GB-os fájl írásával. Ismét közel 50% -os növekedés.

Itt egy 8 GB-os fájl olvasható. Az eredmények majdnem ugyanazok, mint az ext4 beállítása nélkül.

Az AIO-Stress aszinkron módon teszteli a bemenetet és a kimenetet egy 2 GB-os tesztfájl és 64KB-os rekordméret alkalmazásával. Itt közel 200% -os teljesítménynövekedés van a vanilla ext4-hez képest!

Kis fájlműveletek

SQLite adatbázis jön létre, és a PTS hozzáad 12.500 rekordot. Az SSD-t itt körülbelül 10% -kal lassítja a teljesítmény.

Az Apache Benchmark teszteli a kis fájlok véletlenszerű olvasását. Az SSD optimalizálása után körülbelül 25% -os teljesítménynövekedés volt tapasztalható.

A PostMark 25 000 fájl tranzakciót szimulál, 500 egyszerre egy adott időpontban, 5 és 512 KB közötti fájlmérettel. Ez jól szimulálja a webes és levelezőszervereket, és a csípés után 16% -os teljesítménynövekedést tapasztalunk.

Az FS-Mark 1000 fájlra néz 1MB-os teljes mérettel, és megvizsgálja, hogy hányan lehet teljes mértékben írni és olvasni egy előre meghatározott idő alatt. A tweaks ismét megnézi a kisebb fájlméreteket. Körülbelül 45% -os növekedés az ext4 beállításokkal.

Fájlrendszer-hozzáférés

A Dbench teszteli a kliensek által végrehajtott tesztfájl-rendszerhívásokat, mint ahogyan a Samba csinál. Itt a vanilla ext4 teljesítménye 75% -kal csökken, ami jelentős visszaesés az elvégzett változtatásokhoz.

Láthatjuk, hogy az ügyfelek száma emelkedik, a teljesítménykülönbség növekszik.

48 klienssel a különbség a kettő között kissé záródott, de még mindig nagyon nyilvánvaló teljesítményvesztés tapasztalható.

128 ügyfélnél a teljesítmény majdnem ugyanaz. Lehet, hogy a csípőink nem alkalmasak az otthoni használatra, de hasonló teljesítményt nyújtanak, ha az ügyfelek száma jelentősen megnő..

Ez a teszt a kernel AIO hozzáférési könyvtárától függ. itt van egy 20% -os javulásunk.

Itt van egy többszálú, 64 MB-os véletlenszerű olvasás, és itt 200% -os teljesítménynövekedés van! Azta!

64MB adatot 32 szálral írva még mindig 75% -kal nőtt a teljesítmény.

A Compile Bench az életkor hatását szimulálja a kernelfák manipulálásával ábrázolt fájlrendszeren (létrehozás, összeállítás, javítás stb.). Itt a szimulált kernel kezdeti létrehozása révén jelentős előnyhöz juthat, körülbelül 40%.

Ez a referenciaérték egyszerűen azt méri, hogy mennyi ideig tart a Linux kernel kinyerése. Nem túl sok a teljesítmény növelése itt.

összefoglalás

Az Ubuntu out4 of-the-box ext4 konfigurációjában elvégzett módosítások meglehetősen hatással voltak. A legnagyobb teljesítménynövekedés a többszálú írások és olvasások birodalmában, a kis fájl olvasásában és a nagy összefüggő fájlokban olvas és ír. Valójában az egyetlen igazi hely, ahol láttunk egy teljesítményt az egyszerű fájlrendszerhívásokban, amit a Samba-felhasználóknak kell figyelniük. Összességében úgy tűnik, hogy eléggé megnövekedett a teljesítmény, mint például a weboldalak tárolása és a nagy videók figyelése / streamingje.

Ne feledje, hogy ez kifejezetten az Ubuntu Natty 64-bites volt. Ha a rendszer vagy az SSD más, a kilométered változhat. Összességében azonban úgy tűnik, mintha az fstab és az IO ütemező beállításai messzire mentek volna a jobb teljesítményhez, így valószínűleg érdemes megpróbálni a saját berendezésénél.

Legyen saját referenciaértéke és szeretné megosztani az eredményeket? Van még egy csípésünk, amit nem tudunk? Hangozzon ki a megjegyzésekben!