Re: [devel] Time limit

Re: [devel] Time limit

[Dmitry V. Levin]

On Thu, Feb 18, 2021 at 01:34:24AM +0300, Aleksey Novodvorsky wrote:
> Коллеги,
> у нас периодически возникает проблема time limit при сборке заданий. Хуже
> то, что она часто возникает спонтанно. Прошу тех, кто с этим сталкивался,
> рассказать о произошедшем и возможном решении проблемы.

Если коротко, то man hasher-priv(8).

hasher с незапамятных времён реализует 2 временных ограничения:
- wlimit_time_elapsed: общее время сборки (в сборочнице сейчас 8 часов),
  предназначено для защиты от зацикливания сборки;
- wlimit_time_idle: максимальная длительность временного интервала,
  в течение которого сборка ничего не выводит (в сборочнице сейчас 1 час),
  предназначено для защиты от зависания сборки (судя по результатам
  тестовых пересборок, зависания происходят ежедневно).

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


-- 
ldv

Re: [devel] Time limit

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2666 bytes --]

On Thu, 18 Feb 2021 01:58:25 +0300 Aleksey Novodvorsky wrote:
> чт, 18 февр. 2021 г., 01:52 Dmitry V. Levin <ldv@altlinux.org>:
> 
> > On Thu, Feb 18, 2021 at 01:34:24AM +0300, Aleksey Novodvorsky wrote:
> > > Коллеги,
> > > у нас периодически возникает проблема time limit при сборке заданий. Хуже
> > > то, что она часто возникает спонтанно. Прошу тех, кто с этим сталкивался,
> > > рассказать о произошедшем и возможном решении проблемы.
> >
> > Если коротко, то man hasher-priv(8).
> >
> > hasher с незапамятных времён реализует 2 временных ограничения:
> > - wlimit_time_elapsed: общее время сборки (в сборочнице сейчас 8 часов),
> >   предназначено для защиты от зацикливания сборки;
> >
> 
> Это, видимо, случай viy@
> 
> > - wlimit_time_idle: максимальная длительность временного интервала,
> >   в течение которого сборка ничего не выводит (в сборочнице сейчас 1 час),
> >   предназначено для защиты от зависания сборки (судя по результатам
> >   тестовых пересборок, зависания происходят ежедневно).
> >
> 
> А это случай cas@.
> Можно список таких пакетов?
> В случае отдельных сборок firefox я такого не встречал.
> 
> >
> > Пробивание этих лимитов, как правило, свидетельствует о проблемах в
> > соответствующих пакетах
> 
> 
> Не в тулчейне?
> 
> > , и решать такие проблемы приходится мантейнерам
> > этих пакетов наряду с другими мантейнерскими задачами.
> >
> 
> Снизить оптимизацию? Включить отладку?

Снижение оптимизации — это ухудшение качества пакета и UX. Если
сборочница не справляется с возросшей сложностью пакетов
и тулчейна, следует увеличить лимиты или добавить аппаратные
ресурсы.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Time limit

[Alexey Gladkov]

On Thu, Feb 18, 2021 at 01:34:24AM +0300, Aleksey Novodvorsky wrote:
> Коллеги,
> у нас периодически возникает проблема time limit при сборке заданий. Хуже
> то, что она часто возникает спонтанно. Прошу тех, кто с этим сталкивался,
> рассказать о произошедшем и возможном решении проблемы.

Я с этой проблемой живу уже очень давно. Такая проблема возникала у меня с
chromium. В качестве решения было выбрано такое число параллельных потоков
при cборки, чтобы с одной стороны уложиться в time limit, c другой стороны
не пробить лимиты по памяти.

С chromium эта проблема проявляется при пересборке почти на 100%. Я уже
давно просто игнорирую результаты пересборки этого пакета.

http://git.altlinux.org/beehive/logs/Sisyphus-x86_64/archive/2021/0208/error/chromium-88.0.4324.150-alt1.zst

Раньше такая же проблема была с firefox, но после его рефакторинга в
апстриме этой проблемы больше не наблюдается.

-- 
Rgrds, legion

Re: [devel] Time limit

[Alexey Gladkov]

On Thu, Feb 18, 2021 at 02:01:50AM +0300, Aleksey Novodvorsky wrote:
> чт, 18 февр. 2021 г., 01:55 Alexey Gladkov <legion@altlinux.ru>:
> 
> > On Thu, Feb 18, 2021 at 01:34:24AM +0300, Aleksey Novodvorsky wrote:
> > > Коллеги,
> > > у нас периодически возникает проблема time limit при сборке заданий. Хуже
> > > то, что она часто возникает спонтанно. Прошу тех, кто с этим сталкивался,
> > > рассказать о произошедшем и возможном решении проблемы.
> >
> > Я с этой проблемой живу уже очень давно. Такая проблема возникала у меня с
> > chromium. В качестве решения было выбрано такое число параллельных потоков
> > при cборки, чтобы с одной стороны уложиться в time limit, c другой стороны
> > не пробить лимиты по памяти.
> >
> 
> Спасибо.
> 
> >
> > С chromium эта проблема проявляется при пересборке почти на 100%. Я уже
> > давно просто игнорирую результаты пересборки этого пакета.
> >
> >
> > http://git.altlinux.org/beehive/logs/Sisyphus-x86_64/archive/2021/0208/error/chromium-88.0.4324.150-alt1.zst
> >
> > Раньше такая же проблема была с firefox, но после его рефакторинга в
> > апстриме этой проблемы больше не наблюдается.
> >
> 
> Вот именно в нём и возникла, причем спонтанно возникающая. 264611
> И только на aarch64.

Интересно. C этой архитектурой у меня проблем не было. У меня часто были
проблемы с 32-х битными архитектурами.

Уверен, мантейнер увлекательно проведёт время с этой интересной задачкой.
Ну или в лоб уменьшит значение MOZ_MAKE_FLAGS="-j6" :))

-- 
Rgrds, legion

Re: [devel] Time limit

[Sergey Afonin]

On Thursday 18 February 2021, Aleksey Novodvorsky wrote:

> Вот именно в нём и возникла, причем спонтанно возникающая. 264611
> И только на aarch64. 
 
Я в последней сборке mailutils на не x86 столкнулся с wlimit_time_idle
на тестах, но тут wlimit_time_idle правильно сработал видимо. В итоге
я отключил неработающие тесты 

# https://lists.altlinux.org/pipermail/devel/2020-September/212028.html
%ifnarch %ix86 x86_64
sed -i "s|m4_include..strin.at..|dnl m4_include([strin.at])|"   libmailutils/tests/testsuite.at
sed -i "s|m4_include..strout.at..|dnl m4_include([strout.at])|" libmailutils/tests/testsuite.at
sed -i "s|m4_include..strerr.at..|dnl m4_include([strerr.at])|" libmailutils/tests/testsuite.at
%endif

Судя по https://lists.gnu.org/archive/html/bug-mailutils/2021-01/msg00001.html
проблема с этими тестами не только у нас была, но сейчас она исправлена.
В следующей сборке я этот кусок из спека уберу.

-- 
С уважением, Сергей Афонин.

Re: [devel] Time limit

[Dmitry V. Levin]

On Wed, Feb 17, 2021 at 11:55:18PM +0100, Alexey Gladkov wrote:
> On Thu, Feb 18, 2021 at 01:34:24AM +0300, Aleksey Novodvorsky wrote:
> > Коллеги,
> > у нас периодически возникает проблема time limit при сборке заданий. Хуже
> > то, что она часто возникает спонтанно. Прошу тех, кто с этим сталкивался,
> > рассказать о произошедшем и возможном решении проблемы.
> 
> Я с этой проблемой живу уже очень давно. Такая проблема возникала у меня с
> chromium. В качестве решения было выбрано такое число параллельных потоков
> при cборки, чтобы с одной стороны уложиться в time limit, c другой стороны
> не пробить лимиты по памяти.
> 
> С chromium эта проблема проявляется при пересборке почти на 100%. Я уже

$ ls beehive/logs/Sisyphus/x86_64/archive/2021/0???/error/chromium-8* |wc -l
6
$ ls beehive/logs/Sisyphus/x86_64/archive/2021/0???/success/chromium-8* |wc -l
35

6/(6+35) = 6/41
На мой взгляд, это заметно меньше 100%.
Плохо, но не фатально.

Кстати, кто хочет решить задачу оптимального распределения пакетов по
серверам во время тестовой пересборки пакетов?  Пусть вас не пугает,
что эта задача в общем случае NP-полная. :)

> давно просто игнорирую результаты пересборки этого пакета.
> 
> http://git.altlinux.org/beehive/logs/Sisyphus-x86_64/archive/2021/0208/error/chromium-88.0.4324.150-alt1.zst

Это wlimit_time_elapsed.

> Раньше такая же проблема была с firefox, но после его рефакторинга в
> апстриме этой проблемы больше не наблюдается.

Там тоже был wlimit_time_elapsed, или wlimit_time_idle?


-- 
ldv

Re: [devel] Time limit

[Alexey Gladkov]

On Thu, Feb 18, 2021 at 02:22:37AM +0300, Dmitry V. Levin wrote:
> > С chromium эта проблема проявляется при пересборке почти на 100%. Я уже
> 
> $ ls beehive/logs/Sisyphus/x86_64/archive/2021/0???/error/chromium-8* |wc -l
> 6
> $ ls beehive/logs/Sisyphus/x86_64/archive/2021/0???/success/chromium-8* |wc -l
> 35
> 
> 6/(6+35) = 6/41
> На мой взгляд, это заметно меньше 100%.
> Плохо, но не фатально.

Когда-то оно приходило чаще. Это было до того как мне надоели эти письма и
я их зафильтровал. Для меня этой проблемы больше нет. Очень рад, что
теперь эта проблема воспроизводится не часто. Это хорошие новости :)

> Кстати, кто хочет решить задачу оптимального распределения пакетов по
> серверам во время тестовой пересборки пакетов?  Пусть вас не пугает,
> что эта задача в общем случае NP-полная. :)
> 
> > давно просто игнорирую результаты пересборки этого пакета.
> > 
> > http://git.altlinux.org/beehive/logs/Sisyphus-x86_64/archive/2021/0208/error/chromium-88.0.4324.150-alt1.zst
> 
> Это wlimit_time_elapsed.
> 
> > Раньше такая же проблема была с firefox, но после его рефакторинга в
> > апстриме этой проблемы больше не наблюдается.
> 
> Там тоже был wlimit_time_elapsed, или wlimit_time_idle?

Я уже не помню. Кажется да.

-- 
Rgrds, legion

Re: [devel] Time limit

[Anton Farygin]

On 18.02.2021 02:22, Dmitry V. Levin wrote:
> Кстати, кто хочет решить задачу оптимального распределения пакетов по
> серверам во время тестовой пересборки пакетов?  Пусть вас не пугает,
> что эта задача в общем случае NP-полная.:)

а данные по ресурсам, использованным во время предыдущих сборок - где 
лежат ?
меня интересует память, диск, максимальное количество потоков и 
затраченное время.

Re: [devel] Time limit

[Alexey V. Vissarionov]

On 2021-02-18 09:44:14 +0300, Anton Farygin wrote:

 >> Кстати, кто хочет решить задачу оптимального распределения
 >> пакетов по серверам во время тестовой пересборки пакетов?
 >> Пусть вас не пугает, что эта задача в общем случае NP-полная.:)
 > а данные по ресурсам, использованным во время предыдущих
 > сборок - где лежат ? меня интересует память, диск, максимальное
 > количество потоков и затраченное время.

Теоретически эту информацию можно собрать внутри сборочного
контейнера и пихнуть в %package buildinfo

А для распределения пакетов есть смысл перейти от push к pull,
когда сборочные узлы сами нагребают себе задания.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Time limit

[Anton Farygin]

On 18.02.2021 09:56, Alexey V. Vissarionov wrote:
> On 2021-02-18 09:44:14 +0300, Anton Farygin wrote:
>
>   >> Кстати, кто хочет решить задачу оптимального распределения
>   >> пакетов по серверам во время тестовой пересборки пакетов?
>   >> Пусть вас не пугает, что эта задача в общем случае NP-полная.:)
>   > а данные по ресурсам, использованным во время предыдущих
>   > сборок - где лежат ? меня интересует память, диск, максимальное
>   > количество потоков и затраченное время.
>
> Теоретически эту информацию можно собрать внутри сборочного
> контейнера и пихнуть в %package buildinfo
Это перебор, достаточно оставить её где-то в логах или в самом задании 
(выполненном) на сборку в info.json
>
> А для распределения пакетов есть смысл перейти от push к pull,
> когда сборочные узлы сами нагребают себе задания.
>
>
без статистики по предыдущим сборкам всё равно не получится забрать 
максимально подходящее под свободные ресурсы задание из пула.

Re: [devel] Time limit

[Alexey V. Vissarionov]

On 2021-02-18 10:02:22 +0300, Anton Farygin wrote:

 >>>> Кстати, кто хочет решить задачу оптимального распределения
 >>>> пакетов по серверам во время тестовой пересборки пакетов?
 >>>> Пусть вас не пугает, что эта задача в общем случае NP-полная.:)
 >>> а данные по ресурсам, использованным во время предыдущих
 >>> сборок - где лежат ? меня интересует память, диск, максимальное
 >>> количество потоков и затраченное время.
 >> Теоретически эту информацию можно собрать внутри сборочного
 >> контейнера и пихнуть в %package buildinfo
 > Это перебор, достаточно оставить её где-то в логах или в самом
 > задании (выполненном) на сборку в info.json

Совершенно без разницы...

 >> А для распределения пакетов есть смысл перейти от push к pull,
 >> когда сборочные узлы сами нагребают себе задания.
 > без статистики по предыдущим сборкам всё равно не получится
 > забрать максимально подходящее под свободные ресурсы задание
 > из пула.

Да не надо максимально подходящее. Берем любое, а если оно тяжелое
(отъело много ресурсов и держит их долгое время) - просто не берем
дополнительные задания до окончания его сборки.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Time limit

[Anton Farygin]

On 18.02.2021 10:18, Alexey V. Vissarionov wrote:
>   >> А для распределения пакетов есть смысл перейти от push к pull,
>   >> когда сборочные узлы сами нагребают себе задания.
>   > без статистики по предыдущим сборкам всё равно не получится
>   > забрать максимально подходящее под свободные ресурсы задание
>   > из пула.
>
> Да не надо максимально подходящее. Берем любое, а если оно тяжелое
> (отъело много ресурсов и держит их долгое время) - просто не берем
> дополнительные задания до окончания его сборки.

это скучно и не интересно.

Re: [devel] Time limit

[Alexey V. Vissarionov]

On 2021-02-18 10:25:48 +0300, Anton Farygin wrote:

 >>>> А для распределения пакетов есть смысл перейти от push к
 >>>> pull, когда сборочные узлы сами нагребают себе задания.
 >>> без статистики по предыдущим сборкам всё равно не получится
 >>> забрать максимально подходящее под свободные ресурсы задание
 >>> из пула.
 >> Да не надо максимально подходящее. Берем любое, а если оно
 >> тяжелое (отъело много ресурсов и держит их долгое время) -
 >> просто не берем дополнительные задания до окончания его сборки.
 > это скучно и не интересно.

Зато работоспособно и эффективно. А главное - уже неоднократно
проверено на практике.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Time limit

[Anton Farygin]

On 18.02.2021 10:41, Alexey V. Vissarionov wrote:
> On 2021-02-18 10:25:48 +0300, Anton Farygin wrote:
>
>   >>>> А для распределения пакетов есть смысл перейти от push к
>   >>>> pull, когда сборочные узлы сами нагребают себе задания.
>   >>> без статистики по предыдущим сборкам всё равно не получится
>   >>> забрать максимально подходящее под свободные ресурсы задание
>   >>> из пула.
>   >> Да не надо максимально подходящее. Берем любое, а если оно
>   >> тяжелое (отъело много ресурсов и держит их долгое время) -
>   >> просто не берем дополнительные задания до окончания его сборки.
>   > это скучно и не интересно.
>
> Зато работоспособно и эффективно. А главное - уже неоднократно
> проверено на практике.
>
>
Очень спорно насчёт эффективности. Тяжёлое задание или нет можно узнать 
только к концу сборки.

Re: [devel] Time limit

[Alexey V. Vissarionov]

On 2021-02-18 10:43:08 +0300, Anton Farygin wrote:

 >>>>>> А для распределения пакетов есть смысл перейти от push к
 >>>>>> pull, когда сборочные узлы сами нагребают себе задания.
 >>>>> без статистики по предыдущим сборкам всё равно не получится
 >>>>> забрать максимально подходящее под свободные ресурсы
 >>>>> задание из пула.
 >>>> Да не надо максимально подходящее. Берем любое, а если оно
 >>>> тяжелое (отъело много ресурсов и держит их долгое время) -
 >>>> просто не берем дополнительные задания до окончания его
 >>>> сборки.
 >>> это скучно и не интересно.
 >> Зато работоспособно и эффективно. А главное - уже неоднократно
 >> проверено на практике.
 > Очень спорно насчёт эффективности. Тяжёлое задание или нет
 > можно узнать только к концу сборки.

Дык можно и не узнавать. Стохастические алгоритмы выборки именно
этим и хороши.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Time limit

[Anton Farygin]

On 18.02.2021 10:47, Alexey V. Vissarionov wrote:
> On 2021-02-18 10:43:08 +0300, Anton Farygin wrote:
>
>   >>>>>> А для распределения пакетов есть смысл перейти от push к
>   >>>>>> pull, когда сборочные узлы сами нагребают себе задания.
>   >>>>> без статистики по предыдущим сборкам всё равно не получится
>   >>>>> забрать максимально подходящее под свободные ресурсы
>   >>>>> задание из пула.
>   >>>> Да не надо максимально подходящее. Берем любое, а если оно
>   >>>> тяжелое (отъело много ресурсов и держит их долгое время) -
>   >>>> просто не берем дополнительные задания до окончания его
>   >>>> сборки.
>   >>> это скучно и не интересно.
>   >> Зато работоспособно и эффективно. А главное - уже неоднократно
>   >> проверено на практике.
>   > Очень спорно насчёт эффективности. Тяжёлое задание или нет
>   > можно узнать только к концу сборки.
>
> Дык можно и не узнавать. Стохастические алгоритмы выборки именно
> этим и хороши.
>
>
Да, а ещё именно этим они и плохи.

Мне интересно было бы посмотреть на реализацию пересборки пакетов со 
стохастическим алгоритмом.

Re: [devel] Time limit

[Dmitry V. Levin]

On Thu, Feb 18, 2021 at 10:25:48AM +0300, Anton Farygin wrote:
> On 18.02.2021 10:18, Alexey V. Vissarionov wrote:
> >   >> А для распределения пакетов есть смысл перейти от push к pull,
> >   >> когда сборочные узлы сами нагребают себе задания.
> >   > без статистики по предыдущим сборкам всё равно не получится
> >   > забрать максимально подходящее под свободные ресурсы задание
> >   > из пула.
> >
> > Да не надо максимально подходящее. Берем любое, а если оно тяжелое
> > (отъело много ресурсов и держит их долгое время) - просто не берем
> > дополнительные задания до окончания его сборки.
> 
> это скучно и не интересно.

Оно так сейчас и работает.  Не только не интересно, но и неэффективно,
судя по тому, что тот же chromium с вероятностью 15% пробивает 8-часовой
wlimit_time_elapsed.


-- 
ldv

Re: [devel] Time limit

[Vitaly Chikunov]

On Thu, Feb 18, 2021 at 09:44:14AM +0300, Anton Farygin wrote:
> On 18.02.2021 02:22, Dmitry V. Levin wrote:
> > Кстати, кто хочет решить задачу оптимального распределения пакетов по
> > серверам во время тестовой пересборки пакетов?  Пусть вас не пугает,
> > что эта задача в общем случае NP-полная.:)
> 
> а данные по ресурсам, использованным во время предыдущих сборок - где лежат
> ?
> меня интересует память, диск, максимальное количество потоков и затраченное
> время.

В логе сборки и beekeeper есть вывод time, например:

  http://git.altlinux.org/tasks/archive/done/_260/266509/build/700/x86_64/log

  65.11user 19.24system 1:18.20elapsed 107%CPU (0avgtext+0avgdata 125552maxresident)k

Только вместо максимального количества потоков среднее - 107%CPU.
Память - 125552maxresident.

Как считать "диск" - интересный вопрос.


> 
> 
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Time limit

[Dmitry V. Levin]

On Thu, Feb 18, 2021 at 09:44:14AM +0300, Anton Farygin wrote:
> On 18.02.2021 02:22, Dmitry V. Levin wrote:
> > Кстати, кто хочет решить задачу оптимального распределения пакетов по
> > серверам во время тестовой пересборки пакетов?  Пусть вас не пугает,
> > что эта задача в общем случае NP-полная.:)
> 
> а данные по ресурсам, использованным во время предыдущих сборок - где 
> лежат ?

По времени сборки лежит в beehive/logs/$repo/$arch/latest/time.list

> меня интересует память, диск, максимальное количество потоков и 
> затраченное время.

Это отдельная подзадача - какие данные нужны, и как их собрать.


-- 
ldv

Re: [devel] Time limit

[Anton Farygin]

On 18.02.2021 14:37, Dmitry V. Levin wrote:
> On Thu, Feb 18, 2021 at 09:44:14AM +0300, Anton Farygin wrote:
>> On 18.02.2021 02:22, Dmitry V. Levin wrote:
>>> Кстати, кто хочет решить задачу оптимального распределения пакетов по
>>> серверам во время тестовой пересборки пакетов?  Пусть вас не пугает,
>>> что эта задача в общем случае NP-полная.:)
>> а данные по ресурсам, использованным во время предыдущих сборок - где
>> лежат ?
> По времени сборки лежит в beehive/logs/$repo/$arch/latest/time.list
Это же только время сборки, оно интересно, конечно, но в расчётах по 
идее не должно сильно участвовать.
>
>> меня интересует память, диск, максимальное количество потоков и
>> затраченное время.
> Это отдельная подзадача - какие данные нужны, и как их собрать.
>
>
Т.е. - эта задача ещё не решена. Понятно.

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

с потоками сложнее всего, т.к. идеально хочется видеть top cpu usage а 
не average.
В идеальном случае было бы классно строить график по CPU usage, и это 
даже понятно как сделать. Но сборочницу придётся научить использовать 
cgroups2, с которых можно снимать эту информацию прямо во время сборки.

Что касается диска (а он же и память), то, на мой взгляд, от 
использования ramdisk надо отходить в сторону быстрых nvme/U2 SSD с 
большим ресурсом - найти SSD со скоростью записи в 3000 MB/s сейчас 
вообще не проблема. Тогда объём использованного диска для нас станет не 
очень критичным, да и памяти освободится много.

Re: [devel] Time limit

[Michael Shigorin]

On Thu, Feb 18, 2021 at 08:50:57PM +0300, Anton Farygin wrote:
> Что касается диска (а он же и память), то, на мой взгляд, от
> использования ramdisk надо отходить в сторону быстрых nvme/U2
> SSD с большим ресурсом - найти SSD со скоростью записи в 3000
> MB/s сейчас вообще не проблема. Тогда объём использованного
> диска для нас станет не очень критичным, да и памяти
> освободится много.

Для нынешней RAM три гига в секунду -- это очень медленно.
И циклы записи для неё учитывать не приходится вообще.
Ты точно хочешь эти игрушки за сотни тыщ?

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Time limit

[Alexey V. Vissarionov]

On 2021-02-19 00:52:03 +0300, Michael Shigorin wrote:

 >> Что касается диска (а он же и память), то, на мой взгляд, от
 >> использования ramdisk надо отходить в сторону быстрых nvme/U2
 >> SSD с большим ресурсом - найти SSD со скоростью записи в 3000
 >> MB/s сейчас вообще не проблема. Тогда объём использованного
 >> диска для нас станет не очень критичным, да и памяти
 >> освободится много.
 > Для нынешней RAM три гига в секунду -- это очень медленно. И
 > циклы записи для неё учитывать не приходится вообще. Ты точно
 > хочешь эти игрушки за сотни тыщ?

Эти игрушки, будучи собранными в RAID-0, хороши для нагруженных
БД. Разумеется, с репликацией в том числе и на резервный сервер
с RAID-6 из классических НЖМД.

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Time limit

[Anton Farygin]

On 19.02.2021 00:52, Michael Shigorin wrote:
> On Thu, Feb 18, 2021 at 08:50:57PM +0300, Anton Farygin wrote:
>> Что касается диска (а он же и память), то, на мой взгляд, от
>> использования ramdisk надо отходить в сторону быстрых nvme/U2
>> SSD с большим ресурсом - найти SSD со скоростью записи в 3000
>> MB/s сейчас вообще не проблема. Тогда объём использованного
>> диска для нас станет не очень критичным, да и памяти
>> освободится много.
> Для нынешней RAM три гига в секунду -- это очень медленно.
Расскажи мне пожалуйста про производительность современной памяти. Что 
значит "очень медленно" ?  Как ты сравнивал ?
> И циклы записи для неё учитывать не приходится вообще.
> Ты точно хочешь эти игрушки за сотни тыщ?

Сотни тысяч ? Миша, прогресс не стоит на месте и то, что было два года 
назад - сейчас уже не является правдой. SSD уже стоит дешевле SAS дисков 
15К при значительно более высокой скорости работы.


2Tb SSD с ресурсом в 4 петабайта (1.5 носителя в день в течении пяти 
лет) стоит 27 тысяч рублей.

Это ровно в 30 раз дешевле такого же объёма ОЗУ ddr4

И цена в данном случае не самое главное значение.

Re: [devel] Time limit

[Michael Shigorin]

On Fri, Feb 19, 2021 at 10:11:01AM +0300, Anton Farygin wrote:
> > Для нынешней RAM три гига в секунду -- это очень медленно.
> Расскажи мне пожалуйста про производительность современной
> памяти. Что значит "очень медленно" ?  Как ты сравнивал ?

12 Гб/с я видел на DDR3 в 2009 году (Ломоносов);
10 Гб/с тогда для неё было вполне нормальным.
Сейчас не шибко в курсе, но припоминается от
двадцати, что ли.

> > И циклы записи для неё учитывать не приходится вообще.
> > Ты точно хочешь эти игрушки за сотни тыщ?
> Сотни тысяч ? Миша, прогресс не стоит на месте и то, что было
> два года назад - сейчас уже не является правдой. SSD уже стоит
> дешевле SAS дисков 15К при значительно более высокой скорости
> работы.

Что-то не помню поползновений собирать hasher'ом на SAS.

> 2Tb SSD с ресурсом в 4 петабайта (1.5 носителя в день
> в течении пяти лет) стоит 27 тысяч рублей.
> Это ровно в 30 раз дешевле такого же объёма ОЗУ ddr4
> И цена в данном случае не самое главное значение.

Скорость и лишняя необходимость в обслуживании (замене)
в моих глазах тут чистый минус.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Time limit

[Anton Farygin]

On 19.02.2021 13:50, Michael Shigorin wrote:
> On Fri, Feb 19, 2021 at 10:11:01AM +0300, Anton Farygin wrote:
>>> Для нынешней RAM три гига в секунду -- это очень медленно.
>> Расскажи мне пожалуйста про производительность современной
>> памяти. Что значит "очень медленно" ?  Как ты сравнивал ?
> 12 Гб/с я видел на DDR3 в 2009 году (Ломоносов);
> 10 Гб/с тогда для неё было вполне нормальным.
> Сейчас не шибко в курсе, но припоминается от
> двадцати, что ли.
Это реальные цифры работы с tmpfs ? Или что ? Как мерял ?
>
>>> И циклы записи для неё учитывать не приходится вообще.
>>> Ты точно хочешь эти игрушки за сотни тыщ?
>> Сотни тысяч ? Миша, прогресс не стоит на месте и то, что было
>> два года назад - сейчас уже не является правдой. SSD уже стоит
>> дешевле SAS дисков 15К при значительно более высокой скорости
>> работы.
> Что-то не помню поползновений собирать hasher'ом на SAS.

А я помню ;) tmpfs появился ровно потому, что диски умирали.

было бы неплохо сравнить реальную разницу между tmpfs и быстрым SSD в 
случае использования hasher.

У меня нет под рукой стенда с SSD, но есть стенд с ceph (который на SATA 
дисках и медленнее ssd заметно).

разница у hsh --initroot на tmpfs и на ceph составляет 2 секунды (из 
20). 10%. Это медленный ceph (100 MB/sec). Что будет на быстром SSD ?

>
>> 2Tb SSD с ресурсом в 4 петабайта (1.5 носителя в день
>> в течении пяти лет) стоит 27 тысяч рублей.
>> Это ровно в 30 раз дешевле такого же объёма ОЗУ ddr4
>> И цена в данном случае не самое главное значение.
> Скорость и лишняя необходимость в обслуживании (замене)
> в моих глазах тут чистый минус.

Давай подсчитаем частоту замены ?

за такую разницу в цене памяти можно купить больше серверов (или 
покупать эти сервера чаще и менять вместе с ssd).

Re: [devel] Time limit

[Michael Shigorin]

On Fri, Feb 19, 2021 at 02:11:39PM +0300, Anton Farygin wrote:
> было бы неплохо сравнить реальную разницу между tmpfs и быстрым
> SSD в случае использования hasher.

Эт надо стендик сгородить, у меня сейчас скорее эльбрусы под
рукой (на basalt SSD-шек нет, да и на нём вечно что-то да
происходит, хотя бы раздача /space).

> У меня нет под рукой стенда с SSD, но есть стенд с ceph
> (который на SATA дисках и медленнее ssd заметно).
> разница у hsh --initroot на tmpfs и на ceph составляет
> 2 секунды (из 20). 10%. Это медленный ceph (100 MB/sec).

Это с sync?

> Что будет на быстром SSD ?

Примерно то же самое, полагаю: hsh --ini больше упирается
в одно (1) процессорное ядро, чем в I/O, очевидно.
А вот когда у тебя какой-нить гиговый debuginfo пишется,
всё уже не так однозначно.

> >> 2Tb SSD с ресурсом в 4 петабайта (1.5 носителя в день
> >> в течении пяти лет) стоит 27 тысяч рублей.
> >> Это ровно в 30 раз дешевле такого же объёма ОЗУ ddr4
> >> И цена в данном случае не самое главное значение.
> > Скорость и лишняя необходимость в обслуживании (замене)
> > в моих глазах тут чистый минус.
> Давай подсчитаем частоту замены ?  за такую разницу в цене
> памяти можно купить больше серверов (или покупать эти сервера
> чаще и менять вместе с ssd).

Память тоже не стоит совсем уж на месте; а терабайтами её нам
куда именно надо, напомни? (напомню, что вся буза с замером
потребления ресурсов когда-то была поднята с тем, чтоб под
каждую тему оформления не резервировать ресурсов с оглядкой
на LO/chromium; о задумке с проверкой пересборки зависимых
пакетов а-ля гентушный revdep-rebuild -- помню)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Time limit

[Anton Farygin]

On 19.02.2021 15:05, Michael Shigorin wrote:
> On Fri, Feb 19, 2021 at 02:11:39PM +0300, Anton Farygin wrote:
>> было бы неплохо сравнить реальную разницу между tmpfs и быстрым
>> SSD в случае использования hasher.
> Эт надо стендик сгородить, у меня сейчас скорее эльбрусы под
> рукой (на basalt SSD-шек нет, да и на нём вечно что-то да
> происходит, хотя бы раздача /space).
У меня будет такой стенд в ближайшее время, я попробую пособирать пакеты 
и сравнить разницу.
>
>> У меня нет под рукой стенда с SSD, но есть стенд с ceph
>> (который на SATA дисках и медленнее ssd заметно).
>> разница у hsh --initroot на tmpfs и на ceph составляет
>> 2 секунды (из 20). 10%. Это медленный ceph (100 MB/sec).
> Это с sync?
нет.
>
>> Что будет на быстром SSD ?
> Примерно то же самое, полагаю: hsh --ini больше упирается
> в одно (1) процессорное ядро, чем в I/O, очевидно.
> А вот когда у тебя какой-нить гиговый debuginfo пишется,
> всё уже не так однозначно.
так он всё равно в память пишется, кеш то никто не отменял.
>
>>>> 2Tb SSD с ресурсом в 4 петабайта (1.5 носителя в день
>>>> в течении пяти лет) стоит 27 тысяч рублей.
>>>> Это ровно в 30 раз дешевле такого же объёма ОЗУ ddr4
>>>> И цена в данном случае не самое главное значение.
>>> Скорость и лишняя необходимость в обслуживании (замене)
>>> в моих глазах тут чистый минус.
>> Давай подсчитаем частоту замены ?  за такую разницу в цене
>> памяти можно купить больше серверов (или покупать эти сервера
>> чаще и менять вместе с ssd).
> Память тоже не стоит совсем уж на месте; а терабайтами её нам
> куда именно надо, напомни? (напомню, что вся буза с замером
> потребления ресурсов когда-то была поднята с тем, чтоб под
> каждую тему оформления не резервировать ресурсов с оглядкой
> на LO/chromium; о задумке с проверкой пересборки зависимых
> пакетов а-ля гентушный revdep-rebuild -- помню)

Ну как куда. В лимиты, конечно. софт пухнет и узкое место, как всегда - 
память + диск.

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

Re: [devel] hsh --initroot: nvme vs ssd

[Anton Farygin]

On 19.02.2021 15:23, Anton Farygin wrote:
> On 19.02.2021 15:05, Michael Shigorin wrote:
>> On Fri, Feb 19, 2021 at 02:11:39PM +0300, Anton Farygin wrote:
>>> было бы неплохо сравнить реальную разницу между tmpfs и быстрым
>>> SSD в случае использования hasher.
>> Эт надо стендик сгородить, у меня сейчас скорее эльбрусы под
>> рукой (на basalt SSD-шек нет, да и на нём вечно что-то да
>> происходит, хотя бы раздача /space).
> У меня будет такой стенд в ближайшее время, я попробую пособирать 
> пакеты и сравнить разницу. 

Попробовал.

hsh --initroot работает, в среднем, с разницей в 1 секунду на памяти и 
SSD. - 12 секунд на tmpfs и 13 на ssd

На сборке ядра я разницы вообще не заметил - в сборках были как более 
быстрые на ssd, так и более быстрые на памяти. С чем это связано - не 
знаю, но разница между ними обычно не больше 20-30 секунд и в среднем на 
этой системе ядро собиралось18 минут.

тюнингом кеша и шедулера не занимался. шедулер none, диск nvme 
Micron_7300_MTFDHBG1T9TDF 2Tb.

Что ещё попробовать пособирать ?

Re: [devel] hsh --initroot: nvme vs ssd

[Vladimir D. Seleznev]

On Sun, Feb 21, 2021 at 09:23:31PM +0300, Anton Farygin wrote:
> On 19.02.2021 15:23, Anton Farygin wrote:
> > On 19.02.2021 15:05, Michael Shigorin wrote:
> >> On Fri, Feb 19, 2021 at 02:11:39PM +0300, Anton Farygin wrote:
> >>> было бы неплохо сравнить реальную разницу между tmpfs и быстрым
> >>> SSD в случае использования hasher.
> >> Эт надо стендик сгородить, у меня сейчас скорее эльбрусы под
> >> рукой (на basalt SSD-шек нет, да и на нём вечно что-то да
> >> происходит, хотя бы раздача /space).
> > У меня будет такой стенд в ближайшее время, я попробую пособирать 
> > пакеты и сравнить разницу. 
> 
> Попробовал.
> 
> hsh --initroot работает, в среднем, с разницей в 1 секунду на памяти и 
> SSD. - 12 секунд на tmpfs и 13 на ssd
> 
> На сборке ядра я разницы вообще не заметил - в сборках были как более 
> быстрые на ssd, так и более быстрые на памяти. С чем это связано - не 
> знаю, но разница между ними обычно не больше 20-30 секунд и в среднем на 
> этой системе ядро собиралось18 минут.
> 
> тюнингом кеша и шедулера не занимался. шедулер none, диск nvme 
> Micron_7300_MTFDHBG1T9TDF 2Tb.
> 
> Что ещё попробовать пособирать ?

Хромиум.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] hsh --initroot: nvme vs ssd

[Anton Farygin]

On 21.02.2021 21:38, Vladimir D. Seleznev wrote:
> On Sun, Feb 21, 2021 at 09:23:31PM +0300, Anton Farygin wrote:
>> On 19.02.2021 15:23, Anton Farygin wrote:
>>> On 19.02.2021 15:05, Michael Shigorin wrote:
>>>> On Fri, Feb 19, 2021 at 02:11:39PM +0300, Anton Farygin wrote:
>>>>> было бы неплохо сравнить реальную разницу между tmpfs и быстрым
>>>>> SSD в случае использования hasher.
>>>> Эт надо стендик сгородить, у меня сейчас скорее эльбрусы под
>>>> рукой (на basalt SSD-шек нет, да и на нём вечно что-то да
>>>> происходит, хотя бы раздача /space).
>>> У меня будет такой стенд в ближайшее время, я попробую пособирать
>>> пакеты и сравнить разницу.
>> Попробовал.
>>
>> hsh --initroot работает, в среднем, с разницей в 1 секунду на памяти и
>> SSD. - 12 секунд на tmpfs и 13 на ssd
>>
>> На сборке ядра я разницы вообще не заметил - в сборках были как более
>> быстрые на ssd, так и более быстрые на памяти. С чем это связано - не
>> знаю, но разница между ними обычно не больше 20-30 секунд и в среднем на
>> этой системе ядро собиралось18 минут.
>>
>> тюнингом кеша и шедулера не занимался. шедулер none, диск nvme
>> Micron_7300_MTFDHBG1T9TDF 2Tb.
>>
>> Что ещё попробовать пособирать ?
> Хромиум.
>
А хромиум у меня почему-то не собирается, Ну и мне казалось что в его 
сборке больше уходит на CPU, чем на IO.

Re: [devel] hsh --initroot: nvme vs ssd

[Anton Farygin]

On 21.02.2021 21:23, Anton Farygin wrote:
> On 19.02.2021 15:23, Anton Farygin wrote:
>> On 19.02.2021 15:05, Michael Shigorin wrote:
>>> On Fri, Feb 19, 2021 at 02:11:39PM +0300, Anton Farygin wrote:
>>>> было бы неплохо сравнить реальную разницу между tmpfs и быстрым
>>>> SSD в случае использования hasher.
>>> Эт надо стендик сгородить, у меня сейчас скорее эльбрусы под
>>> рукой (на basalt SSD-шек нет, да и на нём вечно что-то да
>>> происходит, хотя бы раздача /space).
>> У меня будет такой стенд в ближайшее время, я попробую пособирать 
>> пакеты и сравнить разницу. 
>
> Попробовал.
>
> hsh --initroot работает, в среднем, с разницей в 1 секунду на памяти и 
> SSD. - 12 секунд на tmpfs и 13 на ssd

update:

наше ядро 5.10 даёт результаты в среднем лучше на 1 секунду (на 10%) на 
hsh --initroot как для nvme, так и для tmpfs.

Re: [devel] hsh --initroot: nvme vs ssd

[Dmitry V. Levin]

On Sun, Feb 21, 2021 at 09:23:31PM +0300, Anton Farygin wrote:
[...]
> Что ещё попробовать пособирать ?

Интересно сравнить скорость работы hsh --initroot-only в режиме
unchecked_initroot_cache="$(b2sum /path/to/Sisyphus/files/list/task.info)"
(cached, без использования apt).  В этом режиме оно работает достаточно
быстро, поэтому имеет смысл замерить скорость выполнения серии операций
(hsh --init, hsh --clean).

Ещё интересно сравнить то же самое, но под нагрузкой, когда `nproc`
потоков выполняют эту серию операций более-менее одновременно.


-- 
ldv

Re: [devel] hsh --initroot: nvme vs ssd

[Anton Farygin]

On 21.02.2021 21:51, Dmitry V. Levin wrote:
> On Sun, Feb 21, 2021 at 09:23:31PM +0300, Anton Farygin wrote:
> [...]
>> Что ещё попробовать пособирать ?
> Интересно сравнить скорость работы hsh --initroot-only в режиме
> unchecked_initroot_cache="$(b2sum /path/to/Sisyphus/files/list/task.info)"
> (cached, без использования apt).  В этом режиме оно работает достаточно
> быстро, поэтому имеет смысл замерить скорость выполнения серии операций
> (hsh --init, hsh --clean).
на серии операций просто накапливается 1 секунда расхождения - т.е. 100 
операций initroot даёт разницу в 100 секунд
>
> Ещё интересно сравнить то же самое, но под нагрузкой, когда `nproc`
> потоков выполняют эту серию операций более-менее одновременно.

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

32 параллельных initroot на nvme = 26 секунд, тоже самое на tmpfs - 7 
секунд.


Но всё равно не очень понятно, насколько существенно это  окажет влияние 
на скорость пересборки репозитория, т.к. с уменьшением количества 
потоков эта разница уменьшается.

возможно, тут уже надо заняться настройкой шедулера и кеширования.

Re: [devel] hsh --initroot: nvme vs ssd

[Anton Farygin]

On 21.02.2021 22:41, Anton Farygin wrote:
> On 21.02.2021 21:51, Dmitry V. Levin wrote:
>> On Sun, Feb 21, 2021 at 09:23:31PM +0300, Anton Farygin wrote:
>> [...]
>>> Что ещё попробовать пособирать ?
>> Интересно сравнить скорость работы hsh --initroot-only в режиме
>> unchecked_initroot_cache="$(b2sum 
>> /path/to/Sisyphus/files/list/task.info)"
>> (cached, без использования apt).  В этом режиме оно работает достаточно
>> быстро, поэтому имеет смысл замерить скорость выполнения серии операций
>> (hsh --init, hsh --clean).
> на серии операций просто накапливается 1 секунда расхождения - т.е. 
> 100 операций initroot даёт разницу в 100 секунд
>>
>> Ещё интересно сравнить то же самое, но под нагрузкой, когда `nproc`
>> потоков выполняют эту серию операций более-менее одновременно.
>
> А вот этот тест оказался более интересным и показал разницу почти в 4 
> раза между памятью и nvme. В принципе это почти соответсвует реальной 
> разнице в производительности между скоростью записи на накопитель и 
> скоростью работы оперативной памяти.
>
> 32 параллельных initroot на nvme = 26 секунд, тоже самое на tmpfs - 7 
> секунд.
>
>
> Но всё равно не очень понятно, насколько существенно это  окажет 
> влияние на скорость пересборки репозитория, т.к. с уменьшением 
> количества потоков эта разница уменьшается.
>
> возможно, тут уже надо заняться настройкой шедулера и кеширования.

Я настроил кеш так, что бы диск не использовался вообще и получил 
выигрыш в 0.5%

Это показалось мне странным и я сделал 100Gb файл на tmpfs, разбил его в 
ext4, смонтировал через loop.

Честнее, конечно же, было бы использовать ramdisk но мне влом перегружаться.

результат - ramdisk на tmpfs с ext4 медленнее чем ssd на 50%. Из этого, 
как мне кажется, можно сделать вывод что тормозит не nvme а файловая 
система ext4 или vfs.

Есть идеи, как можно сделать tmpfs over nvme  ?

[devel] О пропускной способности устройств хранения (Re: Time limit)

[Alexey Sheplyakov]

Добрый день!

On 19.02.2021 14:50, Michael Shigorin wrote:
> On Fri, Feb 19, 2021 at 10:11:01AM +0300, Anton Farygin wrote:
>>> Для нынешней RAM три гига в секунду -- это очень медленно.
>> Расскажи мне пожалуйста про производительность современной
>> памяти. Что значит "очень медленно" ?  Как ты сравнивал ?
> 
> 12 Гб/с я видел на DDR3 в 2009 году (Ломоносов);
> 10 Гб/с тогда для неё было вполне нормальным.
> Сейчас не шибко в курсе, но припоминается от
> двадцати, что ли.

$ cat > hello.c <<EOF
#include <stdio.h>
int main(int argc, char **argv) {
	printf("Hello, world\n");
	return 0;
}
EOF

$ strace -f -o gcc.log gcc -O0 -g0 -c hello.c
$ cat gcc.log | wc -l
1079

$ time gcc -O0 -g0 -c hello.c

real	0m0,046s
user	0m0,022s
sys	0m0,005s

По порядку величины  5 микросекунд на системный вызов.

$ git ls-files '*.c' | wc -l
29574

Нужно примерно 30000 * 1000 = 5 * 10**7 системных вызовов, займут 150 секунд.

$ du -sh .
5.6G	.

(исходники, объекники, история git, вообще все)

При скорости записи 250 МБ/sec (ширпотребный SSD) записать такой объем можно за
22 секунды. 15% времени, необходимого на системные вызовы.
А значит, даже бесконечно быстрый (RAM)диск ускорит сборку не более чем на 15%.


TL;DR: сборка гораздо раньше упрется в скорость выполнения системных вызовов (fork/read/write/access).

Re: [devel] О пропускной способности устройств хранения (Re: Time limit)

[Anton V. Boyarshinov]

В Fri, 19 Feb 2021 16:29:15 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

> При скорости записи 250 МБ/sec (ширпотребный SSD) записать такой объем можно за
> 22 секунды. 15% времени, необходимого на системные вызовы.
> А значит, даже бесконечно быстрый (RAM)диск ускорит сборку не более чем на 15%.
> 
> 
> TL;DR: сборка гораздо раньше упрется в скорость выполнения системных вызовов (fork/read/write/access).

Интересная мысль, но, с другой стороны, у нас много ядер и на всех
выполняются процессы. А читать/писать хотят один и тот же диск, так что
системные вызовы выполняются (во многом) параллельно, а пропускную
способность диска приходится делить на всех...

Re: [devel] О пропускной способности устройств хранения (Re: Time limit)

[Anton Farygin]

On 19.02.2021 16:50, Anton V. Boyarshinov wrote:
> В Fri, 19 Feb 2021 16:29:15 +0400
> Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:
>
>> При скорости записи 250 МБ/sec (ширпотребный SSD) записать такой объем можно за
>> 22 секунды. 15% времени, необходимого на системные вызовы.
>> А значит, даже бесконечно быстрый (RAM)диск ускорит сборку не более чем на 15%.
>>
>>
>> TL;DR: сборка гораздо раньше упрется в скорость выполнения системных вызовов (fork/read/write/access).
> Интересная мысль, но, с другой стороны, у нас много ядер и на всех
> выполняются процессы. А читать/писать хотят один и тот же диск, так что
> системные вызовы выполняются (во многом) параллельно, а пропускную
> способность диска приходится делить на всех...
Разве это кого-то беспокоит на дисках, способных выполнять сотню тысяч 
IO в секунду ?

Re: [devel] О пропускной способности устройств хранения (Re: Time limit)

[Anton V. Boyarshinov]

В Fri, 19 Feb 2021 16:56:10 +0300
Anton Farygin <rider@basealt.ru> пишет:

> >> TL;DR: сборка гораздо раньше упрется в скорость выполнения системных вызовов (fork/read/write/access).  

> > Интересная мысль, но, с другой стороны, у нас много ядер и на всех
> > выполняются процессы. А читать/писать хотят один и тот же диск, так что
> > системные вызовы выполняются (во многом) параллельно, а пропускную
> > способность диска приходится делить на всех...  

> Разве это кого-то беспокоит на дисках, способных выполнять сотню тысяч 
> IO в секунду ?

Беспокоит или нет -- другой разговор, мне просто показалось, что
приведённая оценка не совсем соответствует нашей ситуации.

Re: [devel] О пропускной способности устройств хранения (Re: Time limit)

[Alexey Sheplyakov]

On 19.02.2021 17:50, Anton V. Boyarshinov wrote:
> В Fri, 19 Feb 2021 16:29:15 +0400
> Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:
> 
>> При скорости записи 250 МБ/sec (ширпотребный SSD) записать такой объем можно за
>> 22 секунды. 15% времени, необходимого на системные вызовы.
>> А значит, даже бесконечно быстрый (RAM)диск ускорит сборку не более чем на 15%.
>>
>>
>> TL;DR: сборка гораздо раньше упрется в скорость выполнения системных вызовов (fork/read/write/access).
> 
> Интересная мысль, но, с другой стороны, у нас много ядер и на всех
> выполняются процессы. А читать/писать хотят один и тот же диск, так что
> системные вызовы выполняются (во многом) параллельно,
> а пропускную способность диска приходится делить на всех...

Во-первых, диски тоже выполняют запросы параллельно. Более того,
только в таком параллельном режиме из них и можно выжать заявленную
скорость записи [1]

Во-вторых, далеко не каждый stat/access/read доходит до диска.

А самое главное - системные вызовы выполняются параллельно до тех пор,
пока vfs не начнет брать два ведра блокировок. А дальше с параллельностью
начинаются проблемы.

> а пропускную способность диска приходится делить на всех...

Точнее говоря, пропускную способность vfs приходится делить на всех.
Вот и выходит, что для того, чтобы загрузить SSD более чем на 10%
от его пропускной способности, приходится отказываться от POSIX
(и любой иерархической) файловой системы (см. ceph и прочие block
storage), и стирать границу ядро/пользователь (см. https://spdk.io)


[1] Измерял скорость синхронной записи блоками по 4 KB. Диск Intel 730k.
    В один поток: 34000 KB/sec, в 4: 64000 KB/sec (суммарно). Графики и данные
    можно поглядеть тут:

    https://raw.githubusercontent.com/asheplyakov/ceph-jemalloc-bench/master/desktop_ssd/desktop_ssd_syncwrite_bw.png

    https://raw.githubusercontent.com/asheplyakov/ceph-jemalloc-bench/master/desktop_ssd_4x/desktop_ssd_4x_bw.png

Re: [devel] О пропускной способности устройств хранения (Re: Time limit)

[Anton V. Boyarshinov]

В Mon, 22 Feb 2021 12:54:29 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

> > Интересная мысль, но, с другой стороны, у нас много ядер и на всех
> > выполняются процессы. А читать/писать хотят один и тот же диск, так что
> > системные вызовы выполняются (во многом) параллельно,
> > а пропускную способность диска приходится делить на всех...  
> 
> Во-первых, диски тоже выполняют запросы параллельно. Более того,
> только в таком параллельном режиме из них и можно выжать заявленную
> скорость записи [1]
> 
> Во-вторых, далеко не каждый stat/access/read доходит до диска.

Разумеется. Но как это оценивать в условиях приближённых к "много
сборок одновременно" -- не понятно. Хотя, конечно, из общих соображений
очевидно, что чем часть памяти, которая не будет тратиться на tmpfs
будет тратиться как раз на кэши.

 
> А самое главное - системные вызовы выполняются параллельно до тех пор,
> пока vfs не начнет брать два ведра блокировок. А дальше с параллельностью
> начинаются проблемы.

Ну, собственно это я и имел в виду, когда написал "(во много)
параллельно".

Re: [devel] Time limit

[Anton V. Boyarshinov]

В Thu, 18 Feb 2021 20:50:57 +0300
Anton Farygin <rider@basealt.ru> пишет:

> Что касается диска (а он же и память), то, на мой взгляд, от 
> использования ramdisk надо отходить в сторону быстрых nvme/U2 SSD с 
> большим ресурсом - найти SSD со скоростью записи в 3000 MB/s сейчас 
> вообще не проблема. 

Жаль, что нельзя сделать bcache из tmpfs в качестве быстрого устройства
и SSD в качестве медленного...

Re: [devel] Time limit

[Anton Farygin]

On 19.02.2021 11:47, Anton V. Boyarshinov wrote:
> В Thu, 18 Feb 2021 20:50:57 +0300
> Anton Farygin <rider@basealt.ru> пишет:
>
>> Что касается диска (а он же и память), то, на мой взгляд, от
>> использования ramdisk надо отходить в сторону быстрых nvme/U2 SSD с
>> большим ресурсом - найти SSD со скоростью записи в 3000 MB/s сейчас
>> вообще не проблема.
> Жаль, что нельзя сделать bcache из tmpfs в качестве быстрого устройства
> и SSD в качестве медленного...
почему нельзя ?

не tmpfs, а ramdisk

Re: [devel] Time limit

[Leonid Krivoshein]

19.02.2021 11:47, Anton V. Boyarshinov пишет:
> В Thu, 18 Feb 2021 20:50:57 +0300
> Anton Farygin <rider@basealt.ru> пишет:
>
>> Что касается диска (а он же и память), то, на мой взгляд, от
>> использования ramdisk надо отходить в сторону быстрых nvme/U2 SSD с
>> большим ресурсом - найти SSD со скоростью записи в 3000 MB/s сейчас
>> вообще не проблема.
> Жаль, что нельзя сделать bcache из tmpfs в качестве быстрого устройства
> и SSD в качестве медленного...

В этом смысле tmpfs со SWAP'ом на SSD уже такой себе "bcache".


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Time limit

[Anton Farygin]

On 19.02.2021 12:39, Leonid Krivoshein wrote:
>
> 19.02.2021 11:47, Anton V. Boyarshinov пишет:
>> В Thu, 18 Feb 2021 20:50:57 +0300
>> Anton Farygin <rider@basealt.ru> пишет:
>>
>>> Что касается диска (а он же и память), то, на мой взгляд, от
>>> использования ramdisk надо отходить в сторону быстрых nvme/U2 SSD с
>>> большим ресурсом - найти SSD со скоростью записи в 3000 MB/s сейчас
>>> вообще не проблема.
>> Жаль, что нельзя сделать bcache из tmpfs в качестве быстрого устройства
>> и SSD в качестве медленного...
>
> В этом смысле tmpfs со SWAP'ом на SSD уже такой себе "bcache".
>
>
а в таком решении разве можно сделать так, что бы своп использовался 
только для tmpfs и не использовался для памяти процессов ?

Re: [devel] Time limit

[Michael Shigorin]

On Fri, Feb 19, 2021 at 12:57:26PM +0300, Anton Farygin wrote:
> >> Жаль, что нельзя сделать bcache из tmpfs в качестве быстрого устройства
> >> и SSD в качестве медленного...
> > В этом смысле tmpfs со SWAP'ом на SSD уже такой себе "bcache".
> а в таком решении разве можно сделать так, что бы своп
> использовался только для tmpfs и не использовался для памяти
> процессов ?

Ммм... а есть возможность залочить в памяти не пару килобайт,
а сразу дерево процессов? :)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Time limit

[Anton Farygin]

On 19.02.2021 14:12, Michael Shigorin wrote:
> On Fri, Feb 19, 2021 at 12:57:26PM +0300, Anton Farygin wrote:
>>>> Жаль, что нельзя сделать bcache из tmpfs в качестве быстрого устройства
>>>> и SSD в качестве медленного...
>>> В этом смысле tmpfs со SWAP'ом на SSD уже такой себе "bcache".
>> а в таком решении разве можно сделать так, что бы своп
>> использовался только для tmpfs и не использовался для памяти
>> процессов ?
> Ммм... а есть возможность залочить в памяти не пару килобайт,
> а сразу дерево процессов? :)
>
Конечно есть. Правда, с вместе с ядром.

Но это никак не поможет тому, кто решит увеличить объём tmpfs за счёт 
SWAP на ssd.

Re: [devel] Time limit

[Anton V. Boyarshinov]

В Fri, 19 Feb 2021 12:39:03 +0300
Leonid Krivoshein <klark.devel@gmail.com> пишет:

> >> Что касается диска (а он же и память), то, на мой взгляд, от
> >> использования ramdisk надо отходить в сторону быстрых nvme/U2 SSD с
> >> большим ресурсом - найти SSD со скоростью записи в 3000 MB/s сейчас
> >> вообще не проблема.  
> > Жаль, что нельзя сделать bcache из tmpfs в качестве быстрого устройства
> > и SSD в качестве медленного...  
> 
> В этом смысле tmpfs со SWAP'ом на SSD уже такой себе "bcache".

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

Re: [devel] Time limit

[Anton Farygin]

On 19.02.2021 14:28, Anton V. Boyarshinov wrote:
> В Fri, 19 Feb 2021 12:39:03 +0300
> Leonid Krivoshein <klark.devel@gmail.com> пишет:
>
>>>> Что касается диска (а он же и память), то, на мой взгляд, от
>>>> использования ramdisk надо отходить в сторону быстрых nvme/U2 SSD с
>>>> большим ресурсом - найти SSD со скоростью записи в 3000 MB/s сейчас
>>>> вообще не проблема.
>>> Жаль, что нельзя сделать bcache из tmpfs в качестве быстрого устройства
>>> и SSD в качестве медленного...
>> В этом смысле tmpfs со SWAP'ом на SSD уже такой себе "bcache".
> Мне кажется, что, увы, нет. Хотя, возможно, я неправильно представляю
> себе работу дисковых кэшей в Linux и, возможно-таки это неплохое
> решение.

Для того, что бы понять что это terrible solution достаточно подумать, 
каким образом и за счёт чего заставить дерево процессов не использовать 
swap, а tmpfs - использовать.

Ну и дальше проще - надо понять, в чём будет заключаться выигрыш по 
сравнению с файловой системой на sssd ?

Т.е. - надо трезво оценить разницу в производительности между простой 
файловой системой на SSD и разными извращениями типа bcache, swap и т.д.

Re: [devel] Time limit

[Anton V. Boyarshinov]

В Fri, 19 Feb 2021 14:36:07 +0300
Anton Farygin <rider@basealt.ru> пишет:

> >>> и SSD в качестве медленного...  
> >> В этом смысле tmpfs со SWAP'ом на SSD уже такой себе "bcache".  
> > Мне кажется, что, увы, нет. Хотя, возможно, я неправильно представляю
> > себе работу дисковых кэшей в Linux и, возможно-таки это неплохое
> > решение.  
> 
> Для того, что бы понять что это terrible solution достаточно подумать, 
> каким образом и за счёт чего заставить дерево процессов не использовать 
> swap, а tmpfs - использовать.

Так пусть и дерево процессов использует, коли этот SSD такой быстрый,
что разницы с tmpfs почти нет...
 
> Ну и дальше проще - надо понять, в чём будет заключаться выигрыш по 
> сравнению с файловой системой на sssd ?

Re: [devel] Time limit

[Anton Farygin]

On 19.02.2021 14:43, Anton V. Boyarshinov wrote:
> В Fri, 19 Feb 2021 14:36:07 +0300
> Anton Farygin <rider@basealt.ru> пишет:
>
>>>>> и SSD в качестве медленного...
>>>> В этом смысле tmpfs со SWAP'ом на SSD уже такой себе "bcache".
>>> Мне кажется, что, увы, нет. Хотя, возможно, я неправильно представляю
>>> себе работу дисковых кэшей в Linux и, возможно-таки это неплохое
>>> решение.
>> Для того, что бы понять что это terrible solution достаточно подумать,
>> каким образом и за счёт чего заставить дерево процессов не использовать
>> swap, а tmpfs - использовать.
> Так пусть и дерево процессов использует, коли этот SSD такой быстрый,
> что разницы с tmpfs почти нет...

Объём операций с памятью в дереве процессов и в IO на диске в процессе 
сборки могут отличаться на порядки. Т.е. -  если при общем замедлении 
диска в два-три раза мы этого не заметим, то при замедлении операций с 
оперативной памятью разница может быть намного больше.

Ну и не совсем понятно какой в этом смысл ?

Re: [devel] Time limit

[Anton V. Boyarshinov]

В Fri, 19 Feb 2021 14:48:43 +0300
Anton Farygin <rider@basealt.ru> пишет:

> > Так пусть и дерево процессов использует, коли этот SSD такой быстрый,
> > что разницы с tmpfs почти нет...  
> 
> Объём операций с памятью в дереве процессов и в IO на диске в процессе 
> сборки могут отличаться на порядки.

Ну так при разумном объёме памяти активно используемая память в swap
не должна попадать, а попадать туда должны неиспользуемые страницы, то
есть, в первую очередь, файлы на tmpfs которые никто не читает. И
вымываться в swap они, по идее, будут достаточно быстро после создания.

Re: [devel] Time limit

[Anton Farygin]

On 19.02.2021 14:59, Anton V. Boyarshinov wrote:
> В Fri, 19 Feb 2021 14:48:43 +0300
> Anton Farygin <rider@basealt.ru> пишет:
>
>>> Так пусть и дерево процессов использует, коли этот SSD такой быстрый,
>>> что разницы с tmpfs почти нет...
>> Объём операций с памятью в дереве процессов и в IO на диске в процессе
>> сборки могут отличаться на порядки.
> Ну так при разумном объёме памяти активно используемая память в swap
> не должна попадать, а попадать туда должны неиспользуемые страницы, то
> есть, в первую очередь, файлы на tmpfs которые никто не читает. И
> вымываться в swap они, по идее, будут достаточно быстро после создания.

Так в случае с массированной сборкой эти файлы на tmpfs проживут весьма 
недолго.

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

Re: [devel] ssd for hasher

[Anton Farygin]

On 19.02.2021 14:36, Anton Farygin wrote:
> On 19.02.2021 14:28, Anton V. Boyarshinov wrote:
>> В Fri, 19 Feb 2021 12:39:03 +0300
>> Leonid Krivoshein <klark.devel@gmail.com> пишет:
>>
>>>>> Что касается диска (а он же и память), то, на мой взгляд, от
>>>>> использования ramdisk надо отходить в сторону быстрых nvme/U2 SSD с
>>>>> большим ресурсом - найти SSD со скоростью записи в 3000 MB/s сейчас
>>>>> вообще не проблема.
>>>> Жаль, что нельзя сделать bcache из tmpfs в качестве быстрого 
>>>> устройства
>>>> и SSD в качестве медленного...
>>> В этом смысле tmpfs со SWAP'ом на SSD уже такой себе "bcache".
>> Мне кажется, что, увы, нет. Хотя, возможно, я неправильно представляю
>> себе работу дисковых кэшей в Linux и, возможно-таки это неплохое
>> решение.
>
> Для того, что бы понять что это terrible solution достаточно подумать, 
> каким образом и за счёт чего заставить дерево процессов не 
> использовать swap, а tmpfs - использовать.
>
> Ну и дальше проще - надо понять, в чём будет заключаться выигрыш по 
> сравнению с файловой системой на sssd ?
>
> Т.е. - надо трезво оценить разницу в производительности между простой 
> файловой системой на SSD и разными извращениями типа bcache, swap и т.д.

При этом, пока у нас идёт спор - технологии не стоят на месте и активно 
развиваются.

Вот свежий press-release по этому поводу:
https://business.kioxia.com/en-jp/news/2021/20210219-1.html

Если коротко - то в 2.4 раза быстрее на чтение, на 10 процентов меньше 
латентность, на 66% быстрее IO, на 40 процентов меньше в габаритах ну и 
дешевле на 70% по сравнению с предыдущим поколением.


Даже если учесть то, что это маркетинговые цифры и в реальности всё 
будет хуже процентов на 30 - но сделать поправки на Micron + Intel, 
которые не стоят на месте - к концу года на рынке SSD накопителей 
однозначно произойдёт очередная эволюция, которая позволит нивелировать 
наши сомнения.


Собственно говоря совсем недавно SSD в 15 терабайт просто отсутствовали 
на рынке, а сейчас они уже продаются по приемлемым для серверного 
сегмента ценам в 200 тысяч.

Re: [devel] Time limit

[Alexey Gladkov]

On Thu, Feb 18, 2021 at 02:22:37AM +0300, Dmitry V. Levin wrote:
> On Wed, Feb 17, 2021 at 11:55:18PM +0100, Alexey Gladkov wrote:
> > On Thu, Feb 18, 2021 at 01:34:24AM +0300, Aleksey Novodvorsky wrote:
> > > Коллеги,
> > > у нас периодически возникает проблема time limit при сборке заданий. Хуже
> > > то, что она часто возникает спонтанно. Прошу тех, кто с этим сталкивался,
> > > рассказать о произошедшем и возможном решении проблемы.
> > 
> > Я с этой проблемой живу уже очень давно. Такая проблема возникала у меня с
> > chromium. В качестве решения было выбрано такое число параллельных потоков
> > при cборки, чтобы с одной стороны уложиться в time limit, c другой стороны
> > не пробить лимиты по памяти.
> > 
> > С chromium эта проблема проявляется при пересборке почти на 100%. Я уже
> 
> $ ls beehive/logs/Sisyphus/x86_64/archive/2021/0???/error/chromium-8* |wc -l
> 6
> $ ls beehive/logs/Sisyphus/x86_64/archive/2021/0???/success/chromium-8* |wc -l
> 35
> 
> 6/(6+35) = 6/41
> На мой взгляд, это заметно меньше 100%.
> Плохо, но не фатально.
> 
> Кстати, кто хочет решить задачу оптимального распределения пакетов по
> серверам во время тестовой пересборки пакетов?  Пусть вас не пугает,
> что эта задача в общем случае NP-полная. :)
> 
> > давно просто игнорирую результаты пересборки этого пакета.
> > 
> > http://git.altlinux.org/beehive/logs/Sisyphus-x86_64/archive/2021/0208/error/chromium-88.0.4324.150-alt1.zst
> 
> Это wlimit_time_elapsed.
> 
> > Раньше такая же проблема была с firefox, но после его рефакторинга в
> > апстриме этой проблемы больше не наблюдается.
> 
> Там тоже был wlimit_time_elapsed, или wlimit_time_idle?

Вот убрал фильтр и сразу схватил письмо счастья:

http://git.altlinux.org/beehive/logs/Sisyphus-i586/latest/error/chromium-88.0.4324.150-alt1

hasher-priv: master: time elapsed limit (28800 seconds) exceeded

никогда не было и вот опять :)

-- 
Rgrds, legion

Re: [devel] Time limit

[Dmitry V. Levin]

On Fri, Feb 19, 2021 at 05:11:39PM +0100, Alexey Gladkov wrote:
> On Thu, Feb 18, 2021 at 02:22:37AM +0300, Dmitry V. Levin wrote:
[...]
> > $ ls beehive/logs/Sisyphus/x86_64/archive/2021/0???/error/chromium-8* |wc -l
> > 6
> > $ ls beehive/logs/Sisyphus/x86_64/archive/2021/0???/success/chromium-8* |wc -l
> > 35
> > 
> > 6/(6+35) = 6/41
> > На мой взгляд, это заметно меньше 100%.
> > Плохо, но не фатально.

> Вот убрал фильтр и сразу схватил письмо счастья:
> 
> http://git.altlinux.org/beehive/logs/Sisyphus-i586/latest/error/chromium-88.0.4324.150-alt1
> 
> hasher-priv: master: time elapsed limit (28800 seconds) exceeded
> 
> никогда не было и вот опять :)

Вытянул счастливый билет! :)


-- 
ldv