* [devel] Опыты с ускорением и экономией памяти при параллельной пересборке.
@ 2019-03-19 20:31 Igor Vlasenko
2019-03-23 10:57 ` Igor Vlasenko
2019-03-25 1:14 ` [devel] overoptimizing hasher Dmitry V. Levin
0 siblings, 2 replies; 18+ messages in thread
From: Igor Vlasenko @ 2019-03-19 20:31 UTC (permalink / raw)
To: devel
Ускорение и экономия памяти при параллельной пересборке
с фиксированным репозиторием.
Кому интересен данный текст:
Нужна пересборка с большим количеством пакетов
(beehive ?), либо протестировать пересборку
с новой библиотекой, к примеру, новый питон.
Или параллельно собирать образы в hasher.
Или еще что-то делать одновременно на нескольких
hasher но с одним репозиторием.
Исходная проблема:
На altair можно было параллельно запустить 16-20
параллельных сборок в tmpfs, Я же хотел 32. Ядра там есть,
но на большее уже не хватало памяти.
Нужно уменьшить расход памяти.
Куда уходит в tmpfs память?
Часть, естественно, на chroot-ы,
Но, как оказалось, больше трети,
почти половину в случае легких пакетов (perl-* и т. д.)
забирает hasher на свои служебные нужды.
У нас репозиторий статический,
синхронизируется ночью и во время пересборки меняться не будет.
Поэтому теоретически достаточно создать для
каждой архитектуры единственный hasher workdir
и затем его повторно использовать.
du -sh hasher (без chroot)
500M для sisyphus
640M для sisyphus+autoimports
Умножив, получим 640M*31=20G возможной экономии.
Убрав дублирование, сможем наслаждаться сборкой в 32 потока.
Как это сделать?
Я создаю кеш hasher workdir с помощью
hsh --with-stuff --initroot-only --apt-conf=...
затем хардлинкую на нужное число hasherX
mkdir hasherX
cp -rl кеш/{aptbox,cache} hasherX
rm && touch
pid
aptbox/var/cache/apt/archives/lock \
aptbox/var/lib/apt/lists/lock \
aptbox/var/lib/rpm/.rpm.lock \
aptbox/var/lib/rpm/.dbenv.lock
Затем в идеале я бы сказал
hsh-mkchroot
hsh-initroot
hsh-rebuild
и у меня не только экономилась бы память, но и ускорялась бы сборка:
на mkaptbox c нуля hsh тратит около минуты, а поверх имеющегося -
порядка 20с.
Я же пропускал бы эти (1м|20с.) при сборке и по 20с. на
тестировании установки собранных бинарных пакетов
(а у нас в среднем 3 бинарных на 1 src)
т.е. заодно сборка-тестирование ускорились бы на полторы минуты на
каждый пакет.
Пока так хорошо не получается. Надо будет пропатчить
hsh-initroot, добавить в него полноценную поддержку
такого режима работы. Сейчас же hsh-initroot
с aptbox/'ом от hsh --initroot-only работать не хочет.
Кеш cache/chroot/chroot.cpio там есть.
Но при этом chroot нет, aptbox rpmdb говорит что build_list установлен,
hsh-initroot в недоумении:
fatal 'Failed to generate non-empty build package file list; check your sources.list'
Без патчения hsh-initchroot я пока извращаюсь
следующим образом:
При создании кеша hasher workdir после
hsh --with-stuff --initroot-only --apt-conf=...
я еще вызываю mkaptbox --with-stuff --initroot-only --apt-conf=...
Такой aptbox hsh-initroot уже кушает.
При этом я, как и до оптимизации, теряю 20с на раздумья hsh-initroot
и 200 Mb на то, что во время этих раздумий hsh-initroot
пересоздает
aptbox/var/cache/apt/pkgcache.bin
aptbox/var/cache/apt/srcpkgcache.bin
Но зато cache/chroot/chroot.cpio
и aptbox/var/lib/apt/lists остаются хардлинкованными,
что дает мне экономию в 440 Mb per hasher
или же 16Gb при запуске в altair.
Хотелось бы дожать такую оптимизацию до экономии всех 640 Mb
и полного отсутствия лагов.
В будущем она пригодится и для beehive,
и в сборочнице (например, в тесте на устанавливаемость)
и во многих других местах.
--
I V
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] Опыты с ускорением и экономией памяти при параллельной пересборке.
2019-03-19 20:31 [devel] Опыты с ускорением и экономией памяти при параллельной пересборке Igor Vlasenko
@ 2019-03-23 10:57 ` Igor Vlasenko
2019-03-25 1:14 ` [devel] overoptimizing hasher Dmitry V. Levin
1 sibling, 0 replies; 18+ messages in thread
From: Igor Vlasenko @ 2019-03-23 10:57 UTC (permalink / raw)
To: devel
On Tue, Mar 19, 2019 at 10:31:21PM +0200, Igor Vlasenko wrote:
> Пока так хорошо не получается. Надо будет пропатчить
> hsh-initroot, добавить в него полноценную поддержку
> такого режима работы. Сейчас же hsh-initroot
> с aptbox/'ом от hsh --initroot-only работать не хочет.
> Кеш cache/chroot/chroot.cpio там есть.
> Но при этом chroot нет, aptbox rpmdb говорит что build_list установлен,
> hsh-initroot в недоумении:
> fatal 'Failed to generate non-empty build package file list; check your sources.list'
> Без патчения hsh-initchroot я пока извращаюсь
> следующим образом: ...
Пропатчил hsh-initchroot. Теперь погоняю с ним
недельку-две свою сборочницу для autoimorts
на альтаире и буду готовить pull request.
--
I V
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] overoptimizing hasher
2019-03-19 20:31 [devel] Опыты с ускорением и экономией памяти при параллельной пересборке Igor Vlasenko
2019-03-23 10:57 ` Igor Vlasenko
@ 2019-03-25 1:14 ` Dmitry V. Levin
2019-03-25 4:34 ` Anton Farygin
` (2 more replies)
1 sibling, 3 replies; 18+ messages in thread
From: Dmitry V. Levin @ 2019-03-25 1:14 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 981 bytes --]
On Tue, Mar 19, 2019 at 10:31:21PM +0200, Igor Vlasenko wrote:
[...]
> У нас репозиторий статический,
> синхронизируется ночью и во время пересборки меняться не будет.
> Поэтому теоретически достаточно создать для
> каждой архитектуры единственный hasher workdir
> и затем его повторно использовать.
Тестовая пересборка проводится на снапшоте репозитория,
что создаёт предпосылки для оптимизации.
Первый hsh --initroot (без кэша) занимает там около 21 сек,
повторные (с кэшом) -- около 10.5 сек.
Если кэшировать aptbox после initroot, то
повторные hsh --initroot занимают там около 2.3 сек.
Суммарное время пересборки Сизифа при таком кэшировании получается
примерно на 40 часов меньше, что в теории на нынешнем оборудовании
могло бы сократить время тестовой пересборки примерно на 15 минут.
К сожалению, такая оптимизация, будучи реализованной в hasher,
выглядит как жульничество, поскольку проверки валидности кэша
нет и не может быть.
--
ldv
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] overoptimizing hasher
2019-03-25 1:14 ` [devel] overoptimizing hasher Dmitry V. Levin
@ 2019-03-25 4:34 ` Anton Farygin
2019-03-27 23:52 ` Dmitry V. Levin
2019-04-02 21:40 ` Igor Vlasenko
2 siblings, 0 replies; 18+ messages in thread
From: Anton Farygin @ 2019-03-25 4:34 UTC (permalink / raw)
To: ALT Linux Team development discussions, Dmitry V. Levin
25.03.2019 4:14, Dmitry V. Levin пишет:
> Первый hsh --initroot (без кэша) занимает там около 21 сек,
> повторные (с кэшом) -- около 10.5 сек.
>
> Если кэшировать aptbox после initroot, то
> повторные hsh --initroot занимают там около 2.3 сек.
Может быть есть смысл вернуться к идее apt'а как сервиса (apt-pipe) ?
apt-get во время обычной сборки пакета 6 раз. Время запуска apt'а
порядка 2 секунд. Можно на одном пакете сэкономить 10 секунд на каждой
сборке, что в сумме даст около 4000 минут машинного времени на всех пакетах.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] overoptimizing hasher
2019-03-25 1:14 ` [devel] overoptimizing hasher Dmitry V. Levin
2019-03-25 4:34 ` Anton Farygin
@ 2019-03-27 23:52 ` Dmitry V. Levin
2019-04-02 21:27 ` Igor Vlasenko
2019-04-02 21:40 ` Igor Vlasenko
2 siblings, 1 reply; 18+ messages in thread
From: Dmitry V. Levin @ 2019-03-27 23:52 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
On Mon, Mar 25, 2019 at 04:14:09AM +0300, Dmitry V. Levin wrote:
> On Tue, Mar 19, 2019 at 10:31:21PM +0200, Igor Vlasenko wrote:
> [...]
> > У нас репозиторий статический,
> > синхронизируется ночью и во время пересборки меняться не будет.
> > Поэтому теоретически достаточно создать для
> > каждой архитектуры единственный hasher workdir
> > и затем его повторно использовать.
>
> Тестовая пересборка проводится на снапшоте репозитория,
> что создаёт предпосылки для оптимизации.
>
> Первый hsh --initroot (без кэша) занимает там около 21 сек,
> повторные (с кэшом) -- около 10.5 сек.
>
> Если кэшировать aptbox после initroot, то
> повторные hsh --initroot занимают там около 2.3 сек.
>
> Суммарное время пересборки Сизифа при таком кэшировании получается
> примерно на 40 часов меньше, что в теории на нынешнем оборудовании
> могло бы сократить время тестовой пересборки примерно на 15 минут.
>
> К сожалению, такая оптимизация, будучи реализованной в hasher,
> выглядит как жульничество, поскольку проверки валидности кэша
> нет и не может быть.
Я запушил 1.3.35-alt1-4-gafd5ba4 в hasher.git, можно пробовать.
--
ldv
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] overoptimizing hasher
2019-03-25 1:14 ` [devel] overoptimizing hasher Dmitry V. Levin
2019-03-25 4:34 ` Anton Farygin
2019-03-27 23:52 ` Dmitry V. Levin
@ 2019-04-02 21:40 ` Igor Vlasenko
2019-04-03 4:50 ` Anton Farygin
2 siblings, 1 reply; 18+ messages in thread
From: Igor Vlasenko @ 2019-04-02 21:40 UTC (permalink / raw)
To: ALT Linux Team development discussions
On Mon, Mar 25, 2019 at 04:14:09AM +0300, Dmitry V. Levin wrote:
> Тестовая пересборка проводится на снапшоте репозитория,
> что создаёт предпосылки для оптимизации.
>
> Первый hsh --initroot (без кэша) занимает там около 21 сек,
> повторные (с кэшом) -- около 10.5 сек.
>
> Если кэшировать aptbox после initroot, то
> повторные hsh --initroot занимают там около 2.3 сек.
>
> Суммарное время пересборки Сизифа при таком кэшировании получается
> примерно на 40 часов меньше, что в теории на нынешнем оборудовании
> могло бы сократить время тестовой пересборки примерно на 15 минут.
Для меня основное ускорение пересборки получается не из-за
этой экономии в 20 сек. с каждой пересборки,
а из-за того, что схардлинковав эти кеши,
я снижаю потребление hasherом памяти в tmpfs
что позволяет запускать больше пересборок параллельно.
Было: altair с 32 cores, но мог запустить параллельно только
16-24 параллельно работающих hasherов.
Теперь запускаю все 32 hasherа, и еще памяти хватает.
ускорился в 32/24=1.5 - 32/16=2 раза,
в полтора-два раза!
Для beehive такое тоже не помешало бы.
--
I V
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] overoptimizing hasher
2019-04-02 21:40 ` Igor Vlasenko
@ 2019-04-03 4:50 ` Anton Farygin
2019-04-04 15:58 ` Igor Vlasenko
2019-04-04 16:36 ` Igor Zubkov
0 siblings, 2 replies; 18+ messages in thread
From: Anton Farygin @ 2019-04-03 4:50 UTC (permalink / raw)
To: devel
03.04.2019 0:40, Igor Vlasenko пишет:
> On Mon, Mar 25, 2019 at 04:14:09AM +0300, Dmitry V. Levin wrote:
>> Тестовая пересборка проводится на снапшоте репозитория,
>> что создаёт предпосылки для оптимизации.
>>
>> Первый hsh --initroot (без кэша) занимает там около 21 сек,
>> повторные (с кэшом) -- около 10.5 сек.
>>
>> Если кэшировать aptbox после initroot, то
>> повторные hsh --initroot занимают там около 2.3 сек.
>>
>> Суммарное время пересборки Сизифа при таком кэшировании получается
>> примерно на 40 часов меньше, что в теории на нынешнем оборудовании
>> могло бы сократить время тестовой пересборки примерно на 15 минут.
> Для меня основное ускорение пересборки получается не из-за
> этой экономии в 20 сек. с каждой пересборки,
> а из-за того, что схардлинковав эти кеши,
> я снижаю потребление hasherом памяти в tmpfs
> что позволяет запускать больше пересборок параллельно.
>
> Было: altair с 32 cores, но мог запустить параллельно только
> 16-24 параллельно работающих hasherов.
> Теперь запускаю все 32 hasherа, и еще памяти хватает.
> ускорился в 32/24=1.5 - 32/16=2 раза,
> в полтора-два раза!
> Для beehive такое тоже не помешало бы.
>
А можно просто перейти в hasher root на Optane SSD с петабайтным
ресурсом. Разницы с tmpfs вы не заметите.
https://www.hardwareluxx.ru/index.php/artikel/hardware/storage/44163-intel-optane-ssd-900p-280-gb-3d-xpoint.html?start=2
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] overoptimizing hasher
2019-04-03 4:50 ` Anton Farygin
@ 2019-04-04 15:58 ` Igor Vlasenko
2019-04-04 16:09 ` Anton Farygin
` (2 more replies)
2019-04-04 16:36 ` Igor Zubkov
1 sibling, 3 replies; 18+ messages in thread
From: Igor Vlasenko @ 2019-04-04 15:58 UTC (permalink / raw)
To: ALT Linux Team development discussions
On Wed, Apr 03, 2019 at 07:50:59AM +0300, Anton Farygin wrote:
> А можно просто перейти в hasher root на Optane SSD с петабайтным
> ресурсом. Разницы с tmpfs вы не заметите.
>
> https://www.hardwareluxx.ru/index.php/artikel/hardware/storage/44163-intel-optane-ssd-900p-280-gb-3d-xpoint.html?start=2
Хорошо бы такое в altair установить.
А то народ пристрастился постоянно держать данные
на altair в оперативке,
что и слишком дорого - хранить в оперативке
обходится в 400 руб/гб,
а не на диске 2 руб/гб,
и не надежно - сервер перезагрузится и все пропадет.
Плюс оперативки на всех не хватит.
Кто такие заявки принимает?
--
I V
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] overoptimizing hasher
2019-04-04 15:58 ` Igor Vlasenko
@ 2019-04-04 16:09 ` Anton Farygin
2019-04-04 16:13 ` Anton Farygin
2019-04-04 16:27 ` Alexey V. Vissarionov
2 siblings, 0 replies; 18+ messages in thread
From: Anton Farygin @ 2019-04-04 16:09 UTC (permalink / raw)
To: ALT Linux Team development discussions, Igor Vlasenko
04.04.2019 18:58, Igor Vlasenko пишет:
> On Wed, Apr 03, 2019 at 07:50:59AM +0300, Anton Farygin wrote:
>> А можно просто перейти в hasher root на Optane SSD с петабайтным
>> ресурсом. Разницы с tmpfs вы не заметите.
>>
>> https://www.hardwareluxx.ru/index.php/artikel/hardware/storage/44163-intel-optane-ssd-900p-280-gb-3d-xpoint.html?start=2
> Хорошо бы такое в altair установить.
> А то народ пристрастился постоянно держать данные
> на altair в оперативке,
> что и слишком дорого - хранить в оперативке
> обходится в 400 руб/гб,
> а не на диске 2 руб/гб,
> и не надежно - сервер перезагрузится и все пропадет.
>
> Плюс оперативки на всех не хватит.
>
> Кто такие заявки принимает?
>
Нужно обратиться к администратору этого сервера. Я не уверен, что во все
наши сервера можно установить эти платы.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] overoptimizing hasher
2019-04-04 15:58 ` Igor Vlasenko
2019-04-04 16:09 ` Anton Farygin
@ 2019-04-04 16:13 ` Anton Farygin
2019-04-04 16:27 ` Alexey V. Vissarionov
2 siblings, 0 replies; 18+ messages in thread
From: Anton Farygin @ 2019-04-04 16:13 UTC (permalink / raw)
To: ALT Linux Team development discussions, Igor Vlasenko
04.04.2019 18:58, Igor Vlasenko пишет:
> On Wed, Apr 03, 2019 at 07:50:59AM +0300, Anton Farygin wrote:
>> А можно просто перейти в hasher root на Optane SSD с петабайтным
>> ресурсом. Разницы с tmpfs вы не заметите.
>>
>> https://www.hardwareluxx.ru/index.php/artikel/hardware/storage/44163-intel-optane-ssd-900p-280-gb-3d-xpoint.html?start=2
> Хорошо бы такое в altair установить.
> А то народ пристрастился постоянно держать данные
> на altair в оперативке,
> что и слишком дорого - хранить в оперативке
> обходится в 400 руб/гб,
> а не на диске 2 руб/гб,
> и не надежно - сервер перезагрузится и все пропадет.
И да, быстрые ssd так же как и оперативка - не предназначены для
хранения данных.
А где раздают такую серверную дешевую оперативку, по 400 рублей за
гигабайт ?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] overoptimizing hasher
2019-04-04 15:58 ` Igor Vlasenko
2019-04-04 16:09 ` Anton Farygin
2019-04-04 16:13 ` Anton Farygin
@ 2019-04-04 16:27 ` Alexey V. Vissarionov
2019-04-06 16:35 ` Anton Farygin
2 siblings, 1 reply; 18+ messages in thread
From: Alexey V. Vissarionov @ 2019-04-04 16:27 UTC (permalink / raw)
To: ALT Linux Team development discussions
On 2019-04-04 18:58:48 +0300, Igor Vlasenko wrote:
>> А можно просто перейти в hasher root на Optane SSD с петабайтным
>> ресурсом. Разницы с tmpfs вы не заметите.
> Хорошо бы такое в altair установить. А то народ пристрастился
> постоянно держать данные на altair в оперативке, что и слишком
> дорого - хранить в оперативке обходится в 400 руб/гб, а не на
> диске 2 руб/гб,
Я бы, пожалуй, на такую штуку swap отправил...
> и не надежно - сервер перезагрузится и все пропадет.
Это не техническая проблема: кладем что-то в tmpfs - принимаем
риск потери этих данных. Такова цена производительности.
> Плюс оперативки на всех не хватит.
У меня в свое время была мысль сделать накопитель для swap из
старой оперативки (чтобы при каждой загрузке делать там mkswap
и swapon). Посмотрел в сторону ПЛМ. Увидел ценники на готовые
модули поддержки SATA/SAS и DDR2/DDR3. Пришел к выводу, что мне
дешевле выйдет раз в 3...5 лет покупать топовый компутер, под
завязку набитый актуальной на тот момент памятью (сейчас это
была бы плата на X299 с разъемом ЦП LGA2066, куда можно сунуть
i9 7960X и 128 Гб памяти).
Проприетарщики, [тут был мегабайт мата] ...
--
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] overoptimizing hasher
2019-04-04 16:27 ` Alexey V. Vissarionov
@ 2019-04-06 16:35 ` Anton Farygin
2019-04-06 17:31 ` Yuri Sedunov
0 siblings, 1 reply; 18+ messages in thread
From: Anton Farygin @ 2019-04-06 16:35 UTC (permalink / raw)
To: ALT Linux Team development discussions, Alexey V. Vissarionov
04.04.2019 19:27, Alexey V. Vissarionov пишет:
> On 2019-04-04 18:58:48 +0300, Igor Vlasenko wrote:
>
> > Плюс оперативки на всех не хватит.
>
> У меня в свое время была мысль сделать накопитель для swap из
> старой оперативки (чтобы при каждой загрузке делать там mkswap
> и swapon). Посмотрел в сторону ПЛМ. Увидел ценники на готовые
> модули поддержки SATA/SAS и DDR2/DDR3. Пришел к выводу, что мне
> дешевле выйдет раз в 3...5 лет покупать топовый компутер, под
> завязку набитый актуальной на тот момент памятью (сейчас это
> была бы плата на X299 с разъемом ЦП LGA2066, куда можно сунуть
> i9 7960X и 128 Гб памяти).
https://www.ixbt.com/news/2019/04/06/intel-optane-dc-850-2800.html
Вот вам и аппаратный своп. Цена высокая, но дешевле DDR4 прямо заметно.
Особенно если учесть то, сколько такой памяти можно пихнуть в один сервер.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] overoptimizing hasher
2019-04-06 16:35 ` Anton Farygin
@ 2019-04-06 17:31 ` Yuri Sedunov
2019-04-06 17:39 ` Anton Farygin
0 siblings, 1 reply; 18+ messages in thread
From: Yuri Sedunov @ 2019-04-06 17:31 UTC (permalink / raw)
To: devel
В Сб, 06/04/2019 в 19:35 +0300, Anton Farygin пишет:
> 04.04.2019 19:27, Alexey V. Vissarionov пишет:
> > On 2019-04-04 18:58:48 +0300, Igor Vlasenko wrote:
> >
> > > Плюс оперативки на всех не хватит.
> >
> > У меня в свое время была мысль сделать накопитель для swap из
> > старой оперативки (чтобы при каждой загрузке делать там mkswap
> > и swapon). Посмотрел в сторону ПЛМ. Увидел ценники на готовые
> > модули поддержки SATA/SAS и DDR2/DDR3. Пришел к выводу, что мне
> > дешевле выйдет раз в 3...5 лет покупать топовый компутер, под
> > завязку набитый актуальной на тот момент памятью (сейчас это
> > была бы плата на X299 с разъемом ЦП LGA2066, куда можно сунуть
> > i9 7960X и 128 Гб памяти).
>
> https://www.ixbt.com/news/2019/04/06/intel-optane-dc-850-2800.html
>
> Вот вам и аппаратный своп. Цена высокая, но дешевле DDR4 прямо
> заметно.
> Особенно если учесть то, сколько такой памяти можно пихнуть в один
> сервер.
https://en.wikipedia.org/wiki/NVDIMM
--
Yuri N. Sedunov
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] overoptimizing hasher
2019-04-06 17:31 ` Yuri Sedunov
@ 2019-04-06 17:39 ` Anton Farygin
0 siblings, 0 replies; 18+ messages in thread
From: Anton Farygin @ 2019-04-06 17:39 UTC (permalink / raw)
To: ALT Linux Team development discussions, Yuri Sedunov
06.04.2019 20:31, Yuri Sedunov пишет:
> В Сб, 06/04/2019 в 19:35 +0300, Anton Farygin пишет:
>> 04.04.2019 19:27, Alexey V. Vissarionov пишет:
>>> On 2019-04-04 18:58:48 +0300, Igor Vlasenko wrote:
>>>
>>> > Плюс оперативки на всех не хватит.
>>>
>>> У меня в свое время была мысль сделать накопитель для swap из
>>> старой оперативки (чтобы при каждой загрузке делать там mkswap
>>> и swapon). Посмотрел в сторону ПЛМ. Увидел ценники на готовые
>>> модули поддержки SATA/SAS и DDR2/DDR3. Пришел к выводу, что мне
>>> дешевле выйдет раз в 3...5 лет покупать топовый компутер, под
>>> завязку набитый актуальной на тот момент памятью (сейчас это
>>> была бы плата на X299 с разъемом ЦП LGA2066, куда можно сунуть
>>> i9 7960X и 128 Гб памяти).
>> https://www.ixbt.com/news/2019/04/06/intel-optane-dc-850-2800.html
>>
>> Вот вам и аппаратный своп. Цена высокая, но дешевле DDR4 прямо
>> заметно.
>> Особенно если учесть то, сколько такой памяти можно пихнуть в один
>> сервер.
>
> https://en.wikipedia.org/wiki/NVDIMM
>
>
Там цена намного выше, а не ниже DDR4.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [devel] overoptimizing hasher
2019-04-03 4:50 ` Anton Farygin
2019-04-04 15:58 ` Igor Vlasenko
@ 2019-04-04 16:36 ` Igor Zubkov
2019-04-04 16:37 ` Anton Farygin
2019-04-04 16:47 ` Alexey V. Vissarionov
1 sibling, 2 replies; 18+ messages in thread
From: Igor Zubkov @ 2019-04-04 16:36 UTC (permalink / raw)
To: ALT Linux Team development discussions
On Wed, Apr 3, 2019 at 7:51 AM Anton Farygin wrote:
> А можно просто перейти в hasher root на Optane SSD с петабайтным
> ресурсом. Разницы с tmpfs вы не заметите.
>
> https://www.hardwareluxx.ru/index.php/artikel/hardware/storage/44163-intel-optane-ssd-900p-280-gb-3d-xpoint.html?start=2
https://hard.rozetka.com.ua/ua/intel_ssdpekkw010t8x1/p58440117/#tab=characteristics
Intel 760p m2 по скорости тоже самое (ну почти), а по цене в 4 раза
дешевле. Только m2 нужно на материке.
Или 3D XPoint лучше TLC?
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-04-06 17:39 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-19 20:31 [devel] Опыты с ускорением и экономией памяти при параллельной пересборке Igor Vlasenko
2019-03-23 10:57 ` Igor Vlasenko
2019-03-25 1:14 ` [devel] overoptimizing hasher Dmitry V. Levin
2019-03-25 4:34 ` Anton Farygin
2019-03-27 23:52 ` Dmitry V. Levin
2019-04-02 21:27 ` Igor Vlasenko
2019-04-02 21:40 ` Igor Vlasenko
2019-04-03 4:50 ` Anton Farygin
2019-04-04 15:58 ` Igor Vlasenko
2019-04-04 16:09 ` Anton Farygin
2019-04-04 16:13 ` Anton Farygin
2019-04-04 16:27 ` Alexey V. Vissarionov
2019-04-06 16:35 ` Anton Farygin
2019-04-06 17:31 ` Yuri Sedunov
2019-04-06 17:39 ` Anton Farygin
2019-04-04 16:36 ` Igor Zubkov
2019-04-04 16:37 ` Anton Farygin
2019-04-04 16:47 ` Alexey V. Vissarionov
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git