Bug 27786 - OOM в installer
: OOM в installer
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/alterator-livecd)
: unstable
: x86 Linux
: P3 normal
Assigned To:
:
:
: usability
:
: 27407 27685
  Show dependency tree
 
Reported: 2012-10-01 18:17 by
Modified: 2013-01-11 18:10 (History)


Attachments
патч с плавным progress bar (2.74 KB, patch)
2012-12-24 19:31, vx8400
no flags Details | Diff
патч с плавным progress bar (2.81 KB, patch)
2012-12-24 19:36, vx8400
no flags Details | Diff
> ... усложнение рантайма с адаптивной оценкой расхождения (4.46 KB, patch)
2012-12-26 15:53, vx8400
no flags Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-10-01 18:17:44
+++ Данная ошибка создана размножением ошибки 27407 +++

Created an attachment (id=5477) [details]
oom в dmesg

При установке Simply Linux 6.0.1 c образа
altlinux-6.0.1-simply-i586-ru-live-cd.iso
на машину с 248M RAM установщик ловит OOM на шаге "установка пакетов" (после
разметки диска), переходит к установке загрузчика и завершается без сообщений
об ошибках. Вывод dmesg прилагается.

swap-раздел размером 218M был создан при автоматической разметке диска. Ошибки
нет, если при RAM = 248M назначить руками swap = 512M.

Так как дистрибутив хорошо работает при RAM=128--256M, желательно делать
бОльший swap при автоматической разбивке и предупреждать при ручной разбивке,
что swap-раздела < 512M не хватает.
------- Comment #1 From 2012-10-01 18:22:28 -------
Мне на беглый взгляд не очень нравится патч, предложенный в #27407. Я бы не
стал его прикладывать как есть.
------- Comment #2 From 2012-10-01 18:48:06 -------
(В ответ на комментарий №1)
> Мне на беглый взгляд не очень нравится патч, предложенный в #27407. Я бы не
> стал его прикладывать как есть.

Это proof of concept. Напускать unsquashfs на уже смонтированный в /.ro образ
избыточно и кушает память.
------- Comment #3 From 2012-10-02 11:20:09 -------
(In reply to comment #1)
> Мне на беглый взгляд не очень нравится патч, предложенный в #27407.
А чем?
------- Comment #4 From 2012-12-08 19:32:16 -------
2sem: в преддверии регулярной публикации образов pre-p7 эта бага становится
актуальной. Есть идеи?
------- Comment #5 From 2012-12-24 13:16:25 -------
(В ответ на комментарий №4)
> 2sem: в преддверии регулярной публикации образов pre-p7 эта бага становится
> актуальной. Есть идеи?

2mike, boyarsh, sem: ping
Мы собираем в том числе легкие live-образы, которые работают на <=256Mb, а
установить их из Live не можем. Не уверен, что нужно обязательно предупреждать
при ручной разбивке, достаточно замечания в подсказке. Но вот почему бы не
увеличить swap?
------- Comment #6 From 2012-12-24 14:30:20 -------
Да, я в конце прошлой недели помнил эту багу, работая над livecd-install.

Делать ещё раз unsquashfs действительно кажется избыточным; мало того, на
весьма быстрых CPU при 512M RAM в виртуальной машине нагрузка на процессор при
разливке составляет что-то около 20%, т.е. образ заливается в несколько раз
дольше, чем мог бы (при этом ISO лежит на довольно быстром диске, а sda -- на
tmpfs; судя по "лампочкам", в них совсем не упираемся).

Но нужно не потерять работоспособность progress bar.
------- Comment #7 From 2012-12-24 19:31:57 -------
Created an attachment (id=5681) [details]
патч с плавным progress bar

(В ответ на комментарий №6)
> Но нужно не потерять работоспособность progress bar.

Пример в патче.
------- Comment #8 From 2012-12-24 19:36:26 -------
Created an attachment (id=5682) [details]
патч с плавным progress bar
------- Comment #9 From 2012-12-25 13:14:42 -------
Ночью промахнулся, bug 27407 comment 10 лучше было сюда.

vx8400@ предложил адаптивный алгоритм расчёта процента выполнения с внесением
поправки "на лету", но если ориентироваться на размер, а не иноды --
оптимальнее выглядит его же вчерашнее предложение выполнить оценку размера
тарбола с live-системой заранее при сборке stage2, когда у нас заведомо
достаточно мощностей и памяти, да и кэш горячий; а трогать лишний раз болванку
или флэшку всё-таки накладно.

Подумаю над этим и постараюсь сделать ещё один подход после более неприятных
блокеров bug #27685.

PS: потребление памяти при установке regular-icewm (i586) было около 93M.
------- Comment #10 From 2012-12-25 13:17:33 -------
(В ответ на комментарий №9)
> PS: потребление памяти при установке regular-icewm (i586) было около 93M.

Поясните: при установке с каким-либо из обсуждавшихся тут изменений в
установщике live?
------- Comment #11 From 2012-12-25 13:19:26 -------
(In reply to comment #10)
> > PS: потребление памяти при установке regular-icewm (i586) было около 93M.
> Поясните: при установке с каким-либо из обсуждавшихся тут изменений в
> установщике live?
Именно.  Варианты с tar и cp особо не отличались.  Своп не задействовался вовсе
(VM с 512M RAM, на 256M формально проверить не успевал, но по free и так было
понятно, что должно влезть).
------- Comment #12 From 2012-12-25 13:21:55 -------
(В ответ на комментарий №11)
> (In reply to comment #10)
> > > PS: потребление памяти при установке regular-icewm (i586) было около 93M.
> > Поясните: при установке с каким-либо из обсуждавшихся тут изменений в
> > установщике live?
> Именно.  Варианты с tar и cp особо не отличались.  Своп не задействовался вовсе
> (VM с 512M RAM, на 256M формально проверить не успевал, но по free и так было
> понятно, что должно влезть).

Тогда, если не будет возражений sem@, нужно собирать с этим изменением, пусть
пользователи тестируют.
------- Comment #13 From 2012-12-25 13:26:28 -------
Оно ещё не готово, т.е. как минимум 205% можно получить запросто. :)
------- Comment #14 From 2012-12-26 02:03:29 -------
(В ответ на комментарий №13)
> Оно ещё не готово, т.е. как минимум 205% можно получить запросто. :)

Это шашечки. Пусть они и важны, но надо бы начать проверять как оно едет.
Впрочем, снизить до 140% было бы неплохо.
------- Comment #15 From 2012-12-26 13:34:22 -------
До 102% в случае regular-icewm снизили, а вот дальше -- или усложнение рантайма
с адаптивной оценкой расхождения (уже разработанное и предложенное vx8400@),
или подготовка точного размера заранее, или мухлёж типа реализованного в
текущем варианте:
http://git.altlinux.org/gears/a/alterator-livecd.git?p=alterator-livecd.git;a=blob;f=alterator-livecd/backend3/livecd-install;h=d93ce39b65d369740afcab712a31d97e32087360;hb=HEAD#l133
------- Comment #16 From 2012-12-26 15:07:14 -------
(В ответ на комментарий №15)
> До 102% в случае regular-icewm снизили, а вот дальше -- или усложнение рантайма
> с адаптивной оценкой расхождения (уже разработанное и предложенное vx8400@),
> или подготовка точного размера заранее, или мухлёж типа реализованного в
> текущем варианте:
> http://git.altlinux.org/gears/a/alterator-livecd.git?p=alterator-livecd.git;a=blob;f=alterator-livecd/backend3/livecd-install;h=d93ce39b65d369740afcab712a31d97e32087360;hb=HEAD#l133

Небольшой мухлеж допустим. :-)
------- Comment #17 From 2012-12-26 15:53:42 -------
Created an attachment (id=5686) [details]
> ... усложнение рантайма с адаптивной оценкой расхождения

(В ответ на комментарий №16)
>  усложнение рантайма с адаптивной оценкой расхождения:
------- Comment #18 From 2012-12-26 16:39:54 -------
А есть смысл сохранять старый вариант с unsquashfs? Я бы его выкинул совсем и
рассчитывал на то, что у нас всегда смонтирован образ в /.ro.

> > Оно ещё не готово, т.е. как минимум 205% можно получить запросто. :)
> 
> Это шашечки. Пусть они и важны, но надо бы начать проверять как оно едет.
> Впрочем, снизить до 140% было бы неплохо.

Вся сложность тут как раз в правильном прогресс-баре, тестировать просто
копирование файлов я не вижу особого смысла.
------- Comment #19 From 2012-12-28 13:35:26 -------
Последний вариант патча похоже не рабочий. Да и вообще построить соответствие
между количеством записей в tar и реальным размером не так просто. Я склонюсь к
мысли сделать простой вариант, отталкиваясь от количества файлов, а не их
размера. Это будет не слишком плавный прогресс-бар, но общий прогресс
выполнения работы вполне покажет.
Впрочем, поиграюсь еще с rsync, может получится взять размер файлов из его
вывода.
------- Comment #20 From 2012-12-28 15:10:10 -------
(In reply to comment #19)
> Я склонюсь к мысли сделать простой вариант, отталкиваясь от количества файлов,
> а не их размера. Это будет не слишком плавный прогресс-бар, но общий прогресс
> выполнения работы вполне покажет.
Такая реализация в виде грязного наброска уже есть, но "в лоб" разъезд
получился вида 140% вместо 102% (дело было ночером и уже внимания не хватило
вникать, возможно, это были хардлинки -- оценка по du -i, счёт по выводу cp
-av).

> Впрочем, поиграюсь еще с rsync, может получится взять размер файлов из его
> вывода.
Не трать зря время -- в свежайшем rsync вроде бы как что-то сделали, но
ресурсоёмкое на начальном этапе; в сизифном мане соответствующие опции
упоминаются, но бинарник отнекивается.  См. тж.
http://serverfault.com/questions/219013/showing-total-progress-in-rsync-is-it-possible

IMHO пока наиболее практичным выглядит вариант с выполнением строгой оценки при
сборке и счёта по тому же показателю -- сейчас под руками тоже грязный вариант
с tar, тестирования живьём он ещё не проходил (т.к. пока квант времени на эту
багу закончился в пользу выкатывания стопки образов).

Если хочешь, могу наброски попытаться выделить и прицепить -- просто этот
вариант удобнее всего проверять в комплекте с дополненным ещё одним хуком
профилем.
------- Comment #21 From 2012-12-28 15:38:29 -------
(В ответ на комментарий №19)
> Последний вариант патча похоже не рабочий. 

works for me.

Что не работает?
------- Comment #22 From 2012-12-28 19:24:09 -------
(В ответ на комментарий №20)
> (In reply to comment #19)
> > Я склонюсь к мысли сделать простой вариант, отталкиваясь от количества файлов,
> Такая реализация в виде грязного наброска уже есть, но "в лоб" разъезд
> получился вида 140% вместо 102% (дело было ночером и уже внимания не хватило
> вникать, возможно, это были хардлинки -- оценка по du -i, счёт по выводу cp
> -av).

И все-таки мне кажется это самым простым вариантом.

> > Впрочем, поиграюсь еще с rsync, может получится взять размер файлов из его
> > вывода.
> Не трать зря время -- в свежайшем rsync вроде бы как что-то сделали, но
> ресурсоёмкое на начальном этапе; в сизифном мане соответствующие опции
> упоминаются, но бинарник отнекивается.  См. тж.
> http://serverfault.com/questions/219013/showing-total-progress-in-rsync-is-it-possible

Да, я знаю. Похоже апстрим слишком рано обновил man page. Но может удастся
обойтись и тем что есть.

> IMHO пока наиболее практичным выглядит вариант с выполнением строгой оценки при
> сборке и счёта по тому же показателю -- сейчас под руками тоже грязный вариант
> с tar, тестирования живьём он ещё не проходил (т.к. пока квант времени на эту
> багу закончился в пользу выкатывания стопки образов).

Мне кажется это совершенно излишним усложнением. Большой точности не надо, надо
просто что-то показать пользователю, чтобы ему было не слишком скучно смотреть
на картинку.

(В ответ на комментарий №21)
> > Последний вариант патча похоже не рабочий. 
> works for me.
> Что не работает?

У меня в тестовом скрипте на базе этого патча прогресс начинался сразу с 80+ и
быстро доходил до 100 задолго до конца работы.
Вообще checkpoints никакого отношения к размеру не имеют, если я правильно
понял документацию.
------- Comment #23 From 2012-12-28 20:54:49 -------
(В ответ на комментарий №22)
> У меня в тестовом скрипте на базе этого патча прогресс начинался сразу с 80+ и
> быстро доходил до 100 задолго до конца работы.

Как это воспроизвести? С 80% может начинаться при размере самой большой
директории <~100 блоков.

> Вообще checkpoints никакого отношения к размеру не имеют, если я правильно
> понял документацию.

--сheckpoint=X выводит число записанных блоков через каждые X записанных
блоков.
------- Comment #24 From 2013-01-09 21:17:32 -------
> > У меня в тестовом скрипте на базе этого патча прогресс начинался сразу с 80+ и
> > быстро доходил до 100 задолго до конца работы.
> 
> Как это воспроизвести? С 80% может начинаться при размере самой большой
> директории <~100 блоков.

Не знаю, я просто копировал код из патча в тестовый скрипт. Но может где и
ошибся.
В любом случае предложенный вариант выглядит слишком усложненным и не надежным.
У меня в гите есть простой вариант, где progress bar может и не такой плавный,
но для данной задачи должно хватить.
Тестировал только тестовым скриптом, в самом alterator-livecd еще не проверял.

http://git.altlinux.org/people/sem/packages/?p=alterator-livecd.git;a=commit;h=33a273035ae6fd0ea21f257c6a5dde596726ccef
------- Comment #25 From 2013-01-11 18:10:12 -------
alterator-livecd-0.8.0-alt1 -> sisyphus:

* Thu Jan 10 2013 Mikhail Efremov <sem@altlinux> 0.8.0-alt1
- Don't use unsquashfs, just copy files (closes: #27786).