Аптымізацыя Linux для desktop і гульняў

1. 1. Купіце SSD, калі ў вас яго яшчэ няма
2. 2. Табліца падзелаў
3. 3. Выкарыстоўвайце 64-бітнае ядро
4. 4. Выкарыстоўвайце патсет pf-kernel
5. 5. цюнінг ядро!
6. 6. Prelink
7. 7. Заключэнне

У гэтым артыкуле я хачу падзяліцца амаль 10-гадовым вопытам выкарыстання Linux на хатнім кампутары. За гэты час я правёў шмат эксперыментаў над ядром, выпрабаваў розныя канфігурацыі для розных ужыванняў і цяпер хачу ўсё гэта сістэматызаваць ў доўгі пост з рэкамендацыямі як выціснуць з linux максімум і дамагчыся выдатнай прадукцыйнасці, без неабходнасці купляць магутнае жалеза.

1. Купіце SSD, калі ў вас яго яшчэ няма

Чамусьці многія людзі скептычна ставяцца да SSD, хоць гэта першы і найважнейшы кампанент кампутара, які збіраецца хутка працаваць.

Любы, нават самы танны SSD, скароціць час запуску большасці праграм да 0, што, візуальна, будзе вельмі прыкметна. Амаль у любым кампутары (і серверы) галоўны тормаз гэта заўсёды дыскавая падсістэма і ніякай HDD ніколі не дасць вам патрэбнай хуткасці пошуку (якая ў SSD імкнецца да 0 мс). За ўвесь час размовы з кампутарамі і іх апгрэйду, толькі пераход на SSD даў значны прырост у хуткасці працы і водгуку. Памятаеце як павольна працуюць дыскеты, якое ў іх велізарнае час пошуку? Прыкладна вось так успрымаецца жорсткі дыск пасля SSD.

Так што калі ў вас яшчэ няма SSD, то працягваць далей сэнсу няма, ваш кампутар (хоць нават абсталяваны 12-ядзерных Xeon'ом) усё роўна будзе працаваць павольна, так што наперад па пакупкі.

Датычна надзейнасці: ёсць міф што SSD паміраюць праз год. Яго нараджэння мы абавязаны першым SSD на бажных чыпах SandForce. Натуральна, любы новы SSD з крамы як мінімум надзейней і даўгавечней сучасных жорсткіх дыскаў, так што не варта турбавацца з гэтай нагоды наогул. Свой SSD я купіў 2 гады таму б / у, на той час ён быў у выкарыстанні год. Цяпер у яго 11 681 гадзін напрацоўкі і выкарыстанне рэсурсу 10%, так што пры тым жа рэжыме выкарыстання, мне яго хопіць яшчэ на 27 гадоў. Думаю, да гэтага часу тэхналогіі захоўвання дадзеных ўжо некалькі разоў зменяцца. Так што паўтаруся, праблемы з надзейнасцю больш чым надуманыя.

У Ubuntu 14.04 SSD працуюць са скрынкі, опцыя discard аўтаматам прапісваецца ў fstab, акрамя гэтага больш нічога не трэба рабіць.

У іншых дыстрыбутывах трэба правяраць, ці ёсць гэтая опцыя у раздзелаў на SSD. Варта згадаць, што дадзеную опцыю падтрымлівае толькі ext4. Для іншых ФС прыйдзецца карыстацца fstrim з планавальніка.

2. Табліца падзелаў

Ня дзеліце дыскі на раздзелы.

Для хатняга кампутара гэта бессэнсоўна і шкодна. На SSD ў вас павінен быць адзін падзел для кораня, там у вас будзе захоўваецца сістэма і ўсе дадзеныя. На HDD (калі патрэбен) у вас павінен быць адзін падзел з кропкай мантавання ў / mnt (у мяне / mnt / data), дзе будуць захоўвацца вялікія малаўжываную дадзеныя (фільмы, музыка, гульні). НЕ ТРЭБА рабіць HDD кропкай мантавання / home, так як у / home 99% праграм захоўвае свае дадзеныя і ўвесь час да іх звяртаецца, таму / home павінен быць на SSD.

Не слухайце шкодных саветаў па вынясенні такіх дадзеных на HDD, як ужо было сказана праблемы зносу SSD няма, гэта міф, і вялікая колькасць цыклаў запісу наогул не ўплывае на даўгавечнасць SSD. Яшчэ раз адсылае да артыкула Вадзіма Стеркина, там гэта ўсё апісана больш падрабязна і падмацавана тлумачэннямі.

Наконт SWAP-раздзела: ён вам не патрэбны. Калі ў вас не хапае аператыўнай памяці, то OOM-killer будзе прыбіваць рэсурсаёмістыя прыкладанні, калі гэта адбываецца тое дакупіце аператыўкі, карысць яе цана не моцна кусаецца. Выкарыстанне swap як пашыральніка аператыўнай памяці значна запавольвае працу кампутара. Ёсць шмат меркаванняў, што без SWAP будуць нейкія праблемы, але ІМХО, карані гэтыя размоў растуць ад Win9x і на сёння гэта ўжо міфы, асабіста я не заўважаў ніякіх праблем ад адмовы ад SWAP. Як пруф: на VPS цяпер рэдка ўбачыш падлучаны SWAP і працуюць жа як-то!

suspend-to-disk вам таксама не патрэбен, таму што халодны старт з SSD хутчэй чым аднаўленне з спячкі з HDD, так што карыстайцеся suspend-to-ram або выключайце кампутар цалкам. Адзіны плюс ад СВАПО - магчымасць сысці ў гібрыдную спячку, гэта калі сістэма рыхтуецца да suspend-to-disk, але выконвае suspend-to-ram, так што пазней, калі ўсё добра, ідзе простае выйсце з спячкі, а калі адбыўся збой харчавання - то сістэма адновіцца з дыска.

Я выкарыстоўваю ўсюды файлавую сістэму ext4, так як з іншымі мне не ўдалося атрымаць прыкметнай розніцы ў прадукцыйнасці, а ext4 найбольш распаўсюджаная, плюс маюцца утыліты для аднаўлення дадзеных (але не спадзявайцеся на іх, а рабіце бэкапы). Пры стварэнні выкарыстоўвайце -T largefile або largefile4.

3. Выкарыстоўвайце 64-бітнае ядро

Ад прадукцыйнасці аператыўнай памяці мала што залежыць, ад яе не павялічыцца FPS ў гульнях і не стануць хутчэй запускацца прыкладання. Выкарыстанне 64-бітных прыкладанняў таксама не дае ніякага прыросту для звычайных задач, толькі для вельмі спецыфічных матэматычных разлікаў і аперацый архівавання. Таксама, выкарыстанне 64 ядра не патрабуецца для адрасавання больш за 4 ГБ памяці, PAE дазваляе адрасаваць да 64 ГБ памяці на 32 бітнай сістэме.

Але выкарыстоўваючы 64-бітнае ядро, прыкладання могуць адрасаваць больш чым 4 ГБ памяці, што даволі карысна, бо інакш можа ўзнікаць сітуацыя калі OOM-killer будзе прыбіваць праграмы, хоць аператыўкі яшчэ дастаткова. Таксама на 64-бітнай сістэме можна адрасаваць адразу ж ўсю фізічную памяць, на 32 бітнай ж усё што вышэй ~ 800 МБ трэба пастаянна ремапить, што некалькі зніжае хуткасць старонкавага абмену, хоць, як я ўжо сказаў, гэта асабліва не ўплывае на хуткасць працы.

Яшчэ заўважаў эфект, што OOM-killer можа прыбіваць працэсы, якія быццам бы яшчэ не занялі 4 ГБ. У мяне такое было з некаторымі гульнямі. Праблема вырашылася пераходам на 64 біта. Так што без 64-бітнага ядра ўжо нікуды, хоць гэта і дадае невялікія накладныя выдаткі на выкарыстанне памяці.

4. Выкарыстоўвайце патсет pf-kernel

pf-kernel - гэта набор патчаў для ядра linux, сабраныя украінцам Аляксандрам Наталенко ( pfactum ) Накіраваныя на паляпшэння desktop-experience linux-сістэм.

Ён складаецца з:

Найбольш карыснымі з'яўляюцца патчы BFS і BFQ, пра якія ўжо вельмі шмат напісана. BFQ змагаецца з праблемай тармазоў сістэмы падчас выканання вялікіх дыскавых аперацый (знакаміты баг 12309, які па дакументах выпраўлена, але па факце працягвае дапякаць), BFS - планировщий працэсаў, больш прыдатны для дэсктопнай працы, чым тыя што ідуць у ядры. Напрыклад CFS, які выкарыстоўваецца па змаўчанні дапускае сітуацыю, калі 2 працэсу, якія патрабуюць прыярытэт рэальнага часу будуць спраўдзяцца на адным ядры, хоць іншыя ядра занятыя низкоприоритетными задачамі. Натуральна, такія паводзіны прыводзіць да глабальных тармазах. Затое «сумленны планавальнік». BFS не такі «сумленны», але затое нашмат больш набліжаны да рэалій настольных кампутараў з невялікім (вялікае - гэта 4096) колькасцю ядраў.

Для ўстаноўкі, я пампую з kernel.org неабходную версію ядра без стабилизационнх патчаў і накладваю на яго pf-kernel. У агульным выпадку гэта выглядае так:

cd / usr / src wget ftp://ftp.kernel.org/pub/linux/kernel/v3.x/linux-3.12.tar.xz tar -xf linux-3.12.tar.xz cd linux-3.12 wget https: //pf.natalenko.name/sources/3.12/patch-3.12.4-pf.bz2 bunzip2 patch-3.12.4-pf.bz2 patch -p1 & lt; patch-3.12.4-pf

Гэта вельмі важны патчсет, менавіта ён дазваляе сістэме быць спагаднай, нават у моманты вялікай нагрузкі. У выніку, напрыклад, нават пры максімальнай нагрузцы, час запуску прыкладанняў застаецца такім жа, як і пры простае!

5. цюнінг ядро!

У ядры па змаўчанні выкарыстоўваюцца не вельмі аптымальныя параметры, абумоўленыя гістарычным прызначэннем linux для сервераў і даступнасці для адладкі.

Так што рабіце make xconfig

Найбольш важныя опцыі для аптымізацыі

Выключаем preemption, усталёўваем нізкую частату таймера і выключаем dynticks!

Ідзем у Processor type and features і выбіраем для параметру Preemption Model значэнне No Forced Preemption (Server). Не палохаемся фразы «ocasional longer delays are possible» таму што дадзеную праблему ў нас эфектыўна вырашае BFS і шмат'ядравы працэсар. Як і напісана ў апісанні, мы выйграе ў «raw processing power».

Таксама, у мэтах аптымізацыі, для параметру Processor family выберыце свой працэсар.

Далей, усталёўваем для параметру Timer frequency значэнне 300 HZ.

У гэтым раздзеле ёсць нямала цікавых опцый, паглядзіце, напрыклад можна выключыць hot-plug для cpu і памяці, бо на дэсктопе гэта проста немагчыма зрабіць (а выключаць-уключаць на ляту ядра рэдка каму трэба).

Так як у мяне не ноўтбук, я выключаю ўсе што звязана з энергазберажэннем, гэта значыць да прыкладу выключаю падтрымку CPU Frequency scaling наогул.

Цяпер адключым дынамічны таймер. Не ўпэўнены дакладна, так як не правяраў канкрэтна, але падобна менавіта гэтая опцыя прыводзіць да сталых «паторгванні» на некаторых відэа і асабліва ў гульнях. Так што ідзем General setup -> Timers subsystem і для опцыі Timer tick handling выбіраем Periodic timer ticks (constant rate, no dynticks).

ўключаем BFQ

Па змаўчанні BFQ выключаны і яго трэба ўключыць а таксама выбраць выкарыстоўваным па змаўчанні.

Ідзем Enable the block layer -> IO Schedulers ўключаем опцыі BFQ I / O scheduler і BFQ hierarchical scheduling support, для опцыі Default I / O scheduler выбіраем, відавочна, BFQ.

6. Prelink

Можна папярэдне звязаць з выкананымі файламі дынамічныя бібліятэкі, што дазваляе яшчэ больш паменшыць час запуску прыкладанняў. Па гэтай тэме ёсць асобная артыкул ад peter23 .

7. Заключэнне

Пасля накладання патчсета і цюнінгу ядра сыходзяць «паторгванні» ў гульнях. Чым слабейшы ​​жалеза, тым больш прыкметнымі гэтыя паторгванні, хоць у мяне ёсць падазрэнні што гэта ўсё ж нейкая праблема ў драйверах nVidia, таму што розныя версіі паводзяць сябе па-рознаму.

(via habrahabr )

Калі вы знайшлі памылку, калі ласка, вылучыце фрагмент тэксту і націсніце Ctrl + Enter.