LINUX.ORG.RU

Как отговорить себя от написания своей ФС

 , high performance,


1

4

Моя идея о том, чтобы переписать наш Flussonic с Erlang на Rust оказалась совершенно прекрасной и у меня совершенно прекрасные результаты. Захват 10 000 камер на сервер - это прямо скажем серьезный результат, на рынке таких предложений мало.

Однако трафик записи в 16-17 гигабит на 38 шпинделей - не предел возможности диска, это порядка 420 мегабит, а в теории шпиндель может принять и до 2 000 мегабит.

Единственная мысль, которая осталась после всех оптимизаций (выравнивание по границе блока, fadvise) - это хранение данных в одном файле в interleaved режиме, т.е. все камеры на одном диске держать в одном файле.

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

Давайте 3 причины не лезть в этот блуд.

Давайте 3 причины не лезть в этот блуд.

Rust, Rust, Rust.

dataman ★★★★★
()

Хотел ответить по делу но увидел rust и понял что надо троллить

ckotctvo
()

Я думал так делают даже китайские дешёвые видеорегистраторы. Именно поэтому там надо «экспортировать видео» на флешку.

Это ведь потому что там своя фс и свой формат записи на диск оптимизированный для стриминга с камер да? Да ведь?

// Или у меня слишком фантастические представления о дешёвых китайских регистраторах

Bad_ptr ★★★★★
()

Так и появляются черезжопные проприетарные ФС в видеорегистраторах, которые при сбоях невозможно восстановить и даже принормальной работе приходится использовать всратый софт, который сам по себе ощущается как катастрофа.

Смотрел в сторону видеоконтейнеров типа mkv? Они умеют писать несколько потоков без seek.

legolegs ★★★★★
()

Поддерживаю идею.

Осуждаю адептов подхода «вот там же готовое есть давай его подкостылим чтобы кое-как подходило».

firkax ★★★★★
()

А ты точно замерил свои диски? Вообще-то ФС с нагрузками подобного рода должны справляться хорошо. Главное - иметь достаточно оперативной памяти, чтобы оно буферизовалось, пока на диск не выгрузится. А дальше уже планировщик выдаст достаточно оптимальный маршрут для записи.

В общем через dd c O_DIRECT я бы сначала замерил, диск вообще примет на желаемой скорости данные на достаточно длинном отрезке времени (чтобы исключить всякие кеширования внутри диска).

vbr ★★★★★
()

Прежде чем писать свою ФС, подумай о жене

lovesan ★★☆
()

XFS хорошо справляется с подобной линейной записью большими блоками. Планировщик mq-deadline хорош для линейной записи на hdd.

anonymous
()

это хранение данных в одном файле в interleaved режиме

Это просто организация последовательной записи. Чтобы лишний раз не дёргать головой. Как именно оно будет сделано, не так уж важно. ФС тут ИМХО вообще ни при чём. Но перед любыми телодвижениями сначала нужны тесты текущей ситуации. В частности на XFS и ZFS с разными размерами блоков.

GAMer ★★★★★
()
Последнее исправление: GAMer (всего исправлений: 1)
Ответ на: комментарий от Bad_ptr

вообще не так, что ты. У них проблема другая: надо или писать в формат, с которым ты можешь пережить потерю питания, или можешь перематывать.

Экспорт как раз меняет первое во второе.

Дорогие китайские регистраторы - 120 камер на сервер, максимум 500.

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от vbr

Ты цены на память то видел? =)

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

С O_DIRECT кстати всё хуже становится, выкидывается слой из ядра, который склеивает соседние запросы что ли.

max_lapshin ★★★★★
() автор топика

Как отговорить себя от написания своей ФС

Финского спроси. Он отговорит.

anonymous
()

Классический случай: инженер и оптимизация по одному параметру.

Плюсы слоя абстракции на существующей ФС — совместимость со сценариями, которые архитектор ещё не видит:

  • интеграция с другими системами;
  • масштабирование системы горизонтальное и вертикальное, с разделяемыми ресурсами;
  • доступ к данным при авариях.

Например, можно заранее подумать, как будут решаться вопросы архивирования данных с хранения, буде такое понадобится.

все камеры на одном диске держать в одном файле

Но если данные одноразовые и write-only, то и обсуждать нечего!

anonymous
()
Ответ на: комментарий от hobbit

Во все потолки, какие можно было.

И производительность, и количество библиотек, и количество людей и всё прочее.

Когда стало ясно, что прийдется самому руками писать QUIC, тут я слегка устал от эрланга.

О перфомансе вида «принять 10 000 камер» и речи не идет, причем если бы не медленный сторадж, новый код можно поковырять и до 20 тыс (просто это не нужно).

max_lapshin ★★★★★
() автор топика

Захват 10 000 камер на сервер - это прямо скажем серьезный результат, на рынке таких предложений мало.

Кому кроме полиции и спецслужб может понадобиться записывать видеопоток с десяти тысяч камер одновременно на один сервер? Грядет слежка за гражданами невиданного ранее масштаба?

Enthusiast ★★★☆
()

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

einhander ★★★★★
()
Ответ на: комментарий от hobbit

Erlang упёрся в потолок производительности?

Ну очевидно же, что тут Rust ради Rust… (%
Erlang упёрся в отсутствие форсинга в каждую щель.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

но есть нюанс – эти камеры ничерта не видят(низкое разрешение и широкий угол обзора, не говоря про снег/дождь/туман/ночь)

Bad_ptr ★★★★★
()
Последнее исправление: Bad_ptr (всего исправлений: 1)

Что за 38 шпинделей кстати? 38 дисков? Почему они просуммированы? Если они склеены с помощью какого-нить raid0 то его тоже надо выкидывать, раскладывай по дискам в своём софте из предварительно накопленного буфера в памяти.

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

firkax ★★★★★
()
Ответ на: комментарий от max_lapshin

Сейчас на 128 гигабайтах больше 16 гигабит записи на диски тяжело выдавить

«16 гигабит» это 2 гбайт/с? То есть для записи нужно предкеширование на 64 секунды? Сомнительно.

или надо удалить старый файл

А какой толк там что-то точечно удалять? Переиспользовать это место на запись всё равно не получится, оно же сильно фрагментировано будет.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от Bad_ptr

Видят достаточно, по крайней мере в Москве. Сидел я с дядькой, который через 3 месяца после ЧМ 2018 приезжал в ДС из ДС2. На обратном пути его остановили и попросили документы, в доках сказано: Андрей. Сотрудник уточнил: или всё же Артём? Дядька сознался, что Артём и даже корочку СК демонстрировать не стал.

(В розыске был 9 лет.)

BruteForce ★★★★
()
Последнее исправление: BruteForce (всего исправлений: 1)

Вы все технические решения принимаете после консультации с лором? Дайте догадаюсь, erlang использовать вам тоже тут посоветовали? Ну слушайте дальше.

anonymous
()

«Телеком Erlang» 1 вакансия во всей России. «Телеком C++» 108 вакансий. «Телеком Java» - 52.

dynamic_cast
()

Однако трафик записи в 16-17 гигабит на 38 шпинделей - не предел возможности диска, это порядка 420 мегабит, а в теории шпиндель может принять и до 2 000 мегабит.

Принимайте не 25 ккадров в секунду, а один.
Информативность видео от этого не пострадает.
Вам же нужны эти видео, чтобы получить из него некоторую информацию.
Верно?
А качество видео вам и подавно не нужно.

anonymous
()
Ответ на: комментарий от anonymous

сейчас есть append в 4 файла на каждый поток. Т.е. на 10 тыс камер это 40 тыс открытых файлов.

Есть мысль переделать это в 40 открытых файлов, по одному на каждый шпиндель. Но тогда надо как-то следить за аллокацией блоков и по сути получится ФС.

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от anonymous

А качество видео вам и подавно не нужно.

Или всё же нужно?
По сути ведь фотография кажую секунду будет содержать информацию о происходящем событии.
Зачем петабайты видео хранить?

anonymous
()
Ответ на: комментарий от anonymous

Или всё же нужно?

По сути ведь фотография кажую секунду будет содержать информацию о происходящем событии.

Зачем петабайты видео хранить?

А ИИ оживит картинки.
Зато экономия петабайт дискового пространства.

anonymous
()
Ответ на: комментарий от anonymous

А ИИ оживит картинки.

Зато экономия петабайт дискового пространства.

Это было сказано экспромтом. Для размышления.
И не более того.

anonymous
()
Ответ на: комментарий от anonymous

Если серьезно, то во времена mjpeg клиентов завлекали такой темой, чтобы писать четные/нечетные кадры на разные диски. Очень прикольно получается: если что сломается, то потеряешь только fps-ы

Эти времена давно ушли, сейчас mjpeg используется только в профессиональной студийной съёмке и то, когда хочется выпендриваться, а денег мало.

Всё видео идет с межкадровым сжатием, поэтому ты или пишешь всё, или только кейфреймы (а экономии никакой и нет)

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от max_lapshin

Эти времена давно ушли, сейчас mjpeg используется только в профессиональной студийной съёмке и то, когда хочется выпендриваться, а денег мало.

Монохром спасёт петабайты дискового пространства + пару цветных кадров, чтобы ИИ могло раскрасить остальные.
Надеюсь вы не принимаете сказанное за «совет».
Просто об этом говорю, чтобы не быть заангажированным на чём-то одном.

anonymous
()

А делались какие-то оптимизаии на уровне постановки задач записи в очередь? Типа, при ~250 камерах, дающих порядка 2мбит/камера, на шпиндель может оказаться очень много параллельных задач, от чего существующиеиФС/планировщики не очень понимают «как оптимально».

по факту - самое медленное в шпинделе это ждать когда он довернётся до нужного свободного места, это в зависимости от RPM может достигать 4мс (15К-sas)-11мс(ноутбучные диски).

И для избежания этих простоев - задач в NCQ-буфере должно быть не слишком мало, но и не слишком много чтоб не двигать головку слишком часто. В идеале задачи должны быть по продолжительности на единицы мс (скажем 20МБ), но это я так понимаю слишком долго аккумулировать с одной камеры.

Но хотя бы по 15секунд аккумулировать можно? И поддерживать очередь задач «куски по 15 секунд от 8 камер», когда по какой-то камере кусок записан целиком - в очередь на запись кладётся 15 сек кусок от следующей. Что-то такое видится, то есть сво й планировщик очереди, а не своя ФС. Для его реализации хорощо бы реально пониать когда кусок реально достиг блинов, а не полстотушёл в буфер диска, как именно этот реализовать программно - не очень знаю. Так ка идея именно - не слишком много отдельных задач класть в NCQ-буфер

GPFault ★★★★
()
Ответ на: комментарий от anonymous

Мир бы гораздо лучшим местом, если бы решения принимались после консультации с лором.

legolegs ★★★★★
()
Ответ на: комментарий от max_lapshin

сейчас есть append в 4 файла на каждый поток. Т.е. на 10 тыс камер это 40 тыс открытых файлов.

Звучит ужасно. Это целая куча перепозиционирований головок, это очень дорого. Когда я советовал посмотреть на mkv я не шутил - такие медиаконтейнеры созданы для исключения перепозиционирований голов при чтении (и, как следствие, при записи) - потому что должны играться с компакт-диска или по сети, где любой seek это огромная непредсказуемая пауза.

Если не хочется трогать специальные форматы для видеофайлов (почему?) быстрый грязный прототип непрерывной записи без дрыгания головами HDD можно сделать, записывая маленькие файлы-кусочки видео в огромный файл zip или tar и посмотреть, стало ли лучше.

legolegs ★★★★★
()
Ответ на: комментарий от max_lapshin

завод, складской комплекс

Любопытно. Тогда какой смысл заморачиваться с записью и хранением видеозаписей на единственном сервере, что приходится даже свою файловую систему создавать? Можно же в каждом ангаре поставить отдельный сервер с меньшими требованиями к производительности. Кладовщики и рабочие могут украсть сервер или данные, а единственный сервер будет защищен в кабинете директора завода?

Enthusiast ★★★☆
()
Ответ на: комментарий от Enthusiast

Подозреваю, что

в каждом ангаре поставить отдельный сервер

будет сильно дороже.

ugoday ★★★★★
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария