Pull to refresh

Оптимизация и ускорение N900

Reading time 4 min
Views 11K
Наверное все, кто активно пользуется N900, сталкивались с ситуациями, когда система начинала подтормаживать при копировании по сети больших файлов на большой скорости, или когда после недели активного пользования, начинало быть заметным общее подтормаживание системы и выявить виновника через top/htop не удавалось, приходилось спасаться перезагрузкой. Это конечно не проблема, но как факт очень неприятен — не Linux-way как-бы.

Но, как оказалось, это решаемо. Ещё со времен N8хх народ активно экспериментировал с различными настройками ядра Linux, которые позволят избавиться от подобных вещей на мобильных девайсах, и настройки эти, будучи эмпирически выведенными и проверенными, и вправду очень благополучно сказываются на поведении системы. Благополучно настолько, что система продолжает быть весьма отзывчивой даже при захлебывающимся от радости торрент-клиенте Transmission, принимающим файлы на полной скорости, и после недельного аптайма система продолжает работать плавно и даже при 30 открытых окнах браузера переключение тасков происходит также как и при двух (чего нельзя было наблюдать до нижеописанного способа оптимизации системы). А теперь к делу.

Кому лень читать и разбираться — ставите из репозиториев(сейчас в extras-testing) программу Swappolube («смазка для свопа», если буквально), запускаете и радуетесь жизни. Кому не лень — делаете тоже самое и продолжаете читать. :)



Программа эта — всего лишь GUI для изменения параметров ядра с возможностью его перманентного сохранения. Есть и не-GUI версия — swappolube-nogui. Программа эта не меняет никаких системных файлов, ничего не перезаписывает — только передает необходимые параметры ядру через /proc и создает, по желанию, файл в /etc/event.d, который будет применять эти настройки при каждой загрузке. В любой момент изменения можно откатить либо через GUI, либо убив этот файл и перезагрузив систему — но это врядли понадобится, уж слишком много пользователей N900 уже ее поставили и не устают писать на форумах отзывы со словами smooth, speed increase и brilliant.

Итак, что же это за параметры:
echo "30" > /proc/sys/vm/swappiness
echo "0" > /proc/sys/vm/page-cluster
echo "1" > /proc/sys/vm/laptop_mode
echo "1" > /proc/sys/vm/oom_kill_allocating_task
echo "0" > /proc/sys/vm/dirty_expire_centisecs
echo "0" > /proc/sys/vm/dirty_writeback_centisecs
echo "60" > /proc/sys/vm/dirty_background_ratio
echo "95" > /proc/sys/vm/dirty_ratio
echo "0" > /proc/sys/net/ipv4/tcp_timestamps
echo "1" > /proc/sys/net/ipv4/tcp_no_metrics_save


Первый, swappiness, по-умолчанию на Maemo установлен в 100 — это значит, что система будет пытаться сбрасывать память в своп как можно чаще и больше. Тут мы меняем его на 30 (это проценты) — что позволяет уменьшить количество обращений к диску(точнее к eMMC-флешке, на которой размещен своп), причем заметно. Возможно есть сценарии, при которых это будет не самое оптимальное решение, но в подавляющем большинстве это как раз то, что приводило к заметным подтормаживаниям при активной работе с N900.

Далее, page-cluster — эта опция контролирует количество страниц памяти, которые будут записываться в своп за один раз. Значение «0» означает 1 страницу, «1» — 2 страницы, 2 — 4 страницы и т.д. по экспоненте. По умолчанию в Maemo установлено значение «5» (32 страницы). Возможно на десктоп системах это значение лучше повышать, но на мобильном девайсе один такой цикл записи уже даёт более заметное замедление отзывчивости, а при swappines=100 проявляется во всей красоте. Ставим «1» — пусть в своп пишется дольше, но незаметно для пользователя и без влияния на отзывчивость UI.

Третий параметр, laptop_mode — если установлен не в «0», то активирует отложенную запись на диск. Причем активирует достаточно хитро, пытаясь выделять так называемые «периоды активности» системы, чтобы использовать обращения к диску максимально эффективно. Грубо говоря — если у нас есть страницы памяти, ожидающие сброса на диск(своп или «грязные» — ещё не синхронизированные буферы диска), не начинать операцию записи, пока не будет обращения к диску — это позволяет как-бы «сгруппировать» операции записи на диск, уменьшая количество обращений к диску, увеличивая срок жизни флеш-памяти и уменьшая электропотребление(насколько заметно не знаю, но сам факт).
С этим параметром неразрывно связаны еще четыре:
dirty_expire_centisecs, dirty_writeback_centisecs — это отдельные параметрs для отложенного сброса «грязных» буферов. В laptop_mode установлены в 0 — за откладывание теперь заботится laptop_mode (по-умолчанию, установлены в 500 сантисекунд)
dirty_background_ratio, dirty_ratio — минимальное и максимальное количество памяти(в процентах от общей памяти), которое может отводиться для хранения «грязных» буферов. Эти параметры для меня остаются слегка темным пятном, но поверю на слово maemo-сообществу. По умолчанию установлены в 10 и 40, мы же ставим 60 и 95.

Дальше, oom_kill_allocating_task — меняет поведение «убийцы процессов» — OOM-киллера. Обычно при нехватке памяти(у меня никогда на N900 еще не случалось, правда) он убивает процессы которые сидят в фоне и едят память — и это может быть в принципе любой процесс. Данная же опция заставляет его убивать именно тот процесс, который пытается сейчас получить память и получает ошибку out-of-memory. Звучит здраво, но видимо на общую работоспособность системы не очень влияет, только на критические состояния.

И последние две опции, относятся к TCP/IP стеку:
tcp_timestamps — позволяет отключить добавление временных меток в TCP-пакеты. Как-бы экономит и процессор и место — всмысле в один пакет больше влезет. Насколько реально помогает, не знаю. На безопасность вроде не влияет.
tcp_no_metrics_save — говорит стеку, не кешировать последние соединения. Может быть полезно для 2G/3G сетей.

Вкратце вот как-то так.
В целом резюме такое — раньше можно было спокойно судить о степени загруженности системы по скорости анимации и реакции UI, теперь же система ведет себя одинаково плавно при практически любой нагрузке.
Tags:
Hubs:
+24
Comments 14
Comments Comments 14

Articles