Хотите поблагодарить автора блога - жмите здесь !
1 2 0
1 2 0

Нажмите на рекламный баннер выше, если хотите поблагодарить автора блога !
Написание каждой статьи заняло в сотни раз больше времени, чем один клик.

среда, июля 31, 2013

Android 4.0.4 ICS SWAP с kernel ThunderZap 1.1 - как мы с ним горшки побили

Итак, я обещал написать подробнее о работе со SWAP, впечатлениях, и как это сделать наименее болезненным.
На данный момент я уже под Android 4.1.1 от Cink King (нормально стала на Fly IQ450, обновляется прямо через WIFI, потребление в "спящем" режиме снизилось более чем вдвое, но о его установке будет отдельная заметка позже), а сейчас я опишу почему "дошел до жизни такой", и что в ядре ThunderZap 1.1 for Android ICS оказалось фатальным, и как этого избежать, если Вы всетаки решите его использовать, так как для ICS вроде бы и альтенативы ему нет. как "спасать" девайс, буде это ядро неожиданно превратило его в "кирпич", и как сделать чтобы не превратило.

Сначала о хорошем. Чтобы было меньше "тормозов" от введения свапа, особенно на медленной карточке flash, нужно всего навсего изменить пару параметров в sysctl. А именно, либо через system tuner (где его взять и как через него менять параметры в sysctl, я описывал ранее), либо через init.d (для тех кто знает что это такое :), нужно скорректировать два параметра:
vm.swappinness выставить в 30-40 макс, а вовсе не так как рекомендуют "в 100". Это уменьшит склонность ядра выгружать важные и часто используемые части системы. пытаясь освободить память, и соответственно снизит вероятность появления "тормозов". Это собсно касается любого Android устройства с включенным SWAP.
vm.vfs_cache_pressure - поставить процентов на 40.
После этого, "тормоза" будут появляться крайне редко.

Что реально дает SWAP в данном случае. В общем то не очень много. Дело в том, что в коммандной строке запуска ядра ThunderZap 1.1 прописано: console=ttyMT3,921600n1 root=/dev/ram vmalloc=280M. 
И этим по сути ограничен обьем памяти, который может использовать Андроидная Ява машина для приложений Android. И пофику, сколько у Вас памяти на самом деле, если прописана такая фигня. Больше указанного Android все равно не получит (подробнее можете посмотреть мои размышлизмы по этому поводу вот тут: http://vyacheslav.blogspot.com/2013/07/android-swap.html). Но всеже небольшой выиграш есть, незаметный правда сразу после загрузки устройства. Но если Android без перезагрузки работает долгое время, то спустя день-два, у него остается больше доступной памяти, чем без SWAP, за счет того, что небольшая часть памяти, теряемая из за "утечек памяти", или занимаемая, но реально не используемая драйверами и некоторыми системными приложениями Android, вытесняется в SWAP, вместо того, чтобы уменьшать реально доступное пространство RAM, для Java машины Android. Этот выиграш может достигать нескольких десятков мегабайт. В общем то не так и плохо.

А теперь - почему я отказался от этого ядра: 
Весьма нестабильно, особенно с включенным SWAP (я сильно подозреваю, что все "ужасы" включения SWAP в Android, которые я живописал ранее (http://vyacheslav.blogspot.com/2013/07/android-thunderzap-swap-vs-android-404.html) скорее связаны с самим ThunderZap 1.1 ICS как таковым, а не свапом в принципе).Периодически тело само уходит в перезагрузки - не часто, раз в день, иногда пару в зависимости от интенсивности использования (впрочем это и с родным 4.04 случалось)ю Иногда странные "тормоза". При загрузке аппарата, он иногда по 3-4 раза может сам "перезагружаться" пока наконец загрузится (чего с родным не было). Плюс иногда совершенно "неспровоцированные лаги". Но даже не это главное.
Во всех манах по этому ядру рекомендуют как значительно ускорить его работу и андроид в целом. А имно, сделать в init.d вот так:
echo "0" > /sys/class/misc/fsynccontrol/fsync_enabled
Ну я таки сделал. Все клянутся что "возникновение проблем совершенно маловероятно". Угу, но только не с ядром склонным иногда "перегружаться" самостоятельно.
Дело в том, что этот параметр, делает запись во флэш память асинхронной. незаписанный данные чуть дольше задерживаются в памяти, зато резко снижается интенсивность работы с самой карточкой при тех же потоках данных. И в самом деле лаги почти исчезли  , после того как я это сделал.
Но радость была не долгой. Дело в том, что в случае, если ядро таки "свиснет" или "уйдет в перезагруз", то данные в памяти, которые еще не записаны, пропадут. Вообщето, это теоретически не опасно, так как это касается только данных имно конкретных приложений, записанных в течение нескольких секунд до "перезагруза" или "виса".  Чем и обьясняют везде то что "этим можно клево и безопасно пользоваться". НО, есть одно маленькое "но" - система то и сама в фоне постоянно обновляет и некоторые свои файлы (например калибровки батареи, и не только). И вот если в момент когда она обновляла... А это может произойти в совершенно неподходящем месте, в совершенно неподходящее время... Тело может больше не включиться. У меня это произошло, когда "тело" свисло при установке нового приложения. И все. Телефон загружается (пробегает бар загрузки), и на этом останавливается, и висит-висит-висит. при этом можно подключиться через ADB. И в логе увидеть что то вот такого вида:
D/dalvikvm( 237): GC_CONCURRENT freed 820K, 13% free 12794K/14583K, paused 2ms+3ms
D/dalvikvm( 237): GC_CONCURRENT freed 819K, 13% free 12794K/14583K, paused 2ms+3ms
D/dalvikvm( 237): GC_CONCURRENT freed 820K, 13% free 12794K/14583K, paused 2ms+3ms
D/dalvikvm( 237): GC_CONCURRENT freed 819K, 13% free 12794K/14583K, paused 2ms+3ms
D/dalvikvm( 237): GC_CONCURRENT freed 819K, 13% free 12795K/14583K, paused 2ms+3ms
D/dalvikvm( 237): GC_CONCURRENT freed 819K, 13% free 12795K/14583K, paused 2ms+3ms
D/dalvikvm( 237): GC_CONCURRENT freed 821K, 13% free 12794K/14583K, paused 2ms+3ms

И это навечно. Согласитесь както не рулез, неожиданно, вдалеке от компа и всего чем можно "поднять" аппарат, получить вот такую "радость" с "самогреющимся кирпичем" (проц загружен на 100  процентов).
 Это стало "последней каплей" :)

Нет, поднять после такого аппарат можно. Вышеуказанное обычно возникает, в случае повреждения какого либо из системных файлов, обычно в каталоге /system. Если Вы регулярно делаете бэкапы, с помощью CWM recovery, то лечится это просто. Идете в cwm recovery, форматируете "system", потмо выбираете выборочное восстановление. и восстанавливаете "system" из бэкап. все - все снова заработает нормально. Ну или альтенатива - если комп под рукой и есть желание "на потрахаться", да вдобавок нет свежегоо бэкапа "system", - можно поискать какой файл поврежден и стереть его, либо заменить на файлик из бэкапа. Чаще всего это файлик калибровки батареи - система в него регулярно что нить вписывает, и соотв у него вероятность повреждения в таком случае много выше. Да и вдобавок если его  структура повреждена, Вы железно получите вышеописанный "вис". Его собсно можно просто вытереть, правда потом придется батарею по новой калибровать.

В общем, с ICS Android 4.0.4 это наверное мой последний пост, так как в итоге я перебрался на JB 4.1.1, бо кто как а я конечно не так чтобы терпеть ненавидел секс, но "что занадто то не здраво" :)

Комментариев нет:

Отправить комментарий

Закрыть окно X
Пожалуйста, потратьте несколько секунд на поддержку блога и его автора
Нажмите на рекламную ссылку: Рекламная ссылка для поддержки блога, или на баннер вверху справа страницы.