Оптимизация Linux для desktop и игр
- среда, 27 августа 2014 г. в 03:11:41
http://habrahabr.ru/post/234653/
В этой статье я хочу поделиться почти 10-летним опытом использования Linux на домашнем компьютере. За это время я провел много экспериментов над ядром, испробовал различные конфигурации для разных применений и теперь хочу все это систематизировать в длинный пост с рекомендациями как выжать из linux максимум и добиться отличной производительности, без необходимости покупать мощное железо.
Лично я считаю часть, где я написал про тюнинг ядра все же немного устарела и современное железо уже априори выдает необходимую производительность для нормальной работы, но, как мне удалось заметить недавно, с играми все равно, даже сейчас, есть проблемы, даже на мощном железе.
Хоть я и пообещал, что после прочтения этой статьи, можно будет играть в Metro 2033 на калькуляторе (шутка, такого не будет), все же она начнется с рекомендации купить кое-что из железа, если у вас этого еще нет.
Почему-то многие люди скептически относятся к SSD, хотя это первый и важнейший компонент компьютера, который собирается быстро работать.
Серьезно, все что описано дальше в статье даст вам какой-то прирост в производительности и времени отклика, но любой, даже самый дешевый SSD, сократит время запуска большинства программ до 0, что, визуально, будет очень заметно. Почти в любом компьютере (и сервере) главный тормоз это всегда дисковая подсистема и никакой HDD никогда не даст вам нужной скорости поиска (которая у SSD стремится к 0 мс). За все время общения с компьютерами и их апгрейда, только переход на SSD дал значительный прирост в скорости работы и отклике. Помните как медленно работают дискеты, какое у них огромное время поиска? Примерно вот так воспринимается жесткий диск после SSD.
Так что если у вас еще нет SSD, то продолжать дальше смысла нет, ваш компьютер (хоть даже оснащенный 12-ядерным Xeon’ом) все равно будет работать медленно, так что вперед за покупками.
Касательно надежности: есть миф что SSD умирают спустя год. Его рождению мы обязаны первым SSD на бажных чипах SandForce. Естественно, любой новый SSD из магазина как минимум надежнее и долговечнее современных жестких дисков, так что не стоит беспокоиться по этому поводу вообще. Свой SSD я купил 2 года назад б/у, на то время он был в использовании год. Сейчас у него 11 681 часов наработки и использование ресурса 10%, так что при том же режиме использования, мне его хватит еще на 27 лет. Думаю, к этому времени технологии хранения данных уже несколько раз изменятся. Так что повторюсь, проблемы с надежностью более чем надуманы.
Более подробно о мифах SSD расписал товарищ Вадим Стеркин в своём блоге. Правда, блог у него о Windows, но сути это не меняет. Настоятельно советую почитать, очень интересно.
В Ubuntu 14.04 SSD работают из коробки, опция discard автоматом прописывается в fstab, кроме этого больше ничего не нужно делать.
Не делите диски на разделы.
Для домашнего компьютера это бессмысленно и вредно. На SSD у вас должен быть один раздел для корня, там у вас будет хранится система и все данные. На HDD (если нужен) у вас должен быть один раздел с точкой монтирования в /mnt (у меня /mnt/data), где будут хранится большие малоиспользуемые данные (фильмы, музыка, игры). НЕ НУЖНО делать HDD точкой монтирования /home, так как в /home 99% программ хранит свои данные и постоянно к ним обращается, поэтому /home должен быть на SSD.
Повторюсь кратко: на 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.
От производительности оперативной памяти мало что зависит, от нее не увеличится FPS в играх и не станут быстрее запускаться приложения. Использование 64-битных приложений тоже не дает никакого прироста для обычных задач, только для очень специфичных математических расчетов и операций архивирования. Также, использование 64 ядра не требуется для адресации более 4 ГБ памяти, PAE позволяет адресовать до 64 ГБ памяти на 32 битной системе.
Но используя 64-битное ядро, приложения могут адресовать больше чем 4 ГБ памяти, что довольно полезно, так как иначе может возникать ситуация когда OOM-killer будет прибивать программы, хотя оперативки еще достаточно. Также на 64-битной системе можно адресовать сразу же всю физическую память, на 32 битной же все что выше ~800 МБ надо постоянно ремапить, что несколько снижает скорость страничного обмена, хотя, как я уже сказал, это особо не влияет на скорость работы.
Еще замечал эффект, что OOM-killer может прибивать процессы, которые вроде бы еще не заняли 4 ГБ. У меня такое было с некоторыми играми. Проблема решилась переходом на 64 бита. Так что без 64-битного ядра уже никуда, хоть это и добавляет небольшие накладные расходы на использование памяти.
pf-kernel — это набор патчей для ядра linux, собранные украинцем Александром Наталенко (pfactum) направленные на улучшения desktop-experience linux-систем.
Он состоит из:
Наиболее полезными являются патчи BFS и BFQ, про которые уже очень много написано. BFQ борется с проблемой тормозов системы во время выполнения больших дисковых операций (знаменитый баг 12309, который по документам исправлено, но по факту продолжает досаждать), BFS — планировщий процессов, более подходящий для десктопной работы, чем те что идут в ядре. Например CFS, который используется по умолчанию допускает ситуацию, когда 2 процесса, которые требуют приоритет реального времени будут исполнятся на одном ядре, хотя другие ядра заняты низкоприоритетными задачами. Естественно, такое поведение приводит к глобальным тормозам. Зато «честный планировщик». BFS не такой «честный», но зато намного более приближен к реалиям настольных компьютеров с небольшим (большое — это 4096) количеством ядер.
Для установки, я качаю с kernel.org необходимую версию ядра без стабилизационнх патчей и накладываю на него pf-kernel. В общем случае это выглядит так:
Это очень важный патчсет, именно он позволяет системе быть отзывчивой, даже в моменты большой нагрузки. В результате, например, даже при максимальной нагрузке, время запуска приложений остается таким же, как и при простое!
Вот, например, скриншот htop при работе Dota 2 + The Sims 3 (multiseat):
При такой нагрузке на третьем экране можно спокойно работать и 25% (в 5-минутном окне по данным load-average) перегрузка CPU даже не чувствуется. Хотя, конечно, проц надо менять :(
В ядре по умолчанию используются не очень оптимальные параметры, обусловленные историческим предназначением linux для серверов и доступности для отладки.
Так что делайте make xconfig
Я расскажу о наиболее важных опциях для оптимизации
Выключаем preemption, устанавливаем низкую частоту таймера и выключаем dynticks!
ДА! Мы действительно, даже вопреки документации к BFS отключаем «жизненно важные» опции для повышения отзывчивости системы. А причина в том что они — устарели, толку от них никакого и к тому же preemption негативно влияет на производительность.
Было время, когда у меня был одноядерный процессор, тогда еще в готовых ядрах не включали preemption и высокочастотный таймер, вот тогда, после включения этих опций был огромный эффект. А именно, тяжеловесное приложение, занимающее 100% CPU, даже при наличии дискового ввода-вывода и нехватке ОЗУ никак не влияло на интерактивность и отзывчивость. В те времена, еще кроме WinXP ничего не было, а подробно рассказывать как ужасно себя ведет XP в таких ситуациях, думаю, не надо, она обычно намертво виснет, заставляя тянуться к кнопке reset. Так что иметь систему, которая почти никогда не тормозит и не зависает было приятно.
Но те времена прошли, многоядерные процессоры и огромные объемы памяти сами по себе решают проблемы отзывчивости под нагрузкой, так что дополнительно решать их программными средствами не только бесполезно, но и вредно.
Так что идем в 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. 100 все же будет маловато, да и смысла особого нет (читайте в описании почему), но вы можете поэкспериментировать. Также, 300 Гц нацело делится и на 25 и 30, что является типичными частотами для видео, это вносит свой вклад в борьбу с тирингом (это из хелпа. По факту, с тирингом успешно борется только тройная буферизация + vsync).
В этом разделе есть немало интересных опций, посмотрите, например можно выключить 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.
Самое главное, что я всегда замечаю — после наложения патчсета и тюнинга ядра уходят «подергивания» в играх. Чем слабее железо, тем заметнее эти подергивания, хотя у меня есть подозрения что это все же какая-то проблема в драйверах nVidia, потому что разные версии ведут себя по-разному.
Ради пруфов решил провести тесты с помощью Geekbench 3 из Steam и gputest, результаты которых немного странные:
3.14-pf:
Single-Core Score 2421
Multi-Core Score 8209
gputest: 3720 pts, 62 FPS
3.13-generic:
Single-Core Score 2646
Multi-Core Score 8414
gputest: 3713 pts, 61 FPS
Windows:
Single-Core Score 2572
Multi-Core Score 8242
gputest: 3634 pts, 60 FPS
Как видно, почему-то на «оптимизированный» вариант в тесте CPU набирает меньше попугаев, а в тесте GPU — больше. Только сейчас я заметил что тестировал разные ядра, возможно в этом и причина различий результатов. Как будет время, проведу эти же тесты на 3.16, надеюсь, удастся найти причину. Самое же веселое тут в том, что у Windows результаты хуже, особенно в 3D значительно.
В этой статье я хочу поделиться почти 10-летним опытом использования Linux на домашнем компьютере. За это время я провел много экспериментов над ядром, испробовал различные конфигурации для разных применений и теперь хочу все это систематизировать в длинный пост с рекомендациями как выжать из linux максимум и добиться отличной производительности, без необходимости покупать мощное железо.
Лично я считаю часть, где я написал про тюнинг ядра все же немного устарела и современное железо уже априори выдает необходимую производительность для нормальной работы, но, как мне удалось заметить недавно, с играми все равно, даже сейчас, есть проблемы, даже на мощном железе.
Хоть я и пообещал, что после прочтения этой статьи, можно будет играть в Metro 2033 на калькуляторе (шутка, такого не будет), все же она начнется с рекомендации купить кое-что из железа, если у вас этого еще нет.
1. Купите SSD, если у вас его еще нет
Почему-то многие люди скептически относятся к SSD, хотя это первый и важнейший компонент компьютера, который собирается быстро работать.
Серьезно, все что описано дальше в статье даст вам какой-то прирост в производительности и времени отклика, но любой, даже самый дешевый SSD, сократит время запуска большинства программ до 0, что, визуально, будет очень заметно. Почти в любом компьютере (и сервере) главный тормоз это всегда дисковая подсистема и никакой HDD никогда не даст вам нужной скорости поиска (которая у SSD стремится к 0 мс). За все время общения с компьютерами и их апгрейда, только переход на SSD дал значительный прирост в скорости работы и отклике. Помните как медленно работают дискеты, какое у них огромное время поиска? Примерно вот так воспринимается жесткий диск после SSD.
Так что если у вас еще нет SSD, то продолжать дальше смысла нет, ваш компьютер (хоть даже оснащенный 12-ядерным Xeon’ом) все равно будет работать медленно, так что вперед за покупками.
Касательно надежности: есть миф что SSD умирают спустя год. Его рождению мы обязаны первым SSD на бажных чипах SandForce. Естественно, любой новый SSD из магазина как минимум надежнее и долговечнее современных жестких дисков, так что не стоит беспокоиться по этому поводу вообще. Свой SSD я купил 2 года назад б/у, на то время он был в использовании год. Сейчас у него 11 681 часов наработки и использование ресурса 10%, так что при том же режиме использования, мне его хватит еще на 27 лет. Думаю, к этому времени технологии хранения данных уже несколько раз изменятся. Так что повторюсь, проблемы с надежностью более чем надуманы.
Более подробно о мифах SSD расписал товарищ Вадим Стеркин в своём блоге. Правда, блог у него о Windows, но сути это не меняет. Настоятельно советую почитать, очень интересно.
В Ubuntu 14.04 SSD работают из коробки, опция discard автоматом прописывается в fstab, кроме этого больше ничего не нужно делать.
2. Таблица разделов
Не делите диски на разделы.
Для домашнего компьютера это бессмысленно и вредно. На SSD у вас должен быть один раздел для корня, там у вас будет хранится система и все данные. На HDD (если нужен) у вас должен быть один раздел с точкой монтирования в /mnt (у меня /mnt/data), где будут хранится большие малоиспользуемые данные (фильмы, музыка, игры). НЕ НУЖНО делать HDD точкой монтирования /home, так как в /home 99% программ хранит свои данные и постоянно к ним обращается, поэтому /home должен быть на SSD.
Повторюсь кратко: на 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-систем.
Он состоит из:
- Патчсет -ck с BFS
- BFQ I/O scheduler
- TuxOnIce
- UKSM
Наиболее полезными являются патчи 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 < patch-3.12.4-pf
Это очень важный патчсет, именно он позволяет системе быть отзывчивой, даже в моменты большой нагрузки. В результате, например, даже при максимальной нагрузке, время запуска приложений остается таким же, как и при простое!
Вот, например, скриншот htop при работе Dota 2 + The Sims 3 (multiseat):
При такой нагрузке на третьем экране можно спокойно работать и 25% (в 5-минутном окне по данным load-average) перегрузка CPU даже не чувствуется. Хотя, конечно, проц надо менять :(
5. Тюнингуйте ядро!
В ядре по умолчанию используются не очень оптимальные параметры, обусловленные историческим предназначением linux для серверов и доступности для отладки.
Так что делайте make xconfig
Я расскажу о наиболее важных опциях для оптимизации
Выключаем preemption, устанавливаем низкую частоту таймера и выключаем dynticks!
ДА! Мы действительно, даже вопреки документации к BFS отключаем «жизненно важные» опции для повышения отзывчивости системы. А причина в том что они — устарели, толку от них никакого и к тому же preemption негативно влияет на производительность.
Было время, когда у меня был одноядерный процессор, тогда еще в готовых ядрах не включали preemption и высокочастотный таймер, вот тогда, после включения этих опций был огромный эффект. А именно, тяжеловесное приложение, занимающее 100% CPU, даже при наличии дискового ввода-вывода и нехватке ОЗУ никак не влияло на интерактивность и отзывчивость. В те времена, еще кроме WinXP ничего не было, а подробно рассказывать как ужасно себя ведет XP в таких ситуациях, думаю, не надо, она обычно намертво виснет, заставляя тянуться к кнопке reset. Так что иметь систему, которая почти никогда не тормозит и не зависает было приятно.
Но те времена прошли, многоядерные процессоры и огромные объемы памяти сами по себе решают проблемы отзывчивости под нагрузкой, так что дополнительно решать их программными средствами не только бесполезно, но и вредно.
Так что идем в 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. 100 все же будет маловато, да и смысла особого нет (читайте в описании почему), но вы можете поэкспериментировать. Также, 300 Гц нацело делится и на 25 и 30, что является типичными частотами для видео, это вносит свой вклад в борьбу с тирингом (это из хелпа. По факту, с тирингом успешно борется только тройная буферизация + vsync).
В этом разделе есть немало интересных опций, посмотрите, например можно выключить 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. Заключение
Самое главное, что я всегда замечаю — после наложения патчсета и тюнинга ядра уходят «подергивания» в играх. Чем слабее железо, тем заметнее эти подергивания, хотя у меня есть подозрения что это все же какая-то проблема в драйверах nVidia, потому что разные версии ведут себя по-разному.
Ради пруфов решил провести тесты с помощью Geekbench 3 из Steam и gputest, результаты которых немного странные:
3.14-pf:
Single-Core Score 2421
Multi-Core Score 8209
gputest: 3720 pts, 62 FPS
3.13-generic:
Single-Core Score 2646
Multi-Core Score 8414
gputest: 3713 pts, 61 FPS
Windows:
Single-Core Score 2572
Multi-Core Score 8242
gputest: 3634 pts, 60 FPS
Как видно, почему-то на «оптимизированный» вариант в тесте CPU набирает меньше попугаев, а в тесте GPU — больше. Только сейчас я заметил что тестировал разные ядра, возможно в этом и причина различий результатов. Как будет время, проведу эти же тесты на 3.16, надеюсь, удастся найти причину. Самое же веселое тут в том, что у Windows результаты хуже, особенно в 3D значительно.