Очень медленная компиляция TWRP

vasek	# 6 лет, 3 месяца назад (отредактировано 6 лет, 3 месяца назад)
Темы: 47 Сообщения: 11743 Участник с: 17 февраля 2013	Раньше считал, что это все ерунда, но как то заинтересовало, что память стала уменьшаться, незначительная потеря производительности - грешил на утечку памяти. А когда начитался, то был удивлен тем, что память подвержена фрагментации (и проблема уменьшения памяти не обязательно в утечке памяти), а особенно удивило то, что в самом ядре заложен механизм дефрагментации памяти. Привожу цитату из одной статьи: Фрагментация памяти — нередкая проблема (и характерна не только для Linux), и в ядро регулярно вносятся изменения для борьбы с ней. Одним из виновников фрагментации является само ядро, точнее дисковый кеш, который нельзя ни отключить, ни ограничить в объёме. Это не значит, что фрагментация в нашем случае была вызвана именно дисковым кешем, но точные причины были не так важны. Важнее было решение — дефрагментация. Такой механизм есть в ядре, но очевидно, что он не справлялся (либо вместо него запускалось высвобождение памяти — global reclaim). Дефрагментация запускается только тогда, когда свободная память опускается ниже определённой отметки (zone watermark), и в нашем случае это происходило слишком поздно. Единственный способ заставить её запускаться раньше — это повысить min_free_kbytes через sysctl. Данный параметр говорит ядру стараться держать часть памяти свободной, а чтобы удовлетворить это требование, ему приходится запускать дефрагментацию раньше. Посмотреть кол-во свободных страниц/блоков определенного уровня в разных зонах можно в /proc/buddyinfo - и, как пишут, отсутствие свободных областей большого размера - это и есть признак наличия фрагментации. UPD - пояснение к файлу /proc/buddyinfo Этот файл используется в основном для диагностики проблем фрагментации памяти. Используя алгоритм buddy, каждый столбец представляет количество страниц определенного порядка (определенного размера), доступных в любой момент времени - размеры по столбцам, начиная с 1-го, определяется как степень 2 - (2 ^0) * PAGE_SIZE фрагментов памяти, (2 ^1) * PAGE_SIZE и т.д. EDIT 1 - с параметром min_free_kbytes не игрался, не представился хороший случай, по дефолту он равен - vm.min_free_kbytes = 67584 Ошибки не исчезают с опытом - они просто умнеют

# 6 лет, 3 месяца назад (отредактировано 6 лет, 3 месяца назад)

Сообщения: 11743

Участник с: 17 февраля 2013

Раньше считал, что это все ерунда, но как то заинтересовало, что память стала уменьшаться, незначительная потеря производительности - грешил на утечку памяти. А когда начитался, то был удивлен тем, что память подвержена фрагментации (и проблема уменьшения памяти не обязательно в утечке памяти), а особенно удивило то, что в самом ядре заложен механизм дефрагментации памяти. Привожу цитату из одной статьи:

Фрагментация памяти — нередкая проблема (и характерна не только для Linux), и в ядро регулярно вносятся изменения для борьбы с ней. Одним из виновников фрагментации является само ядро, точнее дисковый кеш, который нельзя ни отключить, ни ограничить в объёме. Это не значит, что фрагментация в нашем случае была вызвана именно дисковым кешем, но точные причины были не так важны. Важнее было решение — дефрагментация. Такой механизм есть в ядре, но очевидно, что он не справлялся (либо вместо него запускалось высвобождение памяти — global reclaim). Дефрагментация запускается только тогда, когда свободная память опускается ниже определённой отметки (zone watermark), и в нашем случае это происходило слишком поздно. Единственный способ заставить её запускаться раньше — это повысить min_free_kbytes через sysctl. Данный параметр говорит ядру стараться держать часть памяти свободной, а чтобы удовлетворить это требование, ему приходится запускать дефрагментацию раньше.

Посмотреть кол-во свободных страниц/блоков определенного уровня в разных зонах можно в /proc/buddyinfo - и, как пишут, отсутствие свободных областей большого размера - это и есть признак наличия фрагментации.
UPD - пояснение к файлу /proc/buddyinfo
Этот файл используется в основном для диагностики проблем фрагментации памяти. Используя алгоритм buddy, каждый столбец представляет количество страниц определенного порядка (определенного размера), доступных в любой момент времени - размеры по столбцам, начиная с 1-го, определяется как степень 2 - (2 ^0) * PAGE_SIZE фрагментов памяти, (2 ^1) * PAGE_SIZE и т.д.

EDIT 1 - с параметром min_free_kbytes не игрался, не представился хороший случай, по дефолту он равен - vm.min_free_kbytes = 67584

Ошибки не исчезают с опытом - они просто умнеют

gentux	# 6 лет, 3 месяца назад
Темы: 3 Сообщения: 119 Участник с: 15 января 2015	vasek /proc/buddyinfo Интересненько. вывод в удобном виде

Aivar	# 6 лет, 3 месяца назад
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011	А если просто очистить кеш: `# sync; echo 3 > /proc/sys/vm/drop_caches` ?

vasek	# 6 лет, 3 месяца назад (отредактировано 6 лет, 3 месяца назад)
Темы: 47 Сообщения: 11743 Участник с: 17 февраля 2013	Aivar А если просто очистить кеш: `# sync; echo 3 > /proc/sys/vm/drop_caches` ? По идее это должно помочь и я обычно это частенько использую после закрытия тяжелых приложений. В подтверждение привожу ссылку из той же статьи .....При очередном росте нагрузки perf top показал 50% нагрузки на isolate_freepages_block. Само по себе название вызова нам, к сожалению, ничего не говорит. Но вот слово freepages несколько смутило, т.к. свободной памяти на сервере было около 45 Гбайт. Из своего опыта мы уже знали, что если на сервере много свободной памяти, а ядро всё равно жалуется на его нехватку (иногда это выражается в запуске OOM killer), то, скорее всего, проблема во фрагментации. Сброс дискового кеша (echo 3 > /proc/sys/vm/drop_caches) моментально исцелял сервер, что только подтверждало наши предположения.... Но лично у меня есть сомнения, что это поможет во всех случаях - это очистит только дисковый кеш - а вот достаточно ли этого? - тут я не совсем понимаю. EDIT 1 - должно помогать в любом случае - дисковый кэш же размещается в зонах DMA32 и Normal. Или я не прав? Ошибки не исчезают с опытом - они просто умнеют

vasek

# 6 лет, 3 месяца назад (отредактировано 6 лет, 3 месяца назад)

Темы: 47

Сообщения: 11743

Участник с: 17 февраля 2013

Aivar
А если просто очистить кеш:
# sync; echo 3 > /proc/sys/vm/drop_caches
?

По идее это должно помочь и я обычно это частенько использую после закрытия тяжелых приложений. В подтверждение привожу ссылку из той же статьи

.....При очередном росте нагрузки perf top показал 50% нагрузки на isolate_freepages_block. Само по себе название вызова нам, к сожалению, ничего не говорит. Но вот слово freepages несколько смутило, т.к. свободной памяти на сервере было около 45 Гбайт. Из своего опыта мы уже знали, что если на сервере много свободной памяти, а ядро всё равно жалуется на его нехватку (иногда это выражается в запуске OOM killer), то, скорее всего, проблема во фрагментации. Сброс дискового кеша (echo 3 > /proc/sys/vm/drop_caches) моментально исцелял сервер, что только подтверждало наши предположения....

Но лично у меня есть сомнения, что это поможет во всех случаях - это очистит только дисковый кеш - а вот достаточно ли этого? - тут я не совсем понимаю.
EDIT 1 - должно помогать в любом случае - дисковый кэш же размещается в зонах DMA32 и Normal. Или я не прав?

Ошибки не исчезают с опытом - они просто умнеют