Paano I-tweak ang Iyong SSD sa Ubuntu para sa Mas Mahusay na Pagganap

Mayroong maraming mga tip out doon para sa pag-tweak ng iyong SSD sa Linux at maraming mga anecdotal na ulat sa kung ano ang gumagana at kung ano ang hindi. Nagpatakbo kami ng sarili naming mga benchmark na may ilang partikular na pag-aayos upang ipakita sa iyo ang tunay na pagkakaiba.

Mga benchmark

Upang i-benchmark ang aming disk, ginamit namin ang Phoronix Test Suite . Ito ay libre at may repositoryo para sa Ubuntu kaya hindi mo na kailangang mag-compile mula sa simula upang magpatakbo ng mga mabilisang pagsubok. Sinubukan namin ang aming system pagkatapos ng bagong pag-install ng Ubuntu Natty 64-bit gamit ang mga default na parameter para sa ext4 file system.

Ang aming system specs ay ang mga sumusunod:

AMD Phenom II quad-core @ 3.2 GHz
MSI 760GM E51 motherboard
3.5 GB ng RAM
AMD Radeon 3000 na isinama w/ 512MB RAM
Ubuntu Natty

At, siyempre, ang SSD na ginamit namin upang subukan ay isang 64GB OCZ Onyx drive ( 7 sa Amazon.com sa oras ng pagsulat).

Mga Prominenteng Tweak

Mayroong ilang mga pagbabago na inirerekomenda ng mga tao kapag nag-a-upgrade sa isang SSD. Matapos i-filter ang ilan sa mga mas lumang bagay, gumawa kami ng maikling listahan ng mga pag-aayos na hindi isinama ng mga Linux distro bilang mga default para sa mga SSD. Tatlo sa mga ito ang may kinalaman sa pag-edit ng iyong fstab file, kaya i-back up iyon bago ka magpatuloy sa sumusunod na command:

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

Kung may mali, maaari mong i-delete ang bagong fstab file anumang oras at palitan ito ng kopya ng iyong backup. Kung hindi mo alam kung ano iyon o gusto mong suriin kung paano ito gumagana, tingnan Ipinaliwanag ng HTG: Ano ang Linux fstab at Paano Ito Gumagana?

Pag-iwas sa Oras ng Pag-access

Maaari kang makatulong na palakihin ang buhay ng iyong SSD sa pamamagitan ng pagbawas sa dami ng sinusulat ng OS sa disk. Kung kailangan mong malaman kung kailan huling na-access ang bawat file o direktoryo, maaari mong idagdag ang dalawang opsyong ito sa iyong /etc/fstab file:

noatime, nodiratime

Idagdag ang mga ito kasama ng iba pang mga opsyon, at tiyaking lahat sila ay pinaghihiwalay ng mga kuwit at walang mga puwang.

Paganahin ang TRIM

Maaari mong paganahin ang TRIM upang tumulong na pamahalaan ang pagganap ng disk sa pangmatagalan. Idagdag ang sumusunod na opsyon sa iyong fstab file:

itapon

Ito ay mahusay na gumagana para sa ext4 file system, kahit na sa karaniwang mga hard drive. Dapat ay mayroon kang kernel na bersyon ng hindi bababa sa 2.6.33 o mas bago; sakop ka kung gumagamit ka ng Maverick o Natty, o naka-enable ang mga backport sa Lucid. Bagama't hindi nito partikular na pinapabuti ang paunang benchmarking, dapat nitong gawing mas mahusay ang system sa pangmatagalan at kaya ginawa nito ang aming listahan.

Tmpfs

Ang cache ng system ay naka-imbak sa /tmp. Maaari naming sabihin sa fstab na i-mount ito sa RAM bilang isang pansamantalang file system upang hindi gaanong mahahawakan ng iyong system ang hard drive. Idagdag ang sumusunod na linya sa ibaba ng iyong /etc/fstab file sa isang bagong linya:

tmpfs /tmp tmpfs default,noatime,mode=1777 0 0

I-save ang iyong fstab file upang gawin ang mga pagbabagong ito.

Pagpapalit ng IO Scheduler

Hindi agad isinusulat ng iyong system ang lahat ng mga pagbabago sa disk, at maraming kahilingan ang nakapila. Ang default na input-output scheduler – cfq – ay pinangangasiwaan ito nang maayos, ngunit maaari naming baguhin ito sa isa na mas gumagana para sa aming hardware.

Una, ilista kung aling mga opsyon ang mayroon ka sa sumusunod na command, palitan ang X ng titik ng iyong root drive:

cat /sys/block/sdX/queue/scheduler

Ang aking pag-install ay nasa sda. Dapat mong makita ang ilang iba't ibang mga opsyon.

Kung mayroon kang deadline, dapat mong gamitin iyon, dahil nagbibigay ito sa iyo ng karagdagang tweak sa ibaba ng linya. Kung hindi, dapat mong gamitin ang noop nang walang problema. Kailangan naming sabihin sa OS na gamitin ang mga opsyong ito pagkatapos ng bawat boot kaya kakailanganin naming i-edit ang rc.local file.

Gagamitin namin ang nano, dahil komportable kami sa command-line, ngunit maaari mong gamitin ang anumang iba pang text editor na gusto mo (gedit, vim, atbp.).

sudo nano /etc/rc.local

Sa itaas ng exit 0 na linya, idagdag ang dalawang linyang ito kung gumagamit ka ng deadline:

echo deadline > /sys/block/sdX/queue/scheduler

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

Kung gumagamit ka ng noop, idagdag ang linyang ito:

echo noop > /sys/block/sdX/queue/scheduler

Muli, palitan ang X ng naaangkop na drive letter para sa iyong pag-install. Suriin ang lahat upang matiyak na maganda ito.

Pagkatapos, pindutin ang CTRL+O upang i-save, pagkatapos ay CTRL+X upang umalis.

I-restart

Upang magkaroon ng bisa ang lahat ng pagbabagong ito, kailangan mong i-restart. Pagkatapos nito, dapat ay handa ka na. Kung may mali at hindi ka makapag-boot, maaari mong sistematikong i-undo ang bawat hakbang sa itaas hanggang sa makapag-boot ka muli. Maaari mo ring gamitin ang isang LiveCD o LiveUSB para mabawi kung gusto mo.

Ang iyong mga pagbabago sa fstab ay magpapatuloy sa buhay ng iyong pag-install, kahit na makatiis ng mga pag-upgrade, ngunit ang iyong rc.local na pagbabago ay kailangang muling isagawa pagkatapos ng bawat pag-upgrade (sa pagitan ng mga bersyon).

Mga Resulta ng Benchmarking

Upang maisagawa ang mga benchmark, pinatakbo namin ang disk suite ng mga pagsubok. Ang tuktok na larawan ng bawat pagsubok ay bago ang pagsasaayos ng ext4 na configuration, at ang ibabang larawan ay pagkatapos ng mga pag-aayos at pag-reboot. Makakakita ka ng maikling paliwanag kung ano ang sinusukat ng pagsubok pati na rin ang interpretasyon ng mga resulta.

Malaking File Operations

Ang pagsubok na ito ay nag-compress ng 2GB na file na may random na data at isinusulat ito sa disk. Ang mga SSD tweak dito ay nagpapakita sa humigit-kumulang 40% na pagpapabuti.

Ginagaya ng IOzone ang pagganap ng file system, sa kasong ito sa pamamagitan ng pagsusulat ng 8GB na file. Muli, halos 50% na pagtaas.

Dito, binabasa ang isang 8GB na file. Ang mga resulta ay halos kapareho ng walang pagsasaayos ng ext4.

Asynchronous na sinusuri ng AIO-Stress ang input at output, gamit ang isang 2GB na test file at isang 64KB na laki ng tala. Dito, halos 200% ang pagtaas ng performance kumpara sa vanilla ext4!

Maliit na File Operations

Ang isang database ng SQLite ay nilikha at ang PTS ay nagdaragdag ng 12,500 na mga tala dito. Ang mga SSD tweak dito ay talagang pinabagal ang pagganap ng halos 10%.

Sinusuri ng Apache Benchmark ang mga random na pagbabasa ng maliliit na file. Nagkaroon ng humigit-kumulang 25% na nadagdag sa performance pagkatapos i-optimize ang aming SSD.

Ginagaya ng PostMark ang 25,000 mga transaksyon sa file, 500 nang sabay-sabay sa anumang oras, na may mga laki ng file sa pagitan ng 5 at 512KB. Ginagaya nito ang mga web at mail server nang maayos, at nakikita namin ang 16% na pagtaas ng performance pagkatapos mag-tweak.

Ang FS-Mark ay tumitingin sa 1000 mga file na may kabuuang sukat na 1MB, at sinusukat kung gaano karami ang maaaring ganap na isulat at basahin sa isang paunang itinakda na tagal ng oras. Ang aming mga tweak ay nakakakita ng pagtaas, muli, na may mas maliliit na laki ng file. Humigit-kumulang 45% na pagtaas sa mga ext4 na pagsasaayos.

Pag-access sa File System

Ang Dbench benchmarks test file system ay tumatawag ng mga kliyente, tulad ng kung paano ginagawa ni Samba ang mga bagay. Dito, nabawasan ng 75% ang performance ng vanilla ext4, isang malaking set-back sa mga pagbabagong ginawa namin.

Makikita mo na habang tumataas ang bilang ng mga kliyente, tumataas ang pagkakaiba sa pagganap.

Sa 48 na kliyente, medyo nagsara ang agwat sa pagitan ng dalawa, ngunit mayroon pa ring napakalinaw na pagkawala ng pagganap sa pamamagitan ng aming mga pag-aayos.

Sa 128 mga kliyente, ang pagganap ay halos pareho. Maaari kang mangatuwiran na ang aming mga pag-aayos ay maaaring hindi perpekto para sa paggamit sa bahay sa ganitong uri ng operasyon, ngunit magbibigay ng maihahambing na pagganap kapag ang bilang ng mga kliyente ay tumaas nang husto.

Ang pagsubok na ito ay nakadepende sa AIO access library ng kernel. mayroon kaming 20% na pagpapabuti dito.

Dito, mayroon kaming multi-threaded random read na 64MB, at mayroong 200% na pagtaas sa performance dito! Wow!

Habang nagsusulat ng 64MB ng data na may 32 thread, mayroon pa rin kaming 75% na pagtaas sa performance.

Ginagaya ng Compile Bench ang epekto ng edad sa isang file system na kinakatawan ng pagmamanipula ng mga kernel tree (paglikha, pag-compile, pag-patch, atbp.). Dito, makikita mo ang isang makabuluhang benepisyo sa pamamagitan ng paunang paglikha ng kunwa na kernel, mga 40%.

Sinusukat lang ng mga benchmark na ito kung gaano katagal bago i-extract ang Linux kernel. Hindi masyadong tumaas ang performance dito.

Buod

Ang mga pagsasaayos na ginawa namin sa out-of-the-box na ext4 na configuration ng Ubuntu ay may malaking epekto. Ang pinakamalaking nadagdag sa performance ay nasa larangan ng multi-threaded writes and reads, maliit na file reads, at malalaking magkadikit na file reads and writes. Sa katunayan, ang tanging tunay na lugar na nakita namin ang isang hit sa pagganap ay sa mga simpleng file system na tawag, isang bagay na dapat abangan ng mga gumagamit ng Samba. Sa pangkalahatan, ito ay tila isang medyo solidong pagtaas sa pagganap para sa mga bagay tulad ng pagho-host ng mga webpage at panonood/pag-stream ng malalaking video.

Tandaan na partikular ito sa Ubuntu Natty 64-bit. Kung iba ang iyong system o SSD, maaaring mag-iba ang iyong mileage. Gayunpaman, sa pangkalahatan, tila ang mga pagsasaayos ng fstab at IO scheduler na ginawa namin ay nakatulong sa mas mahusay na pagganap, kaya malamang na sulit itong subukan sa iyong sariling rig.

May sarili kang mga benchmark at gustong ibahagi ang iyong mga resulta? May isa pang tweak na hindi natin alam? Tunog sa mga komento!

BASAHIN SUNOD