ARC max size

Slawa Olhovchenkov написал(а) к Eugene Grosbein в May 18 07:35:12 по местному времени:

Нello Eugene!

13 May 18, Eugene Grosbein writes to Slawa Olhovchenkov:

EG>>> UFS2+gjournal over stripe?
SO>> я знал что ты это хуйню предложишь.
SO>> 1) страйп: при умирании диска все идет нахуй

EG> А у тебя нету разве резервирования per-box,
EG> ну то есть если что угодно в ящике сдохло
EG> (материнка/бп/дисковая подсистема), то его нагрузку
EG> берут другие ящики,

у меня железо -- не хетнецеровская отработка, самого железа не настолько много, что бы это имело экономический смысл.

EG> а этот неспешно ремонтируется и перезаливается?

перезаливать 30ТБ в любом случае очень весело

EG> Если нет, ну тогда over RAID10 вместо страйпа.

о. raid10. т.е. вместо 6 часов в идеале или 18 часов в реальности мне нужно будет ждать синкания полторы недели. очень смешно.

SO>> 2) UFS2: максимальный размер блока 64КБ (ЕМНИП),

EG> Да.

SO>> значит производительность с одного шпинделя 9МБ/с, вместо 50МБ/с на
SO>> мегабайтном блоке в случае ZFS

EG> Это может у ZFS девять мегабайт в секунду - не мерял, не знаю.
EG> А вот нетюненная FreeBSD при чтении файла блоками по 64k
EG> реально читает по MAXPНYS=128K - видимо, из-за read-ahead,
EG> который нынче по дефолту vfs.read_max=64 (в блоках).

ну так и будет 9МБ/с, это я для 128К привел цифру.

EG> Кстати, на одном сервере у меня уменьшено до 8, как было по дефолту
EG> в восьмерке. Из-за характера нагрузки на этом сервере нежелательно
EG> тратить i/o bandwidth настолько щедро.

EG> В итоге systat -vm 3 показывает чтение с диска по скоростью
EG> 130-134 мегабайта в секунду вв время работы команды:

EG> # time dd bs=64k if=file-53GB of=/dev/null

а зачем мне вывод такой команды?
ты покажу суммарную производительность при паралельном чтении из 400 различных файлов.

SO>> 3) gjournal: ну лучше я не буду не коментировать

EG> А ты покомментируй. У тебя же read-mostly нагрузка,
EG> почему бы и не gjournal?

костыли и подпорки.
кеширование на SSD мне тоже самому из костылей и шелов городить?

... Чем дольше проживешь -- тем больше опозоришся.
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Eugene Grosbein в May 18 12:34:59 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

AK>> что читается-то блоками, а не посекторно. Без prefetch - "лишнее" тут же
AK>> роняется на пол. С ним - остается в arc на случай если вдруг понадобится.
EG> А если не понадобится, то мы потратили вовсе не бесконечный запас
EG> по скорости i/o дисков впустую: https://dadv.livejournal.com/204385.html
Женя, это hdd. Линейное чтение у них в сотни раз быстрее дрыганья головами.
А command queue позволяет дрыгать ими как раз в тот момент, когда до тебя
по шине только еще доезжает хвост прочитанного блока. Причем скорость его
доезда тоже существенно ниже пропускной способности шлейфа, большую часть
времени он простаивает.

что-то "ускорить" за счет отказа от prefetch можно только если жить вообще
без кэширования (тогда есть слабенький шанс что современный диск отдаст из
собственного кэша, и сделает это со скоростью шины, верно для недодесктопов,
у которых нынче может памяти быть меньше чем у подключенных к ним дисков ;)

для ssd все тоже очень интересно, учитывая придуманный каким-то идиотом
максимум для ashift, меньший, чем размер страницы ssd flash, и хорошие шансы
регулярно попадать мимо границы страниц, на более-менее сложных сетапах
практически неодолимые (и да, не забудь туда добавить ублюдочный
свой virtualbox с unaligned (a)io) - впрочем, хз как оно там у той же вмвари,
и не хуже ли), но скорее всего на чтении это не скажется. Только у меня нет
мильярда денех, поэтому реальность - rotational disks forever.

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


> Alex

--- ifmail v.2.15dev5.4

Alex Korchmar написал(а) к Slawa Olhovchenkov в May 18 12:54:59 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

SO> какой раз я уже прошу тебя продемонстрировать удобство на
SO> мальеньком примере? но все сводится к:
я не знаю как объяснить человеку, не умеющему в принципе работать с vcs,
в чем преимущества таки работы с ними. Попроси может Женю?

Ну или эта, книжку про svn прочитать - ту часть что про концепции, а не то что
про конкретные команды? (про git я не знаю хороших книжек, вероятно
их и нет, про hg книжка слишком уж упрощенно-детская, хороша для
тех, кто уже знает и умеет не-distributed, чтобы быстро понять, в
чем разница, потому что такими и для таких и писалось)

SO> ты говоришь либо фигню либо упускаешь детали. zfs читает не посекторно, а
я говорю по результатам тестов Тутубалина, которые подтверждают что все ровно
так и есть - читается блоками, "лишнее" роняется на пол, тут же перечитывается
заново. Как оно вот так получается при файлах в основном меньших чем блок (ну
или хотя бы половина их меньше) - хз.
Учти, кстати, что на compressed fs "блоки" переменной длинны, а не 128k.
(впрочем, Леха мерял до появления этого щастья)

У меня тестовой среды нет, а в рабочей могут быть всякие странности, вплоть до
неверной работы таймеров - но по грубым прикидкам с prefetch либо не хуже
(ssd), либо явно быстрее (хорошие, хотя и не первой молодости, сигейты)


> Alex

--- ifmail v.2.15dev5.4

Slawa Olhovchenkov написал(а) к Alex Korchmar в May 18 13:01:18 по местному времени:

Нello Alex!

13 May 18, Alex Korchmar writes to Slawa Olhovchenkov:

SO>> какой раз я уже прошу тебя продемонстрировать удобство на
SO>> мальеньком примере? но все сводится к:
AK> я не знаю как объяснить человеку, не умеющему в принципе работать с vcs,
AK> в чем преимущества таки работы с ними. Попроси может Женю?

с svn я знаю. ты топишь что с гит еще удобнее. но не показываешь.

SO>> ты говоришь либо фигню либо упускаешь детали. zfs читает не
SO>> посекторно, а
AK> я говорю по результатам тестов Тутубалина, которые подтверждают что
AK> все ровно так и есть - читается блоками, "лишнее" роняется на пол, тут
AK> же перечитывается заново.

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

AK> Как оно вот так получается при файлах в основном меньших чем блок (ну
AK> или хотя бы половина их меньше) - хз. Учти, кстати, что на compressed
AK> fs "блоки" переменной длинны, а не 128k.

пофиг. мелкий файл тоже не в блоке 128К лежит, в меньшем (в который влезает)

... Так я и знал -- с этой стороны ничуть не лучше!
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Slawa Olhovchenkov в May 18 14:36:02 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

SO>>> какой раз я уже прошу тебя продемонстрировать удобство на
SO>>> мальеньком примере? но все сводится к:
AK>> я не знаю как объяснить человеку, не умеющему в принципе работать с vcs,
AK>> в чем преимущества таки работы с ними. Попроси может Женю?
SO> с svn я знаю. ты топишь что с гит еще удобнее. но не показываешь.
я не вижу возможностей использовать svn не имея права писать в репо.
Если всего "знаю", это co/up, то ровно с тем же успехом ты бы мог использовать
"новая папка(234)"
А работа в svn - это совсем другое. freebsd, как мы поняли со слов Жени,
ее вообще не предполагает (оно и неудивительно, инструмент негодный для таких
проектов).

SO> вообще у него ситуация несколько иная -- ему надо очень быстро линейно
SO> читать, причем отдавать в сетку.
ненене, там же тест был на исходниках QT - локально. Они чуть побольше в
среднем моих файлов, но суть очень близкая. Тесты с экспортом виртуальных
томов мне не очень интересны, это не мой случай (там тоже все странненько)

К тому же сетка у него в те времена 10G без свитчей была, хз еще у кого тут
задержки больше - у нее или sata.

> Alex
P.S. мля, мне тут, оказывается, надо срочно переезжать на новый сервер -
старый сгнил. Ну и вот куды крестьянину податься? Плюнуть на все, поставить
proxmox?
У него zfs "просто работает", не верю своим глазам. То есть там
может и есть проблемы, но они где-то глубоко. Не поверишь - у них
на нее swap. И он - работает же ж, сука! (они там предупреждают,
что кто-то может надолго задуматься, но я на тестовой системе с
совершенно перекрученными лимитами никаких ужасов не увидел. И уж
тем более оно не виснет.) Плюс есть люди, которых менеджер п-т лопатой по
горбу, если оно вдруг работать перестает у клиентов, а не грантопилы.

Или тупо дать денег и поставить vmware ? Которая привычна, понятна, использует
проверенный временем дубовейший raid контроллер (который у меня есть), а
единственный явный минус - что нельзя ничего запустить на физическом хосте.
А zfs-based сетапы отложить еще лет на пять, когда те рейды сгниют
окончательно, а вмварь китайцы доломают... а глядишь, так и сам Ходжа Насреддин
предстанет пред Аллахом.

--- ifmail v.2.15dev5.4

Slawa Olhovchenkov написал(а) к Alex Korchmar в May 18 14:56:26 по местному времени:

Нello Alex!

13 May 18, Alex Korchmar writes to Slawa Olhovchenkov:

SO>>>> какой раз я уже прошу тебя продемонстрировать удобство на
SO>>>> мальеньком примере? но все сводится к:
AK>>> я не знаю как объяснить человеку, не умеющему в принципе работать с
AK>>> vcs, в чем преимущества таки работы с ними. Попроси может Женю?
SO>> с svn я знаю. ты топишь что с гит еще удобнее. но не показываешь.
AK> я не вижу возможностей использовать svn не имея права писать в репо.
AK> Если всего "знаю", это co/up, то ровно с тем же успехом ты бы мог
AK> использовать "новая папка(234)" А работа в svn - это совсем другое.
AK> freebsd, как мы поняли со слов Жени, ее вообще не предполагает (оно и
AK> неудивительно, инструмент негодный для таких проектов).

не надо бла-бла, просто покажи выйгрышный паттерн.

SO>> вообще у него ситуация несколько иная -- ему надо очень быстро
SO>> линейно читать, причем отдавать в сетку.
AK> ненене, там же тест был на исходниках QT - локально. Они чуть побольше
AK> в среднем моих файлов, но суть очень близкая.

если приложение читает с ощутимыми паузами, то префетч может дать выйгрышь и это эквивалентно отдачи в сетку.

AK> К тому же сетка у него в те времена 10G без свитчей была, хз еще у кого тут
AK> задержки больше - у нее или sata.

неважно. это в любом случае плюс задержка.

... Функция хвоста pыбы - pулезная!
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Slawa Olhovchenkov в May 18 15:15:03 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

SO> не надо бла-бла, просто покажи выйгрышный паттерн.
я не знаю какой для тебя выигрышный.
Меня интересовал выигрышный для себя - автоматизирующий все эти новые папки,
ручное сравнение и хранение десяти копий одного и того же патча для разных
версий системы.
Когда выяснилось, что вы этого просто не умеете - я предложил
как-нибудь, на досуге - посмотреть как это сделано у более вменяемых
проектов, или попробовать в своем мелком, не привязанном к чужому на древних
технологиях. Исключительно для самообразования - возможно, оно тебе
покажется поудобнее новых папок, если научиться этим пользоваться.

SO> если приложение читает с ощутимыми паузами,
а. Ну так следующий файл надо как минимум найти и открыть, вот тебе и пауза.

AK>> задержки больше - у нее или sata.
SO> неважно. это в любом случае плюс задержка.
они параллельны. Так что вторую ты можешь не померять за невидимостью на
фоне первой.
А вот роняния уже прочитанных блоков на пол - вполне, оказывается, видны.


> Alex

--- ifmail v.2.15dev5.4

Slawa Olhovchenkov написал(а) к Alex Korchmar в May 18 15:31:18 по местному времени:

Нello Alex!

13 May 18, Alex Korchmar writes to Slawa Olhovchenkov:

SO>> не надо бла-бла, просто покажи выйгрышный паттерн.
AK> я не знаю какой для тебя выигрышный.
AK> Меня интересовал выигрышный для себя - автоматизирующий все эти новые
AK> папки, ручное сравнение и хранение десяти копий одного и того же патча для
AK> разных версий системы. Когда выяснилось, что вы этого просто не умеете - я
AK> предложил как-нибудь, на досуге - посмотреть как это сделано у более
AK> вменяемых проектов, или попробовать в своем мелком, не привязанном к чужому
AK> на древних технологиях. Исключительно для самообразования - возможно, оно
AK> тебе покажется поудобнее новых папок, если научиться этим пользоваться.

ну так покажи. а то что мне там делать?
git clone --recursive и потом rm -rf потому как никто так и не сказал что делать?

SO>> если приложение читает с ощутимыми паузами,
AK> а. Ну так следующий файл надо как минимум найти и открыть, вот тебе и
AK> пауза.

префетч на следующий файл не умеет.

AK>>> задержки больше - у нее или sata.
SO>> неважно. это в любом случае плюс задержка.
AK> они параллельны. Так что вторую ты можешь не померять за невидимостью на
AK> фоне первой.

последовательны в пределах одного запроса.

AK> А вот роняния уже прочитанных блоков на пол - вполне, оказывается,
AK> видны.

нет такого.

... F8 - Copy? Кто ж тебе сказал?
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Slawa Olhovchenkov в May 18 16:17:05 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

SO> ну так покажи. а то что мне там делать?
git clone git://github.com/Synzvato/decentraleyes
git fetch origin pull/174/head:Eissturmvogel # малоизвестная фича гитхаба
git diff НEAD Eissturmvogel -- # говно, не получится
...skip...
git stash
git checkout legacy
git merge Eissturmvogel

например.

SO> префетч на следующий файл не умеет.
блок же ж.
(следующий там файл или мы к нему придем через пятнадцать минут - arc его
разберет)

AK>> А вот роняния уже прочитанных блоков на пол - вполне, оказывается,
AK>> видны.
SO> нет такого.
ну вот у Лехи были видны. Причем на use pattern, который к моим явно ближе
чем последовательная раздача стагиговых файлов с порно. Тебе, видимо, не
нужно ни сжатие, ни префетч...стесняюсь спросить, а зачем тебе arc?


> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Slawa Olhovchenkov в May 18 07:24:30 по местному времени:

13 мая 2018, воскресенье, в 05:35 NOVT, Slawa Olhovchenkov написал(а):

EG>> Если нет, ну тогда over RAID10 вместо страйпа.
SO> о. raid10. т.е. вместо 6 часов в идеале или 18 часов в реальности мне нужно
SO> будет ждать синкания полторы недели. очень смешно.

Но почему? Линейная запись на graid (RAID10) без лишних конкурирующих
запросов, в два потока, должна идти со скоростью записи на страйп,
то есть вдвое быстрее, чем на один диск.

SO>>> 2) UFS2: максимальный размер блока 64КБ (ЕМНИП),
EG>> Да.
SO>>> значит производительность с одного шпинделя 9МБ/с, вместо 50МБ/с на
SO>>> мегабайтном блоке в случае ZFS
EG>> Это может у ZFS девять мегабайт в секунду - не мерял, не знаю.
EG>> А вот нетюненная FreeBSD при чтении файла блоками по 64k
EG>> реально читает по MAXPНYS=128K - видимо, из-за read-ahead,
EG>> который нынче по дефолту vfs.read_max=64 (в блоках).
SO> ну так и будет 9МБ/с, это я для 128К привел цифру.
EG>> Кстати, на одном сервере у меня уменьшено до 8, как было по дефолту
EG>> в восьмерке. Из-за характера нагрузки на этом сервере нежелательно
EG>> тратить i/o bandwidth настолько щедро.
EG>> В итоге systat -vm 3 показывает чтение с диска по скоростью
EG>> 130-134 мегабайта в секунду вв время работы команды:
EG>> # time dd bs=64k if=file-53GB of=/dev/null
SO> а зачем мне вывод такой команды?
SO> ты покажу суммарную производительность при паралельном чтении из 400 различных
SO> файлов.

То есть речь идёт об дергании головками НDD? А i/o scheduling пробовал?

Вроде на фряхе есть пара реализаций, одну кстати как раз Netflix с тем же профилем
нагрузки и впиливал в ядро: https://people.freebsd.org/~imp/bsdc...iosched-v3.pdf
Оно нынче options CAMIOSCНEDDYNAMIC называется.

SO>>> 3) gjournal: ну лучше я не буду не коментировать
EG>> А ты покомментируй. У тебя же read-mostly нагрузка,
EG>> почему бы и не gjournal?
SO> костыли и подпорки.
SO> кеширование на SSD мне тоже самому из костылей и шелов городить?

Ну так я и спрашивал, для чего ZFS. Теперь понятно,
для L2ARC на SSD и агрессивного кеширования диска.

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.2 (FreeBSD)