Linux Mint 17.1 SSD-re optimalizálása

Linux-kezdő

Sziasztok,

SSD meghajtóra szeretném optimalizálni Linux Mint 17.1 Op rendszerem, de nem igazán tudom, hogy mit lenne érdemes mindenképpen beletenni. Sok javaslatot olvastam, de a véleményetekre lennék kíváncsi, hogy ki mit optimalizál a rendszerében.

Ezt a két leírást követtem:
https://sites.google.com/site/easylinuxtipsproject/ssd

http://logout.hu/bejegyzes/berus_berus/linux_es_ssd_gyorstalpalo.html

Amit nem tudok, vagyok benne biztos, hogy a "noatime" lépásen kívül mi lenne még a legfontosabb optimalizálás még.

pl: "tmpfs /var/log tmpfs defaults,noatime 0 0"

A log file memóriában tárolása, esetleg erre van-e valami jobb ötlet?

Esetleg fontos-e a trim változtatása?

Köszi!

Kalmi

  • 5165 megtekintés

Azért valamennyit célszerű vele foglalkozni, de tényleg nem érdemes túl sokat. Amit írtál:
- a noatime jó (bár a relatime se rossz, az a default), de akkor már nodiratime is, és persze discard is kell.
- tmpfs mehet a /tmp és /var/tmp alá
- log elfér a vinyón

A googlse sitesről ami szerintem jó:
- bios ahci
- a drive egy részét hagyd üresen
- ext4
- scheduler
- swappiness
- discard hiányában az fstrim
A többi felejtős, a csillió restart meg pláne.

Én még mindig csóringer vagyok és nincs 120GB-nál nagyobb ssd-m.
A hely meg többnyire kell, főleg ha épp custom cm-et fordítok.
S igen, kissé saját szempontból néztem a dolgot, de ha már a swapet tolom, akkor oly mindegy, hogy mennyire gyorsan trashingel a rendszer. (Értsd: ssd alatti swappel is sysrq a végeredmény az esetek 99%-ában.) ;)

Az meg hogy mennyire gyorsan fut a pacman/apt... Nos többnyire lényegtelen.

> Hozzatennem meg a cache kikapcsolasat FF es Chrome alatt is.
> Helyet is sporol, IO-t is.

Epp ilyenek miatt kerdeztem eredetileg, h mire akar optimalizalni.
Az OMG-t arra irtam, h _altalaban_ az emberek nem arra optimalizalnak, h szarul mukodjon a gepuk, persze vannak specialis esetek (ahogy irtad, nalad pl. nincs hely).
Mindezzel egyutt az IO sporolos reszt nem ertem tovabbra sem. Ha van egy SSD-d, ami gyors, minek sporolna az IO-val az ember? Esetleg egy nagyon-nagyon lassu HDD-vel lehet ertelme, de valszinuleg meg egy 5400rpm-essel sem, csak egy igazan gyors uplinkkel.

> S ha van a gepben meg rendes disk is, akkor oda tennem a swapet (ha desktop a gep es van eleg ram) es a /var/cache -t Deb alapu rendszereken (oda kerul az apt cucca es a letoltesek.)

A cache-t megertem, de a swap-nel mi oka lehet barkinek elrakni az SSD-rol? Az az _legelso_, amit oda kell pakolni.

Azt írja a FSTRIM(8):
Running fstrim frequently, or even using mount -o discard, might negatively affect the lifetime of poor-quality SSD devices.

Van valakinek erről releváns tapasztalata, hogy mennyit vesz le az eszköz életéből és menyit növel a sebességen? Mi a gyakorlat desktop környezetben?

Nem érdemes vele foglalkozni.
A 128-as SSD-met teleírtam vagy 200x bő 2 év alatt. Ha olyanom volt akkor fordítottam is rajta (openwrt, openelec), persze nem sokszor, de nem helloworld.c típusú dolgokat.

A poor quality inkább a kulcsszó, de az általában is ellenjavalt.

smartctl -A
Total_LBAs_Written

Nálam ez most 9031250896.
A 128 gigás SSD pedig 128*1024*1024 kb, 4k szektormérettel számolva 33554432 szektor, így 270x íródott tele.
Ha 1024 helyett 1000 a szorzó, akkor 32000000 szektor és 282 átírás. Ha az LBA netán 512 byte lenne, akkor per nyolc.

Nyilván erre jön még rá a wear leveling, ami egy hasraütéses szorzó, 100%-kal számolva se vészes.

Ezen kívül ilyen számok vannak még:
Reallocated_Sector_Ct 0
Power_On_Hours 9104, vagyis 379 * 24 óra
Power_Cycle_Count 2854
Wear_Leveling_Count 88
POR_Recovery_Count 127 (ez gyanúsan szép szám).

A Wear_Leveling_Count adhatna okot aggódásra, erre pre-fail amit ír, de erre ezt találtam:

Wear Leveling Count. This variable is vendor-specific. It decreases with time. When it reaches a certain manufacturer-defined threshold, S.M.A.R.T. reports the drive’s overall health as FAILED.

A szemszáng meg ezt mondja:

ID # 177 Wear Leveling Count

This attribute represents the number of media program and erase operations (the number of times a block has been erased). This value is directly related to the lifetime of the SSD. The raw value of this attribute shows the total count of P/E Cycles.

Viszont a samu azt írja itt, hogy 512 szektormérettel kell számolni, így nézve 33-35 teleírásra jött ki 88 wlc.
Ez vagy eléggé rossz wear level algoritmust feltételez, vagy én tartom rosszul :)

A tune2fs szerint az sda1 partíciót 2012 augusztusában hoztam létre, szóval még 500 ciklust bíró cellákkal is van benne vagy 15 év. Elvileg az mlc bír 10x ennyi ciklust (az enyém az), a tlc 6x ennyit.

Szóval long story short: a 177 Wear Leveling Count amit keresel :)

Köszi!

Nálam ez van: smartctl -A /dev/sda|grep -i writ
241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always - 709

Azaz nem látok Total_LBAs_Written részt. Viszont ez ad egy "Logical Sectors Written", "Logical Sectors Read" adatot:
smartctl -x /dev/sda|grep -i1 writ

TRIM-et nem ismero fs alatt nagyon hamar belassul az SSD.

Szerverkategorias SSD-vel teszteltem, vegtelen ciklusban letrehoztam random tartalmu file-okat, majd azonnal toroltem is. ext3-mal egy par ora utan belassult, ext4-gyel ket het utan is vidaman mukodott.

CF kartyas rendszerekre ext3-at szoktam tenni (jobban birja az aramszunetet). Minden folosleges iras a ramdisken landol (unionfs rulez!), igy csak mountolaskor ir egy par blokkot a kartyara (a /proc/diskstats szerint 3 irasi keres szokott lenni, ami 12 kB). Sok-sok eve mukodnek igy a tuzfalaim, eddig meg egyikben sem kellett CF kartyat cserelni.

( tompos v | 2014. 12. 23., k – 12:32 )

Elobb hatarozd el, mire akarsz optimalizalni. Sokaig birja, vagy a teljesitmenyre? Vagy mit jelent szamodra ez a kifejezes?

( CzLaci | 2014. 12. 23., k – 20:13 )

A partíciók noatime, nodiratime, discard opciókkal csatolva, /tmp noatime-al. Egy régebbi gépemen (Eeepc 901) a log-ot is a memóriába írtam, de itt nem tartottam szükségesnek. Swap egyik gépemen sincs, a jelenlegiben 8 GB van, még nem értem a végére, pedig nem gyakran indítom újra és az Xorg-szerver masszívan mem-leakes, 5 napja megy és már 800 MB-ot eszik.

--
Lenovo E335, LM 17.1 & MATE

( uid_2030 | 2014. 12. 24., sze – 11:17 )

Mint a leírásban is megjegyeztem, én a discard opciót favorizálom. Ha úgy használod az SSD-t, hogy gyakori az írás/törlés, akkor lehet érdemes az fstrimmet napi cron feladatként futtatni.
A /var/log memóriába tételének van pár hátulütője, érdemes átgondolni. Mondjuk nálam az egész /var HDD-n van (és a swap is), tehát nem kérdés...

> BERUS
Motor: Ubuntu 14.04 LTS (KDE)