Bug 27786 - OOM в installer
Summary: OOM в installer
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: alterator-livecd (show other bugs)
Version: unstable
Hardware: x86 Linux
: P3 normal
Assignee: Michael Shigorin
QA Contact: qa-sisyphus
URL:
Keywords: usability
Depends on:
Blocks: 27685 27407
  Show dependency tree
 
Reported: 2012-10-01 18:17 MSK by Mikhail Efremov
Modified: 2013-01-11 18:10 MSK (History)
9 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Efremov 2012-10-01 18:17:44 MSK
+++ Данная ошибка создана размножением ошибки 27407 +++

Created an attachment (id=5477)
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 Mikhail Efremov 2012-10-01 18:22:28 MSK
Мне на беглый взгляд не очень нравится патч, предложенный в #27407. Я бы не стал его прикладывать как есть.
Comment 2 vx8400 2012-10-01 18:48:06 MSK
(В ответ на комментарий №1)
> Мне на беглый взгляд не очень нравится патч, предложенный в #27407. Я бы не
> стал его прикладывать как есть.

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

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

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

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

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

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

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

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

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

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

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

Это шашечки. Пусть они и важны, но надо бы начать проверять как оно едет.
Впрочем, снизить до 140% было бы неплохо.
Comment 15 Michael Shigorin 2012-12-26 13:34:22 MSK
До 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 AEN 2012-12-26 15:07:14 MSK
(В ответ на комментарий №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 vx8400 2012-12-26 15:53:42 MSK
Created attachment 5686 [details]
> ... усложнение рантайма с адаптивной оценкой расхождения

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

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

Вся сложность тут как раз в правильном прогресс-баре, тестировать просто копирование файлов я не вижу особого смысла.
Comment 19 Mikhail Efremov 2012-12-28 13:35:26 MSK
Последний вариант патча похоже не рабочий. Да и вообще построить соответствие между количеством записей в tar и реальным размером не так просто. Я склонюсь к мысли сделать простой вариант, отталкиваясь от количества файлов, а не их размера. Это будет не слишком плавный прогресс-бар, но общий прогресс выполнения работы вполне покажет.
Впрочем, поиграюсь еще с rsync, может получится взять размер файлов из его вывода.
Comment 20 Michael Shigorin 2012-12-28 15:10:10 MSK
(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 vx8400 2012-12-28 15:38:29 MSK
(В ответ на комментарий №19)
> Последний вариант патча похоже не рабочий. 

works for me.

Что не работает?
Comment 22 Mikhail Efremov 2012-12-28 19:24:09 MSK
(В ответ на комментарий №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 vx8400 2012-12-28 20:54:49 MSK
(В ответ на комментарий №22)
> У меня в тестовом скрипте на базе этого патча прогресс начинался сразу с 80+ и
> быстро доходил до 100 задолго до конца работы.

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

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

--сheckpoint=X выводит число записанных блоков через каждые X записанных блоков.
Comment 24 Mikhail Efremov 2013-01-09 21:17:32 MSK
> > У меня в тестовом скрипте на базе этого патча прогресс начинался сразу с 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 Repository Robot 2013-01-11 18:10:12 MSK
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).